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:

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.

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).

When selecting WESB, here are some of the most typical considerations or topics to consider include: