Mediation policy patterns

Mediation policy patterns can simplify the implementation of mediation policies. This topic describes some basic patterns to use with mediation policies.

The mediation policy processing model defines the result of processing any combination of mediation policies. However, you can simplify the implementation of mediation policies by following some basic rules and patterns.

Rules

For each property group, apply the following rules:
  • Have a single default mediation policy with no gate conditions. This default mediation policy contains all module properties that can be overridden, and is used when none of the conditional mediation policies apply. When you export your Service Component Architecture (SCA) module, WebSphere® Integration Developer generates a default mediation policy for each property group in your SCA module. Therefore, if you want to provide a dynamic override for every dynamic property in your module, you can attach all the default mediation policies to your SCA module.
    Note: If you attach all default mediation policies only to your SCA module, all configuation is driven by mediation policies and any changes made on the administrative console are ignored.
  • Do not allow conflicts between mediation policies with gate conditions.

Pattern one: Default mediation policies only

If you want to provide a dynamic override for every dynamic property in your module, when you administer WSRR you should attach all the default mediation policies to your SCA module.

Pattern two: Mutually exclusive gate conditions

If you have mutually exclusive gate conditions, the runtime environment will never try to merge conditional mediation policies.
  • Have a single default mediation policy with no gate conditions (the attachment has no conditions). This default mediation policy contains all module properties that can be overridden, and is used when none of the conditional mediation policies apply.
  • Create gate conditions so that each gate condition represents a distinct case; therefore, gate conditions are mutually exclusive, and a maximum of one conditional mediation policy can be chosen. For example, you could have one mediation policy with a gate condition whose value is InsuranceType = "Gold", and another mediation policy with a gate condition whose value is InsuranceType = "Silver". For a particular message, the InsuranceType will be either Silver or Gold, and the appropriate mediation policy will be chosen.

Example: Mutually exclusive gate conditions

The following example shows three mediation policies attached to one module. Equally, the example could show three mediation policies attached to one scope point of a target service. Two mediation policies have a gate condition, and one mediation policy has no gate conditions. The two mediation policies with a gate condition are mutually exclusive.

At run time, the message content determines which mediation policies are used (and therefore what module properties can be overridden):
  • If the InsuranceType = "Gold", mediation policy P1 is used.
  • If the InsuranceType = "Silver", mediation policy P2 is used and properties not mentioned by P2 are taken from mediation policy P3.
  • If the InsuranceType is neither Gold nor Silver, mediation policy P3 is used.
Figure 1. Mutually exclusive gate conditions
The default mediation policy contains all module properties that can be overridden.

Pattern three: Distributing module properties to avoid conflicts

If you do not have mutually exclusive gate conditions, the runtime environment might try to merge conditional mediation policies. Any conditional mediation policies that might be merged together, must have module properties that are unique.
  • Have a single default mediation policy with no gate conditions (the attachment has no conditions). This default mediation policy is used when none of the conditional mediation policies apply.
  • Create gate conditions so that more than one conditional mediation policy might be used, but ensure that mediation policies that might be merged have unique properties. For example, you could have one mediation policy with a gate condition whose value is InsuranceType = "Gold", another mediation policy with a gate condition whose value is InsuranceType = "Silver", and yet another mediation policy with a gate condition whose value is CustomerType = "Student". For a particular message, the InsuranceType will be either Silver or Gold, and the appropriate mediation policy will be used. However, the mediation policy associated with the gate condition CustomerType = "Student" might need to be merged with the other conditional mediation policy; therefore, it must contain unique module properties.

Example: Distributing module properties to avoid conflicts

The following example shows four mediation policies attached to one module. Equally, the example could show four mediation policies attached to one scope point of a target service. Three mediation policies have a gate condition, and one mediation policy has no gate conditions. The conditional mediation policies that might be merged have no overlapping module properties.

At run time, the message content determines which mediation policies are used (and therefore what module properties can be overridden):
  • If the InsuranceType = "Gold", mediation policy P1 is used.
  • If the InsuranceType = "Silver", mediation policy P2 is used.
  • If the CustomerType = "Student", mediation policy P3 is used.
  • If two conditional mediation policies are used, (either P1 and P3, or P2 and P3), no property appears more than once.
    • If P1 and P3 are used, Property_A and Property_B come from P1 and Property_C comes from P3.
    • If P2 and P3 are used, Property_A comes from P2, Property_C comes from P3, and Property_B comes from P4.
  • If no conditional mediation policies are used, mediation policy P4 is used.
Figure 2. Distributing module properties to avoid conflicts
The default mediation policy contains all module properties that can be overridden.
Parent topic: Policy Resolution mediation primitive