WSO2Con 2011: High Volume Web API Management with WSO2 ESB - Paul Fremantle & Hiranya Jayathilaka

Archived Content
This article is provided for historical perspective only, and may not reflect current conditions. Please refer to relevant product page for more up-to-date product information and resources.
  • By WSO2Con 2011
  • 12 Dec, 2011

Common API Management Headaches

There has been a great deal of interest from IT professionals in how to manage API traffic, especially when enterprises make APIs available to third-parties on the Web, Paul observed; ““It’s a big business change for them, and they really want to know, ‘How is my API being used?’”

Some of the factors these professionals need to consider are traffic shaping, monitoring, mediation, load balancing, and stack unification—all of which can affect how effectively API traffic is being managed.

Traffic Shaping and Load Balancing

One of the most common challenges is the effect of a slow client or denial of service (DNS) attack on traffic, Paul noted. A slow client with a slow connection burdens a high-speed system by soaking up time buffering data; there are no bytes ready to read from the TCP stack. In contrast, a deliberate DNS attack attempts to clog the system by pushing through thousands of concurrent connections.

ESB capabilities that can help manage traffic shaping include:

  • Non-blocking transport, which essentially soaks up connections without soaking up threads.
  • Throttling and caching, which make it possible to limit the number of connections to the back-end that a particular IP address can create, as well as limit CPU power used by the ESB.
  • Priority execution, which ensures that when the system is heavily loaded, important transactions will get through before others.

At the same time, load balancing can be used to help ensure that a Web API is consistently accessible and available. Paul noted that WSO2 ESB enables users to change plug-ins to configure the load-balancing algorithm, and elastic load balancing can spin out ESB instances in the cloud to handle extra loads. A newer session-aware load-balancing feature in WSO2 looks at things like cookies or the XML headers and uses those details to balance the load and ensure that a client keeps going back to the same machine.

Monitoring, Analytics and Metrics

Another factor is the use of monitoring, analytics and metrics for Web API management. Low-level monitoring and metrics show the system administrator if connections are stacking up on the server, Paul explained. Administrators also can see if they will start having a loss of service because of thousands open connections are slowing the system.

For example, WSO2 ESB offers JMX monitoring of the number of connections, endpoints and latencies so administrators can see what the overhead is within the ESB and what is happening with the listeners, memory and garbage collection.

Paul recommended three different ways to configure the ESB to support monitoring: through the admin screens, through the Eclipse plug-in, or raw XML. This provides important flexibility to system administrators and infrastructure specialists who are interested in monitoring and managing Web API traffic.

Transformation and Micro-Orchestration for Mobile Apps

Paul noted that for a lot of API traffic, there is no need for an ESB to actually look at the message, and an ESB should support this use case. However, there are scenarios where enterprises will need to translate messages from their existing SOAP format, particularly when they are building mobile applications. For instance, iPhone and Android developers want a simple interface, he explained, and they often build mobile applications using RESTful services and the JSON data interchange format.

WSO2 ESB provides transformation from SOAP to JSON or other formats, and it has a service-chaining model that enables lightweight asynchronous orchestration, so a device query is run as a service chain.

“What I’m doing is saving the iPhone app from having to make multiple network calls over what may be an unreliable or slow network,” Paul explained. “I’m doing all that work on their behalf, gathering data in portions and producing a consolidated API.”

Unification of multiple stacks

Paul also stressed that an API should be presented as a unified interface. He noted that users should not have to be exposed to the fact that some parts of an API are handled by an Oracle server while other parts are handled by a Sun server or WSO2 Application Services Server. By proxying the API through a central place, it is possible to hide these details and present a unified interface.

“We see the API space as an area to improve, and we believe we have the right core components,” Paul said. “But the question is, can we make it more consumable to people just focused this area? What can we do to help people? We are effectively looking for earlier adopter customers who are interested in using the ESB in this space to help us kind of tune it more toward API management.”

To learn more about best practices for high volume Web API management and configuring ESBs for high volume, view Paul and Hiranya’s full presentation here.

About Author

  • WSO2Con 2011
  • Sri Lanka