Mediation service applications intercept and modify messages that are passed between existing services (providers) and clients (requesters) that want to use those services. Mediation services are implemented using mediation modules that contain mediation flows.
Mediation modules can be deployed on the WebSphere® Enterprise Service Bus or the WebSphere Process Server.
In service-oriented architecture (SOA), services represent business functions that can be reused and combined in an ad hoc manner to create responsive business systems. These services have loosely coupled connections, rather than being connected directly to each other.
To illustrate the concepts covered in this topic, we will use an example of a simple mediation service that provides stock quotes. A client application provides a query containing a stock symbol and customer ID to the mediation service, which processes the query. The customer's subscription level is determined, and depending on the level of subscription, the query is routed to the appropriate service provider. The quote that is returned from the service provider is converted into the customer's preferred currency before it is returned to the client application.
We are using a mediation service because we want to use different interfaces from two external service providers, and expose a single interface to the client application. We also need to build the service quickly, with the ability to change on demand, and without modeling a business process.
Stock Quote example
In the stock quote example, these are the parts in the mediation module, as seen in the Assembly editor.
Services provide access to their business functions through interfaces, so that the service can be used or invoked. Mediation modules and business integration modules have interfaces in their exports, so that the module can be invoked. The interface defines the operations that can be called and the data that is passed, data such as input arguments, returned values, and exceptions. In mediation flow components, this data is passed in the form of messages.
In a mediation flow component, the interface that allows the service requester to access the mediation through an export is called a source interface.
A mediation flow component accesses a service provider (or import) through a reference which specifies the interface that is used by the import to invoke the service. In a mediation flow component, this reference is called a target reference.
Stock Quote example
These are the interfaces and references that are used in the Stock Quote example:
Stock Quote example
In the stock quote example, StockQuote_MediationFlowComponent is the mediation flow component that accepts a customer ID and symbol as input, processes the message, and returns the quote in the currency preferred by the customer. These are the parts of the mediation flow component
A mediation flow consists of a sequence of processing steps that are executed when an input message is received. A mediation flow is created in the Mediation Flow editor by including a number of mediation primitives that define processing steps. Connections represent the flow of the message between the mediation primitives.
Stock Quote example
In the Stock Quote example, the mediation flow is defined by the following operation connections:
See the topics "Mediation Flow editor" and "Building mediation flows" under related links for more information.
.Mediation flows
consist of a sequence of mediation primitives, which define processing
steps. A mediation primitive receives a message, processes it and propagates
the processed message to the next primitive or node in the flow. For example,
a Database Lookup primitive retrieves a value from a database and sets it
in the message. A ready-made set of mediation primitives is available from
the Mediation Flow editor palette. If you need mediation capabilities that
are not provided by this set of primitives, you can create custom mediation
primitives to call your own Java implementation or an imported service.
Mediation primitives have terminals which receive and propagate messages.
For example, these are the terminals of a Message Logger:
As defined earlier, a message is a communication sent from one application or service to another application or service. Messages in mediation flows are represented as service message objects (SMOs) .
Service message objects are enhanced business objects that include the application data and header information related to the transport protocol used to invoke a service such as SOAP or JMS. A service message object is composed of a body that contains the application data (also known as the payload or operation message) in a business object, and headers containing additional context information. You can use XPath 1.0 expressions to access elements in a message. The following picture represents a service message object:
Most mediation primitives have properties that are specified using an XPath 1.0 expression; for example the root property takes an XPath 1.0 expression which specifies the part of the message that is available to the primitive for processing. You can also use an XPath 1.0 expression to identify one or more fields in a message, and use these fields to filter or select by specifying a value.
See "Building XPath expressions" in the topic "Building mediation flows" under related tasks for an example of the relationship between a business object in an interface and an XPath 1.0 condition.
Typically, interfaces and operations of disparate services are not identical, and the service message object from the source needs to be transformed into a format that can be accepted by the target. An XSL transformation mediation primitive is required when the source and target message types are different.
To transform the message in the Mediation Flow editor, define the scope of the message to be transformed with an XPath 1.0 expression. Then, map the source and target service message objects, using the XML Mapping editor.
Related information