[Article] The Benefits of Exposing Microservices in WSO2 API Manager

  • By Chamin Dias
  • |
  • 5 Oct, 2016

Table of contents

Applies to

WSO2 API Manager Version 2.0 and above
WSO2 Microservices Framework for Java Version 2.o and above


WSO2 API Manager is a fully open source solution for managing all aspects of APIs including creating, publishing, and exposing APIs to users. In addition, it has the capability of exposing microservices as APIs. Hence, users of WSO2 API Manager can now use its available functionalities to expose microservices in a secure, scalable, and user-friendly manner.

Brief overview of microservices

In today’s agile enterprises, microservices are attracting the interest of architects and developers who need to ensure continuous, agile delivery and flexible deployment of complex, service-oriented applications. In simple terms, microservices are small parts with big advantages for enterprise applications. MSA provides a mechanism to develop applications as a collection of independent, lightweight, scalable, and deployable services. This architecture can provide suitable solutions, especially for the web services arena.

The core idea behind microservices is maintaining simple, composable software components that work together. In other words, it is a way of breaking large software projects into smaller, independent, and loosely coupled modules. Each individual module has a well-defined task and provides services through APIs. This model has various advantages over traditional, monolithic application development methods.

Since most microservices provide an API endpoint that can be accessed over HTTP/HTTPS just like a standard web page, it makes it easier to consume these microservices with already available tools.

Let’s have a quick look at some advantages of MSA.

Microservices are much easier to understand when compared to monolithic applications since a particular microservice does only a well-defined, specific task. It improves fault isolation as well. It will be easier to modify, maintain, scale, and even throw away services. Moreover, this architecture enables the use of best technology for each task instead of using a single technology that can address all requirements. If MSA is used, system resources are utilized in a more effective and efficient manner. When it comes to event-driven computing in cloud services, microservices can play a major role.

WSO2’s answer to managing microservices

This section will provide a brief overview of WSO2 Microservices Framework for Java (MSF4J).

MSF4J is a free and open source solution for managing microservices. With the help of MSF4J, microservice developers can quickly get started with developing and running Java microservices. MSF4J is created with certain design goals including high performance, low latency, and low memory consumption. It’s a developer friendly programming model for developing and running Java microservices.

Some key features of MSF4J include

  1. Lightweight, fast runtime
  2. Simple development, deployment, and monitoring
  3. High scalability and reliability
  4. Integrated security

Refer the official documentation of WSO2 MSF4J to find out more information about the product. Visit the product page of WSO2 MSF4J to download the product. The performance benchmark for WSO2 MSF4J is available in the GitHub repository as well.

Exposing microservices in WSO2 API Manager

Microservices can be exposed as APIs using WSO2 API Manager. This will enable many facilities to microservices providers that will make their life easier. Figure 1 depicts a high-level overview of this model.

Microservice developers can develop their microservices and they can host it in a certain place (i.e a server). As mentioned in a previous section, WSO2 provides a solution to microservices developers as well. They can use ​WSO2 MSF4J as they wish and make their lives easier when developing and managing microservices.

Figure 1: High-level architecture of exposing microservices in WSO2 API Manager

Once the microservice is hosted, we can use WSO2 API Manager to expose the service to the outside world. To expose the microservice as an API, we only need to specify the service URL of the microservice as the production endpoint when creating an API. If there is a need to use the microservice for testing purposes, we need to include it as the sandbox endpoint of the API.

When the required APIs are created, with the corresponding microservices, users can start using the service via the API. According to Figure 1, consumers can “talk” to the API manager server and consume the microservice. Basically, these APIs are interfaces that serve as contracts between API producers and consumers.

When providing a service to consumers, it’s important to have a contract between service providers and end users while having a mechanism to manage the contract. Hence, there is a need to deal with the data and business logic based on the specifications in the contract. This is one of the most difficult tasks when it comes to providing services to consumers. In the recent past, the number of devices, applications, and users who consume these services have increased rapidly. As a result, new challenges have emerged in enterprise IT (e.g. security issues, user management, monitoring, etc). These challenges are common when exposing microservices as well (with an increase in the consumer base). Therefore, a key requirement is a solution that can address these new challenges and manage complex scenarios when exposing microservices to end users. WSO2 API Manager can be leveraged to do this; it helps to expose microservices as APIs to internal and external parties in a scalable and user-friendly manner.

Creating an API to expose a Microservice

As mentioned earlier, we need an API in WSO2 API Manager to expose the microservice.

When creating the API, API creators can specify the resources based on the services provided by the API. Those resources can be categorized under the corresponding HTTP verb. Parameters can be specified for each resource as well.

Figure 2: Specify the resources based on the services provided by the API/microservice

Figure 3: Adding parameters to resources

API creators need to specify the microservice URL at the API implementation stage. They can specify it as the production endpoint (for production usage) or sandbox endpoint (for testing purposes).

Figure 4: Production and sandbox endpoints

Once the API is published, it will appear in the API Store. API consumers can create applications and subscribe to APIs to consume the microservice through the published API. Based on the need, consumers can generate production or sandbox keys for their application. If the subscription and key generation are successful, consumers can invoke the API (to consume the exposed microservice) using the integrated API console or any other tool, such as cURL, advanced REST client, or postman. They can use the generated access token for this action.

Figure 5: Microservice as an API (view in API Store)

Figure 6: Generating production and sandbox keys to consume microservice

Figure 7: In-built try out tools to consume microservices

Please find more information in the official documentation about creating an API, subscribing to an API, and invoking an API.

Benefits of exposing microservices in WSO2 API Manager

Exposing microservices in WSO2 API Manager has a host of advantages. Let’s have a closer look at these benefits.

Design and deployment flexibility

