SOA

Service-oriented architecture (SOA) is never established in a vacuum. In any real life situation, an existing IT environment must be taken into consideration, offering functionality -- and data -- that cannot simply be replaced by a set of new services. Hence, a key aspect of building an SOA is to decompose existing applications into smaller blocks (that is, the "services") that communicate over standard protocols and have well-defined interfaces. The advantage of this is that such environments are more flexible, without tight coupling between various parts of the overall system.

This concept of loosely coupled and platform independent services is further advanced by the use of an Enterprise Service Bus (ESB). Among other things, an ESB serves as the "glue" between services that use different data and message formats, network protocols, and programming languages. The ESB serves as a level of indirection between a service consumer and a service provider, enabling the deployment of mediations that apply quality of service to an interaction, or to perform required data transformations, to name just two examples.

In this series of articles, we will look at a concrete example of an ESB serving as such an intermediary. We will leverage the IBM WebSphere Enterprise Service Bus (WebSphere ESB) V6.0.1 product to connect service consumers and service providers, using JMS as the messaging mechanism. In this first article, we will take a brief look at the WebSphere ESB product and its tooling environment, namely WebSphere Integration Developer V6.0.1. Part 2 will describe the actual ESB scenario and explain how we build the service consumer and service provider, and then Part 3 will show how we build the mediation between the consumer and the provider that runs in WebSphere ESB. You will learn how to deploy and run the solution, and we will provide all of the code artifacts needed for you to do so. The Enterprise Service Bus and Java Message ServiceAn SOA consists of service consumers and service providers that communicate with each other. They typically do so through an Enterprise Service Bus. Each service has a service definition that describes, among other things, the messages it accepts from consumers and, unless it is a "one-way" service, the messages it returns to its consumers. Thus, building an ESB has much to do with messaging. The ability to send and receive messages in a robust, fast, and reliable way has been a key requirement of IT systems for a long time, and the advent of the ESB does not change that at all; it just introduces additional requirements towards a solution -- for example, support for standards describing message formats, transactional exchanges between services, and so on.

At the same time, systems based on the Java J2EE platform usually utilize the Java Message Service (JMS) API for their messaging needs. Simply put, the JMS standard describes how to send messages from one application to another, potentially exploiting a transactional quality of service.

Given that many applications already use JMS, and given that the services within an SOA need a way to do messaging, it makes perfect sense to use JMS in the context of an ESB. Each ESB must be capable of receiving messages via JMS from a service consumer and forward them to the appropriate service provider, over JMS, or over a different protocol (like HTTP), and vice versa. Moreover, JMS defines several different types of messages that can be sent. For example, a Text message contains a string representation of a message; an Object message contains a serialized Java object; a Map message contains a map of key/value pairs and so forth. Web services typically use SOAP as their message format, but many applications leverage plain XML. Hence, an ESB must support a wide variety of network and message protocols. Figure 1 shows a number of protocol combinations that service consumers and service providers may support. Notice that the ESB acts as the intermediary between the two, enabling connectivity between any consumer and provider regardless of protocol.

How to set up WebSphere ESB to support these different combinations is exactly what we will discuss in this series. First, though, let us look at the product itself and its main components.

WebSphere ESB V6.0.1
The WebSphere ESB product is part of the IBM SOA Foundation. Even though its version number may suggest that this product has been around for a long time, it was released for the first time at the end of 2005, and shares many components with other already existing members of the WebSphere product family. For example, it uses the J2EE-based IBM WebSphere Application Server as its core runtime. WebSphere Application Server offers a JMS implementation that is reused by WebSphere ESB. It also uses the recently announced Service Component Architecture (SCA) as its basic programming model, and it shares the SCA runtime with WebSphere Process Server.

Figure 2 shows an overview of WebSphere ESB and its base components.

WebSphere ESB supports basic messaging via JMS, and can communicate with WebSphere MQ via the MQLink feature in WebSphere Application Server. Web services utilizing SOAP over HTTP and SOAP over JMS are plugged into the ESB, with support for many Web services standards and a UDDI registry provided through the application server. WebSphere ESB can be used not only from standard J2EE clients, but also offers client support for C/C++ and .Net®. Moreover, it provides connectivity to a large number of legacy environments through WebSphere Adapters.

WebSphere ESB and Service Component Architecture
We mentioned above that the programming model utilized by WebSphere ESB is based on SCA. SCA describes a complete service programming model, across a number of components that can all be described and accessed in the same way, namely as services. Such components can be BPEL processes, business rules, human tasks, or plain Java components, just to name some examples. WebSphere ESB introduces a new component type to the SCA model, namely mediation flow components. From the perspective of SCA, a mediation flow component is no different than any other service component, in that a mediation component:

• exists in a module (more specifically, it exists in a mediation module, which is how it is deployed into a server runtime).
• has an interface, described either in Java or in WSDL.
• is exposed to clients via exports, which can have multiple bindings for different protocols (we'll get back to this).
• has dependencies to other service components via imports, which also have bindings describing protocol details.

In one respect, the mediation flow programming model is unique; it enables binding-specific information about the service message being processed (typically header-type information) to be accessed and manipulated. For a detailed description of SCA and its programming model, and how to build and deploy components through it, see the Building SOA solutions with the Service Component Architecture article series. (For the remainder of this series, we will assume you have basic knowledge of SCA, simply so that we don't repeat things that have been sufficiently covered elsewhere.)

Mediation flow components provide a new kind of implementation for a service component, namely that of a mediation flow. A mediation flow is normally built using a visual flow editor, and describes how both request and response messages flow through a series of mediation primitives. These primitives can read and change messages, or route ("filter") them to different targets. While you can build your own custom mediation primitives, the product comes with a number of predefined ones for:

• XSLT transformation
• Message logging
• Message filtering
• Database access.

Figure 3 shows a mediation flow component implementation that uses a number of mediation primitives to implement a response flow.