Defining Run-Time Policies
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. |
