EAI has traditionally been done using point-to-point integration solutions. In point-to-point, we define an integration solution for a pair of applications. Thus we have two end points to be integrated. We can build protocol and/or format adapters, or transformers at one or either end. This is the easiest way to integrate, as long as the volume of integration is low. We normally use technology-specific APIs like FTP, IIOP, remoting or batch interfaces, to realize integration. The advantage is that between these two points, we have tight coupling, since both ends have knowledge about their peers.

The following figure is the diagrammatic representation of the point-to-point integration:

Hub-and-spoke architecture is also called the message broker and is similar to point-to-point architecture in that it provides a centralized hub (broker) to which all applications are connected. When multiple applications connect in this manner, we get the typical hub-and-spoke architecture. Another distinguishing feature of the hub-and-spoke architecture is that each application connects with the central hub through lightweight connectors. The lightweight connectors facilitates for application integration with minimum or no changes to the existing applications. Message transformation and routing takes place within the hub. This architecture is a major improvement to the point-to-point solution since it reduces the number of connections required for integration. Since applications do not connect to other applications directly, they can be removed from the integration topology by removing from the hub. This insulation reduces disruption in the integration setup.

There is a major drawback with the hub-and-spoke architecture. Due to the centralized nature of the hub, it is a single point of failure. If the hub fails, the entire integration topology fails. A solution to this problem is to cluster the hub. A cluster is a logical grouping of multiple instances running simultaneously and working together. But clustering is not the right solution to the problem of single point of failure. This is due to the fact that the very point in having a hub-and-spoke architecture is to have a single point of control. This drawback may be offset to some extent by the fact that most of the clustering solutions provide central management and monitoring facilities, which will provide some form of centralized control.

The following figure is the diagrammatic representation of the hub-and-spoke integration:

While the hub-and-spoke architecture makes use of lightweight connectors for applications to integrate together through a central hub, many a times the integrating applications need to interact in a decoupled fashion, so that they can be easily added or removed without affecting the others. An enterprise message bus provides a common communication infrastructure, which acts as a platform-neutral and language-neutral adapter between applications.

This communication infrastructure may include a message router and/or Publish-Subscribe channels. So applications interact with each other through the message bus with the help of request-response queues. If a consumer application wants to invoke a particular service on a different provider application, it places an appropriately formatted request message on the request queue for that service. It then listens for the response message on the service's reply queue. The provider application listens for requests on the service's request queue, performs the service, and then sends (if) any response to the service's reply queue.

We normally use vendor products like IBM's Websphere MQ (WMQ) and Microsoft MQ (MSMQ), which are the best class message queue solution to integrate applications in the message bus topology. As shown in the following figure, sometimes the applications have to use adapter which handle scenarios such as invoking CICS transactions. Such an adapter may provide connectivity between the applications and the message bus using proprietary bus APIs, and application APIs. The Message bus also requires a common command structure representing the different possible operations on the bus. These command sets invoke bus-level primitives which includes listening to an address, reading bytes from an address, and writing bytes to an address.

The service bus approach to integration makes use of technology stacks to provide a bus for application integration. Different applications will not communicate directly with each other for integration; instead they communicate through this middleware Service Oriented Architecture (SOA) backbone. The most distinguishing feature of the ESB architecture is the distributed nature of the integration topology. Most ESB solutions are based on Web Services Description Language (WSDL) technologies, and they use Extensible Markup Language (XML) formats for message translation and transformation.

ESB is a collection of middleware services which provides integration capabilities. These middleware services sit in the heart of the ESB architecture upon which applications place messages to be routed and transformed. Similar to the hub-and-spoke architecture, in ESB architecture too, applications connect to the ESB through abstract, intelligent connectors. Connectors are abstract in the sense that they only define the transport binding protocols and service interface, not the real implementation details. They are intelligent because they have logic built-in along with the ESB to selectively bind to services at run time. This capability enhances agility for applications by allowing late binding of services and deferred service choice.

The following figure is the diagrammatic representation of ESB integration:

The above qualities of ESB provides for a true open enterprise approach. As we have discussed above, ESB is neither a product nor a separate technology; instead, ESB is a platform-level concept, a set of tools, and a design philosophy. What this means is, if we just buy a vendor product and install it in our IT infrastructure, we cannot say that we have ESB-based integration architecture. Instead ESB-based integration solutions are to be designed and built in the "ESB way". Tools and products help us to do this.

A list of major features and functionalities supported by an ESB will help us to understand the architecture better, which are listed as follows: