The functionality of an ESB is described in general terms in the Java Business Integration (JBI) specification (Ten-Hove, Walker 2005). JBI implements a component architecture. JBI is based primarily on two constructs: service engines and binding components. The service engines contain the business logic, while the binding components merely act as a proxy for the service users (Wallrab 2005).

The tasks of a JBI component are as follows:

Requests from one component to another are decoupled, and take the form of messages, which the JBI infrastructure passes to the recipients. JBI supports different message exchange patterns:

JBI components

The most important JBI components are detailed in the following diagram:

Let's take a look at these components one by one:

• JBI environment: A JBI environment is represented by an individual Java Virtual Machine. Therefore, JBI can take the form of an independent ESB, or can be integrated into an application server and its JVM. Where the environment is integrated into an application server, the Enterprise JavaBean (EJB) components installed on the server can function as service providers, or as consumers of the ESB.
• JBI container: This is comparable to the EJB container of a Java EE application server. The JBI environment itself is a container, which provides service engines and binding components.
• Pluggable components: Service engines (SEs) and binding components (BCs) are pluggable components. They are connected to the normalized message router through delivery channels, which allows them to communicate with one another.
• Service engine (SE): These are service providers or consumers that are installed locally in a JBI environment. They represent the business components or the essential functionality that supports the business logic, such as Extensible Stylesheet Language (XSL) transformations or database accesses.
• Binding components (BCs): These encapsulate the communications and decouple the communication functionality from the business components (SEs). Binding components allow remote access to distributed services, and also enable distributed services to access the JBI environment.
• Normalized Message Router (NMR): This is the backbone of the JBI architecture. All communications between providers and consumers pass through this router. The NMR uses a canonical format.
• Normalized message: This type of message has two parts. There is the header, which contains the metadata (metadata in this context is also referred to as message context data), and the payload, in the form of an XML structure that contains the normalized message. The structure of the normalized message is comparable to that of XML messages from Java Message Service (JMS).
• Delivery channel (DC): This connects a message source with a message target. A channel is a virtual construct that conceals the communication details from the providers and consumers and decouples them from the NMR. Delivery channels connect components (providers and consumers) to the NMR, which is responsible for coordinating communications. Channels are logical addresses in the ESB that encapsulate the physical addresses.