Exploring the Enterprise Service Bus, Part 1: Discover how an ESB can help you meet the requirements for your SOA solution

This article is first in a series that describes and defines the Service-Oriented Architecture (SOA) pattern called the enterprise service bus (ESB). In this series, discover how the ESB fits within the IBM SOA Foundation and how other parts of the foundation relate to the ESB, as well as the core principles of the ESB. Without describing a specific product or ESB implementation, this series also provides a common basis for understanding and evaluating how an ESB can help address the requirements of your service-oriented solution.

Greg Flurry is a senior technical staff member in the IBM SOA Advanced Technology group. His responsibilities include working with customers on service oriented solutions and supporting field-based development of IBM's SOA products.

Introduction

An enterprise service bus (ESB) is a core part of all but the simplest solutions based on a Service-Oriented Architecture (SOA). What exactly is an ESB? You can find a number of definitions throughout the IT industry. This series of articles defines enterprise service bus from the point of view of IBM, or more precisely, in the context of the IBM SOA Foundation. To derive the maximum value from this series, you should first read about the IBM SOA Foundation.

The series discusses the ESB in abstract terms and avoids product specifics; that is, this series is not about the IBM WedSphere ESB product or any other instances of the ESB pattern. This product-agnostic approach offers a broad basis for understanding what the ESB brings to service-oriented solutions and for evaluating specific ESB products and related technologies as a part of such a solution. This article sets the stage for the entire series, positioning the ESB within the IBM® SOA Foundation and describing how other parts of the foundation relate to the ESB. In particular, this article identifies core principles of the ESB. Finally, the article gives you the first level of detail inside the ESB, showing how the ESB achieves those core principles.

IBM SOA Foundation and the ESB

The IBM SOA Foundation is a comprehensive architecture and set of offerings, technologies, and practices that address the important aspects encompassed by SOA. The SOA Foundation describes:

A holistic relationship between the business and the IT organization

Tools and methodologies for modeling the business design

Tools, programming model, and techniques for implementing the business design using IT systems

The middleware infrastructure for hosting an implementation

The management of that implementation, to ensure availability to the business and efficient use of resources in the execution of that implementation

The governance system used to control changes in the business design and its implementation in the IT system

To understand its full value, you need to examine SOA from different perspectives. Similarly, it is necessary to examine the role of the ESB from different perspectives to understand its full value.

Figure 1 shows the SOA Foundation Reference Architecture logical model view. The logical model view decomposes the functional underpinnings of an SOA solution. This functional or IT-focused view portrays the ESB as an integration part that supplies interconnectivity among other IT parts of a solution.

Figure 2 shows the SOA Foundation Reference Architecture solution view. This is a business-focused view of a service-oriented solution. Note the portrayal of the ESB as an integration layer underpinning the interconnectivity among the business parts of the solution.

Figure 2. IBM SOA Foundation Reference Architecture solution view

The views of both Figure 1
and Figure 2 suggest that the ESB is a key architectural pattern in the Foundation reference architecture, enabling loosely coupled interconnectivity between service requesters and service providers in service-oriented solutions. Loose coupling permits a clean separation of concerns (temporal, technological, and organizational) between the parts in a solution, enabling flexibility and agility in both business processes and IT systems. The rest of this article elaborates on the characteristics of the architectural pattern and how they can be achieved.

ESB core principles

Figure 3 shows the logical relationship between service requesters, service providers, and the ESB. Service requesters and providers interact by exchanging messages. The ESB, acting as a logical intermediary in the interactions, provides loosely coupled interconnectivity between the requester of a function and the provider of that function. Its role as a logical intermediary allows the ESB to intercept messages and process them as they flow between a service requester and service provider. This processing is called mediation.

Figure 3. Service virtualization

It is important to understand that the ESB architectural pattern can be physically realized in different ways. The ESB appears as a centralized hub in Figure 1, and the physical realization of the architectural pattern in many solutions is in fact a physical hub. Figure 3 attempts to suggest the architectural pattern can have different physical realizations; for example, the ESB can be distributed so that mediation can physically take place in the service requester environment, the service provider environment, in a centralized hub environment, or in any combination of those realizations. (In upcoming installments in this series, you learn more details about various ESB topologies.)

An example of ESB core principles

A bank has an existing application that must check credit history. The bank is automating its credit-checking process and will use a business partner's credit approval Web service. The existing application interacts with the current credit-checking systems using a text message over MQ, with a correlated response. Consider a mediation in the bank's ESB that can:

Listen on an MQ queue and delivers a correlated response to an MQ queue

Convert a text message from the existing application into a message compliant with the business partner's credit-approval schema and the reverse.

Interact with the security infrastructure to insert the necessary security information

Call the business partner’s Web service and leave an audit trail that it has done so

Implementing an ESB as part of the bank's service-oriented architecture provides the following benefits:

The existing application logic does not change. If the ESB can use the same MQ queues originally used by the application, then even the configuration does not need to change.

The audit trail supports conciliation of the business agreement with the partner.

If the business partner's service does not meet its service level agreements, the bank can change to a new service provider by modifying routing and transformations in the ESB without disrupting the client applications using the service.

Support for various types of mediation allows the ESB to fulfill two core principles in support of separation of concerns: service virtualization and aspect-oriented connectivity. The first principle, service virtualization, refers to the ability of the ESB to virtualize the following during service interactions:

Protocol and pattern. Interacting participants need not use the same communication protocol or interaction pattern. For example, a requester may require interaction through some inherently synchronous protocol, but the service provider may require interaction using an inherently one-way protocol, using two correlated interactions. The ESB provides the conversion needed to mask the protocol and pattern switch.

Interface. Service requesters and providers need not agree on the interface for an interaction. For example, the requester may use one form of message to retrieve customer information, and the provider may use another form. The ESB provides the transformation needed to reconcile the differences.

Identity. A participant in an interaction need not know the identity (for example, the address) of other participants in the interaction. For example, service requesters need not be aware that a request could be serviced by any of several potential providers at different physical locations. The actual provider is known only to the ESB, and in fact, may change without impact to the requester. The ESB provides the routing needed to hide identity.

The second core principle is aspect-oriented connectivity. Service-oriented solutions include multiple cross-cutting aspects such as security, management, logging, and auditing. The ESB can implement or enforce cross-cutting aspects on behalf of service requesters and providers, removing such aspects from the concern of the requesters and providers. The analogy between aspect-oriented connectivity and the more familiar concept of aspect-oriented programming is unmistakable and offers the same value in a different context.

The application of these core principles through mediation allows the ESB to affect the quality of service in interactions. Some aspects of an interaction can be abstracted away from the participants. Consider auditing, for example: If a solution requires auditing, the ESB can add it to interactions with no impact on the participants. Similarly, the ESB can add to or enhance service-level agreements using its virtualization capabilities to retry failed interactions, or in more sophisticated situations, the ESB can match requester requirements with provider capabilities. There are limits, however, since some aspects of an interaction cannot be abstracted. For example, the ESB cannot provide a reliable end-to-end interaction if the ESB cannot interact reliably with one of the participants.

An ESB-centric view of the logical model

An earlier section positions the ESB in the full scope of the SOA Foundation (see Figure 1 and Figure 2), looking at the ESB mostly from an outside-in viewpoint. We now look at the ESB from an inside-out viewpoint. Figure 4 portrays a number of important relationships between the ESB and other parts of the reference architecture logical model.

Figure 4. ESB-centric view of the logical model

Application logic compared with integration logic

Note that several parts of the SOA Foundation are interconnected by the ESB, namely the interaction, process, information, partner, business application, and access services. These have been grouped into a single category labeled applications services, positioned outside the ESB. The parts of the foundation grouped as application services are used to implement different forms of service requesters and service providers. This is the application or business logic in a solution, which is targeted at achieving domain-specific business goals. The ESB implements the connectivity or integration logic in a solution. This logic performs service virtualization and aspect-oriented connectivity, which is targeted at achieving on demand interconnectivity between application services.

In an ideal service-oriented solution, the separation of application and business logic from connectivity and integration logic is "clean," meaning that the service requesters and service providers (the application services) contain no connectivity or integration logic and that the ESB contains no application or business logic. Only by architecting this clean separation can an enterprise achieve the flexibility, agility, and reuse sought from SOA.

Sometimes it is difficult to distinguish between application and business logic and connectivity and integration logic. There are no strict guidelines, and, in fact, the choice may depend on the nature of the enterprise or even a particular situation within the enterprise. One guideline that often works leverages the distinction between semantics and syntax. Application and business logic creates, reads, updates, or deletes the semantics associated with achieving business goals. Conversely, connectivity and integration logic only modifies syntax associated with achieving the necessary interconnectivity. A related guideline leverages interaction characteristics. Application and business logic is active, in that it creates or consumes the messages (requests and responses) used in service interactions; connectivity and integration logic is passive and simply reacts to messages generated by the business logic, simply moving the messages from one participant to another.

Application/business logic versus connectivity/integration logic

A bank has a new application that must check credit history using a call to a Web service. The bank wants to use one of two credit reporting services available as Web services from either of two business partners, neither of which exactly matches the bank'’s data model for credit history. The bank wants to use the first business partner's service unless it is not available. The new application determines when to call the credit history service and does so using the bank's data model. The application/business logic in this example consists of the new application plus the two credit reporting services. The connectivity and integration logic in this example consists of the processing necessary to transform the credit history model to that appropriate for the credit history service invoked and the failover to call the second business partner if the first fails; this logic is embedded in an ESB as mediation.

Management services

Note that some important capabilities of a service-oriented solution, specifically the management services that are part of any service-oriented solution, are also positioned outside of the ESB. This is because such capabilities as security and IT management have a solution-wide scope and require the coordination and cooperation of parts of a solution beyond the scope of ESB.

Note that the ESB does not provide connectivity between application services and management services, and it is possible to secure and manage a solution without participation of the ESB. It is also possible, and frequently desirable, for the ESB to take an explicit, active role in securing and managing a solution. In this situation, the security and management policies are set by the policy administration points outside the ESB, and it's appropriate to consider the ESB as a policy enforcement point for such policies. Thus, policy is set using management and security services that have no direct relationship to the ESB, but the ESB helps enforce the policy. As a result, management services are characterized as loosely coupled to the ESB.

Service registry

The service registry (sometimes called a service repository or service registry/repository) contains and manages the metadata that describes the services in a service-oriented solution. Examples of metadata include interface descriptions, endpoint address, and policies covering service level agreements, security relationships, and so on. The service metadata contained in the registry, and thus, the registry itself, has a broad scope in service-oriented solutions, spanning governance, development, and administration as well as run time. Figure 2 in particular shows the central nature of the registry in a service-oriented solution; the registry is portrayed as an operational system that spans the vertical stack of layers, from integration through governance.

Figure 1 and Figure 4 suggest that the ESB requires service metadata to perform service virtualization and aspect-oriented connectivity. The ESB can provide value using only static metadata provided during development. Realization of fully autonomic service virtualization and aspect-oriented connectivity, however, requires the ESB to access a services registry at run time to obtain the necessary service metadata to control the dynamic behavior of a solution. Thus, we assert that the services registry is the preferred way to configure and control the behavior of the ESB; one might say that the service registry is a policy administration point for the policies that control the behavior of the ESB, and that the ESB is a policy enforcement point for the connectivity-related policies in the service registry. As a result, we can characterize the service registry as tightly coupled to the ESB.

Example of service registry use

A bank has a new application that must check credit history using a call to a Web service. The bank wants use a credit approval service available as a Web service from a current business partner, but wants to minimize any disruption if it becomes necessary to use a service from a different business partner. In the simplest scenario, where the interface to any potential business partner is the same interface, the bank uses an ESB mediation that queries the registry for the endpoint address to use in the interaction.

Development services

The development services in Figure 4 provide tools you can use to develop and administer the ESB. Developers want to use tools to develop the connectivity and integration logic, or mediations, running in the ESB. Similarly, administrators can use tools to administer the ESB post-deployment. Ideally, such tools use the services registry. For example, development tooling might allow the mediation developer to find the service providers required for an interaction using the registry. Also, administration tooling might allow addition, deletion, or modification of service metadata intended to impact the dynamic behavior of a solution.

