IBM is defining a number of "patterns", which are software solutions involving multiple products. They are integrated together to solve specific customer solution needs. One of these is the "SOA Policy Pattern". This pattern brings together WebSphere Service Registry and Repository (WSRR), WebSphere DataPower SOA Appliances (DataPower), and IBM Tivoli Composite Application Manager for SOA (ITCAM for SOA) to provide an environment for authoring, applying, and enforcing policies.
For a more detailed description of the pattern and its usage, see the SOA Policy Pattern User Guide.
Let's begin with some background on SOA Policy, SOA Policy Domains, and the IBM SOA Policy Architecture.
What is a SOA Policy?
Using a service-oriented architecture (SOA) helps a business identify and focus on optimizing the value of its key resources such as services, processes, and information. By adding the concept of a policy to the SOA, you provide a way to add points of control, governance, and agility for business and IT. This makes SOA more consumable and accelerates the usefulness and adoption of SOA solutions.
A separately authored and maintained policy, for example, "a transaction must complete in 2 seconds or less" has the advantage in that the context to which it can be applied, is not limited. The benefits are:
- You can apply the policy to a variety of transactions, such as a credit card transaction or a price lookup transaction.
- You can change the policy once centrally and have it applied to multiple resources consistently, which is not possible with tightly bound policies.
- The policy, in and of itself, says nothing about how or where it gets enforced. That binding can take place to testing or production services as the needs of the business change.
The SOA Policy Pattern allows various policies to be authored, managed, and governed in a centralized location and then automatically distributed to the runtime engines responsible for processing and monitoring service transactions.
SOA Policy Domains
The IBM SOA Policy Reference Architecture document shows how a policy can be introduced throughout the service development lifecycle to express business, architectural, and operational requirements.
The SOA Policy Pattern presented here provides an environment for management of operational policies and their enforcement by specific runtime systems. You can use policies to express requirements in many areas such as security, resource management, service level management, and service routing. We refer to these different areas as policy domains. In the SOA Policy Pattern, we focus on two domains: service mediation and service monitoring.
Mediation policy assertions
A mediation policy controls the configuration of Web Service Proxy objects in DataPower. Its primary purpose is to define service levels (for example, the maximum allowable rate of requests), and how DataPower manages the flow of requests for each service through the appliance to meet these service levels.
Service Level Agreements (SLAs) mean that the quality of service provided by a service must meet a specified standard. As a service is being designed, functional requirements are created to guide the logic of what the service does. Non-functional requirements are specified in parallel as part of the analysis and design of that service to designate the Quality of Service (QOS) that the service is expected to provide.
For example, the business may have a service that supplies information in response to a customer internet query. A customer study has found that if a response is not returned within 3 seconds, the customer's attention wanders and the business loses business that it may otherwise have obtained. As part of the engineering of the end-to-end transaction, it is determined that this service must return its information within 2 seconds to meet the business non-functional requirements.
You can write policy that implements runtime checks on the performance of the service and take action when the SLA is not being met so as to guarantee that service meets its SLA. For example, you may have a service primary endpoint that is normally able to (95% of the time) provide service response within 2 seconds. The SOA Architect has created a secondary endpoint on another server that is normally used as a hot standby for primary endpoint outages, but it is also authorized to be used for overflow traffic when the primary endpoint cannot keep up with the transaction load. You can write policy that checks the service response time and reroutes traffic when necessary to meet the SLA.
Another example where SLAs are maintained via runtime policy is when a service is responding to transactions that have a variety of consumers, each with a different level of priority. A simple example may have "gold" and "bronze" customers, where you only guarantee a specific QoS for your "gold" customers. In the example in the previous paragraph, you can check if the consumer is "gold" and reroute to your secondary endpoint, while leaving your "bronze" customer to deal with a slower response time. The business made the decision that "bronze" customers provide insufficient incremental revenue to justify the expense of engineering response time to meet the SLA of "gold" customers.
In a third example, you may have a situation where a provider service does the best it can, but when the runtime engine determines that service is not meeting its response time SLA, the policy specifies that the runtime engine queues or even throttles (rejects) messages from low priority consumer services. One example of this is when a batch routine floods the system with consumer requests at an unexpected time. In order to protect the QoS of your service, you may create a runtime policy that is in effect during business hours only, and that rejects all batch requests during this period.
Specifically, a runtime policy can decide the situation where it makes sense to throttle, queue, or reroute a transaction in order to meet the SLA.
A policy may be specified for a service (provider) only for a specific consumer-provider pair, or for "anonymous" consumers for a provider. "Anonymous" effectively provides a way of defining a default policy, which only applies to consumers for which no other policies apply. Using this feature allows a policy to be specified, for example, for rogue consumers that do not identify themselves. Such consumer services can have their transactions throttled (rejected) or a log message written so that you may address it with the application team. This is useful to prevent denial of service attacks from consumer hackers attempting to flood the system with transactions and to bring down a provider service.
Monitoring policy assertions
Monitoring a policy controls the configuration of situations in ITCAM for SOA.
An operations group is usually tasked with maintaining an appropriate Quality of Service. A good way to do this is to have a set of automated monitoring policies. These policies specify the conditions, upon which operations are notified, that something needs to be investigated, or that automatic actions are to be taken.
For example, the business may have a service that provides credit information about a consumer. It is expected that there is a small number of transactions initially, but that this ramps up over time. Operations need to know when the number of transactions exceeds a certain level to take appropriate action, such as creating additional endpoints and implementing a load balancer.
This type of policy could have been contemplated during the development process if the non-functional requirements were thorough and thought out to this degree. More likely, operations are tasked with identifying the operational considerations necessary to meet their SLAs and to define and implement the requisite monitoring policy.
SOA Policy Architecture
The SOA Policy Pattern embodies a general architectural pattern for policy management as shown in Figure 1. This general architecture comprises of a number of identified components, which are referred to here as "points".
Figure 1. Standard pattern for policy usage
Policy Administration Point (PAP)
A Policy Administration Point provides policy capabilities that allow authoring of policy, management, and governance of the policy and its assignment to resources, and administration of policy results during runtime.
Policy Monitoring Point (PMP)
A Policy Monitoring Point is a functional component that provides an overall detailed policy monitoring function, that is, shows the big picture on policy and resource results from the distributed environment.
Policy Enforcement Point (PEP)
A Policy Enforcement Point (PEP) is a functional point that takes action to enforce the policies on the service transactions.
Policy Decision Point (PDP)
A Policy Decision Point (PDP) evaluates participant requests against relevant policies or contracts and attributes to render an authorization, eligibility or validation decision, or provide calculated results.
Policy Information Point (PIP)
A Policy Information Point (PIP) provides external information to a Policy Decision Point, such as LDAP attribute information, or the results from a database with information that must be evaluated to make a policy decision.
SOA Policy Pattern
As stated earlier, the pattern brings together WebSphere Service Registry and Repository (WSRR), WebSphere DataPower SOA Appliance (DataPower), and IBM Tivoli Composite Application Manager for SOA (ITCAM for SOA) to provide an environment for managing policies. Specifically, you need WSRR V8.0 (or later), a DataPower appliance running V5 firmware that supports the Web Service Proxy (such as the XS50), and ITCAM for SOA V18.104.22.168 or later.
While you can use WSRR V22.214.171.124 instead of V8.0 to use a substantial part of the pattern's capabilities, there are significant ease-of-use improvements to the mediation policy authoring and attachment widgets in V8.0. Therefore, WSRR V8.0 is used in the figures for this article.
Before you can start to use the pattern, you need to install and configure the various products together. You can find more information about installing and configuring the products in their respective Information Centers (see the Resources section).
Further information about the steps necessary to configure the products is found in the SOA Policy Pattern User Guide.
Normal policy operation
Figure 2 shows the flow of operations between the PAP (as implemented by WSRR), the PEP (as implemented by WebSphere DataPower) and the PMP (as implemented by ITCAM for SOA), which is how the SOA Policy Pattern works.
Figure 2. SOA Policy flow
The SOA Policy Pattern flow is characterized as follows:
- Policies are authored and then attached to services that need that
policy, typically like this (not necessarily sequentially, but
interleaved as appropriate):
- The set of services are loaded into or created in the WSRR service repository (acting as the PAP).
- The set of policies needed are created in the PAP using the policy lifecycle.
- Policies are attached to the services that require those policies - either indirectly via the SLD or SLA, or at the service, operation, or endpoint level as needed.
- Automated publishing and subscription to policies from PAP to PEPs and
- As part of the setup, ITCAM for SOA subscribes to monitoring policy from WSRR (one time).
- As part of setup, proxy gateways are created in each DataPower appliance that has service transactions with policy enforcement (one time, added, or changed as needed).
- As part of the setup, each proxy gateway in appliance subscribes to policies from WSRR for services it is responsible for (one time, added or changed as needed).
- As part of the setup, DataPower is configured so that policies may be shared by other appliances in a cluster (one time, updated as needed).
- ITCAM for SOA successfully downloads monitoring policies as they are published.
- ITCAM for SOA converts policy into internal representation (situation policies).
- DataPower downloads WSDLs for services it is responsible for transacting.
- DataPower downloads policies for services it is responsible for upon notification from WSRR.
- DataPower converts policies into internal DataPower representation (for example, SLM objects).
- Monitoring of SOA policies with reporting and notification of
- Monitoring policies are active in the ITCAM for SOA Situation Policy.
- ITCAM for SOA receives monitoring information and places that information in workspaces.
- ITCAM for SOA periodically (default is every 5 minutes) evaluates each monitoring policy. If the policy is true, it takes the action specified.
- Enforcement of SOA policies:
- Enforcement policies are active in the various DataPower appliances.
- DataPower receives service transactions and evaluates and enforces policies for that consumer service and provider service.
- PEP sends SOA Policy Enforcement statistics to PMP.
- PMP sends monitoring events to PAP:
- Set up the desired events in PAP that are to be updated based on the monitoring policies.
- As monitoring policies evaluate to true, events are pushed to PAP from PMP.
- Monitoring alerts:
- As monitoring policies evaluate to true, events are pushed to PEP from PMP.
Using the SOA Policy Pattern
Next, we will discuss how you can author a policy and then attach it to a service.
Authoring a policy document using WSRR 8.0
WSRR 8.0 has defined policy widgets that allow the user to quickly create a Mediation policy by adding conditions and actions. Figure 3 shows an example of an authoring policy widget that allows the author to quickly and easily create a mediation policy.
Figure 3. Authoring a Policy Assertion
WSRR 8.0 has created policy widgets to allow the attachment of policies to the services in context.
Attaching a policy document to a service or set of services using WSRR 8.0
The WSRR 8.0 policy widgets for attachment of policy to resources allow a policy to be attached directly to specific selected items. Figure 4 shows the WSRR window to make the policy attachment. Figure 5 shows information on managing multiple attachments for a policy.
Figure 4. Attaching a policy to a WSRR SLA
Figure 5. Managing multiple attachments for a policy
In addition, the user is allowed to attach a policy to multiple items by defining a query. You can use this, for example, to attach a policy to all services for a particular business organization or attach a policy to all services, as shown in Figure 6.
Figure 6. Policy Attachment Query
This article introduced the SOA Policy Pattern and how it facilitated the use of policy to control and govern services at runtime in a service-oriented architecture. Specifically, it has shown how you can author and manage mediation and monitoring policies by using WSRR to control the way in which DataPower and ITCAM for SOA, respectively, enforce and monitor service levels. See the SOA Policy Pattern User Guide and the other references in the Resources section to get a more detailed understanding of the SOA Policy Pattern.
- SOA Policy Reference Architecture
- WebSphere Service Registry and Repository V8 Information Center
- WebSphere DataPower Information Center
- IBM Tivoli Composite Application Manager for SOA V7.1.1 library
- SOA governance using WebSphere DataPower and WebSphere Service Registry and Repository, Part 1: Leveraging WS-MediationPolicy capabilities
- Enforcing Service Level Agreements using WebSphere DataPower, Part 1: Applying the SLA Control File pattern
- Enhancements to integration with WSRR in ITCAM for SOA version 7.1.1 Fix Pack 3
- YouTube demo: Policy Attachments in WebSphere Service Registry and Repository V8.0
- YouTube demo: Mediation Policy Integration with WebSphere DataPower V5.0