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 1. IBM SOA Foundation Reference Architecture logical model view
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.)
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.
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.
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.
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
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).
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.
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.
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: 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.
- For more information about the IBM SOA Foundation, read the white paper, "IBM SOA Foundation: An architectural introduction and overview" (developerWorks, Dec 2005).
IBM provides a variety of materials about the ESB design pattern. For more on this subject, see the following:
- From the IBM Systems Journal, The Enterprise Service Bus: Making service-oriented architecture real (developerWorks, Dec 2005).
- "SOA programming model for implementing Web services, Part 4: An introduction to the IBM Enterprise Service Bus" (developerWorks, Jul 2005).
- "Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture, Part 1: The role of the Enterprise Service Bus" (developerWorks, June 2004).
- "Simplify integration architectures with an Enterprise Service Bus" (developerWorks, Aug 2005).
- "Why do developers need an Enterprise Service Bus?" (developerWorks, Aug 2005).
- Stay current with developerWorks technical events and webcasts.
- Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
- Participate in the discussion forum.
- Check out developerWorks blogs and get involved in the developerWorks community.