A peek inside the ESB

Figure 5 shows the first level of detail for the internal structure of the ESB. You can see how the ESB provides service virtualization and aspect-oriented connectivity.

Figure 5. ESB internal structure

Communication protocols

To enable interaction between service requesters and providers (that is, to receive and deliver messages), the ESB must connect to requesters and providers using communication protocols. The ESB can leverage different protocols to support differing qualities of service between requesters and providers; for example, to support best effort or assured delivery. The broader the spectrum of protocols an ESB leverages the broader the spectrum of requesters and providers the ESB can interconnect.

The ESB itself does not actually provide the communication protocols, but instead leverages one or more of the underlying communication fabrics offered by its operating environment (the infrastructure services in the SOA Foundation Reference logical model). You could say that the ESB itself supplies on-ramps and off-ramps or bindings to enable interaction using various protocols.

Communication protocols inherently support one or more interaction patterns due to characteristics of the underlying communications fabric. Some common interaction patterns are synchronous request/reply, one-way (sometimes called event), and publish/subscribe (sometimes called event propagation).

Message models

To interact with service requesters and providers, the ESB must support the message models that define the content of the messages used in interactions. To that end, an ESB must be message-model agnostic and offer the configuration flexibility to support the message models defined by the service requesters and providers.

A message model itself is based on a metamodel, a way of representing message content. An example of a message metamodel is the XML Schema definition language; in fact, that is the most common metamodel found in ESB products. A message model is a specific application of a metamodel; an example of a content model is a specific XML schema. An ESB must obviously support at least one message metamodel and can support many.

While the architectural pattern is message-model agnostic, specific ESB products may provide support for a set of cross-industry or industry-specific standard message models, such as HL7 in the health care industry. Support in this case means built-in recognition of the model in the associated tooling and even optimized run-time transformation capability.

Mediation flows

To support the service virtualization and aspect-oriented connectivity necessary in interactions between service requester and providers, the ESB provides mediation flows. A mediation flow, (commonly shortened to simply mediation), includes receiving an inbound request message from a requester through an off-ramp, processing a request message, and then sending an outbound request message to the provider using an on-ramp. If applicable, a mediation can also include receiving a correlated inbound response message, processing a correlated response message, and sending the outbound response message to the requester.

The mediation flows in a solution can vary in complexity from very simple to very complex. The flows can also vary in reusability from unique to a single interaction to applicable to all interactions in a solution or even across solutions. Certain types of message processing performed in a mediation flow tend to be highly reusable. These commonly occurring, highly reusable, well-defined types of message processing are called mediation patterns. ESB products can offer one or more prebuilt mediation patterns. ESB products that offer more than one prebuilt mediation pattern provide a mediation framework that supports creation of mediation flows through the composition of mediation patterns.

How do mediation flows implement service virtualization? Virtualization of protocol and pattern implies conversion between different communication protocols and interaction patterns. An ESB can only convert between one protocol and another if it has on-ramps and off-ramps, or bindings, for both. Conversion between interaction patterns may be inherent with support for the inbound and outbound protocols or may require additional processing. For example, converting from an inbound one-way request using SOAP/HTTP to an outbound one-way request using a queue-based protocol where the message model is the same is inherent because a queue-based protocol is inherently one way. Conversely, converting between an inbound synchronous request/reply using SOAP/HTTP to an outbound asynchronous request/reply using a queue-based, one-way request with a one-way reply requires the mediation flow to enable correlation between the queue-based request and reply. Conversion-related mediation patterns include the on- and off-ramps and correlation patterns, although because correlation is core to mediation flows, in many cases, it is implicit in the mediation framework.

Virtualization of interface requires that the ESB support syntactic transformation between the message models defined by the service requesters and providers. Messages inbound from service requesters using one message model might have to be transformed into the specific message model required by the service provider; any response messages must also be transformed. Transformation-related mediation patterns include those that allow a single metamodel (for example XSLT), more generic any-to-any transformation patterns that support multiple metamodels, and other forms of message manipulation, such as message enrichment and message filtering (changing syntax, not semantics).