Microservice providers/developers can use WSO2 API Manager to design APIs in a flexible manner while fulfilling their business needs. They can deploy a prototyped API and provide early access to APIs. This allows them to get early feedback about the exposed microservices before migrating to production. At the same time, WSO2 API Manager allows to write and use custom handlers for each API that exposes microservices so that it can be used to enable required functions. Moreover, WSO2 API Manager provides a role-based access control mechanism for managing users and their authorization levels. Hence, WSO2 API Manager offers a user-friendly interface with all required facilities to expose microservices as fully functional, well-defined APIs.

Consumer community management and consuming services

When managing the consumer community of microservices, the API Manager Store web interface might be helpful. It’s capable of exposing the services to the outside world (i.e. consumers) while providing user-friendly dashboards. Users can register themselves using the self-signup feature in the API Store and start developing applications to consume the microservices. Since microservices are exposed as APIs, consumers can search APIs that they need to use.

Once they have found the relevant APIs, they can register applications and subscribe to those APIs. WSO2 API Manager’s API Store has built in try-out tools so consumers can observe the responses of each microservice. It also facilitates the invoking of APIs (in this context it’s a microservice) via third-party tools, such as cURL or advanced REST client. Moreover, consumers can discuss their ideas about the service in embedded forums and rate each API that exposes a microservice.

Security and access control

Security is one of the main concerns in any solution that provides any kind of service. If the microservice is exposed in WSO2 API Manager, service providers do not have to worry about the security of microservices. WSO2 API Manager can handle it on behalf of the microservice providers.

Key manager in WSO2 API Manager mainly handles security aspects. It can issue access tokens to consumers who wish to consume microservices via the API manager. Moreover, it can keep track of the lifetime of those access tokens and allow/block requests. By default, the key manager is powered with OAuth2 security protocols. Moreover, it can be configured to use other security protocols based on the requirement (extendability). In addition, it can handle more advanced scenarios, such as authenticating via Facebook or Google accounts. This helps to consume microservices easily since it allows users to use their existing Facebook or Google accounts (many service providers follow this strategy to their consumers nowadays).

WSO2 API Manager is empowered with an advanced access control mechanism as well. Hence, it can be used to block a subscription (related to a particular microservice API) and restrict a complete application. Restricting API access tokens to domains/IPs is also possible. To ensure more control over the APIs (that expose microservices), it can associate the API to system-defined service tiers so it helps to expose the microservices for complex scenarios.

Monitoring and analyzing

When microservices are exposed via WSO2 API Manager, monitoring service usage is easy. It can be configured with WSO2 API Manager analytics to enable monitoring. Requests, responses, faults, throttling, subscriptions, self-sign ups and latency breakdown are a few of the areas covered in this model. Both graphs and tabular representations are included based on the scenario. With WSO2 API Manager analytics, service providers can analyze how the exposed microservices are used and make decisions based on the usage requirements. In addition, the API manager analytics model supports real-time analysis as well. Log analyzer and alerts are the main parts of the real-time analysis model. Hence, it enables service providers to keep an eye on how the microservices are used at that given time. At the same time, service providers can configure payment schemes to monetize API (that expose microservices) usage.

Managing traffic, protecting backends

Since microservices are lightweight services, it’s important to expose the service endpoints (i.e. backends) in a controlled manner. High traffic (i.e. high hit count for a given time duration) might be a reason for backend failures. Hence, it’s important to manage traffic in an effective manner. If the microservice is exposed using WSO2 API Manager, it makes sure that only the allowed requests will consume the service provided at the backend.

When it comes to managing API traffic, API gateway is the major actor. The API gateway hosts the runtime. It sits as a proxy to the backend (i.e. microservice) and intercepts all requests that come from the consumers. The API gateway has the capability to perform message mediation and message transformation that will facilitate to convert the messages (i.e. requests/responses) to a format supported by the backend or client.

The API gateway can perform response caching as well. This will be useful to reduce the load/number of hits to the backend (i.e. microservice). More interesting information on this can be found in the official documentation as well.

Enforcing service policies

Microservice providers will need to apply different policies when exposing microservices to end users. With the integration of WSO2 API Manager to expose microservices, users can have a hassle-free mechanism to enforce service policies based on their business needs. WSO2 API Manager is now empowered with an advanced throttling feature that can regulate traffic according to infrastructure availability, protect APIs from common types of security attacks, and make an API, application or a resource available to a consumer at different levels of service. On the other hand, WSO2 API Manager has the ability to engage multiple throttling policies to a single API, so that an API that exposes a microservice can have multi-layer throttling. If there is a need to define dynamic rules for specific use cases, custom throttling in WSO2 API Manager will be helpful to manage APIs that expose microservices. An overview of this throttling feature is included in this WSO2 library article. Deeper technical information and how to enable throttling is included in the WSO2 API Manager official documentation as well.

Extension points

In addition to the above advantages, we can use the extensions points in the API manager to offer a better user experience while having a systematic control mechanism for exposing microservices. Some of these extension points are mediation extensions, security extensions, workflow extensions, and API lifecycle extensions. For example, if there is a need to create a workflow for application creation, API subscription or user signup, we can use the “workflow extensions” in WSO2 API Manager with WSO2 Business Process Server. This strategy will provide an option to administrators to review user sign ups and API subscriptions and allow/block them depending on the need. Hence, it ensures that only the permitted users/application are consuming the microservices exposed via the API manager.


This article focused on how WSO2 API Manager can be used to expose microservices as APIs. Since WSO2 API Manager is a complete, enterprise-ready solution for managing APIs across the complete API lifecycle, microservices providers can use it to expose microservices in a secure, scalable, and user-friendly manner. It further explained the major benefits of exposing microservices in WSO2 API Manager with related concepts.



About Author

  • Chamin Dias
  • Senior Software Engineer
  • WSO2