Defining the ESB
An accepted definition for this term has yet to be firmly established that is most likely caused by a lack of industry standards, whereas standards like BPEL and BPMN 2.0 exist for process engines and other components. The term “Enterprise Service Bus” was coined by Gartner in 2002, and further introduced by the analyst Roy Schulte to describe a category of software products that he observed were available on the market at that time. Ten years later, there is still very little agreement on what exactly an ESB is or what it should deliver. There are different definitions depending on the manufacturer or source. Among other things, an ESB is defined as:
“A style of integration architecture that allows communication via a common communication bus that consists of a variety of point-to-point connections between providers and users of services.”
“An infrastructure that a company uses for integrating services in the application landscape.”
“An architecture pattern that enables interoperability between heterogeneous environments, using service orientation.” (Figure 1)
Figure 1: The ESB architecture pattern is divided into these main system architectures
The ESBs that are available in today’s market essentially differ in terms of the architecture of their systems. As shown in the preceding figure, they are mostly based on the following architectures:
Extended Message-Oriented Middleware (MOM)
These systems correspond to the original definition of ESB and typically distribute multiple nodes across the network, using a MOM infrastructure to support reliable messaging and event-driven processing among the nodes. Although the ESB nodes communicate using a proprietary protocol, service endpoints don’t need to be aware of the MOM. Services can be exposed using a WSDL or other protocols.
Extended Integration Brokers
Over the last five years, traditional integration broker vendors have been adding support for Web services and repositioning their products as ESBs. These systems are more standards-compliant than they once were but still tend to be more proprietary than most ESBs. They also tend to provide a very centralized solution in which all messages pass through a centralized broker.
Extended Application Servers
A number of ESB vendors use a Java EE application server as the basis for their ESB products. These products are typically stronger in terms of service creation and composition than they are in legacy integration. They tend to be rather centralized, although they do support distributed nodes.
Endpoint-Based Plug-In Channels
A few ESB vendors support an extremely distributed model that implements service mediation at the service endpoint, and supports heterogeneous communications using a channel plug-in architecture
Although these products don’t technically qualify as ESBs because a service platform is provided, more than one vendor has been known to label this type of product as such. Mediation agents can be centralized or distributed and support service mediation. There are also related product categories that implement parts of ESBs but are not officially marketed as ESBs by manufacturers [REF-1]:
XML gateways are hardware appliances that primarily support service mediation, which is one of the key features of ESBs. In fact, XML gateways often support service mediation capabilities that ESBs do not or cannot support, such as transformation acceleration and the decryption and encryption of XML documents. However, XML gateways do not provide a service platform, a feature that is typically associated with ESBs.
- ESB Does Not Equal SOA; Learn the Real Equation (thetibcoblog.com)
- Integration Patterns in the Wild (eaipatterns.com)
- Enhancing your JBoss Integration with JBoss BRMS (howtojboss.com)
- UltraESB 2.0 is Released! (architects.dzone.com)
- ESB Built for IoT (mholdmann.wordpress.com)