Mediation policy processing model

The mediation policy processing model explains the conditions under which information is taken from mediation policies and applied to message flows.

Introduction

The mediation policy model describes how the runtime environment calculates the effective mediation policy for a particular scope, and when the runtime environment applies intersection rules. For a summary of the Web Services Policy 1.5 Framework terminology, see the end of this topic.

At run time, the following actions occur:
  1. If the Policy Resolution primitive has a Policy Scope property of Module or Intersection, the runtime environment calculates the effective policy for the SCA module. To calculate the effective policy, the runtime environment must merge the mediation policies that belong to the module.
  2. If the Policy Resolution primitive has a Policy Scope property of Target Service or Intersection, the runtime environment calculates the effective policy for the target service. To calculate the effective policy, the runtime environment must merge the mediation policies that belong to the target service.
    Note: If you want to use more than one WSRR object type to represent the target service, you should always attach mediation policies to the most granular scope point. For example, because a portType can apply to more than one binding, any mediation policies you attach to the portType should contain assertions that are binding independent. Be aware that by using more than one WSRR object type to represent the target service, you can significantly increase the level of complexity. The Web Services Policy 1.5 framework states that an effective policy is calculated for each policy subject, and the effective policies are then merged. Therefore, if you define mediation policies for all the target service scope points that are supported, the runtime environment would take the following actions:
    1. Calculate the effective policy for the endpoint policy subject, by merging the mediation policies attached to the port, binding, and portType objects.
    2. Calculate the effective policy for the service policy subject, by merging the mediation policies attached to the service object.
    3. Merge the effective policy of the endpoint policy subject with the effective policy of the service policy subject. If property values conflict, the effective policy of the endpoint policy subject takes precedence.
  3. If the Policy Resolution primitive has a Policy Scope property of Intersection, the runtime environment applies policy intersection rules to determine if the two effective policies are compatible (according to the Web Services Policy 1.5 framework).

Hierarchy of mediation policies

In a message flow, you can override the values of dynamic properties defined for the current SCA module. The runtime environment applies the following rules to decide which property values to apply to a message flow:
  1. Mediation policies with gate conditions have the highest precedence. Therefore, property values defined by these mediation policies have the highest precedence.
    Note: Before a mediation policy with gate conditions can be further evaluated, all of the gate conditions must be met.
  2. Mediation policies without gate conditions have a lower precedence. Therefore, property values defined by these mediation policies have a lower precedence.

Administrative console values are used if there is no suitable property in a mediation policy.

Merging mediation policies

If multiple mediation policies (at the same precedence) contain the same dynamic property, the mediation policies are merged. In this case, the value of the property must be the same in all the merged mediation policies. Any mismatch is termed a policy error, which means that there is no mediation policy for that policy merge.

Therefore, the merging of mediation policies has the following steps:
  1. Process the highest-precedence mediation policies.
    1. Merge the mediation policies.
    2. If any property occurs in multiple mediation policies, the value of the property must be the same in all mediation policies.
      • If there are no property mismatches, the values of the properties are stored in the service message object (SMO).
      • If there are property mismatches, no properties from this precedence-level are used.
        Note: Policy processing continues to the lower-precedence mediation policies, but when that processing is complete the output will be sent to the policyError terminal.
  2. Process the lower-precedence mediation policies.
    1. Merge the mediation policies.
    2. If any property occurs in multiple mediation policies, the value of the property must be the same in all mediation policies.
      • If there are no property mismatches, the values of the properties are stored in the SMO, unless they have already been set by the highest-precedence mediation policies.
      • If there are property mismatches, no properties from this precedence-level are used.
        Note: If a property has been successfully set in the highest-precedence policies, but it causes a mismatch in the lower-precedence policies, the normal rules apply. Because there has been a policy merge error, no mediation policies from the lower-precedence level are used; the output will be sent to the policyError terminal. The value from the highest-precedence policies is used.

Any dynamic property that has not been assigned a value from a mediation policy document, is assigned the value shown by the administrative console.

Example: Successful merge

