What's the difference between an ESB and EAI technology?
Based on some feedback after my last article regarding using an ESB successfully, as well as reviewing a debate entitled "To ESB or not ESB ... that is the question" on the LinkedIn SOA Special Interest Group, I thought it would be useful to discuss ESB and EAI technology.
EAI, or enterprise application integration, technology was around long before the term ESB was coined. These technologies were intended to provide a means for managing the point-to-point integration sprawl that was occurring as connections between disparate systems were becoming increasingly important. EAI technology allowed these integrations to be centrally managed, even promoting organizational units such as an Integration Competency Center (ICC) or Integration Center of Excellence. Unfortunately, many EAI technologies suffered from performance issues due to the centralized consolidation of all integration logic, which can get quite complicated.
Along came SOA and with it, ESB technology. While some ESB products were brand new, there were also a number of EAI products that were re-branded as ESBs. This certainly created some confusion for customers, as in some cases companies not only had legacy integration products, but also ESBs, XML appliances, and Web Services Management products that all overlapped in the functionality that they provided. It only became more complicated when BPM technology gained traction, as many EAI tools leveraged a graphical modeling environment for integration pipelines in the same way that BPM tools provided a graphical modeling environment for process orchestration. So how do we clear this up?
First, integration is still necessary, and always will be. While the best path will always be to make the systems involved in the integration all use the same interface, sometimes that just isn't possible. For example, you may have two third-party systems, each with their own incoming and outgoing integration techniques. If those two aren't compatible out of the box – and they probably won't be – your only choice is to put something between them to make that integration happen. Even if only one side of the integration has a fixed interface, you may still need something in the middle, because you may not want all of your systems using that proprietary interface.
Second, remember that integration logic must be developed. Even if the "language" is a graphical environment, it should not be considered a configuration exercise in the same way that one configures a firewall or load balancer. This is the point I emphasized in my last article. A technology geared toward developers may be a force fit for operational policy management and enforcement. A technology geared toward operations may be great for policy management and enforcement, but a force fit for developing integration logic.
Third, understand that the technology spaces overlap, so it is still possible to get by with a single technology purchase. Vendors have created this overlap because not every company wants to spend millions on an integrate-anything-to-anything EAI tool. However, they may still have integration needs specific to a single ERP system. While an ESB may not have all of the integration capabilities of legacy EAI tools, it certainly may be sufficient for many scenarios.
What you want to avoid, however, is a single deployment of the ESB that tries to handle all operational policies for all service interactions, as well as all integration logic. This is doomed to be both a performance bottleneck as well as an operational risk where policies can be inadvertently modified, misconfigured, or left out altogether because of poor separation of responsibilities.
My advice is two-fold:
First, as stated in my last article, try to maintain a separation between business and integration logic and configurable operational policies, even if using the same technology for both. That may mean having separate instances of the technology.
Second, deploy the technology responsible for both runtime policy enforcement and for integration logic in places where they only deal with traffic that is subject to those policies or logic. If you need integration logic for messages going into and out of your ERP system, put the ESB or EAI in front of the ERP system, but don't also allow that ESB to handle traffic for other applications doing simple web service interactions that don't involve the ERP system. If you have policy enforcement for traffic control over all web service requests from outside your firewall, utilize a single ESB or service gateway for those policies, but don't mix that with integration logic only applicable to a subset of those messages. Put that logic in another instance, or even another technology more suited for that task.
This was first published in October 2011