Connecting Enterprise Software: ESB vs. API Management

How do you connect two software applications to enable them to share data and send each other instructions and requests? Enterprises today often have a Human Resource Management (HRM) platform and a Customer Relationship Management (CRM) platform. Interfacing those two giants and enabling them to talk to each other once required a clever negotiator. Nowadays, many strategies exist to accomplish this important task, but we will focus on the two most competitive options: the Enterprise Service Bus (ESB) and the Application Program Interface (API). Both can be used to interface disparate apps, but one solution has a lot more functionality than the other, as we will see shortly. Our purpose is to explore the important factors and choose the most effective solution. Let’s begin with distinguishing examples of both.

Continuing our example above, modern CRMs and HRMs today will provide APIs as featured parts of their platforms. Developers coding ad hoc applications elsewhere in the enterprise can authenticate with an access token and call the API functions to lookup an employee’s sales commission and bonus history or birthdate. A CRM at an insurance company may use a third party API, for example, to look up license tags when a policyholder submits a claim. Admin at a private school may embed third party analytics by subscribing to an API. As you can see, APIs usually have a very specific purpose. While that purpose is indeed an interface, it is an interface only to a designated function, like flight booking, GPS coordinates, theater tickets, weather, and a million other singular points of interest meant to bring it all together. But what about more comprehensive or universal interfacing between enterprise level software applications? This more adaptive universal interfacing is the domain of the Enterprise Service Bus.

Unlimited Connectivity with ESB Architecture

Every enterprise level software application contains innovation and ingenuity, the creative work of its visionaries and developers. However, each unique feature has the unintended consequence of incompatibility with its neighbors. The genius could lie in a brilliant data format or a hyper efficient data transfer protocol; by virtue of its innovation the new application is isolated from others. Over the recent 20 years, enterprise application development necessitated the parallel creation of equally diverse integration tools to connect the modern application with the legacy. In a spiral of increasing complexity, a paradox arose: integration tools themselves needed to be interfaced conceptually with other integration tools! 

In other words, several integration paradigms which connected the protocols, data formats, and abstracted the function calls of one enterprise application, themselves merited consolidation into a unifying interface architecture. Those integration solutions include:

• Service-oriented architecture (SOA)
• Event-driven architecture (EDA)
• Business-to-business (B2B)
• Services provided through Web (SPW) 
• Enterprise application integration (EAI)

Just in time to meet the growing demands of IoT and Edge Compute, and event streaming machine learning applications, among myriad other burgeoning data-centric endeavors, the Enterprise Service Bus has evolved to meet the challenge of unifying the other integration strategies. Among the brightest technologies emerging to supply the functionality needs of the ESB paradigm is Apache Pulsar, hosted by Pandio.

Enterprise resource planning (ERP) applications, for example, now consist of numerous component technologies such as analytics performance tools, IoT sensors and event streaming to machine learning applications, as well as databases and visualization tools, programming tools, and much more. Ideally, these components are integrated smoothly to communicate with each other and provide resource sharing ubiquitously across enterprises. ESB architecture achieves these feats remarkably well, well enough in fact to replace the legacy paradigms like SOA and EDA. For an even deeper discussion, refer to our dedicated coverage of ESB.

At this level, we draw an important conditional distinction between ESB and API: any of the functionalities of the ESB architecture could be built into an API or an assembly of APIs. Indeed, an assembly of technologies and processes used in developing APIs to provide interfaces among otherwise disparate systems is now commonly referred to as API management, and this  ad hoc approach to interfacing is a satisfactory alternative to ESB for many small ventures. For practical purposes however, ESB begins the race with vastly greater functionality – the functionality needed most by larger enterprises. While protocol transformation, to name one example, is standard functionality in ESBs, an equivalent API must be curated within an API management scope. Today, the providers of ESB as a comprehensive middleware solution include:

• IBM applicationConnect
• Pandio
• Open ESB 
• Software AG webMethods
• Peregrine Connect.
• webMethods Integration Server

Standard ESB functionality solutions integrate a variety of transport protocols using transformed XML packets, to name one of many. Have a look at our ESB profile for a complete table. Critical requirements include absolute data integrity and the guarantee of message delivery. Zero downtime, with monitoring and logging for performance analytics are ensured by an innovative new ESB solution which uses the Publisher-Subscriber model, incorporating Apache Pulsar via a Pulsar host. As such, Pandio is the only Pulsar host to integrate upstream systems and downstream systems as an ESB architecture expert.

Comparing API Management Use Cases

Suppose a manufacturing company’s Enterprise Resource Management (ERP) platform makes its factory production and shipping data available via API to its purchasers, so they can predict real-time product availability and extend this data to their own customers. Such an API has specifically defined capabilities and security features to authenticate subscribers. In this use case, the API is a service provided free of charge by the manufacturer as a convenience to its customers. If the subscribers to this API needed, for example, to transform IoT sensor data from a shipping container in the supply chain, and especially if protocol transformation were needed, this scenario would demand either another API, or the introduction of a full ESB platform. Here we arrive at the real divergence of ESB from API.

API use cases are certainly vast. Any number of them can be assembled in an API Management scope. However, this gets increasingly cumbersome, and it runs contrary to standardization and abstraction. How far down the API management rabbithole should an enterprise go before resurfacing and retrofitting with ESB? Let’s look at a brief list of the most common API use cases:

• Finance: expose customer account data, bill payment, transfers.
• Transport: Google uses Android phone subscriber location and speed to generate traffic maps exposed as an API.
• Government: provides land ownership data via API to consumers.
• Supply chain: parcel ETA, inventory, shipping cost estimates.
• Healthcare: insurance APIs provide patient data on covered medications and procedures to https://slimlifehw.com healthcare providers.
• Customer service: AI-based chatbot APIs deliver NLP tech support at call centers.

ESB Solidarity

Distilling the complexity of ESB and API in order to choose which one works best for you may be as simple as listing your external data sources and dependencies, and determining how much developer overhead is required to re-invent the ESB wheel in-house. Suppose for example that your web applicationrelies on a third party embedded analytics app, but the bulk of your service is generated in-house. In such a simple scenario, your analytics third party API may be all you need. However, for large scale enterprises with big data warehouses and numerous departments, API Management will be a headache that worsens with time. Pundits say embrace ESB before the headache starts.

The security provided by ESB architects is that interfacing and translating scenarios which you have not even thought of yet are already baked into the giant’s ESB recipe; the solutions are there waiting all along when you realize the need. And it’s no longer necessary to pay a giant price for a full function ESB. The progenitors of ESB may have dominated in previous years, but today much of their tech substance is open source. Pandio, for example, offers the ESB capability of Apache Pulsar as a service at half the price of larger competitors. And with Pandio’s creative data science team, you can “stand on the shoulders of giants” and run 2.5 times faster with better latency and guaranteed zero data loss.