An enterprise service bus (ESB) is the layer of technology that makes SOA possible. It creates the necessary abstractions by translating the messages defining a service into data that can be manipulated by the physical process implementing it. The ESB also provides the plumbing to connect the services to each other. In addition to the implementing the interface between an abstract service and a real-life implementation, an ESB also provides some of the qualities of service (QoS) such as security, reliability, and logging that are expected in enterprise environments.

An ESB takes the concrete details defined in the WSDL contract and uses it to make the service accessible to other resources on the network. This information includes details on how the abstract messages are mapped into data that can be manipulated and transmitted by the service’s implementation. It also includes information about the transport and addressing details that other resources need to access the service. The endpoint is the physical representation of the abstract service defined in a WSDL contract.

As shown in Figure 1.4, “Billing System SOA with an ESB”, the ESB sits between the service’s implementation and any consumers that want to access the service. The ESB handles functions such as:

A brief description of an ESB may trigger nightmares about EAIs. While the concern is warranted, ESBs have several key differences from past integration layers:

The use of standardized WSDL for the interface definition language and the use of XML as a native type system make an ESB future safe and flexible. As discussed in the previous section, both are platform and implementation neutral which avoids vendor lock-in.

The key differentiators between ESBs and EAI systems are:

EAI systems were designed as a hub-and-spoke system. ESBs, on the other hand, are designed to be as distributed as the components they are integrating. As shown in Figure 1.5, “Distributed Nature of an ESB”, an ESB distributes the work of data translation, routing, and other QoS tasks to the endpoints themselves. Because the endpoints are only responsible for translating messages that are directed to them, they can be more efficient. It also means that they can adapt to new connectivity requirements without effecting other endpoints.

EAI implementations relied on specialized adapters to connect applications together. There was no one standardized means for describing how the applications were wired together and different EAI implementations generally did not talk to each other. ESBs on the other hand use standardized technologies to connect applications together. The use of WSDL as the common contract language ensures that all ESBs understand how to expose a service. In addition, there are a number of standards that define how ESBs interact. Ideally, if you deploy multiple ESB implementations in your organization, they should all talk to each other.

ESBs offer a number of features such as transactionality, security, routing, and reliable messaging. To ensure maximum interoperability between implementations, ESBs base many of their features on a set of standards that include:

These standards are all maintained by the W3C and provide a common framework on which ESBs build their functionality. They were all designed around the idea that information would be passed using SOAP/HTTP. They were also designed so that services could be easily shared and accessed over the Web. Therefore they, and ESBs that implement them are built to be maximally interoperable.