Policy Resolution mediation primitive

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 mediation policies associated with the current Service Component Architecture (SCA) module. You can also retrieve mediation policies associated with a target service used by the mediation flow. If you want to retrieve mediation policies associated with a target service, add an Endpoint Lookup primitive to the mediation flow before the Policy Resolution primitive. The Endpoint Lookup primitive selects the target service and the Policy Resolution primitive retrieves mediation policies attached to the target service.

If valid mediation policies are found in the registry, their contents can be used to override the dynamic properties of mediation primitives that come after the Policy Resolution primitive. If a mediation flow contains the Policy Resolution primitive, any promoted property that is in the top-level request, response, or fault flow is a dynamic property. Mediation policies contain the equivalent of promoted property groups, names, and values, and must conform to the Web Services Policy Framework (WS-Policy).

If there are mediation policies attached to either the current module or to the target service, 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, you create a module that contains one mediation flow component, and the component contains two mediation primitives: a Policy Resolution primitive followed by a Mapping mediation primitive. If you promote the Mapping primitive property, Mapping file, you can override the value at run time, using mediation policies in your registry.

Any dynamic properties not overridden by mediation policies take the values shown on the administrative console. However, the administrative console values are not stored in the /context/dynamicProperty location.

Before you use the Policy Resolution mediation primitive you might need to add SCA modules, WSDL documents, mediation policies, and mediation policy attachment documents to your WSRR registry. You can create mediation policies using WSRR, directly. Alternatively, you can create mediation policies using Business Space widgets, and the widgets create the mediation policies in WSRR. Both WebSphere Enterprise Service Bus (WebSphere ESB), Version 7.0, and WebSphere Process Server, Version 7.0, include Business Space widgets for creating mediation policies.

To retrieve mediation policies for the current module, the details of your SCA module must exist in the appropriate registry. When you load an SCA module into WSRR, the registry creates an SCA module document. The registry also creates an SCA module object to which you can attach mediation policies.

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. If you create your own mediation policies, they must refer to the group and alias names of your dynamic properties.

When you have the mediation policies you need, you can attach them to your SCA module or your target service. If you want to specify gate conditions on a mediation policy, you must specify them 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 lifecycle 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 lifecycle, but you can define your own. If you want to filter mediation policies according to particular WSRR classifications, including lifecycle classifications, you must also define the classifications on the Policy Resolution primitive.

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. However, you must specify a valid default value for every property you want to override. Generally, you put a Policy Resolution primitive at the start of the flow, except when you need other mediation primitives, typically the Endpoint Lookup primitive.

WSRR has many classification systems, including lifecycle classifications, and you can select mediation policies based on their WSRR classification. Lifecycle classifications allow you to impose governance on your policies, or create your own classification systems.