To be able to adapt to market changes, organizations tend to focus on flexibility and responsiveness. The IT challenge has usually been to support this business vision with the appropriate architectures and technologies.

Early initiatives were to break monolithic applications into callable sub-routines but the advance of remote object invocation and messaging processing changed that.

More recently, it has become crucial to increase the reuse of existing assets in the organization (which increased return on investment) and to assemble heterogeneous applications to form a coherent business solution. This has helped to drive the adoption of SOA and EDA. These two different design paradigms are aimed at maximizing the reuse of application-neutral services that increase IT adaptability and efficiency. But building and deploying large-scale integration solutions has never been easy to achieve. That's where the ESB comes into play, because it simplifies the realization of flexible and reliable architectures (SOA and EDA) for mission critical applications.

Service-Oriented Architecture
SOA is an architectural concept in which all functions, or services, are defined using a description language and where their interfaces are discoverable over a network. The interface is defined in a neutral manner that is independent of the hardware platform, the operating system, and the programming language in which the service is implemented.

One of the most important advantages of a SOA is the ability to get away from an isolationist practice in software development, where each department builds its own system without any knowledge of what has already been done by others in the organization. This "silo" approach leads to inefficient and costly situations where the same functionality is developed, deployed and maintained multiple times. A SOA is based on a service portfolio shared across the organization and it provides a way to efficiently reuse and integrate existing assets, as shown in Figure 1:

SOA is based on a conventional request/reply mechanism, as seen in Figure 2. A service consumer invokes a service provider through the network and has to wait until the completion of the operation on the provider side.

Table 1 summarizes the fundamental characteristics of a SOA solution:

Event-Driven Architecture
In 2003, Gartner introduced a new terminology to describe a design paradigm based on events: Event-Driven Architecture (EDA). EDA defines a methodology for designing and implementing applications and systems in which events transmit between decoupled software components and services. EDA does not replace, but rather, complements the SOA. While SOA is generally a better fit for a request/response exchange, EDA introduces long-running asynchronous process capabilities. Moreover, an EDA node posts events and does not depend on the availability of a published service. It is really decoupled from the other nodes. EDA is sometimes also referred to as "event-driven SOA".

EDA uses messaging to communicate among two or more application processes. The communication is initiated by an "event". This trigger typically corresponds to some business occurrence. Any subscribers to that event are then notified and thus activated, as shown in Figure 3:

Table 2 summarizes the fundamental characteristics of an EDA:

Enterprise Service BusDefinition
An Enterprise Service Bus (ESB) combines event-driven and service oriented approaches to simplify integration of business units, bridging heterogeneous platforms and environments. The ESB acts as an intermediary layer to enable communication between different application processes. A service deployed onto an Enterprise Service Bus can be triggered by a consumer or an event. It supports synchronous and asynchronous, facilitating interactions between one or many stakeholders (one-to-one or many-to-many communications). So the ESB provides all the capabilities of both SOA and EDA paradigms (see Table 1 and Table 2).

An Enterprise Service Bus is an architectural pattern and can be implemented by many different products within the organization, and assembled together to act as a federated bus. More and more vendors are now offering a complete product to fulfill enterprise integration needs. For instance, IBM WebSphere® Enterprise Service Bus (see Resources) delivers an integration bus to connect applications efficiently, leveraging standards like web services and J2EE.

ESB services
There is no official specification to define what an ESB implementation should be, but it is commonly accepted that it must at least provide transport, event and mediation services to facilitate the integration of large-scale heterogeneous applications.

Transport services must ensure the delivery of messages among the business processes interconnected via the enterprise bus. Transport also includes content-based routing. It means it can direct messages to different destinations. As part of a mission-critical environment, these services are transactional, secured and monitored.

Event services provide event detection, triggering and distribution capabilities. They are related to the notion of event processing, a technique for analyzing and controlling the complex series of interrelated events in Event-Driven Architectures (EDA). Event-driven paradigms are not new. However, they are gaining industry momentum and represent the core concepts of emerging technologies like Complex Event Processing (see Resources).

Mediation services address two different purposes. First, the mediation ensures the necessary protocol matching to integrate heterogeneous systems (Figure 4). As two different services do not have to use the same transport protocol, the mediation service takes care of the transformation from one protocol to the other, so that the communication is possible. The protocol switch is transparent for all the participating services of a business transaction.

Second, the mediation offers the possibility to transform the content of any message (Figure 5). This is a key service for business integration. It ensures that the data which transits through the bus is understandable by any process. Moreover, the mediation enables content augmentation to enrich a message with any additional information. The content transformation is managed by the bus: it is transparent for any participating service.

Let's take an example to illustrate the content mediation benefits. A fictitious company called Yummy Inc. provides online catering services. In order to plan the menus they offer to their customers, they need to verify the availability and the prices of the food items from their supplier. The typical structure of the message they send to obtain this information contains a product identification, a quantity and a target delivery date (Figure 6).

Of course, Yummy Inc. and its supplier do not have the same way to represent the information. For example, the dates are not harmonized in both systems. Moreover, the supplier needs a delivery location because Yummy Inc. is not the only company they deal with. The ESB mediation service can transform and augment the information of a transiting message so that the target service receive all the information it requires, as illustrated in Figure 7: Leveraging the key technical services previously defined, an ESB offers a flexible connectivity infrastructure for integrating loosely-coupled applications. It supports both SOA and EDA paradigms.

ESB benefits
Leveraging its internal services, an ESB solution provides a variety of benefits. In essence, it simplifies the task of connecting dissimilar applications and ultimately improves business agility, and provides the following:

• Standard-based connectivity
  As the integration backbone between many heterogeneous systems, it is essential for an ESB to provide many different integration techniques, and to leverage a large choice of standard technologies. The messaging integration usually supports the Java^TM Message Service (JMS) API, while the connectivity with enterprise information systems is provided by the J2EE Connector Architecture (JCA). To ensure Web service interoperability, an ESB supports the JAX-RPC programming model. Integration between different ESB components can be standardized by the Java Business Integration specification (JBI) (see Figure 8).
• Pervasive integration
  An ESB is by nature pervasive because it can integrate applications across different departments, business units or even business partners. Moreover, its core architectural principle is also to facilitate the communication between applications built on heterogeneous development environments. For example, an ESB solution can bridge different programming languages like J2EE, C++ or .Net.
• Reliable integration
  The ESB architectural pattern improves system security, scalability and availability. As it leverages SOA and EDA, the Enterprise Service Bus provides both synchronous and asynchronous capabilities. The transport service ensures reliable delivery and transactional integrity. So every characteristic of an ESB tends to strengthen its robustness, minimizing the risk of failure of the integrated and federated solution.