Mediation flow 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 flow 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 an "in" operation that processes
or handles messages that are represented by service message objects
(SMOs). A mediation primitive can also define "out" operations
that send messages to another component or module.
Figure 1. Mediation module containing three mediation primitives
You can use WebSphere Integration Developer to
configure mediation primitives and set their properties. Some of these
properties can be made visible to the runtime administrator by promoting
them. Any mediation primitive property that can be promoted can
also be a dynamic property. A dynamic property can be overridden,
at run time, using a policy file.
WebSphere Integration Developer also
allows you to graphically model and assemble mediation flow components
from mediation primitives,
and assemble mediation modules from
mediation flow components. The administrative console refers to
mediation modules as SCA modules.
WebSphere Integration Developer also
allows the definition of subflows in modules or their dependent libraries.
A subflow can contain any mediation primitive except for the Policy
Resolution mediation primitive. A subflow is invoked from a request
or response flow, or from another subflow using the Subflow mediation
primitive. Properties promoted from mediation primitives in a subflow
are exposed as properties on the Subflow mediation primitives. These
may then be promoted again until they reach the module level at which
point they can then be modified by the runtime administrator.
Supported mediation primitives
The following
set of
mediation primitives are
supported by
WebSphere ESB:
- Business Object Map
- Transforms messages.
- Defines message transformations using a business object map, which
can be reused.
- Allows you to define message transformations graphically, using
the business object map editor.
- Can alter the content of a message.
- Can transform an input message type to a different output message
type.
- Custom Mediation
- Allows you to implement your own mediation logic in Java™ code. The Custom Mediation primitive combines
the flexibility of a user-defined mediation primitive, with the simplicity
of a pre-defined mediation primitive. You can create complex transformations
and routing patterns by:
- Creating Java code.
- Creating your own properties.
- Adding new terminals.
You can call a service from a Custom Mediation primitive, but
the Service Invoke mediation primitive is designed to call services
and provides additional functionality, such as retry.
- Data Handler
- Allows you to transform a part of a message. It is used to convert
an element of a message from a physical format to a logical structure
or a logical structure to a physical format. The primary usage of
the primitive is to convert a physical format, such as a Text string
within a JMS Text Message object, into a logical Business Object structure
and back again. This mediation is commonly used to:
- Transform a section of the input message from a defined structure
to another - an example of this would be were the SMO includes a string
value that is comma delimited and you want to parse this into a specific
Business Object.
- Alter the message type – an example would be when a JMS export
has been configured to use a JMS basic typed data binding and within
the mediation module the integration developer decides that the content
should be inflated to a specific BO structure.
- Database Lookup
- Modifies messages, using information from a user-supplied database.
- You must set up a database, data source, and any server authentication
settings for the Database Lookup mediation primitive to
use. Use the administrative console to help you do this.
- 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 simple XML schema
type, or an XML schema type that extends a simple XML schema type.
- Endpoint Lookup
- Allows for the dynamic routing of requests, by searching for service
endpoints in a repository.
- Service endpoint information is retrieved from a WebSphere Service
Registry and Repository (WSRR). The WSRR registry can be local or
remote.
- You make registry changes from the WSRR administrative console.
- WebSphere ESB needs
to know which registry to use, therefore, you must create WSRR access
definitions using the WebSphere ESB administrative
console.
- Event Emitter
- Enhances monitoring by letting you send events from inside a mediation
flow component.
- You can suspend the mediate action by deselecting the check box.
- You can view Event Emitter events using the Common Base Events
(CBE) browser on WebSphere ESB.
- You should only send events at a significant point in a mediation
flow, for performance reasons.
- You can define the parts of the message that the event contains.
- The events are sent in the form of Common Base Events and are
sent to a Common Event Infrastructure server.
- To fully use the Event Emitter information, event consumers need
to understand the structure of the Common Base Events. The Common
Base Events has an overall schema, but this does not model the application
specific data, which is contained in the extended data elements. To
model the extended data elements, the WebSphere Integration Developer tools
generate a Common Event Infrastructure event catalog definition file
for each of the configured Event Emitter mediation primitives.
Event catalog definition files are export artifacts that are provided
to help you; they are not used by WebSphere Integration Developer or by
the WebSphere ESB runtime.
You should refer to the event catalog definition files when you create
applications to consume Event Emitter events.
- You can specify other monitoring from WebSphere ESB. For
example, you can monitor events to be emitted from imports and exports.
- Fail
- Stops a particular path in the flow, and generates an exception.
- Fan In
- Helps aggregate (combine) messages.
- Can only be used in combination with the Fan Out mediation primitive.
- Together, the Fan Out and Fan In mediation primitives allow aggregation
of data into one output message.
- The Fan In mediation primitive receives messages until a decision
point is reached, then one message is output.
- The shared context should be used to hold aggregation data.
- Fan Out
- Helps split and aggregate (combine) messages.
- Together, the Fan Out and Fan In mediation primitives allow aggregation
of data into one output message.
- In iterate mode, the Fan Out mediation primitive lets you iterate
through a single input message that contains a repeating element.
For each occurrence of the repeating element, a message is sent.
- The shared context should be used to hold aggregation data.
- HTTP Header Setter
- Provides a mechanism for managing headers in HTTP messages.
- Can create, set, copy, or delete HTTP message headers.
- Can set multiple actions to change multiple HTTP headers.
- MQ Header Setter
- Provides a mechanism for managing headers in MQ messages.
- Can create, set, copy, or delete MQ message headers.
- Can set multiple actions to change multiple MQ headers.
- SOAP Header Setter
- Provides a mechanism for managing headers in SOAP messages.
- Can create, set, copy, or delete SOAP message headers.
- Can set multiple actions to change multiple SOAP headers.
- Message Element Setter
- Provides a simple mechanism for setting the content of messages.
- Can change, add or delete message elements.
- Does not change the type of the message.
- The data in the value columns must be either a simple XML schema
type, or an XML schema type that extends a simple XML schema type.
- Message Filter
- Routes messages down different paths, based on the message content.
- You can suspend the mediate action by deselecting the check box.
- Message Logger
- Logs messages in a relational database or through your own custom
logger. The messages are stored as XML, therefore, data can be post-processed
by XML-aware applications.
- You can suspend the mediate action by deselecting the check box.
- The rational database schema (table structure) is defined by IBM.
- By default, the Message Logger mediation primitive uses the Common
database. The runtime maps the data source at jdbc/mediation/messageLog to
the Common database.
- You can set Handler implementation classes to customize the behavior
of the custom logger. Optionally, you can provide Formatter implementation
classes, Filter implementation classes, or both to customize the behavior
of the custom logger.
- Policy Resolution
- Allows for the dynamic configuration of requests, by searching
for service endpoints, and associated policy files, in a repository.
- You can use a policy file to dynamically override the promoted
properties of other mediation primitives.
- Service endpoint information and policy information is retrieved
from a WebSphere Service Registry and Repository
(WSRR). The WSRR registry can be local or remote.
- You make registry changes from the WSRR administrative console.
- WebSphere ESB needs
to know which registry to use, therefore, you must create WSRR access
definitions using the WebSphere ESB administrative
console.
- Service Invoke
- Calls a service from inside a mediation flow, rather than waiting
until the end of the mediation flow and using the callout mechanism.
- If the service returns a fault, you can retry the same service
or call another service.
- The Service Invoke mediation primitive is a powerful mediation
primitive that can be used on its own for simple service calls, or
in combination with other mediation primitives for complex mediations.
- Set Message Type
- During integration development, lets you treat weakly-typed message
fields as though they are strongly-typed. A field is weakly-typed
if it can contain more than one type of data. A field is strongly-typed
if its type and internal structure are known.
- At runtime, the Set Message Type mediation primitive lets you
check that the content of a message matches the data types you expect.
- Stop
- Stops a particular path in the flow, without generating an exception.
- Type Filter
- Allows you to direct messages down a different path of a flow,
based on their type.
- XSL Transformation
- Transforms messages.
- Allows you to perform Extensible Stylesheet Language (XSL) transformations.
- You transform messages using an XSLT 1.0 transformation. The transformation
operates on an XML serialization of the message.