The following example shows a successful merge of mediation policies, attached to an SCA module.

The SCA module has the following promoted properties:
  • Property_1
  • Property_2
  • Property_3
  • Property_4
  • Property_5
In addition, the SCA module has the following mediation policies attached:
  • Policy_X, with associated conditions
  • Policy_XX, with associated conditions
  • Policy_Y, with no associated conditions
There are no mismatches between property values, at the same precedence.
Table 1. Example showing a successful merge of mediation policies
Mediation policy precedence Mediation policy name Promoted property: alias name Promoted property: value Use this promoted property value Merged mediation policy values Properties used for message flow
Highest precedence: with conditions Policy_X Property_1 A Yes Property_1 = A Property_1 = A
Property_2 B Yes Property_2 = B Property_2 = B
Policy_XX Property_3 C Yes Property_3 = C Property_3 = C
Lower precedence: without conditions Policy_Y Property_1 D No    
Property_4 E Yes Property_4 = E Property_4 = E
Administrative console promoted properties Property_1 F No    
Property_2 G No    
Property_3 H No    
Property_4 I No    
Property_5 J Yes   Property_5 = J

Example: Unsuccessful merge

The following example shows an unsuccessful merge of mediation policies, attached to an SCA module.

The SCA module has the following promoted properties:
  • Property_1
  • Property_2
  • Property_3
  • Property_4
  • Property_5
In addition, the SCA module has the following mediation policies attached:
  • Policy_X, with associated conditions
  • Policy_XX, with associated conditions
  • Policy_XXX, with associated conditions
  • Policy_Y, with no associated conditions
There are mismatches between property values, at the same precedence: the mismatches occur between the property values in Policy_X and Policy_XX. Therefore, Policy_X and Policy_XX are not merged and none of the property values in Policy_X, Policy_XX or Policy_XXX are used (even though there are no merge errors in Policy_XXX). The mediation policy processing then processes mediation policies at the next level of precedence. The only mediation policy at this level is Policy_Y. Therefore, the values from Policy_Y are used.
Table 2. Example showing an unsuccessful merge of mediation policies
Mediation policy precedence Mediation policy name Promoted property: alias name Promoted property: value Use this promoted property value Merged mediation policy values Properties used for message flow
Highest precedence: with conditions Policy_X Property_1 A No    
Property_2 B No    
Policy_XX Property_1 C No    
Policy_XXX Property_3 D No    
Lower precedence: without conditions Policy_Y Property_1 D Yes Property_1 = D Property_1 = D
Property_4 E Yes Property_4 = E Property_4 = E
Administrative console promoted properties Property_1 F No    
Property_2 G Yes   Property_2 = G
Property_3 H Yes   Property_3 = H
Property_4 I No    
Property_5 J Yes   Property_5 = J

Terminology

Web services policy terminology is described in the Web Services Policy 1.5 Framework and in the Web Services Policy 1.5 Attachment; in addition, the mediation policy model uses some further terms.

The Web Services Policy 1.5 Framework includes the following terms:
Policy subject
A logical entity with which a policy can be associated. For example, there is a service policy subject and an endpoint policy subject.
Policy scope
A point where you can attach a policy. A policy scope could relate to a service, port, binding, portType, operation, or message.
Note: The service policy subject has one policy scope: service. However, the endpoint policy subject has a number of policy scopes: port, binding, and portType.
Effective policy
For a particular policy subject, the effective policy is calculated by merging the policies that belong to the policy subject.
The mediation policy model also uses the following terms:
Policy Scope property
A Policy Resolution primitive property that specifies whether a mediation policy is associated with the current Service Component Architecture (SCA) module, or with a target service.
Module scope
Relating to the current SCA module.
Target Service scope
Relating to all the relevant definitions of the target service, included in a WSDL description; for example, service, port, binding, and portType.
Scope point
A point where you can attach a mediation policy. The following types of scope point are supported:
  • Module
  • Service
  • Port
  • Binding
  • PortType
Parent topic: Policy Resolution mediation primitive