Defining a Generic API

With a premium placed on loose coupling, a typical SOA deployment displays a high degree of heterogeneity. Different service platforms run in scattered datacenters on a variety of server hardware, operating systems, and development platforms. The services expose different communication and security standards. Individual SOA implementation and maintenance teams will become acclimated to the level of heterogeneity with exposure to the environment, but when an external or internal consumer tries to access the SOA, they will come face to face with this complexity.

image

A common way to simplify and normalize interactions with a heterogeneous environment is to provide a unified API for service consumers — a unified, generic service layer.

One of our commercial bank customers with multiple service platforms began a project of defining a unified services layer, generalizing the the multiple service platforms active in the bank. At first they approached the problem in the traditional way: writing wrapper/proxy services in front of each of the existing services.  As part of an engagement with WSO2 they changed to a “Generic API” solution pattern which dramatically simplified the project by hiding the internal complexity of each service behind a user friendly API, a common URL for service access, and unified security policies.

The “Generic API” pattern installs a common API for the existing service infrastructure, converts traditional applications to services exposed over a normalized set of communication and security protocols, and provides a foundation supporting the easy addition of future service platforms.

image

When implemented with WSO2 products, the Generic API pattern leverages the WSO2 Enterprise Service Bus (ESB) and WSO2 Governance Registry. The WSO2 ESB connects with the back-end service layers and legacy applications, and exposes them through a new service layer.  This is easily accomplished with the proxy service capability of the WSO2 ESB.  Supporting a wide variety of of the transports and message formats, the WSO2 ESB provides a central hub for protocol switching and security mediation between the heterogeneous systems.

With sophisticated transformation capabilities, the WSO2 ESB extends the Generic API pattern to the problem of unifying data models, by converting or mapping messages representing different data models into a common and easily consumed model.

Storing and publishing common metadata such as service descriptions and policies describing the generic API also aids new developers interacting with the system.  In the deployment above, the WSO2 Governance Registry provides a common repository for storing and sharing all the necessary SOA artifacts.

The Generic API pattern provides the foundation for other other solution patterns as well.  In future posts we’ll discuss solution architectures for a Public Services Gateway and an Internal Services Gateway pattern.

Asanka Abeysinghe, Director of Solutions Architecture
Asanka’s blog: http://asanka.abeysinghe.org/

2 thoughts on “Defining a Generic API”

    1. Generic API should design based on your internal and external business consumers of the API.
      Yes, exposing APIs for industry standards is one use-case, that will allow you to transform your internal datamodels into standard datamodels. Addition to that generic API helps you to hide the complexity of the internal APIs used.

Comments are closed.