Social SOA with API Gateway

In a recent conversation with a large customer of ours, some interesting facts came to light. This blog is a recapitulation of the insights I got from that discussion. I’ll not only tell you how this customer is using our solution, but also, how it is helping them to take their online presence to the proverbial next level.

Our customer, an online university, is using our solution, as middleware – providing both security and data mediation functions, to push through SOAP & REST API transactions to the backend. They are processing about 18 million messages per day. Now think about that for a second. The number in itself is mind staggering. While most educational institutions use freeware middleware solutions due to being part of an ultra cost-conscious milieu, this University decided to use our solution to bring their presence to a whole new level – while still doing so in a completely cost effective fashion.

We also helped the University integrate with a home grown single sign-on solution fairly easily so they would not be forced to “rip and replace” all of their technology, unlike some of the implementation plans that would be thrust upon them by some of our competitors. We integrate with identity management systems, as well solutions that address governance, various registries ,and an array of monitoring solutions. For us, it’s never about pushing an entire stack to a customer. Instead we feel customers should have the latitude to choose a technology from a range of available options, consistent with a “best of breed approach.”

Though it initially started off as more of an academic security experiment for a University, our solution has been embraced much more widely and has grown into a solution that encompasses SSL offloading, XSLT transformation, service aggregation, and service mediation. In addition, our solution is being used to abstract the authentication layer to communicate with a custom authentication service. We provide the backbone of their social SOA.

The initial services were mostly SOAP based, however, when the REST services were ready — we were ready too, to help them out with a product that similarly could address all of the same relevant security concerns.

The true reason everyone is excited, though, is because the University is looking to move their service offerings to the cloud. At first glance, moving all your services (or even just a service abstraction layer) to the cloud and exposing that 24×7 to hackers can be quite the daunting task! Another concern revolves around their customers’ resource utilization. Especially when you are offering your services for free (at least most of the time,) if you expose those services without throttling them, can be asking for a lot of trouble. Rest assured — Intel has a feature built in our solution set that will help them with both their security concerns and their ability to implement throttling .

Our Quality of Service (QOS) functionality allows service providers to limit the usage of services, a classic need in a cloud delivery model which is often overlooked due to the perception about the elasticity of the cloud. In my mind, just because you can throw resources without any limit – ignoring fundamental architecture design principles such as TOGAF, DoDAF, Zachman – should be a huge concern, and “top of mind” for everyone. While you can implement some of these functions at the application/services level, , a lot of overhead will be added to the application itself. Moreover, here will be no uniformity across applications on how this feature is implemented.

If, on the other hand, you were to use our QOS functionality – you can monitor API usage, meter the usage based on the identity of the user (technically, not only based on the identity, but you can even go lower than that. Think more along the lines of something location + identity + invocation based).

You not only can limit the service usage based on predefined policies, but you can enforce those policies globally. Our solution provides for the ability for a backend application to recover in case of overload. This built-in “self healing” feature should allow many services to recover without a need to bounce / reboot often. And the built-in auditing, reporting, logging tool keeps extensive details so it can be used not only for a forensic analysis, should the need arise, but also when implementing a charge back system if so desired.


About Andy Thurai
This blog is published by Andy Thurai, Program Director - API Economy, IoT, Connected cloud solutions with IBM. The views expressed here are my own and not of my employer. Please feel free to comment or engage in a stimulating conversation, but please keep it professional. I can be reached via the “Contact Me” page here. You can also find me on LinkedIn or on Twitter @AndyThurai

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: