EAI vs. ESB vs. SOA vs. BPM

Posted on 22. August 2011by renepeinl

As often in the industry, buzzwords are created to better sell a product, although it is not fundamentally different from earlier products. We had computer-based training overcome by e-learning which is being made obsolete by blended learning which nowadays is replaced by technology-enhanced learning. Each term stresses a different part of the story and tools are enhanced over time, nevertheless there are great similarities.

The same is true in the systems integration business. We have enterprise application integration (EAI) as probably the oldest term, service-oriented architecture (SOA) as a very general approach and the more recent enterprise service bus (ESB) and business process management (BPM) terms. But which is what and how are they different?

There are a lot of internet resources (e.g. [1], [2] or [3])that try to shed light into the mist of terms, but my impression is, that there is still need for more clarity.

EAI

As I did one of the first Microsoft Biztalk projects in Germany back in 2000/2001, the term EAI is very natural to me. The idea behind EAI is to replace the direct connections between systems that lead to n times n-1 interfaces with a hub and spoke architecture, so that each system needs only one interface to the central EAI server. This server, like Biztalk or Seeburger integration server, had adapters to the most important systems like SAP R3 or Oracle Applications, an XSLT engine for conversion between the different formats exchanged and some routing capabilities. HTTP, SMTP, MOM (message-oriented middleware) and file shares were used as transport ways and XML-based message formats were favored, although it was also possible to do system specific API calls with proprietary formats using the adapters. So for me, EAI is both a concept and concrete products that implement the concept.

SOA

Nearly at the same time, the idea of breaking up monolithic systems into basic services that can be flexibly orchestrated came up. The benefit of this approach is, that you can in theory connect the different systems directly without any integration efforts because each has a platform- and programming language-neutral way to access its API, an XML-based Web Service. Still, the better way is to use a middleware component in between in order to make systems easier to replace. It is even required, if you really want to configure the flow of messages and function calls without any programming. The SOA however, is not a product you can buy, but emerges if you are using the right combination of SOA-enabled application systems and middleware components.

BPM

The flexible orchestration of Web services is often called business process management. Besides the technical part that allows to do Web service calls, model workflows based on these Web services and allows its execution in BPEL (business process execution language), there is also a business connotation that references the flexible alignment of IT systems to the fast changing business needs. Since EAI tools already had most of the required components to build a SOA all of the major products implemented BPEL execution functionality and provided a utility to do the modelling in a graphical way, lately based on BPMN (business process modelling notation).

ESB

So far for the easy part. Until lately, I was not really sure about the difference between an ESB and BPM tools. After some research on the Internet, here is my latest opinion on that. The main difference between an ESB and the afore-mentioned BPM tools is, that ESB provides the possibility to distribute the previously central hub over the whole intranet. In some occasions, e.g., due to different security zones, it may be preferable to handle most of the communication locally and only access other zones when necessary to get to the systems that are located there. If you have a central hub, every system does always have to access the zone the hub is in for every kind of communication, even those to the local systems. This is especially annoying if the systems are distributed geographically across different countries or even continents. The ESB concept is fitting in there by providing local ESB instances that do the job, but act together like a single central hub since they are connected with each other using MOM technologies or http connections for synchronous calls. Therefore, local communication remains local and global communication is still possible with the same means.

That’s it! I hope you find this article illustrative. Please leave comments, if you have different opinions or want to add some aspects that I neglected.