One of the niceties of mainframes was the simplicity of a single API for the users. After years of evolution towards a decentralized model we still find this pattern appearing, even among SOA implementations that span many subsystems and service platforms.
Presenting entire subsystems, which may include legacy systems, databases, and internal and external services as a single unified API makes integration easier for a partner (further decoupling detailed knowledge of the subsystems), and is increasingly used for internal users such as business processes, business rules and mashups. A unified API hides a variety of transports and systems behind a single, consistent, API.
With the introduction of unified API, API management and monitoring becomes an important factor. Different formats and protocols like SOAP/HTTP, JSON, XML/HTTP, JMS can be exposed across the range of services. A centralized configuration change at the ESB layer enables different protocols or enables QoS features across the API. Features such as usability, the security, governance can be managed in a single location, as can enterprise features like scalability and high-availability. Monitoring provides a single point for assessing the usage and health of the system.
As I described in my previous posts, the WSO2 Enterprise Service Bus (ESB) provides the a simple yet powerful and highly performant system upon which to implement a unified API and select the various QoS characteristics. WSO2 ESB supports all the popular security standards required for integration and leverages WSO2 Carbon clustering features for scalability and high-availability out of the box.
The WSO2 Governance Registry builds the required governance framework for the unified API by providing a repository for policies and API metadata – even for API documentation – and adds the ability to share, version, analyze dependencies and policy conformance, and manage lifecycles of this metadata. The WSO2 Governance Registry helps you define the and manage the QoS of your API, and works in conjunction with the ESB to assess and enforce the defined policies.
Monitoring – a key part of runtime governance – is accomplished by deploying the WSO2 Business Activity Monitor (BAM) to collect, summarize, and report on the API usage. Or you can use the JMX support in the WSO2 ESB and other WSO2 Carbon products to tie into third-party monitoring tools.
Certain services need to go beyond simple monitoring. When we looked at the business requirements of our API management customers, billing and metering, isolated runtimes for specific consumers/consumer groups, as well as customization or overriding of the API for specific consumers emerged. We have found multi-tenancy to be a powerful answer for those requirements, and is available in the WSO2 cloud platform, WSO2 Stratos. With WSO2 Stratos you can easily expose your API in the cloud or as part of the SaaS offerings you provide.
In summary, both essential and extended features for API implementation and management are provided by WSO2 middleware platform, making it a great choice for meeting both your business and technical requirements.
Asanka Abeysinghe, Director of Solutions Architecture
Asanka’s blog: http://asanka.abeysinghe.org/