![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
This document is meant to be a brief tutorial for understanding and using the SOA Policy Reference Architecture. For a more detailed understanding on this subject, including a fully worked example, access the full document from the Reference section.
Consider the figure below for an understanding of typical policy roles for who would be Creating, Authoring, Administering, Managing and Enforcing SOA Policies:
Figure 1. Roles for Usage of the SOA Policy Reference Architecture
SOA Policy Reference Architecture Description
The SOA Policy Reference Architecture is based around the management of services using policy as shown in the figure below.
Figure 2. SOA Policy Reference Architecture
The SOA Policy Reference Architecture layers its representation of policy to support the existing SOA roles and personas.
- The Business Layer should be led by a business analyst or a representative from the business who can specify the needs of the business.
- The Architecture Layer should be led by architects who are responsible for the integrity of the SOA.
- The Operational Layer reflects the specification of the runtime policy that implements the operational policy patterns.
At the highest level of abstraction, a policy is simply a statement of a specific business need. At this level, the policy is normally expressed in natural language (for example, English, French, and so on) and is used to communicate business requirements between business analysts and IT professionals. As the two parties begin to collaborate, this business policy is then decomposed into a set of objectives, strategies, and tactics that define the details of how the business requirement is going to be implemented and enforced across the organization.
Those business policies need to be defined in the context of the business solution to which they apply. Services will usually have traceability to the business capabilities that they deliver, so that it is usually possible to quickly relate a business policy to the services that it will need to influence.
One the business requirements have been decomposed into policies that can be applied to sets of services, the Architectural Policy layer is used to define the common patterns that can be used to enforce those policies.
The architectural policy layer provides patterns for integrating policy into the architecture adopted by the enterprise. Policies may apply to the way a service behaves (e.g. controlling a pricing service through policies defined in business rules) or they may be applied to the use of one service by another.
The Operational policy layer provides the deployed products and software infrastructure that realizes the business solutions and the use of policy within those solutions. The SOA Policy reference architecture defines a number of components that characterize the way policy is realized in operational SOA solutions.
The following figure shows a very simple example for a Service Level Management requirement.
Figure 3. Policy Tree example of SLA Policy Top down analysis
Business Policy Layer Solution
The policy tree analysis starts with a high level, simple statement of the business policy requirement, such as one may obtain from the business user or business analyst. This statement is then refined, still at a business level, to specify in more detail the implications of the business policy requirement, as wells as what needs to be measured to ensure policy compliance.
Defining a high level business intent or goal is relatively easy based on conversations with the business users. Examples might include "Response time must meet customer needs", "Sell insurance policies only if the client is a good credit risk", or "The CFO must approve high cost transaction".
However, then the more detailed questions start. The knowledgeable analyst might start asking questions like these:
- Do some customers have different response time requirements than others?
- What is an adequate response time?
- What is the solution context in which this policy will apply?
- How do we measure a good credit risk?
- Do different types of insurance policies have different risk levels?
- What is a high cost transaction?
- Do risk levels affect what is high cost?
We decompose the result as shown in the following figure:
Figure 4. Example for decomposing policy at the Business Layer
Lets describe and decompose the policy for the business layer:
Table 1. Decomposition of policy from business goals
| Name | Description | Example |
|---|---|---|
| Identify Business Goal | A Business Goal is a statement of intent and defines what needs to be done from a business point of view | Customer response time expectations should be met |
| Derive Policy Directive | The Policy Directive defines the intent of the Business Goal and therefore gives direction as to how the business goal should be further decomposed. It is further refined in the Solution Context, the Policy Domains, the Solution Policies and the Governance Policies stages. | The end to end customers response time (from depressing the enter key to response received) should be less than 3 seconds |
| Quantify Business Objectives | The Business Objectives defines what should be measured in detail to track achievement of the goal in the form of KPIs. | KPI 1: Measure the maximum response time of the customer services and provide a critical operations warning if this time is exceeded |
| Scope the Solution Context | The solution context defines where the business directive will apply in the business. Its scope may be localized within a small business capability or broadly deployed across the entire business. | Phase 1: Banking ATM Services only |
| Select the Policy Domain(s) | Each Domain identifies a common vocabulary that should be used for consistent policy definition. The business
policy sub domains to consider are:
| Service Level Management Policy Domain is used |
| Decompose to Solution Policies | The Policy Directive should be further refined as we receive more detailed knowledge of the context we are dealing with | All Banking ATM Services must provide a response to its service consumer in less than 3 seconds |
| Apply the Governance Policies | The Policy Directive will need to be governed so that agile change can be accommodated in future. This relates to where the SOA Policy Lifecycle may be implemented. | Marketing will have authority to create, update or delete any business policies classified as marketing |
The main outputs from the business layer decomposition, which will be used at the Architecture layer, are:
- Solution Policies: Decomposed from the Policy Directive and influenced by the Solution context.
- Solution KPIs: Decomposed from the Policy Directive and Business Objectives and influenced by the Solution Context.
- Policy Domains: Service Level Management selected in our example with Customer focus.
Architectural Policy Layer Solution
Once a reasonable level of business policy is specified, then it can be decomposed into the architectural layer policies that will be needed to implement the business policies. The architectural policies refine the business policy as needed in order to ensure a high quality design for the solution and identify which policy pattern, if needed, should be used to meet the business needs.
There are three main concepts in the Architectural layer that need to be considered. These are shown in the figure and table below.
Figure 5. Example for decomposing policy at the Architecture Layer
At this point in the SOA Policy lifecycle we have shown a means for authoring and transforming business policies down to operational policy sets that can be associated with each service invocation.
Table 2. Architecture Layer Decomposition
| Name | Description | Example |
|---|---|---|
| Solution Policy Decomposition | This activity defines how the architecture layer is used to decompose the solution policies provided by the business layer into policies that can be applied to the SOA resources for the solution in context. This involves identifying the resources affected (service, information, or process) | All banking services must respond within 2 seconds. All information services must respond within 1 second. |
| Domain Pattern Selection | Domain patterns, provided by the existing SOA infrastructure, can be used to enforce the usage of a particular implementation pattern. Selection of existing patterns accelerates time to value and development, by allowing these existing components to be reused rather than having to develop a new solution. | Use an SLA Pattern that will monitor service latencies and route to the appropriate service to realize the service level required. |
| Operational Policy Sets | These are the result of transforming the solution policies into policy sets that can be executed using the operational implementation of the domain pattern. This delivers the end to end policy management lifecycle using the deployed capabilities and products used to manage these policies. | Specific service policy sets include routing and monitoring policies. |
Operational Policy Layer Solution
Finally, at the operational policy layer, the business and architectural policies can be further decomposed into the set of actionable operational policies that are needed in order to enforce and monitor the policy and ensure it is meeting the original needs of the business.
The architectural layer provided the means to map the business policies onto the functional policies interpreted by the processes and services and non-functional policy sets that control how the architectural patterns are configured in the operational solution. The SOA Policy Reference Architecture identifies four key non-functional policy areas implemented in the operational layer. These operational policy areas provide the non-functional building blocks used for the architectural patterns described in the last section.
Taking the Policy Tree example there are three main concepts in the Operational layer that need to be considered. These are shown in the diagram and table below and described in more detail in subsequent sections.
Figure 6. Example of Operational Layer policy elaboration
Table 3. Operational Layer Decomposition
| Name | Description | Example |
|---|---|---|
| Collate policy sets across policies for any given interaction | The policy sets resulting from a particular policy directive need to be merged with other policies that are already deployed to any particular service interactions | SLA policies for Banking service interactions will need to be merged with existing security policies that protect the customer account data |
| Map policy sets to PDP/PEP configuration | The PDPs and PEPs used to interpret and enforce the policies will often use the policy set in association with other dynamic information to perform the enforcement. Introduction of new terms in the policies may require that the configuration of the PEPs, mediations, or their associated registries be changed to support the updated policies. | The SLA mediation uses provider policy latency statistics to determine available endpoints that can deliver the required SLA |
| Map monitoring policy sets to KPI dashboards and alerts | The policy sets from the architectural layer will define what needs to be recorded from each interaction. However the means of displaying the policy KPIs in dashboards and reacting to important exception criteria and alerts will still need to be configured | Raise alert if the latency is GT SLM Policy or a service utilization is GT 90% |
SOA Policy provides the means to deliver business agility and responsiveness in SOA solutions but requires a systematic approach to governing and managing those policies. This document has summarized the recommended practices and lifecycle that should be adopted to realize solutions that can leverage the SOA policy building blocks and patterns provided by the various policy technologies.
The IBM SOA Policy Reference Architecture describes how to systematically author, deploy, enforce and monitor policies as part of a solution. It describes how this policy lifecycle interacts with the SOA Development lifecycles being used to develop the solution services, processes and applications. Finally it describes how SOA policy aligns with and supports the overall Governance processes being adopted by the organization.
| Name | Description |
|---|---|
| SOA_Policy_Reference_Architecture_Full_Article.pdf | Download the complete SOA Policy Reference Architecture |
- Stay current with
developerWorks technical events and webcasts focused on a variety of
IBM products and IT industry
topics.
- Follow developerWorks on
Twitter.
-
Evaluate IBM
products in the way that suits you best: Download a product trial, try
a product online, use a product in a cloud environment, or spend a few hours
in the
SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
Bob is an Executive Architect with IBM in the SOA Advanced Technology group, performing worldwide consulting for IBM customers in the area of SOA Governance and SOA Architecture since May, 2006. He is a co-author of IBM's SGMM (SOA Governance & Management Method). He is a member of the industry TOGAF (The Open Group Architecture Framework) SOA Governance working group, has written two books on SOA: 'SOA Governance, Achieving and Sustaining Business and IT Agility', and 'Executing SOA, A Practical Guide for the Service Oriented Architect', and has two patents pending in the area of SOA Governance. Bob has over 20 years experience in the telecom industry at MCI and Verizon Business. He was the MCI chief architect, leading the enterprise architecture group and working across the entire order to cash suite of applications. He led the development of the SOA based single stack strategy to simplify the multiple network and applications silos. Bob has driven the strategy, planning, and execution of MCI's product development in the area of contact centers, IP/VPN, VOIP, IMS, and managed services. For OSS, he has led successful implementations to automate network provisioning, network restoration, and network management. Prior to joining MCI, Bob worked as a consultant for American Management Systems (AMS) and Ideation, Inc. He has MS and BS degrees in Computer Science from Purdue University and has been granted two patents in the area of telephony. He has spoken at various industry forums, written for The SOA Magazine and been quoted in CIO Insight, Telecommunications, Infoworld and Computerworld.
John Falkl is an IBM Distinguished Engineer and the Chief Architect for SOA Governance within IBM’s Software Group. John’s responsibilities include driving the overall technical strategy and product requirements for SOA Governance functionality, as well as coordinating SOA Governance activities across IBM organizations. John led the Governance Incubation Project for the IBM Software Group CTO. With this project, John led the establishment of key SOA Governance processes and aligned the software product strategy against these baseline use cases. Of his 28 years with IBM, John spent 12 years in IBM Global Services where he lead a number of high impact projects, most recently the definition and development of an SOA Management service offering for IBM’s Global Business Services organization. John holds 3 industry certifications in IT Technology and has a significant background in enterprise architecture and development (including 9 years in management). John has also led many high level technology studies within IBM.
Stephen Cocks is a senior software engineer at IBM's development laboratory in Hursley, UK, where 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.
Arnaud Le Hors, a member of IBM software standards group, is responsible for driving the coordination of several IBM standards activities from a strategic and technical point of view. Arnaud has been working on open standards for 15 years, both as a staff member of the X Consortium and W3C and as a representative for IBM. He has been involved in every aspect of the standards development process, including technical, strategic, political, and legal, both internal and external to an SDO and to a company like IBM. Arnaud was involved in the development of standards such as HTML and XML and one of the lead architects for Xerces, the XML parser developed by the Apache Software Foundation. Arnaud is currently IBM's Linked Data Standards Lead.
Duncan Clark is an architect currently managing requirements for integrating the IBM Operational Decision Management product with other IBM products and solutions. He is based in IBM Hursley Labs and over the last year has been responsible for demonstrations and integrations including IBM ODM, BPM, and Tivoli products. He managed the integration of the ILOG embedded Rules into BPM 7.5 and the development of support pack LA71 providing integration tooling and development patterns for using ODM with Business Process Manager. Prior to this, Duncan was an architect working in the WebSphere Service Registry and Repository team with responsibilities for the SOA Governance and Policy Management aspects of WSRR.
Andy Ritchie is a Senior Software engineer and architect in IBM focused on BPM and Decision Management. His main focus is on joint solutions with multiple IBM products and regularly works with IBM services and technical sales teams on client solutions and methodologies. With more than 27 years in IBM he has a broad and varied experience. Business Policies and rules are part of his core role in Decision Management working on Banking, Retail, Telecoms solutions for Eligibility, Compliance and Pricing decisions and rules. He has also architected IBM SOA Middleware, solutions in multiple industries so SOA Service Governance with Policies is also key. Previous to this he spent an 18 year period in IBM Development on ISDN, X.25 communications and Speech products.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
