Run-Time Policy Management
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:
CentraSite does not support versioning for run-time policies.
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.
Run-Time Policy Actions
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 (for example, 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.
Run-Time Policy Scope
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.
Refining the Run-Time Policy's Scope with Additional Selection Criteria
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.
Run-Time Policy Deployment
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 policy resolution rules.
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.
Creating and Testing Policies
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.
Distributing the Development of Policies
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 (that is, 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.
Lifecycle Model for Policies in a Multi-Stage Deployment of CentraSite
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.