WebSphere

Policy Resolution mediation primitive

Use the Policy Resolution mediation primitive to dynamically configure a mediation flow, using mediation policies. Mediation policy information is obtained from WebSphere® Service Registry and Repository (WSRR).

Introduction

You can use the Policy Resolution mediation primitive to retrieve mediation policies from a WSRR registry, and control mediation primitives that come later in the flow. The registry can be local or remote.

The Policy Resolution primitive lets you retrieve a mediation policy for the current Service Component Architecture (SCA) module. If valid mediation policies are found in the registry, their contents can be used to override the dynamic properties of subsequent mediation primitives. Any property that you promote from a mediation primitive in the top-level request, response, or fault flow is also a dynamic property. Mediation policies contain the equivalent of promoted properties (groups, names, and values) and must conform to the Web Services Policy Framework (WS-Policy).

The Policy Resolution mediation primitive has one input terminal (in), two output terminals (out and policyError), and a fail terminal (fail). The in terminal is wired to accept a message and the other terminals are wired to propagate a message. If an exception occurs during the processing of the input message, the fail terminal propagates the input message, together with any exception information. The fail terminal is fired if the run time cannot find an instance of WSRR. If no problems occur, the out terminal propagates the original service message object (SMO) modified by any property overrides that the mediation policies have provided.
Note: There might not be any property overrides. For example, the out terminal is fired if there are no mediation policies for the current SCA module. Also, the out terminal is fired if there are mediation policies, but they do not contain property overrides for the module.
If there is an error while mediation policies are being processed, the policyError terminal is fired. If this happens, mediation policies might still be used to override dynamic properties. The outcome depends on the mediation policy processing model. If property overrides are used, the SMO is modified, otherwise the terminal propagates an unmodified message.

Details

If you add a Policy Resolution primitive to your mediation flow, when the Policy Resolution mediation primitive receives a message it sends search queries to the registry. If there are mediation policies attached to the current module, they are analyzed according to the mediation policy processing model. The resulting property information is copied to the SMO at location /context/dynamicProperty. For each property, the /context/dynamicProperty location stores the group, name, and value. The property group and name are compared to dynamic properties in later mediation primitives. When a match occurs, the value of the dynamic property is overridden.

For example, suppose you create a module that contains one mediation flow component, and the component contains two mediation primitives: a Policy Resolution primitive followed by an XSL Transformation primitive. If you promote the XSL Transformation property, Mapping file, you can override its value at run time, using mediation policies in your registry.

Any dynamic properties not overridden by mediation policy control take their value from the administrative console. However, the administrative console values are not stored in the /context/dynamicProperty location.
Note: You cannot enable and disable individual Policy Resolution primitives from the administrative console.

Mediation policy conditions

Optionally, you can specify conditions that you want the mediation policy to fulfil:
  • To specify conditions, you set XPath expressions in the XPath property. You can specify more than one XPath expression.
  • For each XPath expression, you must provide a condition name using the Policy condition name property.
  • The Policy condition name property can then be used in a gate condition, on a mediation policy attachment in WSRR.
  • At run time, if the gate condition resolves to true, using the XPath expression to extract the condition value, the mediation policy referenced by the mediation policy attachment is applied.

WSRR registry

Before you use the Policy Resolution mediation primitive you might need to add SCA modules, mediation policies, and mediation policy attachment documents to your WSRR registry.

If you want to use the Policy Resolution mediation primitive, the details of your SCA module must exist in the appropriate registry. In addition, you must attach at least one mediation policy to your SCA module.

When you export an SCA module containing a Policy Resolution mediation primitive, 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.

If you load an EAR file containing your SCA module into WSRR, the registry creates an SCA module document and loads any default mediation policies. In addition, you can create your own mediation policies in WSRR but they must refer to the group and alias names of your dynamic properties, and provide property values.

When you have the mediation policies you need, in WSRR, you can attach them to your SCA module. If you want to specify gate conditions on a mediation policy, you must specify them on both the Policy Resolution primitive and on the policy attachment in WSRR.

If you want to use WSRR governance you must make your WSRR policy document governed. Then you can move the policy document, and any associated policies, through the life cycle classifications. If you want to use classifications that are not related to governance, you must add classifications to the WSRR policy, not the policy document. In WSRR, there is a default governance life cycle, but you can define your own. If you want to filter mediation policies according to particular WSRR classifications, including life cycle classifications, you must also define the classifications on the Policy Resolution primitive.

Usage

Using mediation policies, you can develop new service interactions that achieve greater levels of flexibility and administrative control. In addition, you can get new value out of existing systems by adjusting message flows according to the context in which they occur.

