An Enterprise Service Bus (ESB) is fundamentally an architectural pattern. As explained through the IBM SOA reference architecture, from an SOA point of view, an ESB provides the connectivity layer between services and serves as the core backbone for the SOA—it's the nervous system. The service consumers in a service interaction are connected to the ESB, rather than directly to one another including the service provider. When the service request connects to the ESB, the ESB takes responsibility for delivering its requests, using messages, to a service provider offering the required function and quality of service. The ESB facilitates requester provider addresses despite mismatched protocols, interaction patterns, or service capabilities. An ESB can also enable or enhance monitoring and management. The ESB provides virtualization and management features that implement and extend the core capabilities of SOA. So what are the core capabilities that an ESB should support? The fundamental capabilities of an ESB include:
Message processing
Mediations and Communications
Service interactions
Integration
Quality of services
Security
Service level
Management and autonomic services
Infrastructure intelligence
SOA mandates that the service providers and the service consumers be loosely coupled and support the use of explicit interfaces. This flexibility enables IT change with very limited impact such as the update or replacement of a given Business Service or the development of a new composite solution which leverages existing services. That is, the power of the ESB enables you to realize the full value of SOA. As shown in the following figure, interposing the ESB between the participants in an SOA ecosystem enables you to modulate their interactions through a logical construct called mediation. Mediations operate on messages in transit between service consumers and service providers. For complex interactions, mediations can be chained sequentially. The following figure lists the core capabilities that are provided by WESB and how they interact with the various backend applications and how they expose them to the service consuming layers north of it (Process Services and Business Services). In some cases, Interaction Services can also become consumers of these WESB mediations. But it is always preferable to have the mediation wrapped into Business Services because more than likely, you would want to expose core business functions to the service consumers. In doing so, you can account for service variability within the Business Service through the use of business policies and rules. An example would be that WESB can expose mediations that manipulate customer data from one or many customer information management systems. Which customer information system is chosen will depend on the business context of the request (examples include customer location – North America or Europe, type of customer—residential or commercial, service level agreements with the customer, or request priority and so on). All these account for service variability behavior and how the service should behave based on a combination of such cases. Having such a kind of processing logic within the WESB mediation flows is not preferable for the simple reason being it can change as business conditions change. Hence WESB, in an SOA architecture, should be positioned to deal with the hardcore integration and connectivity needs and should not be overloaded with capabilities it is not meant to do architecturally.
As depicted in the core platform architecture for WPS (as mentioned earlier WPS includes WESB), WESB is also built on top of WebSphere Application Server. WESB mediation flows provide routing, transformation, and logging operations on the messages. The information that governs their behavior is often held in headers flowing with the business messages. WESB also adopts the same programming model as WPS (explained in the previous sections), but also introduces the Service Message Object (SMO) pattern for SDOs to support this pattern of operating on the messages, including its headers. We will discuss in detail about SMO in the coming chapters.
As shown in the WPS platform architecture, mediation flows belong to the support services. The mediation flows provide capabilities that include:
Centralizing the routing logic so that service providers can be exchanged transparently
Performing tasks such as protocol translation and transport mapping
Acting as a facade to provide different interfaces between service consumers and providers
Adding logic to provide tasks such as logging
The following figure is an example of a mediation flow that provides routing, transformation, and logging operations on the messages through the use of Mediation primitives. Mediation primitives are the smallest building blocks in WESB and are contained within a mediation flow. With Mediation primitives, you can change the format, content, or target of service requests, as well as log messages, perform database lookups, and so on and so forth. WESB can interconnect a variety of different service consumers and providers using standard protocols including JMS, SOAP/HTTP, SOAP/JMS, HTTP, and so on. It supports web services standards including WS-Security and WS-Atomic Transactions. It also includes Universal Description Discovery and Integration (UDDI), Version 3.0 that can be used to publish and manage service end point metadata, which enables service definitions to be made available to client applications. WESB also supports IBM WebSphere Service Registry and Repository and is used for cases where you may have to do dynamic endpoint lookup.
There are three categories of usage patterns when building WESB-based solutions:
Now let's look in more detail at some of the most common usage scenarios that belong to the preceding categories that WESB can be used in.
These are the very basic set of patterns that allow service interactions to occur via the WESB. Types of interactions include:
These are the next level of message exchange and manipulation patterns. This category of patterns typically deals with message mediations and having to "work on" the messages before allowing service interactions to occur. Some example message exchanges include:
Protocol Switch / Transformation—typically dealing with protocol transformation, for example, receiving a JMS request from a service consumer and going to a service provider who supports MQ.
Data Transformation —transforms and translates the incoming message from one schema format to the target schema format. You may have to perform and apply data validation, integrity, and transformation rules.
Data Enrichment—augments or enriches the incoming message payload by fanning-out and fetching data from one to many sources and fanning-in.
Content Based Routing—routes the message from a service consumer to one among the many service providers based on some message content.
Message Observer—monitors and observes messages (non-invasively) as they pass through the mediation by applying filters. Examples could be watching out for too many ATM transactions on the same account, observing response time from a particular backend application, and monitoring for SLA breaches, logging, and auditing messages.
This category of patterns deals with how WESB can be deployed in a variety of ways including, federated, brokered, and so on.
Global ESB: All services share one namespace, and each service provider is visible to every service requester across a heterogeneous, centrally administered, geographically distributed environment. Used by departments or small enterprises where all the services are likely to be applicable throughout the organization.
Directly connected ESB: A common service registry makes all of the services in several independent ESB installations visible. It is used where services are provided and managed by a line of businesses but made available enterprise-wide.
Brokered ESB: Bridge services that selectively expose requesters or providers to partners in other domains regulate sharing among multiple ESB installations that each manages its own namespace. Service interactions between ESBs are facilitated through a common broker that implements the bridge services. Used by departments that develop and manage their own services, but share a few of them or selectively Access Services provided across the enterprise.
Federated ESB : One master ESB to which several dependent ESBs are federated. Service consumers and providers connect to the master or to a dependent ESB to Access Services throughout the network. Used by organizations that want to federate a set of moderately autonomous departments under the umbrella of a supervising department.
It's quite possible for an organization to have multiple ESB configurations/topologies. It's all driven by business needs and the ESB topologies may change as business requirements change. The flexibility and "service virtualization" provided by the ESB is achieved through what architects call "separation of concerns", the clear separation between the applications which run the business (including Business Services and business processes) and the ESB (the infrastructure for connecting applications and services together).
Note
IBM has three ESB products in its offering portfolio:
WebSphere Enterprise Service Bus
WebSphere Message Broker is used in scenarios where the infrastructure has heterogeneous applications with standard and non standard interfaces, protocols, and data formats
WebSphere DataPower Integration Appliance XI50 is Appliance-based ESB for simplified deployment and hardened security
When selecting WESB, here are some of the most typical considerations or topics to consider include:
Focus on standards-based interactions using XML, SOAP, and WS*
Mediate and integrate to existing systems using JMS, MQ, Web Services, and so on
Support for protocols including HTTP, MQ, JMS, RMI, and so on
Need for message transformation using XSLT
Use WPS for process choreography and orchestration (common tooling, runtime infrastructure)
Your team has skills with WebSphere Application Server Administration and Java coding
Reliability and extensive transactional support are key requirements