Mediation components operate on message flows between service components.
The capabilities of a mediation component are implemented by mediation
primitives, which implement standard service implementation types.
A mediation component has one or more flows; for example, one for request
and one for reply.
WebSphere ESB supports
a supplied set of mediation primitives, which implement standard mediation
capabilities for mediation modules deployed into WebSphere ESB.
If you need special mediation capabilities, you can develop your own custom
mediation primitives.
A mediation primitive defines one "in" operation that processes or
handles messages that are represented by service message objects. A mediation
primitive can also define "out" operations that send messages to another
component or module.

Mediation primitives typically function at the level of a single operation,
with possible mediation of the request (input) and response (output). In some
cases, you can specify mediation primitives down to the level of a single
parameter on an operation; for example, selectors can operate at the operation
level or parameter level.
You can use WebSphere Integration Developer to
graphically model and assemble mediation components from mediation primitives,
and assemble mediation modules from mediation components.
The following set of mediation primitives are supported by
WebSphere ESB:
- Custom Mediation
- Runs custom logic. The Custom Mediation primitive can call an external Service Component Architecture (SCA) component,
that you provide.
- The operation that is called must be a two-way operation.
- The target SCA component must
exist in the same mediation module as Custom Mediation primitive.
- Database Lookup
- Modifies messages, using information from a user-supplied database.
- You must set up a database, datasource and any server authentication settings
for the Database Lookup mediation primitive to use.
- The Database Lookup mediation primitive can read from only one table.
- The specified key column must contain a unique value.
- The data in the value columns must be either a Java primitive or a Java
String (or be able to be cast to a Java primitive or a Java String).
- Fail
- Generates a failure in the flow.
- Message Filter
- Routes messages down different paths, based on the message content.
- Message Logger
- Logs messages in a database. The messages are stored as XML, therefore
data can be post-processed by XML-aware applications.
- The database schema is defined by IBM.
- The default installation for WebSphere ESB creates
a Cloudscape database and datasource. By default, WebSphere Integration Developer configures
Message Logger mediation primitives to use this Cloudscape database.
- If you want to create your own database and datasource, using the administrative
console, then WebSphere ESB provides
data definition language (ddl) files that describe the table schema. The Table.ddl
files are stored in: install_root/util/EsbLoggerMediation/database_
type/Table.ddl. Where database_ type refers to
the type of database, for example, CLOUDSCAPE_V50. If you create your own
database and want to use the default JNDI name for your datasource, then you
must remove the default datasource.
- Stop
- Stops a particular path in the flow, without generating an exception.
- XSLT
- Transforms messages.
- The XSLT mediation primitive can change the headers or the body of your
messages.
- You transform messages using an XSLT (Extensible Stylesheet Transformations)
1.0 transformation. The transformation operates on an XML serialization of
the message.