Virtualization of identity requires the ESB to support various forms of routing. Routing allows the ESB to send messages from a service requester to a service provider chosen statically (for example, at the time of deployment), or dynamically, based on the conditions at the time of the request. Routing mediation flows range from very simple to very complex. For example, a simple routing mediation flow might do nothing but supply a different address for the provider; the address might come from a property set at deployment. A more complex routing mediation flow might do the following:

Access a service registry to understand the needs of the requester and the offers of the potential providers.

Use a complex matching algorithm to determine the "correct" provider.

Perform various conversions and transformations as discussed above.

Routing-related mediation patterns allow simple address manipulation, various forms of registry access, and various forms of decision making. Larger-grained routing patterns can contribute to differing qualities of service; for example, offering request retry and failover, or even dynamic matching of requester and provider based on policies extracted from a service registry. An ESB can support more complex and sophisticated routing patterns, such as distribution of a request and correlated aggregation of responses, or even complex event processing.

How do mediation flows implement aspect-oriented connectivity? The mediation flow may simply log that a request was passed from requester to provider, block requests from unknown or unauthorized requesters, or block requests based on provider availability. Related mediation patterns include auditing and logging in a manner appropriate for the solution. Other mediation patterns provide direct or indirect access to the security and management policy definition points so that the mediation flow can perform the appropriate control.

From this discussion, it is clear that many mediation flows are likely composed of mediation patterns supporting various forms of service virtualization and aspect-oriented connectivity. Individual mediation patterns are placed appropriately in the mediation flow to achieve the goals of the intended interaction as well as to enforce management and security policies.

SOA life cycle and the ESB

A key element of a service-oriented solution is the life cycle of its parts. Let's examine how the SOA life cycle applies to the ESB. In Figure 6, you can see the SOA Foundation life cycle.

Figure 6. The SOA Foundation life cycle

The model phase includes the following activities:

Gathering the interconnectivity and metadata requirements by examination of the service requesters' and providers' interactions; the relevant needs and offerings can be described in the registry.

Modeling and designing the mediation flows required to support the required interconnectivity.

The assemble phase includes the following activities:

Composing the mediation flows from smaller-grained mediation patterns. The mediation patterns may be prebuilt, as part of an ESB product. They may exist in an enterprise-specific asset repository. Or, they may be newly developed for the solution.

Storing metadata about the mediation in the service registry for use by service requesters. The metadata describes the relevant connectivity aspects, such as security.

The deploy phase includes the following activities:

Configuring the mediations for deployment into a particular run-time topology; some of the necessary configuration information will be in the registry as service metadata.

Deploying the mediations into one or more run-time environments.

Modifying the service metadata to impact the dynamic behavior of the solution.

The manage phase includes the following activities:

Monitoring the behavior of service interactions using mediation patterns

Managing and securing service interactions as a policy enforcement point for security and management services as well as the registry

The ESB plays an indirect part in the governance processes for a service-oriented solution in that governance drives the policies for security, management, and service interactivity. The ESB, as indicated, can act as a policy enforcement point in these areas. The ESB must also be factored into governance decisions. For example, governance processes determine which services are accessible through the ESB to guarantee loose coupling, and thus, determines which mediations are deployed in the ESB.

Summary

In this introductory article, you learned how the enterprise service bus is a key architectural pattern in SOA and in IBM's SOA Foundation. The article described, in product-independent terms, how the ESB supports service virtualization and aspect-oriented connectivity between interacting participants. The architectural pattern can be implemented using a variety of logical topologies and a variety of middleware technologies and products. Future articles in the series explore various ESB topologies and how they offer value. You'll also take a more detailed look at mediation flow, the relationship with the service registry, and even how IBM ESB products like WebSphere ESB, WebSphere Message Broker and WebSphere DataPower relate to the architectural pattern.

Acknowledgements

Acknowledgements: Special thanks to Rachel Reinitz, Distinguished Engineer, Software Services for WebSphere and Andre Tost, Senior Technical Staff Member and Senior Consulting IT Specialist, Software Services for WebSphere, for their contributions to the article. I also wish to acknowledge the following for motivation and editorial guidance: Rob High, Marc-Thomas Schmidt, and Beth Hutchison.

The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.