A run-time policy defines a sequence of actions that a policy-enforcement point (PEP), such as webMethods Mediator, will carry out when the PEP receives a request from a consumer application. The actions that a run-time policy can execute depend on the type of PEP you are using. If you are using webMethods Mediator, for example, you might create run-time policies to perform the following kinds of tasks:
Verify that the requests submitted to a virtual service come from consumer applications that are authorized to use the virtual service.
Validate request and response messages against the schema specified in the service's WSDL.
Log the request and response messages to the CentraSite event log.
Alert an administrator if the average response time for a service drops below a specified threshold.
Run-time policies enable service architects to separate the logic that relates to general functions, such as security, message validation, logging and monitoring, from the business logic of the service. By using policies to carry out these general activities, an organization can easily modify and redeploy the policies as necessary without disrupting the native services that perform the business logic.
Like a design/change-time policy, a run-time policy consists of two major elements: an action list and a defined scope. The policy's action list specifies the sequence of actions that are to be executed by the PEP. The policy's scope determines to which virtual services the policy applies.
Note:
The remaining sections assume that you are creating run-time policies
that will be deployed with virtual services on webMethods Mediator. If you are
using another PEP, the principles described in these sections will be similar,
however, it will support its own unique set of policy actions. The built-in
policy actions that CentraSite provides out-of-the-box are to be used only
with webMethods Mediator. You cannot use these actions with other PEPs.
The scope of a run-time policy specifies for which virtual services the policy will be enforced. The scope of a run-time policy is determined by the following policy parameters:
The Target Type parameter specifies the type of PEP on which the policy will be enforced. When you create run-time policies for webMethods Mediator, you set the Target Type to "webMethods Integration Server".
The Organization parameter specifies to which organization's virtual services the policy applies. Like design-time policies, a run-time policy can be system-wide or organization-specific. System-wide policies apply to virtual services in any organization. Organization-specific policies apply only to virtual services that belong to a specified organization.
Note:
Once you create a policy, its organizational scope is fixed and
cannot be changed. That is, if you create a policy whose scope is specific to
organization ABC, you cannot change its scope to make it system-wide or switch
it to another organization. You must create a new policy and set its
organizational scope as needed.
The Asset Type parameter specifies to which types of assets the policy applies. When you create run-time policies for webMethods Mediator, you set the Asset Type parameter to "Virtual Services". When you are creating a run-time policy for another type of PEP, you will set this parameter to "Web Services" (or possibly to some other asset type).
Although it is possible to create a run-time policy that applies to all virtual services, this is not the common case. More frequently, you will create run-time policies that apply to a particular set of virtual services (or possibly even one specific virtual service). For example, you might define a run-time policy that monitors the response time for all virtual services that are considered to be "critical".
To target a policy for a particular set of virtual services, you refine the policy's scope by specifying additional selection criteria based on the virtual service's Name, Description or Classification properties. For example, if you wanted to apply a particular run-time policy to "critical" services as described above, you would classify virtual services according to their criticality and create a policy that targets virtual services that are classified as "critical".
In cases where you need to apply a run-time policy to one specific virtual service, you can use the selection criteria to identify the virtual service by name.
Note:
While you are creating a run-time policy, you can refer to the
policy's Service profile to see exactly which set of
virtual services are currently within the policy's scope.
To use run-time policies effectively, you need to think about what selection criteria your policies will use to identify the set of virtual services with which they are to be used. You must also ensure that the virtual services in your registry adhere to the Name, Description and/or Classification conventions needed to support your selection scheme. For example, if you intend to enforce different logging policies for different classes of virtual services, you must define the taxonomy by which the virtual services will be classified (for logging purposes) and ensure that virtual services are classified according to this taxonomy before they are deployed.
CentraSite is installed with a set of actions that you use to define run-time policies for virtual services deployed on webMethods Mediator. These actions fall into the following four categories:
Security actions, which you use to identify and authenticate the consuming application that submitted a request, to enforce the use of the SSL protocol (if required), to perform encryption and decryption of specified parts of the request and response messages, and to validate signatures of messages that are digitally signed.
Logging actions, which you use to log the request and/or response messages associated with a virtual service. Logging actions can send the logged messages to Mediator's local log, CentraSite's policy or audit log, to an SNMP server and/or email the messages to specified addresses.
Performance monitoring actions, which you use to monitor specified metrics (e.g., service availability, average response time, fault count, request count) and log instances when these metrics violate specified thresholds. Violations can be reported in Mediator's local log, in CentraSite's policy or audit log, in an SNMP server and/or sent as an email message to specified addresses.
Data validation actions, which you use to validate the request and/or response message against the WSDL associated with the virtual service.
Note:
CentraSite does not require you to deploy run-time policies with a
virtual service. It is possible to deploy virtual services to webMethods
Mediator without accompanying policies. In practice, however, this is rare. One
nearly always deploys virtual services with, at the very least, some type of
security-related policy to identify and authenticate the consuming application.
When you deploy a virtual service to webMethods Mediator, CentraSite combines the actions from all of the run-time policies that apply to the virtual service and generates what is called the effective policy for the virtual service. For example, let's say your virtual service is within the scope of two run-time policies: one policy that performs a logging action and another policy that performs a security action. When you deploy the virtual service, CentraSite automatically combines the two policies into one effective policy. The effective policy, which contains both the logging action and the security action, is the policy that CentraSite actually deploys to the Mediator with the virtual service.
When CentraSite generates the effective policy, it validates the resulting action list to ensure that it contains no conflicting or incompatible actions. If the list contains conflicts or inconsistencies, CentraSite resolves them according to the rules described in the section Run-Time Governance Reference > Built-In Run-Time Actions Reference for Virtual Services . For example, an action list can include only one Identify Consumer action. If the resulting action list contains multiple Identify Consumer actions, CentraSite resolves the conflict by including only one of the actions (selected according to a set of internal rules) in the effective policy and omitting the others.
The effective policy that CentraSite produces for a virtual service is contained in an object called a virtual service definition (VSD). The VSD is given to Mediator when you deploy the virtual service. After you deploy a virtual service, you can view its VSD (and, thus, examine the effective policy that CentraSite generated for it) from CentraSite Control or from the Mediator user interface.
In a two-stage deployment of CentraSite, you will create and test run-time policies on the creation CentraSite and then promote them to the consumption CentraSite when they are considered ready for use.
Because run-time policies involve several different aspects of operational behavior, there are often several different types of architects or experts involved in their creation. For example,
Security-related policies might be defined and managed by a security architect, who is responsible for ensuring that the policies adhere to corporate security standards.
Performance-monitoring policies might be defined and managed by an administrator or analyst from the Operations organization.
Application-related policies (i.e., policies that involve logging or validating the data associated with the service itself) might be defined and managed by an SOA Application Architect.
Because CentraSite combines applicable run-time policies at deployment time, it is possible to distribute the policy-development responsibilities to the appropriate experts in your organization as described above. Each expert defines and manages the policies for his or her area of expertise. Then, at deployment time, CentraSite combines the applicable policies produced by each of these experts into one effective policy for the virtual service.
A run-time policy is not eligible for deployment unless it is "active". In other words, when CentraSite deploys a virtual service, it uses only "active" run-time policies to produce the effective policy for the virtual service. Whether a run-time policy is active or inactive is determined by its lifecycle state.
Run-time policies are governed by the same lifecycle model as design/change-time policies. The predefined lifecycle model for policies that is installed with CentraSite is made up of four states: New, Productive, Suspended and Retired. Under this lifecycle model, all policies enter the New state when they are initially created.
While a run-time policy is in the New state, it is inactive. To activate a run-time policy, you must place the policy in the Productive state. Switching the policy to the Productive state triggers an internal system policy that activates the policy and makes it eligible for deployment.
If you activate a run-time policy that applies to a virtual service that is already deployed on webMethods Mediator, be aware that CentraSite will automatically re-deploy that virtual service with the updated run-time policy. That is, CentraSite will automatically regenerate the effective policy for the virtual service (to include the newly activated run-time policy) and then redeploy the virtual service on webMethods Mediator.
To deactivate a run-time policy, you switch the policy to the Suspended state or the Retired state. When you deactivate a run-time policy, CentraSite will automatically remove the policy from any virtual service with which it is currently deployed. That is, CentraSite will automatically regenerate the effective policy for each of those virtual services (to remove the deactivated policy) and then redeploy the virtual services on webMethods Mediator.
Note:
We recommend that you use the lifecycle model that CentraSite
provides for policies "as-is", even for a multi-stage deployment.
For more information, see Lifecycle Model for Policies in a
Multi-Stage Deployment of CentraSite.
You cannot make changes to a run-time policy while it is active. To make changes to a policy after it has been switched to the active state you must do one of the following:
Switch the policy to the Suspended state (to deactivate it), update the policy and then switch it back to the Productive state (to reactivate it).
OR
Create a new version of the policy, make your changes to the new version of the policy and then switch the new version to the Productive state. Switching the new version of the policy to the Productive state will automatically Retire (and deactivate) the old version.
If you need to update a run-time policy that is already deployed with virtual services that are in production, always use the second method described above (i.e., create a new version of the policy). If you use the first method, which requires you to suspend the existing policy, your production services will be running without the policy while you are making your revisions to it.
Additionally, if you need to make a change to a run-time policy on the creation CentraSite, and that change needs to be promoted to the consumption CentraSite, always create a new version of the policy and then promote the new version to the consumption registry. This will ensure that the import process creates a new instance of the policy on the consumption registry (i.e., that it does not overwrite the existing run-time policy) and that the updated policy is added to the registry in the New (inactive) state. When you are ready to activate the imported policy, you switch it to the Productive state.
CentraSite provides a lifecycle model for policies that applies to both design/change-time policies and run-time policies. The lifecycle model has associated policies that CentraSite uses to validate, activate and deactivate policies. Because of the complex nature of this lifecycle model, we recommend that you use the lifecycle model as installed. Do not attempt to customize this lifecycle model. (You can associate additional policies with its state changes, however.)
If you are operating in a multi-stage deployment, this means that you will use the same lifecycle model on all stages in your environment. You will not define a multi-stage lifecycle model for policies as you would for an asset.
When you develop a run-time policy on the creation CentraSite, that policy will enter the New state. It will transition between the Productive and Suspended states as it undergoes development and testing. When the run-time policy is considered to be ready for production, you will promote it to the consumption CentraSite. Here it will also enter the lifecycle in the New state. When you are ready to activate the policy in the consumption CentraSite, you switch it to the Productive state.
Tip:
To indicate that a policy has been promoted to the production
environment, consider adding a comment such as "PROMOTED" or
"[Moved to Production]" to the policy's
Description property on the creation CentraSite.
