Several years into the era of APIs and still one of the most common points of confusion is the positioning of APIs and Services (and Microservices) and the positioning of an Enterprise Service Bus (ESB) and API Management solution. Many see the similarities between an ESB and API Management – technologies supported such as REST and SOAP, some commonality in integration capability, and believe that one can play the part of the other. This is not the case.
Previously I have addressed the positioning of APIs, Services, and Microservices in both video and blog formats:
Please take a look at one of these if this is still an issue you find confusing.
Today I will begin to take on positioning of ESBs and API Management. I plan to do this in two parts. In this blog I will discuss what an API Management solution provides beyond what is supplied in an ESB. Of course there are capabilities in an ESB that are not in API Management as well. In part two I will explore whether it is a good idea to combine the capabilities into a single product or construct in the architecture.
Let’s start by taking a look at what is causing the confusion. Can an ESB expose a REST interface? The answer is “Yes”. Almost every ESB today can expose REST or SOAP interfaces to a consumer and transform/map this to one or more service calls in the Systems of Record (SoR) returning a response to the called interface in JSON, for example. Since REST/JSON is closely associated with API Management, there is similarity and confusion. If the creation of a REST API interface were the only thing that an API Management solution provided then an ESB would be sufficient. But, this is not the case.
So, what else does an API Management solution provide that is not provided by an ESB? Here are just some of the high level additional capabilities provided:
On top of all these capabilities it should also be noted that an ESB is not the only technology inside or outside the enterprise that can create a REST interface. Other technologies such as application servers (e.g. WebSphere Application Server), packaged applications (e.g. SAP), SaaS applications (e.g. Salesforce), and Mainframe transaction systems through z/OS Connect can all surface REST interfaces. All of these REST interfaces can be brought into an API Management solution (such as IBM’s API Connect) for the advantages it provides in enabling the simple and secure consumption of the APIs.
Finally, let’s discuss Governance. An ESB is a central component of an SOA architecture connecting back end SoR together. The ESB
is in effect part of the SoR, coordinating transactions across applications and ensuring data is in sync. The ESB may also contain business logic or other programming to fulfill its purpose. Changes to ESB connectivity flows are governed strongly as are changes to the SoR itself to ensure these changes do not cause problems with the systems running the business. API Management on the other hand requires a lighter weight governance to meet the need for speed. (IBM has been referring to this as “
two-speed IT” for several years.) APIs do not contain business logic and are not part of the SoR. They simply expose SoR data and transactions for simple, secure and controlled consumption.
See part 2 of this discussion, “
Is a Combined ESB and API Management a Good Idea?”
To understand more about IBM’s thoughts on the API Economy visit the IBM
API Economy website. IBM API Connect is IBM’s complete foundation to Create, Run, Manage, and Secure APIs. You can find more information about IBM API Connect at the
API Connect website. And you can also experience a
trial version of API Connect.
If you have questions, please let me know. Connect with me through comments here or via twitter
@Arglick to continue the discussion.
#APIConnect#APImanagement#APIsecurity#APIstrategy#APIConnect#architecture#GettingStarted#governance#ibmapimgt#rest#security#soa#soap#TechnicalStrategy