In essence, the API Middleware layer plays a similar role as middleware plays in other IT solutions. It sits between the client level and the systems of record, translating the desires of the client into execution within the core systems of record.
Typical roles of the API Middleware layer are:
In some API architecture implementations, the API Middleware layer is fairly minimal. This is the case for example where the ‘back-end’ systems of record are already packaged as programmable services, perhaps accessed through RESTful interfaces. Indeed, for these simpler environments a generic layer of API Middleware is sufficient to meet most needs, and for this reason it is common for API Management tools such as Apigee API Management, IBM API Connect, Red Hat 3Scale and CA API Management to include a generic subset of API Middleware in their offerings. This generic layer typically supports simple web service and SOAP calls and sometimes provides some limited level of orchestration support.
However, for mainframe users the API Middleware layer is absolutely key. Many applications, services and processes will not be available through a simple call interface. A mainframe-specific layer will be needed to handle all the complicated mainframe-specific resources like 3270 applications, CICS and IMS transactions, mainframe databases and corporate systems of record processes. This mainframe specific layer of API Middleware, will be critical for delivering a successful API-enabled environment while mitigating the inherent risk. The diagram below indicates how the mainframe-specific API tools such as GT Software Ivory and IBM z/OS Connect relate to the generic API Management tools mentioned above in terms of the basic architecture.
-Steve Craggs, Lustratus Research
Want to find out more about API integration? Download the complete ebook from Lustratus Research.