[Based on a post originally appearing at http://asanka.abeysinghe.org/2013/04/pragmatic-approach-to-api-facade-pattern.html.]
Business APIs expose business functionality for access by external and internal consumers. In technical terms APIs provide an abstract layer for the internal business services to cater to consumer demand.
Most service platforms are not ready-made to safely and cleanly expose internal services to consumers, posing a common challenge for API providers. Providing a pragmatic approach to the well-known API Façade pattern is the motivation of writing this post.
Facades hide the complexity of internal implementations and provide simple interfaces. This is a common pattern in computer science but we can even find it in real world too. Lets look at a real world example first: if you walk to a shoe store you find samples displayed in a manner making them easy to pick and select, but if you walk to the back of the store you will find a massive warehouse with millions of shoes that will not provide an easy way find the correct shoe for you. What does the showroom do? It provides a facade that displays the shoes in a way that helps buyers select and buy the shoes they want, thereby reducing the complexity and enhancing the buying experience.
Similarly, facades used in computer systems hide complexity and provide a better experience for the consumers (demand).
Lets look at how Façade pattern applies for API Management. There is a clear gap between the consumer demand for APIs and the internal services available in each enterprise. As an example, consumers look for Web APIs that can access using REST principles, deliver content using JSON and secured by OAuth addition to that the APIs can be externally accessible and discover. This may map to an authenticated XML/SOAP based service within the enterprise.
API Façade patterns mainly contains four functional layers:
1. Backend services
4. External format / Demand
Most commercial API Management solutions treat the Mediation, Façade and Demand as a single functional, architecture as well as deployment layer.
If we look at the gap between backend services and the Demand, can a lightweight mediation layer with limited service bindings such as HTTP/s, JMS can build a business API? Are you willing to add the resulting additional wrapper service layer and maintain it?
WSO2 recommends more pragmatic approach by recommending dividing the Façade layer and Mediation layer into clear functional, architecture and deployment layers.
This architecture can facilitate heavy mediation including service chaining/orchestration to provide a business friendly API for the consumers. This also allows one to do a clean deployment by inheriting the infrastructure policies appropriate for each layer, as well as scale each architecture layer separately.
Implementation of WSO2 API Façade is facilitated by using the WSO2 API Manager to build the Demand and Façade layers, the WSO2 ESB to build the Mediation layer (also add in products like the WSO2 Business Process Server if required) and connect to the existing services. If you are planning to write new set of backend services using standards such as JAX-WS, JAX-RS you can use the WSO2 Application Server as a runtime. In addition to that if there are any other business/technical requirements to build new business APIs you can add them with or after the mediation layer by leveraging the 17+ products in the WSO2 Middleware Platform.
This pragmatic and architecturally rich approach of WSO2 API Façade pattern results many benefits for the API management solutions:
- Clean architecture by separating the concerns
- Have a clear separation of internal and external processing of an API call
- Ability to scale based on the actual usage of each layer
- Avoid implementing new services or building wrapper service layers
- Leverage SOA principles with the new Web API architecture
- Utilize the middleware and go to market quickly
Having said that if you are planning to have a single layer to facilitate all three layers of API Façade, there are no technical limitations in WSO2 API Management Platform to doing that. You can build the mediation by configuring the pre-configured ESB running as the internal dispatching engine of API Gateway. However for a real-world deployment we recommend that you consider using the flexible, componentized nature of the WSO2 platform to build a clean, scalable, manageable WSO2 API Façade. In my next post I’ll talk more about how to implement this pattern using WSO2 technologies.
Vice President of Solutions Architecture