Conceptual curve

A new front for SOA: Open API and API management as a game changer – Part II

Kai Wähner

The continuation of our deep dive into Open Api – taking a look at the management products.

This is a continuation of Kai Wähner’s article “A new front
for SOA: Open API and API management as a game changer” – part
one is over here


API Management solutions
have to scale. Unlike internal service calls in a SOA, public APIs
have other requirements: Service consumers are not known, SLAs
differ, and the number of service calls depends on success of
external partners and can increase quickly and significantly.
Therefore, an API Management solution has to ensure different
scalability aspects:

  • No single-point-of-failure
  • Multiple instances of a gateway can be deployed across multiple
  • Can be scaled dynamically to address peak demand
  • Can be deployed across data centers for geo-resilience
  • Allow caching to improve performance
  • Gateways report availability to load-balancer
  • Centralized logging of distributed deployments
  • Infrastructure can be monitored by existing agents and

Policy based Service Delivery

The service delivery of open APIs has to be policy based.
Depending on the use case, many of the following policy aspects
have to be managed in a flexible, configurable way:

Authentication and Authorization

  • Access control granularity down to service endpoint or
  • Single-edit configuration changes through web user

Throttle Capabilities

  • Rate & high-water mark technical throttles designed to
    protect particular service implementations
  • Quota commercial throttle designed to prevent commercial
    over-use of services (e.g. wholesale usage)
  • Time-of-day throttle behavior down during known busy periods or
  • Error-rate/ payload-size technical throttles designed to
    minimize impact of external parties
  • Group logical throttle to help manage large partners, large
    service deployments

Routing Capabilities

  • By operation: Routing based on the
    requested service, such as a SOAPAction or URL string
  • By requestor: Routing based on the name,
    type or class of requesting-device
  • By version: Version routings can be used
    to support multiple concurrent versions of a service or a service
  • By protocol: Routing can be used to
    safely abstraction requests bi-directionally
  • Time-of-day routing to difference
    services (explicitly, orchestrations)
  • By identity: Different partners’ and
    consumers’ can be routed to different services
  • By size: For some requests (e.g. with
    attachments), requests can be routed by size to appropriate service


Different roles have to be defined for Open API. API consumers
represent partners and external developers while API providers can
be developers, administrators, or partner managers. Let’s take a
look at the functions each role has to accomplish:

  • Developers
  • Provide a catalog for organizing and publishing APIs
  • Supply a repository for documentation, sample code, usage
  • Create product options and support plans
  • Provide REST and SOAP service interoperability
  • Monitor and report on API usage and performance
  • Administrators
  • Manage environments and developer accounts
  • Set access rights by user or organization
  • Configure deployment policies for APIs
  • Partner Managers
  • Partner onboarding
  • Community management
  • API Consumers
  • Discover and use APIs
  • Use a self-service portal for enrollment, key requests, and API
  • Select product options and support plans
  • Monitor and report on API consumption


Different kinds of API Management solutions are available on the
market. More are arising year by year. Analysts such as Gartner and
Forrester see Open API as a hot topic for future IT investments and
growing revenue.

Let’s recap from above: To realize an Open API solution, you
need three components:

  1. A portal (used by API providers to offer
    API products and by API consumers to use them)
  2. A gateway (configured by API
  3. An analytics tool (used by providers and
    consumers) to react to feedback, usage and other events

Some vendors offer all these components. Others just offer some
of these features. On the one side, there are some vendors “just”
offering a portal to publish existing APIs and manage payment /
billing. On the other side, there are vendors, which offer a total
solution for building services, making them public (including
billing), and analytics for improving your services. In between,
some vendors offer something “in the middle”.

To make the right selection of an API Management product, you
have to think about your requirements and then evaluate
corresponding products available on the market. An overview or
extensive comparison of different vendors would push boundaries of
this article. Though, the next two sections give a short overview
about questions you should concern before making a selection, and a
short overview of some available API Management products.

Selection Criteria

Vendors differ a lot regarding their API Management offerings.
Ask yourself the following questions, decide what you need, and
evaluate corresponding vendors with regard to:
  • Do you just want to build a directory for your existing
    service, or do you want a real infrastructure for building,
    governing, deploying, and managing your services?
  • Do you just want to publish REST services, or do you also want
    / have to make other service protocols such as SOAP or JMS
  • Do you need a flexible configuration and routing options using
    different security standards (e.g. LDAP, SAML, Kerberos, OAuth,
    WS-*, XACML, etc.)?
  • Do you need an elastic highly scalable architecture for
    millions of messages (based on event driven architecture instead of
    synchronous HTTP calls)?
  • Do you need to extend the portal to your needs (regarding
    topics such as service management, developer portal,
  • Do you want to leverage other products of the same vendor (e.g.
    products for integration, mapping, transformation, routing,
    business processes, complex event processing, etc.)?
  • Do you want to deploy your API Management solution on premise
    or in the cloud? If in the cloud, is virtualization through VMs
    fine for you, or do you want a real, i.e. elastic, cloud
  • Do you want a hardware appliance or just software? Is it
    required to configure your API engine for running in your DMZ on
    existing servers?

The products

Available products differ a lot in functionality and maturity. A
more detailed evaluation is required to make the right decision for
your use case. The following is just a short overview of different
vendors, which offer API Management solutions (but not a complete

Apigee offers a complete API Platform.
As the company’s name states, Apigee is focused especially on API
Management. The solution is designed to meet the challenges of the
new mobile, social, cloud marketplace head-on. Users can start with
a (very limited) free version.

Mashery is another solution focused
especially on API Management. It was born out of the Web mashup
movement of the 2000’s, hence its name. However, Intel Corporation
acquired it in 2013. Mashery offers a very affordable and easy to
use cloud solution to publish existing APIs. Thus, it is good for
simple scenarios. Users can start with a (limited) free

Layer7 has deep roots in the XML gateway
market and offers many advanced routing and security features. It
has extended its product portfolio to API Management. The solution
is very powerful, but therefore very good technical knowledge is

TIBCO provides a comprehensive
operating platform called API Exchange, which lets you build and
test APIs, define runtime governance policies, migrate APIs between
environments, and monitor and report on API usage. TIBCO API
Exchange leverages other TIBCO products to combine ESB, BPM, CEP,
etc. with its API Management solution. TIBCO’s products focus on
complex enterprise scenarios.

IBM is also focused on complex
enterprise scenarios and has different powerful API Management
solutions in its portfolio, for example IBM API Management,
DataPower XML gateway, Cast Iron Live Web API Services, and

Several further vendors offer API Management solutions. Some of
the most visible ones are Vordel andApiphany, acquired by Microsoft recently,
focusing especially on API Management while Software AG andOracle are examples for other big software
vendors which offer not just API Management, but solutions for the
whole integration portfolio.

MuleSoft and WSO2 are two open source Enterprise Service Bus
vendors, which also included API Management solutions in their


Open API and API Management represent the leading edge of a new
business model. 

Enterprises have very good opportunities to increase revenue,
reduce costs and improve efficiency by publishing and monetizing
internal services to external consumers via API Management
solutions. Many API Management solutions are available on the

Their functionality differs a lot. The products are still young
and have to improve in the next months and years – but they are
already mature enough for getting started to innovate in creating
new business models and increasing revenue. Open API and API
Management have a great future!

comments powered by Disqus