To use mediation policies effectively, you should understand
the concepts behind them and plan your overall system. This topic
explains the concepts, and also explains how the development and administration
teams interact to produce mediation policies.
Introduction
When you use WebSphere® Integration Developer to create
SCA modules that contain mediation flows, any module property that
you choose to promote (make visible to the run time) is also a dynamic
property, so long as the property exists at
the top level. Dynamic properties can be overridden, at run time,
using mediation policies in a registry. After you deploy an SCA module
to your run time, you can see the dynamic module properties, and values,
from the administrative console; using mediation policies you can
override these values. Whether property values are overridden for
a service interaction depends on the message being processed and the
configuration of the mediation policy.
Details
When you export your SCA module, WebSphere Integration Developer
generates a default mediation policy for each property group in your
SCA module. For example, if your SCA module contains three property
groups, WebSphere Integration
Developer generates three default mediation policies each containing
all the dynamic properties belonging to one group. The default mediation
policies represent the values given to all dynamic properties, at
development time. Although WebSphere Integration
Developer generates default mediation policies, it does not attach
them to the SCA module. You must decide how to use the default mediation
policies.
Generally, you should use default mediation policies
without any associated conditions, and create your own mediation policies
if you want to have conditional mediation policies. Before you can
create conditional mediation policies, in WebSphere Service Registry and Repository
(WSRR), you must define the conditions in WebSphere Integration Developer. In WSRR,
you create conditions on the mediation policy attachment that WSRR
generates when you attach a mediation policy to an SCA module. At
run time, the conditions (sometimes referred to as gate conditions)
must be met before the mediation policy can be used.
You can use WSRR
classifications with your mediation policies. WSSR supports many classification
systems, including life cycle classifications that you can use to
govern your mediation policies.
Overview of development and administrative tasks
In
order to use mediation policies, the developer, the runtime administrator,
and the WSRR administrator must work together. They must create and
integrate the SCA modules and mediation policies required.
- From WebSphere Integration
Developer:
- Create an SCA module containing a Policy Resolution mediation
primitive. Generally, any other mediation primitives in the SCA module
should come after the Policy Resolution mediation primitive, and have
at least one dynamic property.
- Promote the module properties you want to override, assigning
each property an appropriate alias and group.
- Optional: Create conditions on the Policy Resolution
mediation primitive.
- Optional: Create classifications
on the Policy Resolution mediation primitive. The classifications
must match the WSRR classification URIs.
- Export the SCA module.
Note: If you have created a versioned SCA
module, you must export your module as a command line deployment;
otherwise, you can export your SCA module in an EAR file.
- From the run time:
- Ensure you have a suitable WSRR definition for your SCA module.
- Optional: If you have a versioned SCA module, you
must run serviceDeploy on each of the exported
modules to generate an EAR file.
- Optional: If you have a versioned SCA module that
you want to deploy to clusters, you must run createVersionedSCAModule to
create a new EAR file that contains a unique instance of a versioned
SCA module. You must create one instance of the module for every cluster
you want to deploy to.
Note: You must load your versioned SCA modules
into WSRR from the new EAR files.
- Deploy the SCA module.
- From WSRR:
- Load the SCA module.
- Optional: Create your own mediation policies.
- Attach the appropriate mediation policies to your SCA module.
- Optional: Create gate conditions.
- Optional: Make your policy document
governed.
- Optional: Add non-life-cycle classifications
to your policies.
Planning
Before you develop mediation policies
you should plan your overall system:
- Decide which WSRR instance you will use.
- Decide what mediation primitive properties need to be overridden
using mediation policies.
- Decide on the property group name (or names). The group name helps
to form the namespace of the mediation policy.
- Decide on your mediation policy pattern.
- Optional: Decide if you need to create your own mediation
policies, rather than use only the default mediation policies. If
you choose to create your own mediation policies, you should decide
on their identifiers. The namespace and identifier, when taken together,
must be unique across the instance of WSRR that contains the mediation
policy.
- Decide if you need any conditional mediation policies. At run
time, gate conditions must be satisfied before a conditional mediation
policy can be used. In WebSphere Integration
Developer, every gate condition must be specified on the Policy Resolution
mediation primitive as a Policy condition name.
In WSRR, the gate conditions are specified on the mediation policy
attachment.
- Decide if you want to use WSRR classifications.
You must specify the classifications you want to use, in both WebSphere Integration Developer
and in WSRR.