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 model
- Policies are authored and then attached to services that require
that policy. Typically this follows the following order:
- The set of services are loaded or created in the service repository.
This is a part of the Policy Authoring Point.
- The set of policies required are created in the Policy Authoring
Point using the policy lifecycle:
- Policies are attached to the services that require those policies
– at the service, operation, or endpoint level as required.
- 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.
- As a part of the setup, ITCAM for SOA subscribes to the monitoring
policy from WSRR. This occurs only once.
- 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.
- 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.
- 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.
- ITCAM for SOA downloads the monitoring policies as they are published.
- ITCAM for SOA converts the policies into the internal representation
called situation policies.
- WebSphere DataPower downloads the WSDLs
for services that it is responsible for transacting.
- WebSphere DataPower downloads the policies
for services that it is responsible for when notified by WSRR.
- WebSphere DataPower converts the policies
into internal WebSphere DataPower representation in
the form of SLM objects.
- Monitoring of SOA policies with reporting and notification of
operations:
- Monitoring policies are active in the ITCAM for the SOA Situation
Policy.
- ITCAM for SOA receives monitoring information and places that
information in workspaces.
Note: Monitoring is not provided in this pattern.
- Enforcement of SOA Policies:
- Enforcement policies are active in the various WebSphere DataPower appliances.
- WebSphere DataPower receives service
transactions and applies policies for that consumer service and provider
service.
- The Policy Enforcement Point sends SOA Policy Enforcement statistics
to the Policy Monitoring Point.
Note: Monitoring is not included in
this pattern.
- The Policy Monitoring Point sends monitoring events to the Policy
Authoring Point:
- 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.
- 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.
- Monitoring of alerts:
- Situation policies run periodically and take operational action
as specified in the policy. The default is every 5 minutes.