When you design your mediation flow, any mediation primitive that occurs after the Policy Resolution primitive can have its dynamic properties overridden (using values from mediation policies). Therefore, to dynamically configure the whole mediation flow, you would put a Policy Resolution primitive at the start of the flow.

You can use mediation policies in many ways. The following are some of the ways in which you can use mediation policies:
  • Activate or deactivate properties. For example, you could turn off message filtering by unsetting the Enabled property of the Message Filter primitive.
  • Set the value of properties.
  • Conditionally set the value of properties. For example, you could apply different message transformations depending on different customer types: one transformation for gold customers and another transformation for silver customers. The mediation policies could contain a different value for the XSL Transformation Mapping File property, depending on the customer type.
Note: You can only override mediation primitive properties if they are dynamic properties. In addition, you must always specify a valid default value for every property you want to override.

WSRR has many classification systems, including life cycle classifications, and you can select mediation policies based on their WSRR classification. This allows you to impose governance on your policies, or create your own classification systems.

Properties

Registry Name
Identifies the WSRR definition to be used by the Policy Resolution mediation primitive. A WSRR definition is created using the server administrative console and provides connection information for a WSRR instance. At least one WSRR definition needs to exist on the server on which your SCA module is installed. If you do not specify a value for the Registry Name, the default registry (WSRR definition) is used.
Policy condition name
The name of a condition that a mediation policy must have. Conditions allow different mediation policies to apply in different contexts. At run time, the conditions must be satisfied before a conditional mediation policy can be used.
Note: In WSRR, you must specify the conditions on the policy attachment objects.
XPath
The XPath location from which the run time gets the mediation policy condition. For example, if an XPath is set to /body/input/customerName and the associated Policy condition name is Customer, the run time sets the value of Customer to whatever it finds at /body/input/customerName.
Comment
Any comments that you want to be saved with the mediation flow component.
Propagate mediation policy to response flow
Defines whether the mediation policy selected on the request flow is propagated to the response flow. By default the mediation policy is not propagated to the response flow. You can propagate the mediation policy to the response flow by selecting the check box.
Classification
A set of classification names, expressed as a list of URIs.
You must go to WSRR to find the URIs of the classifications:
  1. In the navigation pane of the WSRR Web user interface, click Service Documents > Policy Documents.
  2. In the content pane, click a mediation policy document.
  3. Click Edit Classifications.
  4. Optional: If your policy document does not have the classification whose URI you want, select the check box of the classification that you want and click Add >>>.
  5. Select (highlight) the classification whose URI you want, and the URI appears in the table at the bottom of the page.
  6. Click Cancel. Do not add governance classifications using the Edit Classifications method.

At run time, any Classification you specify in WebSphere Integration Developer must be found on a suitable mediation policy in WSRR. WSRR has many classification systems, including life cycle classifications that can be used for governance.

Note:
  • If you want to use WSRR governance you must make the appropriate WSRR policy documents governed. Then you can move the policy documents, and any associated policies, through the life cycle classifications. However, if you want to use classifications that are not related to governance, you must specify the classifications on the WSRR policies that you want to retrieve, not on the policy documents.
  • Mediation policies, in WSRR, have two classifications that are used for internal processing: WESB Mediation Policy and WS Policy Framework 1.5. Do not edit or delete these classifications, or move them to WebSphere Integration Developer.

If you specify one classification in the Policy Resolution primitive and two classifications in WSRR, then the mediation policy can be returned, assuming the names match. For example, if the Policy Resolution primitive specified a classification of Test and the WSRR policy object specified classifications of Test and Managed, then the mediation policy would match the query. However, if the Policy Resolution primitive specified classifications of Test and Managed but the WSRR policy object only specified a classification of Managed, then the mediation policy would not match the query.

WSRR defines classification systems using the Web Ontology Language (OWL), in which each classifier is a class and has a URI. OWL implements a simple hierarchical system. For example, a bank account could start with the following details:

  • Account
    • Identifier
    • Name
      • First name
      • Second name
    • Address
      • First line of address
      • Second line of address

Specifying a classification of Address matches any object classified as Address, First line of address or Second line of address.

Table 1. Policy Resolution mediation primitive properties
Property Valid Values Default
Registry name String The default registry
Policy condition name String  
XPath XPath  
Comment String  
Propagate mediation policy to response flow Boolean: true or false false
Classification List of URIs  

Considerations

Consider the following when you using the Policy Resolution mediation primitive:


reference Reference topic

Terms of use | Feedback


Timestamp icon Last updated: 20 June 2010 00:39:59 BST (DRAFT)


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.wbit.help.medprim620.doc/ref/rwesb_PolicyResolutionmediationprimitive.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).
iDoc on