The SOA Policy architecture

The SOA Policy architecture describes the interaction of the Policy Authoring Point (PAP), Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Information Point (PIP), and the Policy Monitoring Point (PMP). In this pattern, the PAP is achieved using WSRR, and the PEP is achieved using WebSphere® DataPower®.

The organization of the basic policy architecture and definition of those key points: The consumer and provider both interact with the middleware, which in turn interacts with the repository and any monitoring software.

How the SOA Policy architecture works together

The SOA Policy actionable pattern flow is shown in Figure 1 and described below.
Figure 1. Service Level Agreement (SLA) Policy - the SOA deployment modelPolicies are authored and can be attached to services. There is automated pub/sub of policies from the Policy Authoring Point. Policies can be monitored with reporting and notification of operations. There is enforcement of SLA policies. SLA Policy enforcement metrics are sent to the Policy Monitoring Point. Policy analytics are available for Policy Authoring Point management. There are monitoring alerts for usage in policy enforcement.
  1. Policies are authored and then attached to services that require that policy. Typically this follows the following order:
    1. The set of services are loaded or created in the service repository. This is a part of the Policy Authoring Point.
    2. The set of policies required are created in the Policy Authoring Point using the policy lifecycle:
      1. Policies are attached to the services that require those policies – at the service, operation, or endpoint level as required.
  2. Automated pub/sub of policies from the Policy Authoring Point to the Policy Enforcement Points and the Policy Monitoring Point:
    Note: Monitoring using ITCAM for SOA is not included in this pattern.
    1. As a part of the setup, ITCAM for SOA subscribes to the monitoring policy from WSRR. This occurs only once.
    2. As a part of the setup, proxy gateways are created in each WebSphere Data Power® appliance that has service transactions with policy enforcement. This occurs only once, and is added or changed as required.
    3. As a part of the setup, each proxy gateway in the appliance subscribes to policies from WSRR for services that it is responsible for. This occurs only once, and is added or changed as required.
    4. As a part of the setup, WebSphere DataPower is configured so that policies can be shared by other appliances in a cluster. This occurs only once, and is added or changed as required.
    5. ITCAM for SOA downloads the monitoring policies as they are published.
    6. ITCAM for SOA converts the policies into the internal representation called situation policies.
    7. WebSphere DataPower downloads the WSDLs for services that it is responsible for transacting.
    8. WebSphere DataPower downloads the policies for services that it is responsible for when notified by WSRR.
    9. WebSphere DataPower converts the policies into internal WebSphere DataPower representation in the form of SLM objects.
  3. Monitoring of SOA policies with reporting and notification of operations:
    1. Monitoring policies are active in the ITCAM for the SOA Situation Policy.
    2. ITCAM for SOA receives monitoring information and places that information in workspaces.
    Note: Monitoring is not provided in this pattern.
  4. Enforcement of SOA Policies:
    1. Enforcement policies are active in the various WebSphere DataPower appliances.
    2. WebSphere DataPower receives service transactions and applies policies for that consumer service and provider service.
  5. The Policy Enforcement Point sends SOA Policy Enforcement statistics to the Policy Monitoring Point.
    Note: Monitoring is not included in this pattern.
  6. The Policy Monitoring Point sends monitoring events to the Policy Authoring Point:
    1. Events are set up in the Policy Authoring Point that need to be monitored from the Policy Monitoring Point. This occurs only once, and is added or changed as required.
    2. As situation policies evaluate to true, events are pushed to the Policy Authoring Point from the Policy Monitoring Point.
    Note: Monitoring is not included in this pattern.
  7. Monitoring of alerts:
    1. Situation policies run periodically and take operational action as specified in the policy. The default is every 5 minutes.

Concept Concept

Feedback

Timestamp icon Last updated: Thursday, 3 July 2014
http://publib.boulder.ibm.com/infocenter/prodconn/v1r0m0/topic/com.ibm.scenarios.soawdpwsrr.doc/topics/csoa2_SOA_architecture.htm