Introducing the SOA Policy Pattern to create reusable policy patterns and to control your services

In general, a policy asserts a requirement, a capability, or another property of intended behavior. In a service-oriented architecture, you can use a policy to reduce risk and increase dynamic control as you author and maintain it separately from any business logic. This article introduces the "SOA Policy Pattern" in which policies are authored, managed, enforced, and monitored using the specific combination of WebSphere® Service Registry and Repository, WebSphere DataPower SOA Appliances, and IBM® Tivoli Composite Application Manager for SOA.

Share:

Robert Laird (rglaird@us.ibm.com), Software Architect, IBM

Bob Laird photoRobert Laird is an Enterprise Architect who leads the software product architecture for SOA, SOA Governance, and SOA Policy at IBM. He has consulted on SOA for a wide variety of industries and customers while at IBM. Robert has 20 years of experience in the telecommunications industry and had a variety of roles there, including various development and architect roles, and then Chief Architect at MCI, where he led the SOA and SOA Governance effort. He has written such books as Executing SOA, SOA Governance: Achieving and Sustaining Business and IT Agility, and SOA Governance: Governing Shared Services On-Premise and in the Cloud with Thomas Erl that are part of the Prentice-Hall Service-Oriented Computer Series.



Stephen Cocks (scocks@uk.ibm.com), Senior Software Engineer, IBM

Photo of Stephen CocksStephen Cocks is a Senior Software Engineer at IBM's development laboratory in Hursley, United Kingdom. His current responsibilities include working with product teams to define, architect, and deliver SOA policy-based capabilities. Since joining IBM in 1989, Stephen has worked in a variety of roles on many of IBM's key WebSphere products, including IBM Business Process Manager, IBM WebSphere Enterprise Service Bus, and IBM WebSphere Application Server.



10 October 2012

Also available in Chinese

Introduction

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
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 V7.1.1.3 or later.

While you can use WSRR V7.5.0.2 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.

Initial setup

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
SOA Policy flow

The SOA Policy Pattern flow is characterized as follows:

  1. Policies are authored and then attached to services that need that policy, typically like this (not necessarily sequentially, but interleaved as appropriate):
    1. The set of services are loaded into or created in the WSRR service repository (acting as the PAP).
    2. The set of policies needed are created in the PAP using the policy lifecycle.
    3. 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.
  2. Automated publishing and subscription to policies from PAP to PEPs and PMP:
    1. As part of the setup, ITCAM for SOA subscribes to monitoring policy from WSRR (one time).
    2. 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).
    3. 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).
    4. 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).
    5. ITCAM for SOA successfully downloads monitoring policies as they are published.
    6. ITCAM for SOA converts policy into internal representation (situation policies).
    7. DataPower downloads WSDLs for services it is responsible for transacting.
    8. DataPower downloads policies for services it is responsible for upon notification from WSRR.
    9. DataPower converts policies into internal DataPower representation (for example, SLM objects).
  3. Monitoring of SOA policies with reporting and notification of operations:
    1. Monitoring policies are active in the ITCAM for SOA Situation Policy.
    2. ITCAM for SOA receives monitoring information and places that information in workspaces.
    3. ITCAM for SOA periodically (default is every 5 minutes) evaluates each monitoring policy. If the policy is true, it takes the action specified.
  4. Enforcement of SOA policies:
    1. Enforcement policies are active in the various DataPower appliances.
    2. DataPower receives service transactions and evaluates and enforces policies for that consumer service and provider service.
  5. PEP sends SOA Policy Enforcement statistics to PMP.
  6. PMP sends monitoring events to PAP:
    1. Set up the desired events in PAP that are to be updated based on the monitoring policies.
    2. As monitoring policies evaluate to true, events are pushed to PAP from PMP.
  7. Monitoring alerts:
    1. 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
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
Attaching a policy to a WSRR SLA
Figure 5. Managing multiple attachments for a policy
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
Policy Attachment Query

Conclusion

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.


Download

DescriptionNameSize
PDF fileSOA_Policy_Pattern_User_Guide.pdf9,936KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Tivoli, Tivoli (service management)
ArticleID=839772
ArticleTitle=Introducing the SOA Policy Pattern to create reusable policy patterns and to control your services
publish-date=10102012