SOA Policy Reference Architecture Full

Article

Authors:
Robert Laird, SOA Foundation Architect
Andy Ritchie, BPM, Business Rules & Events Solutions Synergy
Duncan Clark, ILOG Synergies Architect
John Falkl, Distinguished Engineer & Chief Architect, SOA Governance
Stephen Cocks, Architect, SOA Policy and Governed Service Gateway
Arnaud Le Hors, Software Standards Architect

Page 1 of 94 SOA Policy Reference
Architecture

Table of Contents
1. SOA Policy Reference Architecture Introduction............................................3
1.1 Abstract ............................................................................................................... 3
1.2 Purpose and Scope .................................................................................................... 3
1.3 Audience & Usage .................................................................................................... 6
1.4 The journey of policy................................................................................................ 8
1.5 Policy Management Primer..................................................................................... 13
1.5.1 Policy Administration Point (PAP)....................................................... 15
1.5.2 Policy Monitoring Point (PMP)............................................................ 16
1.5.3 Policy Enforcement Point (PEP) ......................................................... 16
1.5.4 Policy Decision Point (PDP) ............................................................... 16
1.5.5 Policy Information Point (PIP) ........................................................... 17
1.6 SOA Policy and SOA governance .......................................................................... 17
2. SOA Policy Reference Architecture Description............................................18
2.1 Policy Lifecycle Management ................................................................................ 19
2.1.1 Policy Lifecycle & Governance Policy .................................................. 22
2.1.2 Policy Lifecycle................................................................................ 23
2.1.3 Policy Building Blocks....................................................................... 35
2.2 SOA Policy Layers ................................................................................................. 41
2.2.1 Business Policy Layer....................................................................... 42
2.2.2 Architectural Policy Layer ................................................................. 47
2.2.3 Operational Policy Layer ................................................................... 50
2.3 Service Development Lifecycle.............................................................................. 60
2.3.1 Service Lifecycle & Governance ......................................................... 61
2.3.2 Service Support & Delivery ............................................................... 62
3.0 Example for applying the SOA Policy Reference Model .............................63
3.1 Policy Layers – How to think about and decompose policy so that it is useful ..... 64
3.1.1 Mapping Business Requirements to Solution Policies and Policy Domains at
the Business Layer................................................................................... 66
3.1.2 Using the Architectural Layer to leverage SOA Policy Lifecycle and Map
business policies to Architectural Policies .................................................... 74
3.1.3 Operational Layer............................................................................ 84
4.0 Conclusion ........................................................................................................91
5.0 Mapping of SOA Policy Architectural Elements to IBM Product .............91
6.0 References and Appendix................................................................................92
6.1 References............................................................................................................... 92
6.2 Term Definitions..................................................................................................... 92

Page 2 of 94 SOA Policy Reference
Architecture

1. SOA Policy Reference Architecture Introduction

1.1 Abstract

Every organization has and uses policy to make decisions that are important to
the business and IT. Many times policy is created as a result of something
negative happening in the organization. Management reacts by creating a policy
to ensure that the actions of the organization follow the proscribed standards and
guidelines that is manifested as policy. Efforts are made to automate the
resultant policy implementation so that once policy is made, control is in place
and will eliminate the negative event or at least control the consequences.

There is a better way. Understanding the SOA Policy Reference Architecture
allows the practitioner to be proactive instead of reactive about policy. This
paper will provide a detailed understanding about the component parts of policy,
where it can be effective, and where it should come from. Taking a top down
approach allows the IT and business practitioner to use the goals and objectives
of the business to drive policy understanding and decomposition into its
component layers at the business, architectural, and operational level. The
policy lifecycle will be explored so that the practitioner can manage and govern
policy in an appropriate manner. The application of policy to resource
management, specifically to the Service Development Lifecycle for SOA services
will also be discussed. The paper finishes with an example that demonstrates in
detail the process of creating policy.

1.2 Purpose and Scope

Policy is a word that most people have heard of, but often do not fully understand.
The Merriam-Webster dictionary defines policy as “a definite course or method of
action selected from among alternatives and in light of given conditions to guide
and determine present and future decisions”. A more technical definition may be
found in The Open Group’s SOA Ontology, which defines policy as “a statement
of direction that a human actor may intend to follow or may intend that another
human actor should follow. Knowing the policies that apply to something makes it
easier and more transparent to interact with that something.”

Page 3 of 94 SOA Policy Reference
Architecture

e.A “business policy” then. This makes SOA more consumable and accelerates the usefulness and adoption of SOA solutions.pdf.g. OMG defines business policy and business rule as follows1: • Business policy: a broad directive that needs further interpretation (in business rules) in order to be put into practice. having Policy defined to control the behavior of its resources in a consistent manner can align the Business and IT environments and provide agility to change the behavior quickly in a well governed manner. the agility and flexibility within SOA is limited. Where policies are implemented.omg. 1 “Overview of OMG Business Motivation Model: Core Concepts”. is a type of business directive that expresses the course of action that the business wants to have happen within a set of business conditions. Business rules make business policies practicable. SOA practices help businesses identify and focus on optimizing the value of its key resources like services. e. This means: • The policy can be applied to a variety of service. enforced and tightly bound to the resource itself.g. By adding policies to the SOA. OMG Org. processes and information. Business policies may be documented in an enterprise BMM. “a transaction must complete in 2 seconds or less” has the advantage that it is abstract and can be applied to any service. for example. In business solutions. 8 December 2008 Page 4 of 94 SOA Policy Reference Architecture . or in a separate policy management system • Business rule: reference to a rule in the operational business. we add points of control and agility for business and IT. including a service-oriented architecture (SOA).org/oceb/BMM_Overview-Core_Concepts_%5B081208%5D. Policy management is only applicable when policies are abstracted from the resources and enforcement points that they are eventually applied to. Policy management plays a key role in enabling policy and governance in any environment. A separately authored and maintained policy. “A home mortgage must not be for more than 4 x the borrower’s salary”. “Loans must be repayable”. say a credit card service or a price lookup service. http://www. Any change to the tightly bound policy requires the resource to also be updated and not just the policy. and guide business processes Policy is most effective when it is defined in clear terms that are understandable and can easily be communicated to its intended audience and when it can be enforced accurately and consistently to achieve its intended purpose.

This is an example of an anti-pattern that results in poor (or no) agility. Architects are concerned with addressing the usage of policies and policy infrastructure to support all aspects of Business and IT agility. service level. For the business. is to first ensure that design time policies identify and fix quality issues and non-conformance before services are put into production. Many times today. including:  What Business Goals. being able to readily change policy is a core component of having true business and IT agility. and regulatory policies. that important business policy is buried in a set of procedural code that must be identified and changed system by system. heterogeneous. Runtime policies monitor and enforce actions in the production environment to provide a quality of service necessary for the proper transaction of the service to meet security. That binding can take place later for a specific development. for example to help maintain a certain level of service or to provide a secure environment. Policies are used at runtime to enforce specific standards and behaviors. An SOA policy may define the principles and guidelines for a resource at design time. Design policies define and enforce a certain quality of service in the service development that helps to create a high quality of service. • There is the ability to change the policy once centrally and have this applied to multiple services consistently which is not possible if the policy is tightly bound to a particular service. technical. This helps the service’s runtime ability to function in an optimal manner. • The policy says nothing about how or where it gets enforced. Directives and Objectives can be implemented by Policy?  What are the Benefits for the business of solutions using Policy?  How will impact analysis on policy effectiveness be performed?  What is the lifecycle for a policy?  How do we categorize policies and their implementations in a manner that is useful to the Business and IT? The SOA Policy Reference architecture defines an enterprise approach to: Page 5 of 94 SOA Policy Reference Architecture . while another policy defines the principles and guidelines for a resource at run time. The goal.highly distributed. testing or production environment. and any other runtime standards. of course. The nature of SOA . Having business policy specified in one or more machine readable repositories that can be easily changed and tested is a “best practice”.means that it is critical for its artifacts to be governed by specific business. and very dynamic .

Business policies and Information policies all be supported within one architecture?  Provide a detailed example of how to use the SOA Policy Reference Architecture 1. Service Level Management policies. including Security policies. managing and enforcing SOA Policies. Consider Figure 1 below and then the explanation of roles in the table: Page 6 of 94 SOA Policy Reference Architecture .3 Audience & Usage This document is meant for all roles who would be Authoring.  Use policy to realize business requirements  Obtain visibility and understanding of how policies should be used in the business solutions  Establish architectural principles that support consistent realization of policies and goals in those solutions  Provide tools and components to transform business goals and policies into operational solutions  Adopt processes to govern and manage change management for the policy component in the operational solutions In this document we'll address:  What are the components of a SOA Policy architecture?  What are the responsibilities of each policy component in that architecture?  What are the details around the SOA Policy Reference Architecture that allows the user to consider all SOA policy needs?  How can all needed policies. Administering.

Infrastructure Architect and Security Architect. Usage of the SOA Policy Reference Architecture Business Policies & Domains Architecture & Operational Policies and Standards Business Plans & Business Enterprise Objectives Analyst Architect SOA Architect Infrastructure Architect Security Architect Usage of Policy SOA Policy with SOA Patterns for Policy KPI’s SOA Policy Security Policy Services services Infrastructure Patterns Architecture Service & Policy Realization Developer Figure 1 – Roles and their usage of the SOA Policy Reference Architecture Role Usage Business  MUST use the business plans and objectives and Analyst refine them into business policies and domains that are needed for their implementation. and operational policy domains and standards and then use this document to create guidelines and standards around architecting the use of Page 7 of 94 SOA Policy Reference Architecture . Enterprise  MUST translate the business policies and domains into Architect the set of architectural and operational policy domains and standards and identify and apply those policy domains and standards to the architectural oversight of the enterprise with the SOA Architect. architectural. SOA Architect  MUST work with the Enterprise Architect to understand the business.

 MUST create KPI’s around policy usage so that how policy is used can be modified as the business changes (“Policy KPI’s”).  MAY use this document to understand where to use Policy to enhance current solutions and create additional dynamicity. the “SOA Policy Infrastructure” from the Infrastructure Architect. Page 8 of 94 SOA Policy Reference Architecture . “Policy KPI’s” from the SOA Architect. Infrastructure  MUST use this document to create the SOA Policy Architect solution specific deployment models for the overall SOA infrastructure in consultation with the Enterprise Architect (“SOA Policy Infrastructure”.4 The journey of policy There are 2 main value aspects to policy that we have captured into a policy repository: 1. and the “Security Policy Patterns” from the Security Architect.  MAY use this document in conjunction with the SOA Policy Lifecycle document to understand importance of Monitoring in policy driven solutions to prove policy is being enforced. SOA services with policy (“Usage of Policy with SOA Services Architecture”)  MUST create the specific policy patterns to be used in the architecting and operation of SOA services at the enterprise (“SOA Policy Patterns for Services”). Value for IT teams deploying SOA solutions in a standardized manner that optimizes the value of such solutions. Security  MUST decide on which security standards and Architect patterns are to be used for SOA and create the security policy patterns (“Security Policy Patterns”)  MUST identify goals related to security domain and apply from a security perspective to the business solutions (“Security Policy Patterns” Developer  MUST create realizations of services and policy using the “Usage of Policy with SOA Services Architecture”. Table 1 – SOA Policy Reference Architecture Roles & Responsibilities 1. “SOA Policy Patterns for Services”.

An important component of traceability is a policy information exchange mechanism between the different parts of the enterprise architecture in which policies are defined. 4. Automation . Formalization . we identify and discuss the set of policy domains that SOA Policy addresses. The resulting reduction of the ambiguity of the characterized policies makes them readily available for automation. An example is providing access to view insurance quote premium policies authored in decision tables or in a natural language type format using an agreed business vocabulary. any manual management of the relationships across the horizontal and vertical policy Page 9 of 94 SOA Policy Reference Architecture . and management solutions. A business vocabulary is used that is easy for both IT and Business teams to understand. Standardization . and enforced. Formalization and standardization can provide a good basis for traceability. Value for Business users in specifying their business intent in a standardized and manageable manner and having the resultant business policies automated and easily changed in the future. The synergy between SOA and policy management is achieved by a number of benefits resulting from the introduction of policies: 1. standardization.Common policy expressions and semantics for a specific policy domain can be unified into an implementation-independent standard that guarantees that two different systems are compliant with the same policy regardless of their specific implementation.The formalization and standardization of policy domains. and service orchestration are now seamlessly recognized as “first class citizens” by development tools. 3. Such concepts as service. Traceability . and management systems. allows the automatic and transparent configuration of these systems and the automatic enforcement of related policies. together with the recognition of these standards by tools. and automation. service composition. 2. middleware. the IT team may enable business visibility to the Business Policies or Rules via new tools. This has the added value of reducing the number of iterations between Business and IT teams to understand and successfully implement the business requirements. middleware.In a federated policy management system. transformed. traceability between related policies at different levels of abstraction can be achieved by leveraging formalization. In some policy areas.Policy domains have been identified and formalized into a standard representation of policy expressions. Later in this document. However. The adoption of SOA best practices has created an ideal environment for the introduction of several aspects of policy management inside an SOA solution. 2.

leaving the human to focus on governance tasks that cannot be automated. as described in a latter session. PEP. Policy traceability at the vertical dimension means that the origin of the policy can be traced to a business or IT objective and the resultant decompositions into policy of that objective. which is where automation can play an important role. Dynamicity . In other cases. This is possible since the policy changes can be updated separately from the IT processes. Policy is updated by configuration updates or in some cases by separate business decision services. In any case.Reuse can be achieved at various levels by collecting policy expressions and related values from best practices in the specific domain into a library of reusable policies. c. Reuse . For example: a. 6. Specification of policies for governance is likely to include instances where human decisions will need to be made. including the policy being vertically traced. Technical standards are an example of this where software can validate that the service has followed the standard. b. 7.Ability to request business changes which are policy driven. 5. and PMP. reuse can be achieved at a higher level. Alternatively. and delete of the policy itself. services or applications which use the policies. Business request to change insurance quote premium policies for implemented as business rules. Business request to change the Service Level agreement for a specific group of customers to provide enhanced support. It should be noted that policy traceability is a required SOA Solution building block. For example. and the detailed results of applying the policy to each resource. in which a tree of related policies of a different type and level of abstraction can guarantee compliance with mandates or standards at the business level. and therefore specified once but reused multiple times. This enables the changes to be implemented and deployed more quickly by IT and at lower cost with improved time to value. there is an opportunity to automate the policy checking. policy traceability at the horizontal dimension means that a single policy can be traced with all of its relationships. the various forms of the policy in the PAP. Page 10 of 94 SOA Policy Reference Architecture . update. who and when applied policy to the resources the policy is controlling. Policies for Governance and Governance of Policy – Governance is ultimately characterized by a series of “control points” that allow for checking that the governance policies have indeed been followed. Business request to change security password policies to increase security in a specific area. a single policy can be attached to one or more services. This would include all create. dimensions is difficult to scale up to an enterprise level. read.

Formalization Agreed Policy domains Some new business and Policy expressions requirements can be reduce design work and implemented faster repeated effort 2. updating. This allows the business either to confirm the policy is meeting the business goals and requirements or identifies that further policy change is needed. Change Management . should be governed in a manner that is consistent with the overall governance plan at the enterprise. Standardization Improved and simpler Reduced costs and less integration across risk in projects business 3. 9. This includes the creation. Policy Measurements . This is extremely important in business situations where some business policies or rules may be changing on a daily basis to respond to market needs. The value to IT and business can be summarized as follows: Benefit areas for Policy Value to IT Value to Business 1. and KPI’s to measure policy effectiveness. Identifying the change management rules around policy will allow the enterprise to enable the direct stakeholders to update policy as quickly as possible while keeping the policy that is more sensitive to change within the control of the experts. like any resource. reading. IT may enable business users to change aspects of the policies directly in a controlled manner. 8. Traceability Trace which business Reduced risk for new function(s) are using the changes since policies dependencies can be viewed and validated Page 11 of 94 SOA Policy Reference Architecture . Policy. we can make sure that policy effectiveness is optimal and benefiting the business. Automation Automation of policies Business Policies can be can improve performance captured in form that both of IT systems.By ensuring well defined Business Objectives. It also includes the assignment of policy to a resource and the ability to trace a policy both vertically and horizontally (see Traceability above). and deletion of policy. Only certain individuals or roles should be allowed to perform each policy action. business and IT can understand and collaborate 4. Policy that has been captured into a policy repository can deliver significant value to two main groups. setting the measurement criterion.In some cases for Business Policies.

more new maintenance & new business projects can be business projects. Re-use Reduced time. Change Management IT have good tools for IT can enable some Policy changes business policies to be changed by business users 9. and used. technical.highly distributed.5. Policy Measurements IT can monitor IT Policy Business can monitor performance to identify effectiveness of high problems and provide level business policies to ongoing improvements assess how effective they are using KPI’s Table 2 – Benefits of Policy Usage The nature of SOA . and regulatory policies very important for providing a common framework of rules and guidance for both the development (design time) and operation (run time) of services. makes a set of business. effort & With IT being more cost for ongoing efficient. heterogeneous. Dynamicity Reduced effort to change Business changes and test solutions to meet available faster to new business needs address changing market needs & opportunities 7. undertaken 6. Mapping the policy benefit areas into the 3 main policy points shows where those benefits will be realized in the policy architecture: Aspects Key factors Comments Policy Authoring & Formalized Defined Policy domains & Management Vocabulary Standardized Consistent semantics across business domains Dynamicity Policies can provide Page 12 of 94 SOA Policy Reference Architecture . IT team has the SOA Business has the ability Policy building blocks to control who accesses necessary to control how the policy that it needs to policy is created. are updated. updated control. and very dynamic. 8. Policies for IT team has required Business has auditable Governance and controls to manage processes which control Governance of Policy updates to policies that who and when policies business solutions use.

This makes your SOA more agile and consumable. and therefore. By adding policies to the mix. SOA practices help businesses identify and focus on the key services of the business. improving time to value for business users with reduced costs for their projects. especially in a distributed environment. processes and services Traceability Trace who is consuming policies and results from policy decisions Policy Monitoring Policy Measurements Ensure Policies meeting KPI’s set by Policy Objectives Table 3 – SOA Policy Benefit Realization in SOA Policy Reference Architecture 1. accelerating the adoption of SOA solutions.5 Policy Management Primer We are going to demonstrate that benefits arise to your organization from adopting policy as a control mechanism. In the case of SOA. improved dynamicity for solutions Change Management Dynamicity requires good tools for change management Governance The best change management solutions have strong governance Re-use Having policies managed & stored in central repository enables re-use Policy Enforcement Automation Policies invoked and enforced by runtime applications. A policy is an independent entity that may be applied to one resource or a variety of resources. the assignment of the policy and any associated metadata. we create points of control and agility for the business and IT. In a similar fashion. a “resource” is a service. may take place to a variety of physical enforcement points and decision points. but the same concept may be applied to non-service resources. Page 13 of 94 SOA Policy Reference Architecture .

For example. had some architectural policies applied resulting in some operational policies. As a brief example here is a policy tree showing a business goal which has been refined into a Business Policy. Creating the set of policies will many times be an iterative process that starts with non functional business requirements.An SOA policy may define configurable rules and conditions that affect services during their design-time lifecycle and run-time lifecycle. as we discuss below. Policies are used at runtime to enforce specific standards and behaviors. such as the security needs of the organization. Those policies then need to be managed to the policy target solution. well before these services are made available in a production environment. Figure 2 – Business requirement to policy decomposition The organization of the basic policy architecture and definition of those key points are as follows: Page 14 of 94 SOA Policy Reference Architecture . for example to help maintain a certain service level or to provide a secure environment. architecture level policies are used as standards or guidelines to guide high quality of service at design-time.

including the assignment of policy to resources.5. It accepts management results from the resource runtime engines and is able to provide management functions to be effected based on those policy results. governance and monitoring of policies. It is responsible for deploying policy in a standardized form to any resource runtime engine that subscribes to a policy or set of policies. results in the Policy Management. distributed environment Policy Runtime Architectural Pattern for Service Policy: Author Monitor Store Policy Monitoring Policy Administration Repository Point (PMP) Point (PAP) Enforce Provider Consumer Middleware PEP – Evaluate Policies And take action Policy Enforcement Point (PEP) Policy Decision Policy Information PIP – provides PDP – renders Point (PDP) Point (PIP) External information Authorization. eligibility. Page 15 of 94 SOA Policy Reference Architecture . Or validation decisions Or provides calculated result Figure 3 – SOA Policy Architecture Points 1. The policy lifecycle and resource assignment are governed in a manner that is standardized and repeatable. A PAP provides a single point of presence for policy management and governance. PMP – provides overall picture on policy PAP – Policy Authoring. Policy is created and maintained according to a policy lifecycle and then assigned to resources (such as services) that require it. and management of policy results from the distributed policy runtime engines.1 Policy Administration Point (PAP) A Policy Administration Point (PAP) provides centralized administration. management.

Page 16 of 94 SOA Policy Reference Architecture . o During runtime. including: • Taking action to enforce policies • Receives and makes ready for usage (translates) enforcement policy updates • Provides enforcement metrics to the PMP • Provides enforcement policy results & analytics to PAP and PMP • The places where policies are actually applied and enforced change depending on the lifecycle stage: o During design time.5.4 Policy Decision Point (PDP) A Policy Decision Point (PDP) evaluates participant requests against relevant policies/contracts and attributes to render an authorization.2 Policy Monitoring Point (PMP) A Policy Monitoring Point is a functional component that provides an overall detailed policy monitoring function (i. aggregates measurements and highlights significant events (as specified by monitoring policy) • Provides monitoring policy analytics to PAP and PEP 1.5. analyzes and visualizes the data fed in by the various real time collectors including policy enforcement points • Provides a management console that provides visibility into the management of distributed network of policy enforcement points and the status of these enforcements • Logs. the service registry/repository itself is the point of enforcement.5. including: • Receives and makes ready for usage (translates) monitoring policy updates • Captures real time collection and statistics analysis for display • Correlates.e. 1. policies are generally enforced by the underlying intermediary (middleware) system that connects service providers with consumers. It is typically associated with one or more Policy Enforcement Point’s (PEP’s) and provides specialized decision functionality that is not appropriate for a PEP. eligibility or validation decision or provide calculated results.3 Policy Enforcement Point (PEP) A Policy Enforcement Point (PEP) is a functional point where policy is applied to a resource. the big picture on policy in the distributed environment).1.

4. definition. Page 17 of 94 SOA Policy Reference Architecture . easy to automate governance aspects first. Document the manual steps that are needed to enforce those governance aspects that cannot be automated. 3. The progressive delegation to automation of selected governance and management aspects is a positive trend that reduces the complexity of SOA Governance. 1. An approach seeking to automate as much of SOA Governance as possible would typically address the most operational. as we address more strategic governance aspects. Some aspects of SOA governance can be automated and enforced through policies. Governing policies is addressed in “Policy Lifecycle Management” in this document.6 SOA Policy and SOA governance SOA governance has a broad remit potentially covering processes.5. enablement. Such an approach enables us to: 1.5 Policy Information Point (PIP) A Policy Information Point (PIP) provides external information to a Policy Decision Point. Using policies for governance decisions is addressed in the “Service Development Lifecycle” and “SOA Policy Layers” in this document. and measurement of the governance aspects.1. Define new roles and responsibilities related to the planning. we realize that a more comprehensive and prescriptive approach is required in order to ensure that the governance adequately and consistently reflects business requirements. or the results from a database with information that must be evaluated to make a policy decision. Identify relevant policies starting from our business goals. architectural principles and technologies. such as LDAP attribute information. 5. Associate policies with specific activities and artifacts and their coordination with the manual steps. However. Associate policies to relevant metrics in order to measure the effectiveness of the related governance aspect and its improvement. and those policies themselves may be governed. This includes governing policies (applying governance to policies) and governance policies (policies used for governance decisions). 2.

policy change management is easier. and so on) and is used to communicate business requirements between business analysts and IT professionals. • The Business Layer should be led by a business analyst or a representative from the business that specifies policy that meets the needs their needs. Once an enterprise has designed and implemented business solutions which use policy using this architecture. the policy is normally expressed in natural language (for example. At the highest level of abstraction. Page 18 of 94 SOA Policy Reference Architecture . We refer to this as the policy life cycle. and tactics that define the details of how the business requirement is going to be implemented and enforced across the organization. Policy Lifecycle Management – Manages the authoring.2. This includes breaking down policy into its various layers. • The Architecture Layer should be led by architects who are responsible for the integrity of the SOA. French. The SOA Policy Reference Architecture assists the organization in understanding and properly creating its SOA Policy Architecture and ultimately. The reference architecture provides enough information to implement a policy system. and operational. As the two parties begin to collaborate. a policy is simply a statement of a specific business need. To understand how a policy expression can be used as a component of a policy-enabled SOA solution. strategies. what they do and how they interact with each other. English. the lifecycle for managing policy. SOA Policy Reference Architecture Description The reference architecture delves into the details of the various policy components. enforcement. 2. and monitoring of the policies. architectural. • The Operational Layer reflects the specification of the runtime policy that implements the operational policy patterns. At this level. SOA Policy Layers – Policy layers is a vertical dimension for policy classification which provides a level of abstraction for policies that includes business. the SOA Policy Reference Architecture has a strong interaction with the Service Development Lifecycle (SvDLC) and will also be discussed. its SOA policy solution. and the application of policy to the Service Development Lifecycle. this business policy is then decomposed into a set of objectives. transformation. we have to look more closely at the stages that a policy goes through on its way from authoring to being enforced and monitored. It consists of 2 parts (see Figure 4 below): 1. In addition.

Business Policy Policy Business Policy Service Lifecycle Development Management Business Policy domains for behavior and performance Lifecycle Business Policies Policy Lifecycle Service Lifecycle & Governance Policy & Governance Policy Architectural Policy Architectural Policy domains for SOA Resources Model Author Architecture Policies Transform Assemble Deploy Enforce Operational Policy Monitor Manage Operational Policy domains that are non-functional Operational Service Support & Policy Building Blocks Policies Delivery Policy Figure 4 – SOA Policy Reference Architecture 2.1 Policy Lifecycle Management The Policy Lifecycle Management consists of 3 main areas as shown on the figure below: Page 19 of 94 SOA Policy Reference Architecture .

For example. Consider the following: Page 20 of 94 SOA Policy Reference Architecture . Enforce. Policy Lifecycle . Further complicating this task is that it’s necessary to consider the impact at the business layer. and Monitor phases. It’s difficult to translate business goals and requirements into policies that can be applied to a wide range of resources.each policy will go through the Author.specify the policies that govern the Policy Lifecycle. and operational layer and create policy statements in an actionable form. Policy Building Blocks – provides the standardized policy functions to manage the policy lifecycle in a consistent and efficient manner. Transform. architecture layer. 3. 2. such policies define how the policy lifecycle is governed for a given role or identity in an organization. Business Policy Business Policy Policy Service Lifecycle Development Management Business Policy domains for behavior and performance Lifecycle Business Policies Policy Lifecycle Service Lifecycle & Governance Policy & Governance Policy Architectural Policy Architectural Policy domains for SOA Resources Model Author Architecture Policies Transform Assemble Deploy Enforce Operational Policy Monitor Manage Operational Policy domains that are non-functional Operational Service Support & Policy Building Blocks Policies Delivery Policy Figure 5 – SOA Policy Lifecycle within the SOA Policy Reference Architecture 1. Policy Lifecycle & Governance Policy . identifying policies which provide standards and guidelines for the Policy Lifecycle.

This includes examining the policy domains and vocabularies that are available for policy implementation and deciding if it is necessary to create new domains or policy vocabularies. It’s easier. Another way of stating this is to examine if the existing policy domain implementation contains a solution for specifying the particular policy needed. As shown in Figure 1 on roles and their usage of the SOA Policy Reference Architecture. certain work needs to be performed prior to initiating the Policy Lifecycle. by solutions created through Service Development Lifecycle The Policy Lifecycle describes the sequence of policy management activities required to translate the business intents and goals into the realized set of business. If it does not. of course to just make policy updates to an existing solution. or if it is necessary to enhance the vocabulary of an existing policy domain. architectural.Figure 6 – Policy Lifecycle provides policies to be used. Contrasting that with creating new policy domains: Page 21 of 94 SOA Policy Reference Architecture . and operational policies that standardize those intents and goals. then the architects must consider expanding the policy domains and/or vocabulary to accommodate the policy needs before the core task of actually authoring the policy specification can proceed.

‘define’. This is inherently expensive and time consuming. The policy lifecycle & governance policy must be able to restrict access to policy authoring at a variety Page 22 of 94 SOA Policy Reference Architecture . This monitoring provides information to the SOA Architect about how well the updated policy domain is working. In an environment characterized by coding policy in procedural code. For example. The architect should ‘plan’. and ‘implement’ the domain policy changes and then ‘monitor’ to see how well the policy domains and vocabularies are meeting the needs of the business. When policy is not working well.Figure 7 – Changes to policy domain vs. when policy is rejecting transactions it should be accepting. for example. requiring substantial investment by the enterprise in analysis. the SOA Architect will need to consider adjustments. changes to the policy solution The ‘Policy Changes to Domain’ step includes the assessment and update of the policy domains and vocabularies as described previously.1. it was necessary to change policy via the System Development Lifecycle. coding. design. The ‘Policy Changes to Solution’ addresses the instantiation of policy into specific rules. such policies define how the policy lifecycle is governed for a given governance role or identity. testing and deployment. conditions.1 Policy Lifecycle & Governance Policy We’ll now address policies that provide standards and guidance to govern the Policy Lifecycle. Far better is it to design services to use policies and business rules that are subject only to a Policy Lifecycle. 2. and actions.

3. Permit create/update/delete to HIPPA policy domain to the role of health administrator. Transform. Permit read to HIPPA policy domain to the role of any.2 Policy Lifecycle Let’s now look further into the SOA Policy Lifecycle in figure 8. Author Monitor Transform Enforce Figure 8 – Policy Lifecycle Phases Page 23 of 94 SOA Policy Reference Architecture .1. 2. For example: 1.of levels for a role or specific identity. The first is authoring by a specific operation (create/read/update/delete). individual policy templates. The second dimension is the level of policy authoring being allowed or restricted. Enforce and Monitor. a policy set or a policy domain. The level of policy authoring is described in more detail in the next section on functions. which consists of 4 phases including Author. Permit delete to SAML Security policy template to the role of security administrator 2. This could permit/deny access for three different dimensions. which could include all policies. The third dimension is the specification of a user role or specific user identifier. specific policy template patterns.

Authoring is a function of the Policy Administration Point (PAP). In solve the policy selected. In fact. may be policy domains 2. discuss with the business analyst or equivalent until it is. Identify the KPI’s for restricted to that are needed to each policy domain certain roles.1 Author Phase The goal of the author phase is to create the set of policies needed to support the business goals and objectives.These Phases are described in the following sections. will be necessary to identify personnel that have that role and consult and work with them. 2. Name Goals Tasks Governance Understand The policy 1. such cases. 2. The selected policy domains must be further decomposed into the needed policies using the existing vocabulary for that domain. domains identify the policy the subset needed for example domain or set of for this policy intent. it directive. The following table describes the different tasks related to the Author phase. policy creation is the result of a decomposition process where it is first necessary to understand the policy directives and then select the policy domains that are needed. Identify the The policy will be 1.2.1. Identify The policy 1. If the policy directive is not clear. Review the policy None policy architect must directive and make directive understand the sure that its intent of the policy business goals and objectives are understood. security. Review and Only certain vocabularies authored using a determine if the roles will be Page 24 of 94 SOA Policy Reference Architecture . Review the policy Access to certain policy architect must domains and select policy domains.

The goal of the transform phase is to: • associate policies with the resources they should be applied to. But there is still work to be done in order for the policy to be applied to a resource and then understood so that it can be enforced. Page 25 of 94 SOA Policy Reference Architecture . If not. enhanced.2 Transform Phase The author phase is responsible for creating the set of policies that solve the business directive. vocabulary for that domain so that it may solve the needs of the business intent. the vocabulary 2. create. Such exist in terms of or enhance the domain a vocabulary may policy templates or vocabulary. Name Goals Tasks Governance needed for domain specific vocabulary already allowed to create each vocabulary. This next step in the policy lifecycle is the transform phase. • deploy them to the set of PEPs. Table 4 – Author Phase Tasks 2. If vocabulary. instantiate those policies. or delete appropriate in specific policy parameters to domains. use the roles will be policy policy domain policy rules engine allowed to statements identified or policy templates.1. and PMP’s which are responsible for those resources. It will already exist in a rules engine with be necessary to terms of policy a sufficiently identify templates or a complete personnel that rules engine. Test the policies via simulation to make sure they do what you intend.2. For each policy Only certain specific statements in each domain. 2. create or and consult and must be enhance the work with them. Author the Author the policy 1. previously. have that role not. PDP’s. read. and specify the update.

The policies. or pricing policies. Use case #2 – PAP. • Transform the policy into a local execution form that is understood by the particular PAP or PMP. We want to: • Associate the business decision policies with a decision service resource. PEP. and a monitoring policy tied to a KPI. perform this resource or set of 2. PMP with a PDP: The second use case is for a business decision with a PDP/PEP configuration.e. To describe this process we will consider two main use cases: Use Case #1 – PAP. Associate the task. It will be resources that policies and necessary to they are relevant resources. PEP. a message security protection policy. identify for. for example. PDP or PMP. PMP: The first use case is based on a resource which is a SOA provider service. personnel that have that role and consult and Page 26 of 94 SOA Policy Reference Architecture . • Deploy the policies from the PAP to the PDP which owns the decision services. • Transform the policy from their authoring form in the PAP to the execution form needed in the PEP. We want to: • Associate and protect the SOA provider service with a Service Level Agreement policy. • Transform the policies with the PDP into a local executable form which the PDP can execute when invoked by the PEP. Name Goals Tasks Governance Associate Each policy or set 1. Identify resources Only certain policies with of policies must the policy or set of roles will be resources be associated (i. could be Industry compliance policies eligibility policies. The following table describes the different tasks related to the Transform phase for both of these use cases. • Deploy the policies from the PAP to the PEP and PMP that are responsible for this SOA provider service in a standard WS-Policy form. policies is relevant allowed to attached) to the for.

Transform Instantiate specific 1. 3. PAP. The policies are then retrieved in a standard form by the PEP from the PAP. Deploy The policies must 1. The PAP groups The PAP and policies be deployed to the the appropriate PDP must be Use Case #2 PEPs responsible policies together to aware of each for the physical form a decision other. subscribed to those policies is notified. Table 5 – Transform Phase Tasks Page 27 of 94 SOA Policy Reference Architecture . any PEP required. The PEP The PAP and policies be deployed to the subscribes for all PEP must be Use Case #1 PEPs responsible policies that it is aware of each for the physical responsible for other and have execution of the transacting from the appropriate policy. that is required for representation that PEP. security 2. The PAP deploys and publishes the decision service to the PDP. Deploy The policies must 1. execution of the services. As policies are credentials if published. policy 2. Name Goals Tasks Governance work with them. The PEPs which require this decision based on policy invoke the decision service from the PDP. The policy is None authored policy or set of transformed to a policy into policies that have proprietary format internal been authored. 3.

When the condition for the policy is found to be true.1. Create results for Only certain roles Analytics an overall view. PIP when needed. of what’s going on occur. The following table describes the different tasks related to the Enforce phase. Dispatch analytics policy environment. to PAP and PMP.3 Enforce Phase The author and transform phases set up the policies to be published and then used by the appropriate execution units. in the distributed 2.1. It is sometimes necessary for the PEP to hand off a complex condition for evaluation to a PDP. The policies must then be enforced when events or transactions take place on the resources that the units are responsible for. if too many transactions have occurred in a time period (the condition). resources that the 3.2.2. Policy Analytics provide 1. a policy execution should be allowed management view whenever analytics access to analytics. sometimes security transactions take 2. Enforce the policy units are using the PDP or responsible for. Name Goals Tasks Governance Enforce The policies must 1. A policy has the basic form of condition and action. Identify policies for access to the PDP place on the that resource. Table 6 – Enforce Phase Tasks 2. it is sometimes necessary for the PEP or PDP to retrieve database or file information from a PIP. and PIP.4 Monitoring Phase Page 28 of 94 SOA Policy Reference Architecture .2. and give the policy management function the opportunity to assess and take action. Receive event or The PEP will need policies then be enforced transaction for a connectivity and when events or resource. its action is then enforced. For example. the transaction is rejected (the action). Also.

monitoring policy identifies an exception that requires operational attention. Provide Policy runtime audit 1. because it provides a dashboard and big picture for what is really going on for policy execution. in the distributed 2. Receive event or Interaction with policies be monitored when transaction for a operational units in and events or resource or policy. the environment will resources transactions take 2. Make the results opportunity to available assess and take whenever a action. condition is true area. Check if the policy foundation in this responsible for. This is where the PMP is important. queries for the and give the policy analytics management information. of what’s going on occur. PEPs will usually exist in a distributed environment while a more centralized view is required for monitoring. good governance units are 3. function the 3. of runtime activities events.Policy Monitoring is responsible for providing a management level of interaction with the actual execution of policies and recording how the KPI’s are actually performing in the real world. Create results for Only certain roles Analytics an overall view. a policy execution should be allowed management view whenever analytics access to analytics. Create reports and policy environment. Policy Analytics provide 1. and take action. ITIL is a resources that the that resource. Periodically. Name Goals Tasks Governance Monitor The policies must 1. Table 7 – Monitor Phase Tasks Page 29 of 94 SOA Policy Reference Architecture . for policies. need to be place on the identify policies for governed. The following table describes the different tasks related to the Monitoring phase. Provide reports Only certain roles policy provides for the and queries to should be allowed audit centralized logging runtime policy access to audit.

Monitor Phase (PMP) PMP Translate policy Policy Authoring notifies operation when directives into specific monitoring policy breached policy statement and and sends management author that statement. This aligns to the SLM Policy Domain. ‘TooSlowAction’ Policy created to reroute to secondary endpoint 2A. 2B. 3. A monitoring policy is written to notify operations if “Average response time > 2. Identify the vocabularies needed for each domain – The existing vocabulary is sufficient. 2C. Enforce Phase (PEP & PMP) ‘TooSlowAction” policy PEP sends information about for ‘Credit Card Service’ transaction and policy results is deployed from the to PMP. Author Phase 1. 4. 1. In this case. Author the specific policy statements – A Service Level Agreement (SLA) mediation policy is written to “Reroute to Secondary endpoint if Primary endpoint has latency > 3 seconds”.5 seconds” Page 30 of 94 SOA Policy Reference Architecture . Enforce Phase (PEP) PEP receives request Message from consumer services for ‘Credit Card Message Credit Card Service’ provider service. Operations has agreed to be notified and take action on the primary service. Translate Policy Directives into operational action – the policy directive needs to be decomposed.2. If latency from Secondary Message primary endpoint is > 3 seconds then endpoint transaction is rerouted to secondary endpoint Figure 9 – Policy Lifecycle Example Use Case #1. the decision was made to have a hot standby that will be used if the primary service is too slow or unavailable. Author Phase (PAP) – 4. Transform Phase (PEP) PAP to the PEP – the ‘TooSlowAction” policy for the ‘Credit Card Service’ is converted to PEP internal representation Credit Card Primary endpoint Application Message Service 3A. Identify Policy Domains – The policy directive refers to service availability. Transform Phase (PAP & PEP) – the 3B. ‘Credit Card Service’ primary endpoint.2. information to PAP. the policy directive is ‘Credit Card Service must be available at all times’. 2. After discussion with the business owner.1. Further. Transform Phase (PAP) when primary endpoint – the ‘TooSlowAction” has an average latency policy is assigned to the greater than 3 seconds.5 SOA Policy Lifecycle Example The following illustrates an example of the policy lifecycle Use Case #1.

1. Monitor Phase 1.Transform Phase 1. hence the need for dual lifecycles to manage the service development lifecycle and the policy lifecycle separately. Enforce Phase 1. Enforce Policies – as transactions occur. or routes to Credit Card secondary endpoint. Policy analytics – Analytics are provided to PAP for management control. the PEP either lets transactions pass through to Credit Card primary endpoint if latency is less than 3 seconds.6 Using the Policy Lifecycle in SOA development and governance processes All business changes of governed processes and solutions require a change lifecycle to govern them effectively. 2. 2. Page 31 of 94 SOA Policy Reference Architecture . Monitor Policy Results – The Policy results are monitored and can provide operation notification and action. Policy analytics – Information on the policy results are written to a data collector and then periodically disbursed to the PAP and PMP. Both are in WS-Policy format 3. Monitoring policy for Credit Card service is deployed to the PMP device. 2.2. Deploy policy – SLA Mediation Policy is deployed to the PEP device that handles transactions from any consumer to the Credit Card service. The PMP transforms Monitoring from WS-Policy format to internal policy format. 2. Transform authored policy into internal representation – The PEP transforms SLA Mediation policy from WS-Policy format to internal policy format. Associate policy with resources – Both policies are associated with the Credit Card Service.

Let’s take a simple example of a Business Process or Application which has some embedded decision logic and business function as shown in 11 below. Figure 11 – Example of Process or Application with tightly coupled policies In this example: Page 32 of 94 SOA Policy Reference Architecture .Figure 10 – Governing Processes also has to be managed Ultimately. as to whether to implement using a policy or as procedural code. This choice will either be a solution design choice or a choice as mandated by an Enterprise Architecture Policy. a choice needs to be made for any specific policy solution.

• Process/application tightly binds decision logic or business functions.6. Benefits include: Page 33 of 94 SOA Policy Reference Architecture .Example of using separate Security and SLM policies to enhance SOA solution In this example. the deployment has to wait for the SDLC to complete other changes to processes and applications which impacts time to market. Now. • In many cases even for simple changes to policy.. Provide SLM via policies in a non intrusive manner via the ESB using an SLM pattern which uses the SOA Policy Lifecycle as described in section Error! Reference source not found. in the middleware. Figure 12 . the whole process or application needs to be changed and redeployed.1.1 Using Policy Lifecycle for Service Level Management (SLM) and Security Policies SLM and Security policies will be applied. we have made the architectural decision to: 1. It makes no use of SOA design guidelines to separate the process flow and encapsulate the business function and decision logic as services. let’s look into the details of the Policy Lifecycle and how it can provide the flexibility that IT and the business needs.2. on page Error! Bookmark not defined. for example. in this case at the (ESB) level. • As a result policies influencing the behavior of the solution are tightly coupled to the Service or System Development Lifecycle (SDLC) • Whenever there is a change to policy. 2.

This enables a more agile solution and enables us use the SOA Policy Lifecycle for Business Policies when change is required. • Monitoring the performance of the services is centralized at the ESB and therefore much easier. the Process and the Business Services are still managed by the Service Development Lifecycle. We can separate out the decision logic into decision services.1.1. Changes to policy in these services are not agile or easy to change independent of the SDLC. In this example. • Agile control over which services from various service providers are allowed to be invoked from service consumers. 2. Some policies are still hard coded within this process or application decision logic. 2.Example using separating business policy logic from process and services to improve solution agility. Benefits include: • It is easier to centrally manage service authorization and security without changes to the services and processes managed in the service development lifecycle. Figure 13 .2 Using Policy Lifecycle for Business Policies In this example. Manage security between the process or application and the business services using security policies for service authorization and a Security pattern which uses the SOA Policy Lifecycle as described in section 3.6. we are following good SOA design practice and controlling process decision logic by policy. We have made the architectural decisions to: Page 34 of 94 SOA Policy Reference Architecture .2.

1. services) with policy sets with associated functions for the proper governance and administration of this association. They are: 1. pricing decisions. There are three main building blocks that support the ability to create policies. can be separated out and made far more agile.3 Policy Building Blocks Policy building blocks are necessary for the competent management and functioning of SOA Policy. changing. describe the pattern that enables this use of the SOA policy Lifecycle. Benefits include: • Process flow logic which is process specific stays within the process.1. Policy Runtime – functions for the administration of policies during runtime. Policy Management & Governance – adding. Implement Business Policies as Business Rules within the SOA Policy Lifecycle which can be combined together and deployed as a Decision Service to meet the business needs of processes or business services. 3. and deploy them to policy runtime units for policy enforcement and monitoring. 2. This pattern is normally used when there are business requirements to optimize the agility of the business logic in the solution. or scoring. but interact with each other in a well defined manner: Page 35 of 94 SOA Policy Reference Architecture . changing. For example: eligibility decisions. Policy Authoring. or deleting the association of resources (e.3 and Figure 9 on page Error! Bookmark not defined. Section 3. The Process and Business Services functional logic is still managed by the Service Development Lifecycle. Policy Authoring – adding.g. which may change at a different rate to the process. or deleting policy documents and policy sets with associated functions for the proper administration of said policy documents and policy sets. 2. assign them to resources. • Re-use of business decisions and rules is possible across multiple processes or applications. but the decision logic. Policy Management & Governance and Policy Runtime are distinctive aspects of how policy must be enabled.

including allowing such policies to be associated with (i. Figure 14 shows in more detail the interaction between the PAP functions: Page 36 of 94 SOA Policy Reference Architecture . 1. This takes place in the runtime environment at Policy Enforcement Points (PEP) and Policy Monitoring Point (PMP). Policy Authoring is responsible for creating and publishing a policy or set of policies and making those policies available for Policy Management & Governance. Policy Runtime is responsible for the executable policy runtime machine enforcement and monitoring. 2. This function also covers deployment of the policies to the runtime units that enforce and monitor those policies. assigned to) resources. Policy Management & Governance is responsible for governing and managing the policy or set of policies. 3.e.

governed. SOA Policy Authoring Policy Registry Policy Authoring Policy Policy Set Set Policy Policy Policy Policy Policy a b c d Policy Mgt & Governance Resource Resource Resource X Y Z Policy PEP 1 PMP 1 PEP 2 Deployment Policy Enforcement Consumer Web Services & Monitoring Service or Endpoint application Figure 14 – Policy must be enabled to be authored. managed and deployed Page 37 of 94 SOA Policy Reference Architecture .

c) Ability to consider whether a policy can be applied to a specific resource and. This enables management of policy accountability. provides the ability to respond with a message as to why such an association cannot take place. delete) and any subsequent action to them including action during the policy lifecycle such as retirement. user management changes (for example. or both) b) Ability to apply policy set to a set of resources. output message. read. 3) Resource Definition – is the ability to define resources in such a manner as to allow policy association with those resources. A policy association indicates that the policy set should be applied to the resource at runtime. there are potentially different roles and different individuals who make changes to the policy. if not. traceability will show that there are flaws in the authorization policy for policy lifecycle changes. Rules: a) As a policy is created. f) Traceability on the creation. e) Traceability for policies must include any authorization changes that affect ability to effect policy authoring or changes (for example. adding new roles that may address policy or adding roles that can affect a particular policy domain). update. Conflict resolution is the ability to suggest changes to one or more of the policies to eliminate such conflict. or similar changes.e. Page 38 of 94 SOA Policy Reference Architecture . c) If changes were supposed to be made to a policy and were not. all services that are classified as “HR” services. the traceability will show that no changes were made. and how policy is used (input message. modification and deletion of policy templates and policy sets is supported. b) It is important to be able to reconstruct who did what and when to a policy. 4) Policy association – A resource (such as a service or an operation of the service) can be associated (i. governance. g) Traceability of the association of a policy with a resource (further described in the Policy Association item below) 2) Conflict Analysis & Resolution . managing. for example. d) If changes are made by a person or role that should not make such changes. and running of policies: 1) Policy Traceability . a) Ability to apply policy set at various levels of the resource (for example at an entire service. users assigned to additional user groups). assigned) to one or more policies or policy sets.Conflict analysis for policy is the ability to identify when two policies have a subset of those policies that are in conflict with each other and cannot both be enforced. published and then revised.A competent PAP must support the following sub-functions to assist in the authoring. a single operation.It is necessary to keep track of the authoring of policies (create.

e. A policy set lifecycle needs to exist that provides for the governance of the policy set for create. and delete of the policy data structures. which enforcement or monitoring point handles which policies and resources). XACML. provider service.) 8) Policy Set Lifecycle – A policy set is the grouping of one or more policies together to provide a policy pattern that solves a specific business or IT problem. Instead. help identify a policy/resource that has no PEP to enforce it.. Policy Enforcement Points (PEP’s) will subscribe for all policies for the resources that they are responsible for. d) Input / output message – ability to apply a policy on the front end of the provider transaction (the input to the provider) or the response (response from the provider). at the service level. This query/report will. or both). The function provides the ability to understand the specific policies which are already associated to the resource. for a consumer service. there should be a centralized policy logging function that shows Page 39 of 94 SOA Policy Reference Architecture . etc. including the policy set. among other things. 10) Policy Audit . during a non busy time. There are usually a multitude of policy enforcement points and its non optimal to require operations to review the logs of each such device in order to determine the overall policy audit results. 6) Impact Analysis – Impact analysis for a policy helps to identify the potential impacts to changing a policy.Policy runtime audit provides for the centralized logging of runtime activities for policies. As per the Pub/Sub requirement.Policy pub/sub provides the ability to bind policy enforcement points to operational assets (i. This means being able to query what resources the policy is applied to and where the resource/policy pair is being enforced. etc.) b) The PAP must have the capability to deploy policy to the right set of PEP’s. update. 5) Resource analysis . a) Policy must be distributed in a standard form (WS-Policy. Be able to identify which resources are applied to a specific policy and in what manner (i. 9) Policy Runtime Usage – There is a need to validate that published policies are in fact being used as contemplated.e. c) The PEP/PMP has the option to pull the policy update at a time of its choosing (real time.Resource analysis helps to identify the current status of a resource with respect to policies. operation level. PDP’s and PMP’s via a standardized subscription / notification / registration mechanism. 7) Policy Pub/Sub .

results from all policy enforcements.e. and give the policy management function the opportunity to assess and take action. Many times. 11) Policy Analytics . taking action. the results of policy enforcement may suggest that changes to policies may need to be made. For example. and where vulnerabilities may exist that need to be addressed. Further. Analytics provides an overall view.Policy analytics is responsible for providing information on how often policies are being accessed. how often those policies are “triggering”. Policy management is then able to use this information to have an overall view of the runtime state of the business. a management view of what’s going on in the distributed policy environment. i. the policy audit function is performed by the Policy Monitoring Point. this may mean that the policy has been defined in an incorrect manner and needs adjustment. if policy analytics show that a policy is never getting enforced. Page 40 of 94 SOA Policy Reference Architecture .

2 SOA Policy Layers Business Policy Policy Business Policy Service Lifecycle Development Management Business Policy domains for behavior and performance Lifecycle Business Policies Policy Lifecycle Service Lifecycle & Governance Policy & Governance Policy Architectural Policy Architectural Policy domains for SOA Resources Model Author Architecture Policies Transform Assemble Deploy Enforce Operational Policy Monitor Manage Operational Policy domains that are non-functional Operational Service Support & Policy Building Blocks Policies Delivery Policy Figure 15 – SOA Policy Layers within the SOA Policy Reference Architecture This section will discuss the business. architectural. Policies at each layer have a different focus.2. and operational layers. but what does that mean? What are the typical areas that should be considered from a business perspective? The same concept is true at the architectural and operational layer. What are the architectural concerns that should be thought about for policy implementation? What operational domains does the competent policy architect need to think about and provide policy for? Page 41 of 94 SOA Policy Reference Architecture . It’s easy to say that policies at the business layer should be specifying the business rules or intent.

not all channels are treated the same in terms of business policy with respect to the availability to users / clients.1. 2. such policies are implemented in tool kits that consist of specific policies that can be used and modified as necessary. offer different types of claims through the common process.2. For example. • For channel specific information. the content provided. employees. policy based information. This could be party based information like customer. or cost of purchasable items. and the context the policy is being used in. employee. “Home Building Insurance”. Depending on the industry. In some cases.2. order. They are channel specific information. “If customer is in the customer category “Gold” then ……. A business solution may have a common business process for handling Insurance Claims such that it enforces business activities in a specific order to align with industry regulations and policies. The following are examples: Page 42 of 94 SOA Policy Reference Architecture . “Home Contents Insurance”. capability available. “Car Insurance” and “Bicycle insurance”.2. For example. For example. Many industries have forums that identify best practices or standardized policies for handling common situations. “if “channel” is the “web channel” then provide a 5% discount on all items in the “furniture” category”. Note that channel based implications exist for other policy domains including the security domain and mediation domain. • Probably the biggest aspect around enforcing business policy is using the content provided.1 Situational Aware Policies Situational Aware policies are typically industry specific and help guide best practices behavior for that industry. There are 3 main (but not the only!) aspects of business policy that one should consider when thinking about the possible used of business policy at your organization. It may. item. however. “ • Context provides an additional aspect for business policy. it can be tightly regulated and therefore subject to regulatory policy that must be identified and articulated in such a manner that it is actionable.1 Business Policy Layer Anything that affects business behavior and performance within a business solution is a candidate for a policy at the business layer. supplier. As such some process activities need some context specific rules to implement appropriate business policies to handle the claims effectively.

and technical safeguards for covered entities to use to assure the confidentiality.Type Description Example The Health Insurance The HIPAA Privacy Rule provides If this is customer Portability and US federal protections for personal information. Policies defining interchanges of messages and transactions between businesses to improve speed of operations and reliability / security of operations i.e.000 then record Business Operations for HR of transaction will be processes sent to government revenue authorities. If transaction > Policies Equal Opportunities for Internal $10. integrity. Table 8 – Situational Aware Policy Examples 2. Privacy Rule is balanced so that it permits the disclosure of personal health information needed for patient care and other important purposes. At the same time. Industry Regulation Policies defining Health and Safety.2. then it Accountability Act of health information held by covered must be encrypted 1996 (HIPAA) Privacy entities and gives patients an array whenever it is data in and Security Rules of rights with respect to that motion or data at information.1. and availability of electronic protected health information. Inter Banking transactions and Clearing operations Policies defining detailed stages in complex operations for improving consistency. the rest.2 Business Situation Policies Page 43 of 94 SOA Policy Reference Architecture . standards and reducing ability for inappropriate behavior with Anti Money Laundering regulations and Basel II regulations. physical. The Security Rule specifies a series of administrative.

Always attempt to Investment or downward trends over a period of up sell a customer to Opportunities time to improve business returns the next tier of and investment decisions. Table 9 – Business Situation Policy Examples 2.1. business situation policy can be used to identify the correlation of complex events that. for Business Process Management (BPM). transactions. notification of this or security required before has not taken place. In this case defining taking place in is not policies in terms of the value the customer home constraints.2. a series of business events may occur that indicate that a valuable customer has stopped buying. transactions can be permitted will then identify a decrease the chances of malicious potential fraud business behavior. but taken as a whole provide valuable information that needs to be acted upon. Page 44 of 94 SOA Policy Reference Architecture . intervention can occur. for example. Typically. geographic aspects. Malicious Business Policies which detect fraudulent 1.000. additional selling.3 Business Automation & Process Policy This sub-domain defines policies for the behavior of specific business logic or Business Services. By notifying the proper business personnel of this pattern. For example. Credit where the country Card purchases or money the transaction is laundering. For example. and have > $100 per selling behavior can be used for month in billings. Also service when they policies which detect situations call with a question where client or supplier buying. situation. Type Description Example Business Sales and Policies that detect market upward 1. such actions will result in a potential opportunity that increases revenue or decreases costs.Business situation policies allow for pattern recognition from data about situations that are of interest to the business. country and prior time periods between transactions. in and of themselves. For transactions > Behavior behavior or monetary business $500 and < $10. are not particularly interesting. In other words. perhaps with a visit to the suddenly quiet business or an offer of a one time discount in a constrained time frame. marketing opportunities.

Supply Chain and Manufacturing If the supply is Distribution/Shipping policies to do Procurement. required to ensure maximum uplift If transaction is for and profitability can be achieved.how can policy be used to orchestrate the flow of process in an automated and consistent manner. Supplier Policies Policies which define criteria by If this transaction is which suppliers can be chosen as a for a purple widget of preferred supplier for specific items superior quality. marketing does not drive a incentives and factor in loyalty sports car. and the supplier of choice is expected prices and delivery aspects XYX Company. and adhering to industry regulations on denied party lists for shipping Employee / HR Policies defining the stages of the If job application is Policies hiring processes. then of a certain quality level. white widget then ask for quotes to find lowest current price from all approved suppliers. calculation Policies which relate to calculating Prices has had no claims in that optimize sales across last 3 years and geographical areas. Tax based Policies defining multiple aspects If customer is > 25. Tax Rates based automobile on expected revenue governments insurance expect to receive need to be factored into calculations like state taxes or Value added taxes. Examples include: Type Description Example Pricing. then costs authorize overnight shipping. This allows for a specific control point when business policy can be changed. Manufacturing. needed within 24 Policies Assembly tasks and QA tasks at hours and VP specific parts of Manufacturing approval has been process to optimize efficiency and obtained. otherwise Policies optimizing costs of shipping use normal shipping. and what skills received for post required and time periods to hire which is already allocated then send Policies defining when the business a “Thank You but decides when to provide salary post allocated Page 45 of 94 SOA Policy Reference Architecture . reduce aspects / bonuses for customer quote by 15% for retention purposes.

non-functional standards and guidelines. customer within 3 (Service Level Examples include banking transactions. Business Defines the performance aspects of All web transactions Performance customer facing processes and must respond to the Policies situational awareness solutions. Policies defining customer focused sales promotions to enhance products selling well to further increase market share. Type Description Example Business Data Identifying the security needs of a All product pricing can Security particular data domain and creating policy be viewed by anyone to secure that domain but can only be changed by a manager in the product pricing group.4 Service Level Management Policy Business policies also address service level management. customer satisfaction policies. changes & bonuses based on response” business performance Client sales & Policies defining what sales If this is a ‘gold’ Marketing Policies channels to best sell products at customer. then specific prices to maximize business transfer this call to revenue and profitability the Gold Customer Call Center. or to clear stock on poorly selling lines and reduce inventory Table 10 – Business Automation & Process Policy Examples 2.1. hours. otherwise Page 46 of 94 SOA Policy Reference Architecture . and enterprise operations policies. Agreements) internet sales transactions. Business Determine what steps and what time If this is a ‘gold’ Complaints periods are allowed for customer customer complaint. Policies complaints in order that these complaints then respond within 24 should be handled to provide fast. Introduce new products at initial attractive prices to increase adoption. including various aspects of business performance. seconds. and supermarket queues.2.

The SOA Policy Lifecycle Management defines the architectural principles and best practices needed to develop those architectural policies and apply them to the solutions so that they operate together effectively. policy around usage of a public cloud instead of a private cloud. Service HR processes. 3rd party Defines agreed levels of service for 3rd If this is a cloud service party’s which provide ability for enterprise service. shipped. is provided. The architectural policies themselves represent points of control or configurable constraints on the behavior of the architectural solution.2. Internal Inventory Policies management and warehousing and payroll.2 Architectural Policy Layer Policy is used at the architecture layer to effectively manage the process. Internal Defines how performance service levels Information about Enterprise and are achieved for departmental or Cross employees who leave Cross enterprise processes and situational the company must be enterprise awareness solutions. Business Provide QOS on sold goods by providing If the product breaks Quality extended guarantees on product quality within the first year.2. the store Policies will match that price. for example allowed.1 Architecture Process Policy Architectural process policies provide configurable control of the manner in which the processes operate. and policies for using more cloud resources in times of high demand. a Policies by providing service for multiple years at replacement will be a reduced rate or part of purchase price. 2. then no Policies to meets its internal and customer proprietary data is focused service policies.2. Business Attracting market share and additional If proof of a lower price Competitive business demonstrating value for money. This allows policy to be used to control the decisions or Page 47 of 94 SOA Policy Reference Architecture . Table 11 – Service Level Management Policy Examples 2. service and information elements of a service oriented architectural solution. Examples include available for 3 years. hours. responsive service while allowing respond within 48 business time to investigate properly.

2.2 Architecture Service Policy Architectural service policies provide configurable control to services to provide effective usage. Examples of process policy include: Example Description Example Process Flow Processes will often contain decision Business rules can be Decisions points where the optimal decision will used to provide evolve over time and need to be defined eligibility decisions as by policy rather than defined as part of part of an insurance the process. routing to policy gives the business the ability to separate process optimize and manage the process paths for eligible or decision using the Policy management ineligible insurance lifecycle. quotes.paths taken within a process or the roles or individuals to which the activities and tasks should be routed or assigned. solution become The governance roles and responsibilities overdue. Process There is often a need for escalations and When activities in an Governance exception handling within processes that insurance quoting policies will vary as the organization changes. Examples include: Example Description Example Quality of SOA provides a flexible means of sharing Customers are Service services across multiple consumers and categorized as Gold. However the requirements of Silver and Bronze and each consumer may be different and are offered different policy is used in conjunction with an ESB response times when to route to the appropriate endpoint of the obtaining information service to deliver the required quality of about their accounts. routing and quality of service within the solution. Table 12 – Architecture Process Policy Examples 2.2. Routing clients. service. escalation (as defined in a RACI matrix) can be routes automatically to defined as policies and thus configured the correct manager to into the process allowing the governance ensure that the quote required. These response times are defined through Page 48 of 94 SOA Policy Reference Architecture . Control of the decision by process. This use of policy allows the processes themselves to be controlled using policy. is reallocated and the customer satisfaction is maintained.

2. and deleted across the services in the solution. This information is made available through data can be accessed services it becomes increasingly difficult by systems on behalf to define the context in which a service of the customer but not should allow access to the information it by marketing or third manages. updated. By using policy to define the party systems. Information In modern solutions the confidence that Case management Page 49 of 94 SOA Policy Reference Architecture . As the personal data. Table 13 – Architecture Service Policy Examples 2. encryption of This security will depend on the particular the data will be context of the interaction and policy can required.3 Architecture Information Policy Architectural information policies provide configurable control of information used within the solution.2. This ensures secure and optimal quality of information when the information is being created. interactions to say whether the information could be accessed. policies and used by the ESB to route to an appropriate service that can deliver that response. Service Maintaining security and integrity in a All customer data must Security and solution will often require the use of be confidential implies Integrity standard patterns that determine the that when passing this protection to be applied to information information between passing between services in the solution. services. This conditions under which the information would typically result in may be accessed or changed in the the use of XACML service. be used to configure the behavior of the interaction within this context. read. Example Description Example Information Information will often need to be A customer can only Security protected in terms of who can see or modify their own update what elements of data. the system architecture allows policies being applied the security goals to be maintained to the service across different and evolving contexts.

Policies can be used to information becomes identify certain situations that warrant available. 2.2. 2.3.3 Operational Policy Layer Policy at the operational policy layer is specific policies that are actionable and are rendered as settings and entitlements.Quality can be placed in information is often solutions require subject to interpretation and depends on activities to be initiated the history and provenance of the when the correct information. changes in that confidence or require other activities to occur. the concepts of access control remain the same. Although the operational policies for access control at runtime and management differ.2. This section addresses the main areas of common usage of operational policy but is by no means exhaustive.1. we must consider the following key broad requirements: Denial of Service Prevention Policies to ensure that runtime services do not become unavailable due to a deliberate denial of service attack. Page 50 of 94 SOA Policy Reference Architecture .1 Security Policy The following policies come under the broader grouping of runtime Security Policies and should be considered together: Access Control Policies for access to runtime resources Message Protection Policies for protection of data contained in messages at runtime Integrity Policies to ensure that data is not invalid or does not become invalid In order to secure an enterprise.3.2. Table 14 – Architecture Information Policy Examples 2.1 Access Control Policies Access Control is fundamental to security in order to ensure confidentiality and integrity of both runtime resources and management data.

identity management is an action performed at management time (and not during runtime) even if the managed identities are used during runtime.1 Identity Management Policies Identity management concerns the management of the identity of the users within the enterprise. integrity. the policies for each aspect differ. suspend userid. As its definition suggests.3. archive user identities and delete from LDAP Require This policy is usually realized by If Password > 80 days password automated email and mandatory user old. ultimately the policy should be converted to a standard machine-readable WS-SecurityPolicy Page 51 of 94 SOA Policy Reference Architecture . such as Identity Federation (establishing a single Identity to be used across multiple domains). Authentication and Authorization. reject access to LDAP Table 15 – Identity Management Policy Examples 2.1. the policies are considered in turn for each below. Aspects of authentication include origin authentication. If Password > 90 days old.1.1. Although these three elements should be considered together.2 Authentication Policies Authentication is the act of confirming an identity to be true. This includes the management of userid's along with the grouping of userid’s into roles such as ‘customer support personnel’. For this reason. 2.There are three key aspects to access control: Identity Management.3. within 1 year. Type Description Example Audit and This policy is realized by a regular check If user id not used remove old of User Identities. The user interface that the Security Architect uses to define the authentication information that must be passed in the message will vary depending on the product that is used to deploy the policy but. Identity management can encompass more complex concerns. changed within the required timeframe. send email for change identity revalidation if password is not password change.2. The grouping of userid’s to roles allows the easy application of security policies to a set of users who perform similar functions. User Identity Policies that define who can manage If Role not = Management User Identities User_Administrator.1.2. and confidentiality.

SOAP Message Security defines the basic mechanisms for providing secure messaging and for using security tokens that represent a set of claims. the authorization step establishes whether the user has the right to access the resource to which the message is targeted.1.1. Authorization may take a variety of forms. allow transaction to proceed. found in LDAP.1. WS-Authorization extends this by definition additional primitives and extensions for security token exchange. Another machine readable standard for authorization policies is eXtensible Access Control Markup Language (XACML).3.3 Authorization Policies Authorization is establishing the right of the authenticated identity to access the resource in question. all managers may access a particular document) or based on an individual. Authorization might be role based (for example. When the appropriate authentication has occurred in order to validate that a message is from a user known to the enterprise.Type Description Example Authentication Identifying the origin of a message If username/pw is securely. The Enterprise Architect defines access to resources by means of centrally managed authorization policies and rules.2 Message Protection Policies Page 52 of 94 SOA Policy Reference Architecture .2.2.3. Table 16 – Authentication Policy Examples 2. Type Description Example Authorization Establish the right of the if the Identity of the authenticated identify to message originator matches the access the resource in CustomerId of the data in the question service and the action is read or if the Identity of the message originator is of the role ‘Customer Support Personnel’ Table 17 – Authorization Policy Examples 2.

and PMP.Message protection could be viewed as a special type of access control that applies to ‘in flight’ rather than ‘at rest’ data.1. Message protection policies define requirements on messages to ensure that the data contained within the message remains confidential and maintains its integrity. cannot be forged and can be validated by the recipient. Message protection not only applies to messages containing customer information. Type Description Example Origin Identifying the origin of a message Accept messages only Authentication securely. Message integrity is achieved through associating a digital signature with the message which proves the originator. Infrastructure to ensure confidentiality Table 18 – Message Protection Policy Examples 2. Message confidentiality is ensured by encrypting the message prior to its sending and then performing the appropriate decryption on message receipt. PEP.3. Message integrity is a guarantee to the message receiver that the message is from who it says it is from and that it has not been tampered with during transit. from node ‘ABC7543’ Integrity Detecting that no entity has tampered Use Public Key Authentication with information. In practice this is a concern that should be guaranteed by the integration capabilities provided by the PAP. Infrastructure to authenticate integrity Confidentiality Ensuring that only the intended recipient Use Public Key of information is able to view it. message protection should be applied to policy data when it is in flight.3 Data Integrity Policies Page 53 of 94 SOA Policy Reference Architecture . The same concepts apply in terms of the authentication and authorization of parties accessing messages but the mechanisms for message protection are very different from those of access control. There are a variety of encryption algorithms that may be considered for this purpose.2. There are a variety of algorithms that may be considered for this purpose. In particular. it should also apply to messages containing any potentially sensitive information within the enterprise.

2. Type Description Example Data Validation Necessary data fields and when Validation rules validation is required defining the minimum requirements of service data or metadata in the context of service lifecycle governance.1. Type Description Example Denial of Policies to prevent overwhelming of If unexpectedly high Service provider service due to excessive number traffic from a set of of transactions meant to disable.3.Ensuring the integrity of data (be it management data or resource data) is more than simply restricting access to those who are authorized to update the policies.3.2.2.3.1 Service Level Agreement policy Page 54 of 94 SOA Policy Reference Architecture .2. then throttle from those nodes Table 20 – Denial of Service Prevention Policy Examples 2. Data Decay Rates defining how regularly customer Issue a customer data re-validated to ensure that it does details update form not get out of date. internet nodes.2 Service Mediation Policy Mediation policies enable mediation or reliable transactions between a consumer and a provider service or application and are of many different sub-types.4 Denial of Service Prevention Policies Ensure that runtime services do not become unavailable due to a deliberate denial of service attack via appropriate security policies. 2. each year with an insurance renewal Table 19 – Data Integrity Policy Examples 2.

Type Description Example Filter Identify and take action on any content.XML. SAML token. throttling (rejecting) the transaction. Filter on messages metadata. Validate XML schema well-formedness matches pattern Transform between varying data formats . Binary. Type Description Example Service Level Compare current state to SLA limits and If response time of Agreement’s take action when violated Service X endpoint is > 5 seconds then queue transaction Table 21 –Service Level Agreement Policy Examples 2. Validation Enforce incoming/outgoing XML schema.Operational implementation of SLA policy focuses on conditions where a particular statistic being measured has been violated. from one schema to COBOL copybook another.3 Routing policy This policy enables the consumer service to be routed to the appropriate provider service when certain criteria are met.3. etc Table 22 – Messaging & Enrichment Policy Examples 2. Type Description Example Page 55 of 94 SOA Policy Reference Architecture .2 Messaging & enrichment policy This policy enables the consumer service to be filtered or transformed.2. or re-routing the transaction to another provider that is in better shape to handle the transaction. from node ‘ABC7543’ Message Insert header info. etc.2.3.. Kerberos Insert SAML token Enrichment token. specific action will be taken. such as putting the offending transaction in a queue for later processing. etc. from one transport protocol to another. or network variables. Transform XML into Text. As a result.2. transaction ID.2.

5 Partner & customer gateway Page 56 of 94 SOA Policy Reference Architecture . an MQ queue once and only once delivery Table 24 – Protocol Mediation Policy Examples 2. transaction attributes.2.g. content Leverage a Quickly deploy routing changes. HTTP  MQ  Application Convert HTTP to MQ configuration server  FTP  ESB Request.2. databases. including Use msg_key to routing table for protocol conversions lookup real-time Exec_Routing_Table decisions for routing IP. etc. Type Description Example Simple e. route to gold provider message Analyze legacy or XML content. protocol If msg-type = ‘gold’ context and/or headers. Matching separate transactions to take Match asynchronous response and action request and response sync-async transactions and take matching action Fully Guaranteed delivery Guarantee delivery to guaranteed.) IP from other systems for real time decisions Table 23 – Routing Policy Examples 2..3.2..4 Protocol mediation policy This enables the service to bridge inbound and outbound protocols.2.Transaction Analyze originating URL. etc.g. Retrieve Retrieve routing information from other Use msg_id to lookup routing systems (E. web servers.3. LDAP Table for routing information file servers.

The AS sends a message to the RMS. Type Description Example B2B protocol Enforcing protocol type to and from Validate protocol is enforcement business partner zone HTTPS B2B access Automatic security and filtering actions to Access control from control. and data security Table 25 – Partner & customer gateway Policy Examples 2. To accomplish this they make reliable use of a Reliable Messaging Source (RMS) and a messaging Reliable Messaging Destination (RMD).This gateway enables the service to extend connectivity from organization to customers.2.7 Reliable Messaging / Atomic Transactions There are two more mediation policy sub-types that enable reliable transactions between a consumer and a provider service or application. partners. Type Description Example Reliable An Application Source (AS) wishes to reliably send Transaction messaging messages to an Application Destination (AD) over an is using unreliable infrastructure. and from business partner zone partner zone to message validate security filtering.3.2. and suppliers (aka Trading Partner Management).3.6 Mediation Device Management This device enables the management of the resources of the mediation device.2.2. Type Description Example Cache Manage amount of memory used for Increase cache by 1 Management cache Gigabyte if free memory is < 100 Megabytes Device Manage various device attributes Set device on Management Table 26 – Mediation Device Management Policy Examples 2. The RMS uses the WS- Page 57 of 94 SOA Policy Reference Architecture .

2.1 Service Delivery Page 58 of 94 SOA Policy Reference Architecture .3. guidelines.3 Service Delivery & Support Policy Define standards.3. for example. ReliableMessaging (WS-RM) protocol to transmit the message to the RMD. The RMD delivers the message to the AD. The actions taken by a Transaction transactions transaction participant prior to commit are only is using tentative. typically they are neither persistent nor made Atomic visible outside the transaction. Abort directs the participants to make the tentative actions appear as if they never happened. it must raise an exception or otherwise indicate to the AS that the message was not transmitted. Table 27 – Reliable Messaging / Atomic Transaction Policy Examples 2. the coordinator commits all actions taken.2. If the RMS cannot transmit the message to the RMD for some reason. Atomic transactions have proven to be extremely valuable for many applications. Atomic An all-or-nothing property. it requests the coordinator to determine the outcome for the transaction.3. the coordinator aborts all actions taken. Commit directs the participants to make the tentative actions final so they may. They provide consistent failure and recovery semantics. be made persistent and be made visible outside the transaction. If a participant votes that it needs to abort or a participant does not respond at all. The coordinator determines if there were any processing failures by asking the participants to vote. When an application transactions finishes working on a transaction. 2. rights and responsibilities for IT services management and operations. If the participants all vote that they were able to execute successfully. so the applications no longer need to deal with the mechanics of determining a mutually agreed outcome decision or to figure out how to recover from a large number of possible inconsistent states.

Table 28 – Service Delivery Policy Examples 2. Type Description Example Service Reduce service downtime and time to Provide first level Request. Resiliency and prioritization to ensure services are available when needed. Provides for the managing of provisioning Change support policy Release and of tested software and IT services and Configuration deployment to environment(s) and Management minimize risk when changes are introduced – especially in service dependencies.3.3. Network and Managing supply and demand of IT Add additional server Capacity resources to minimize cost and maximize when utilization Management business performance exceeds 85% Managing network and resource configuration to meet business need Availability Maintaining reliable resources and Clusters must be used Management applications while minimizing for high priority maintenance downtime. Type Description Example Service Level Specify service catalog and service levels HR customers receive management available to customers.2 Service Support This function uses policies to provide consistent and automated responses for service configuration & deployment.2. Page 59 of 94 SOA Policy Reference Architecture . services Risk management. lower priority Ensuring services are delivered when and where they are needed. repair and ensure IT services support the support within 2 hours Problem and business need.This sub-type includes policies to define and enable various service delivery capabilities. for gold customers Incident management Change.

4 Service Monitoring Policy This type of operational policy monitors services and provides instruction to the operations group on actions to take. Table 30 – Service Monitoring Policy Examples 2.3 Service Development Lifecycle Page 60 of 94 SOA Policy Reference Architecture . notify operations of critical problem. greater than 10.2. Type Description Example Monitoring Operational policy to monitor services If average response and provide instruction to the operations time for Service X is group on actions to take. Table 29 – Service Support Policy Examples 2.3.Rollback Backout unforeseen incidents to a stable Rollback policy working position.

Governance teams Page 61 of 94 SOA Policy Reference Architecture . Service Development is the creation of the “resource”. in this case a service that one or more SOA policies may be applied to.3. Ali Arkansan’s summary of SOMA (click on SOMA) with links to various resources including his original paper should be reviewed for additional detail.1 Service Lifecycle & Governance A service registry that is managing the service lifecycle must have the ability to create and affect policy to govern that service lifecycle. the SOA Policy Reference Architecture can become a “Policy Reference Architecture” and the Service Development Lifecycle becomes a “Resource Lifecycle”. Taking that thought to its logical conclusion. Business Policy Policy Business Policy Service Lifecycle Development Management Business Policy domains for behavior and performance Lifecycle Business Policies Policy Lifecycle Service Lifecycle & Governance Policy & Governance Policy Architectural Policy Architectural Policy domains for SOA Resources Model Author Architecture Policies Transform Assemble Deploy Enforce Operational Policy Monitor Manage Operational Policy domains that are non-functional Operational Service Support & Policy Building Blocks Policies Delivery Policy Figure 16 – Service Development Lifecycle with the SOA Policy Reference Architecture The Service Development Lifecycle (SvDLC) is similar to the System Development Lifecycle (SDLC) but is applied to SOA service development instead of applications. Dr. There is a rich suite of material about the Service Development Lifecycle and Service Oriented Modeling and Architecture (SOMA). 2.

a common area of difficulty is the configuration of runtime service policy to the policy enforcement points with deployment in such a manner that the operational work is distributed appropriately. and capacity planning. naming conventions. and security and helps ensure that the runtime infrastructure provides visibility into runtime operations. It allows governance and change to be managed across a broader range of roles. 2. is a series of documents that are used to aid the implementation of a framework for IT Service Management (ITSM). coding practices. design. Coordinating all of this with service support policy can optimize the results. The IT Infrastructure Library. a proxy server must be configured and then policy established as part of a runtime handler stream of actions upon the service. When more than 20% of traffic is being rerouted to a secondary endpoint.2 Service Support & Delivery The purpose of service support & delivery policy is to establish policies for service packaging. Frequently. configuration. Better definition as to whether the scope of the policy is across the business and multiple functional areas or simply in the context of 1 capability 3. instrumentation.should establish policies and procedures that support the architecture.com/ Page 62 of 94 SOA Policy Reference Architecture . a policy could be put in place that measures the percentage of time an SLA (Service Level Agreement) policy that is rerouting traffic to a secondary server is actually doing so. testing practices. For example.2 For example. and detect and address runtime anomalies.itil-itsm-world. ITIL (®). It’s cleaner and more efficient to do this centrally with configuration policy than to try and work across the distributed devices one by one. There are 3 main benefits from separating out the policy lifecycle from the service development lifecycle: 1. service versioning and documentation requirements. can enforce runtime policies. interface patterns. registration. management.3. The policy lifecycle allows some business users to influence policy domains more directly where the Service development domain is mainly managed and governed by IT. Improving the agility of IT solutions to better meet business needs 2. and development teams ability to follow standards for preferred technologies. design patterns. then an alert 2 http://www. They should also establish policies and processes that facilitate service creation and enhancement. This framework defines how Service Management is applied within specific organizations and is the industry standard. Service support & delivery policy also concerns itself with standards and facilities that support service monitoring.

is raised to operations to consider possible action on the server that contains the
primary endpoint.

3.0 Example for applying the SOA Policy Reference
Model
This section gives a detailed example for how to use the SOA Policy Reference
Architecture to analyze and create the set of policies needed for your
organization.

We’re going to describe how to take the business requirements, goals, and
objectives at the business level, and refine the business needs so that we can:

• Transform the business policies into actionable policies and business
rules across the Business, Architectural, and Operational Layers.
• Use the Policy Lifecycle to add improved business agility.
• Identify which Policy domains are applicable and how to use Policy
Patterns.

This work in your organization will be led by various architects as described in
Figure 1 – Roles and their usage in the SOA Policy Reference Architecture.

Various policy sub-domains are associated with each layer as shown below:

Page 63 of 94 SOA Policy Reference
Architecture

Business Policy
Policy Business Policy Service
Lifecycle Development
Management Business Policy domains for behavior and pe rformance Lifecycle
Busin ess Business Business Business
Policies Policies Policies Policies
Po licy Lif ecycle Service Lifecycle
& Govern ance Policy & Governance Policy
Architectural Policy
Architectural Policy domains for SOA Res ources
Model
Author

Process Service Information
Assem ble
Transform

Deplo y
Enfo rce
Operational Policy

Monitor Manage
Operational Policy domains that are non-functional

Security Monitor Mediation Service Support &
Policy Building Blocks
Delivery Policy

Figure 17 – Detailed SOA Policy Reference Architecture

3.1 Policy Layers – How to think about and decompose policy so
that it is useful

Various policy sub-domains are associated with each layer.

Page 64 of 94 SOA Policy Reference
Architecture

A very simple but intuitive method for thinking about policy and then
decomposing the policy into its component parts it to use a Policy Tree as shown
in Figure 18 below.

The policy tree example shows how a business requirement is refined into one or
more business policies at the business layer. The Business Policy should be
considered from a Process, Service, and Information resource point of view.
Lastly the policies can be mapped to support specific technologies at the
operational layer.

This shows a very simple example for a Service Level Management requirement.

Figure 18 – Policy Tree example of SLA Policy Top down analysis

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.

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

Page 65 of 94 SOA Policy Reference
Architecture

What is a high cost transaction? 7.1. 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. Finally. The knowledgeable analyst might start asking questions like these: 1. should be used to meet the business needs.needed in order to ensure a high quality design for the solution and identify which policy pattern. What is an adequate response time? 3. Do some customers have different response time requirements than others? 2. Page 66 of 94 SOA Policy Reference Architecture . How do we measure a good credit risk? 5. The following figure shows how the various business layer entities get decomposed into more detailed tasks. Do risk levels affect what is high cost? The business layer of the SOA Policy Reference Architecture provides a framework to address these questions and decompose what are really business goals into the set of business policy metadata that is required to fully specify policy at the business layer. However. at the operational policy layer. Defining a high level business intent or goal is relatively easy based on conversations with the business users. Do different types of insurance policies have different risk levels? 6. 3. then the more detailed questions start. ‘Sell insurance policies only if the client is a good credit risk’. or ‘The CFO must approve high cost transaction’. What is the solution context in which this policy will apply? 4. Examples might include ‘Response time must meet customer needs’. if needed.1 Mapping Business Requirements to Solution Policies and Policy Domains at the Business Layer The business layer provides a means to transform the requirements defined in the business policy layer into Solution Policies within specific Policy Domains as the first step towards implementing these as operational policies.

Derive Policy The Policy Directive defines the The end to end Directive intent of the Business Goal and customers response therefore gives direction as to how time (from the business goal should be further depressing the enter decomposed. the Policy Domains. Name Description Example Identify Business A Business Goal is a statement of Customer response Goal intent and defines what needs to be time expectations done from a business point of view.Figure 19 . we shall explain all aspects of this in the following table. the less than 3 seconds. However for those readers new to this area or considering larger changes.Business Policy Layer decomposition into more detailed tasks For simple changes to an existing environment using policy. should be met. key to response It is further refined in the Solution received) should be Context. only a subset of these entities may need to be used. Solution Policies and the Page 67 of 94 SOA Policy Reference Architecture .

Page 68 of 94 SOA Policy Reference Architecture . to its service consumer in less than 3 seconds. Select the Each Domain identifies a common Service Level Policy vocabulary that should be used for Management Policy Domain(s) consistent policy definition. Decompose to The Policy Directive should be All Banking ATM Solution further refined as we receive more Services must Policies detailed knowledge of the context provide a response we are dealing with. Business process policies which affect the behavior of the process at specific activity steps. 3. Situational awareness policies such as detection of patterns of events over a specific time period. Domain is used. Industry specific policies which could implement industry standards or compliance regulations. Apply the The Policy Directive will need to be Marketing will have Governance governed so that agile change can authority to create. Its scope may be localized within a small business capability or broadly deployed across the entire business. The business policy sub domains to consider are: 1. services and provide a critical operations warning if this time is exceeded. 4.Name Description Example Governance Policies stages Quantify The Business Objectives defines KPI 1: Measure the Business what should be measured in detail maximum response Objectives to track achievement of the goal in time of the customer the form of KPI’s. 2. Service Level Management policies. Scope the The solution context defines Phase 1 – Banking Solution where the business directive will ATM Services only Context apply in the business.

In our example on Figure it is easy to map the Business Goal to the Policy Tree policy of: “Customer response time expectations should be met”. • One or more detailed Business Objectives defining what should be measured in detail to track achievement of the goal in form of KPI’s.Align Policy Tree example with Business Layer tasks. 3. Figure 20 . update or delete any This relates to where the SOA business policies Policy Lifecycle may be classified as implemented. Table 31 – Decomposition of policy from business goals The following sections will take you through a step by step approach. business goals can be refined into: • One or more Policy Directives defining intent of goal. Name Description Example Policies be accommodated in future.1. Page 69 of 94 SOA Policy Reference Architecture .1.1 Business Goals and Policy Directives Using guidance from Industry bodies which define Business Policy like the Business Motivation Model (BMM) from OMG. starting at a simple level using a Policy tree to identify what tasks at the business level are required in all cases in an example depicted below. “marketing”.

this is a new business policy influencing a new or existing business area.1. 3.It is worth noting that the statement is quite vague. Figure 21 – Business Layer Policies also require a Content and Domain If there is a change to an existing policy in an existing policy domain these steps may not be required. it still has no context on where it would be enforced. If there is a broad context for the Policy Directive.1. It is also easy to map the more detailed and specific “intent” as a Policy Directive: “The end to end customer Service response time should be less than 3 seconds “ It is more specific but. which may also help with some interim business objectives 3.1. considering solution context and Policy domains.1.3 Solution context & Scope of the Policy Directive In our example let’s assume the project has 3 phases: Page 70 of 94 SOA Policy Reference Architecture . it may be useful to implement this in stages. but this is not uncommon as a starting point in clarifying what the business priorities are.2 Solution Context and Policy Domains The next logical steps are to determine whether.

4 Policy Domain of the Policy Directive In our example since the policy directive is about service performance levels the natural fit is Service Level Management policies. Business Automation & Process Policy. Business Objectives Once the context is well defined the next logical steps are to decompose the Policy Directive into Solution Policies and to identify how to measure the Policy Directive in the Business Objectives.1. Phase 1 – Banking ATM Services only Phase 2 – Add Banking Loan Services Phase 3 – All Banking Services To assess which of the Policy business sub-domain aligns with the Policy Directive we need to review and think about the four sub-domains of Situational Policy Awareness. and can be seen in Figure on page 69. • Enterprise Operation policies defining how the internal business needs to be run to be efficient and successful.5 Policy Refinement.1. There normally are two categories for such SLM policies: • Customer satisfaction policies defining what client expectations to succeed in the marketplace are. Page 71 of 94 SOA Policy Reference Architecture .1. As our example identifies “customers”.1. 3. it is a straightforward mapping to a Customer Satisfaction SLM Policy domain. and Service Level Management Policy as defined in Error! Reference source not found. Business Situation Policy. 3.

1.1. 3. but measuring the effectiveness of the policies is also important and often forgotten. we can decompose the policies into: • All Banking ATM Services must provide a response to its service consumer in less than 3 seconds.e. In our example we need to measure service latency within the Service Level Management domain for all service requests by customers. Without these metrics.1.Figure 22 – Full Policy Business Layer Model 3. It also limits the ability to apply ongoing changes to fine tune a solution for improved performance. ATM Services and Loan Services).1.6 Solution Policy Refinement Taking the Policy Directive and the Solution Context which were more specific in the areas the policies had to apply to (i. The Business Objective for the solution is: Page 72 of 94 SOA Policy Reference Architecture .7 Business Objectives and KPI’s define how we measure the Business Directive performance Decomposing the policies from business goals and objectives is an important milestone. • All Banking Loan Services must provide a response to its service consumer in less than 3 seconds. it is impossible to provide to the business stakeholders information on how effective any policy solution is.

8 Business Policy Governance Policy Governance defines how Policy directives will be governed or changed in the future. 3.1. but less than 0. At the SOA Policy Lifecycle Governance level we need to ensure that: • A Marketing role has authority to change any policies within this solution scope at a later date.1. • Set Amber condition if at least one service exceeds. In our example when the business goal is assessed on what the frequency of change might be and by which roles in the organization we find: • Marketing will manage and optimize this policy on a monthly basis.1. • Monitor all ATM services to ensure they provide < 3 second latency.05% of all banking ATM services exceed 3 sec latency in 24 hour period.05% of all banking ATM services exceed 3 second latency in 24 hour period AND send Alert Message to Operations to Fix Immediately.1. • Measure average latency of all ATM services. Amber and Green status for ATM Services: • Set Green condition if no Banking ATM services exceeds 3 second latency in 24 hour period.9 Completed example at the Business Layer Bringing the whole example together at the business level provides us with the following summary in Figure 23: Page 73 of 94 SOA Policy Reference Architecture . • Provide a warning to business users if 3 second latency is exceeded. It provides policies for the SOA Policy Lifecycle governance as well as SOA Development Lifecycle Governance. • Set Red condition if more than 0. In addition there is the possibility of refining KPI’s further into Red. 3.

• Policy Domains – Service Level Management selected in our example with Customer focus.1. In simple cases. • Solution KPI’s – Decomposed from the Policy Directive and Business Objectives and influenced by the Solution Context. Page 74 of 94 SOA Policy Reference Architecture .Figure 23 – Completed example using the Business Layer Model The main outputs from the business layer decomposition. only the Solution Policies may need to be changed. which will be used at the Architecture layer. are: • Solution Policies – Decomposed from the Policy Directive and influenced by the Solution context. 3.2 Using the Architectural Layer to leverage SOA Policy Lifecycle and Map business policies to Architectural Policies The architectural policy layer provides a means to transform the requirements defined in the business policy layer into operational policies as shown in Figure 24 below. where some changes are being made to an existing policy which is already active in an existing Policy domain and the KPI’s don’t need to change.

PEP’s. enforce. PMP’s. In order to consistently perform this transformation Architects leverage the key aspects of the SOA Policy Reference architecture: • The Service Development Lifecycle – which defines the processes used by the organization to develop and manage their SOA Business solutions. Page 75 of 94 SOA Policy Reference Architecture . This describes how all the applications are built and integrated. are integrated together with the solutions to realize. etc. starting from the output of the Business Layer. • The SOA Policy lifecycle management activities and tools are used by the architects to manage and change the policies used to configure the patterns and thus deliver the business agility into the solutions. and monitor policies as part of the solutions. A summary of the Architectural elaboration of the Policy tree example is shown in Figure 25 below. Business Policy Policy Business Policy Service Lifecycle Development Management Business Policy domains for behavior and performance Lifecycle Business Business Business Business Policies Policies Policies Policies Policy Lifecycle Service Lifecycle & Governance Policy & Governance Policy Architectural Policy Architectural Policy domains for SOA Resources Model Author Process Service Information Transform Assemble Deploy Enforce Operational Policy Monitor Manage Operational Policy domains that are non-functional Security Monitor Mediation Service Support & Policy Building Blocks Delivery Policy Figure 24 – Architecture Layer considers both Policy and Service Development Starting from the Policy Tree example we will illustrate how the architectural Policy layer is used to perform this transformation. These patterns are reusable and describe how the PAP’s. • The Architectural Policy Patterns which describe common patterns for implementing certain types (domains) of policy enforcements.

service Selection of existing patterns latencies and Page 76 of 94 SOA Policy Reference Architecture . These are shown in the table below and described in more detail in subsequent sections. can be used Pattern that will to enforce the usage of a particular monitor implementation pattern. services must This involves identifying the resources respond within 1 affected (service.Figure 25 – Overview of Architectural layer policy elaboration There are three main concepts in the Architectural layer that need to be considered. or second. SOA resources for the solution in All information context. provided by the Use an SLA Selection existing SOA infrastructure. process) Domain Pattern Domain patterns. Name Description Example Solution Policy This activity defines how the architecture All banking Decomposition layer is used to decompose the solution services must policies provided by the business layer respond within 2 into policies that can be applied to the seconds. information.

routing and quality of service within the solution. Page 77 of 94 SOA Policy Reference Architecture . • Process Governance policies to ensure compliance and audit.2. Examples include: • Information Security policies to protect information. Architectural Service Policies provide configurable control of services to provide effective usage. Architectural Information Policies provide configurable control of information used within the solution. realize the service level required. Examples include: • Decision Service policies to use rules to configure the way decisions are made. and monitoring This delivers the end to end policy policies. 3. Examples include: • Process Flow Decisions to determine activity flows and exceptions. In order to consider this. • Information Quality policies to ensure confidence in information.1 Decomposing the Solution Policies The first step in the refinement of the solution policies is for the architects to identify the SOA solution resources to which the policies will apply. they use the SOA Policy Reference Architecture layer to identify the types of resources that are relevant. Table 32 – Architecture Layer Decomposition The remaining sections elaborate the SLA policy tree example through the Architectural layer. • Service Security and Integrity policies to protect resources. as summarized below: Architecture Process Policies provide configurable control of the manner in which processes operate. For example pricing or eligibility. by allowing these existing the appropriate components to be reused rather than service to having to develop a new solution. • Quality of Service Routing policies to ensure efficient delivery. Operational These are the result of transforming the Specific service Policy Sets solution policies into policy sets that can policy sets be executed using the operational include routing implementation of the domain pattern.1. Name Description Example accelerates time to value and route to development. management lifecycle using the deployed capabilities and products used to manage these policies.

Figure 26 – Policy Tree Example after decomposing the customer service policy. This gives IT some leeway to meet the business goals easily. This results in the policy tree example shown in Figure 26 below. We have two different services that may contribute to the overall Banking ATM customer response: • An information service that accesses and validates a customer’s card and account details from their bank to authorize cash withdrawals.In our example. we allow 2 seconds overall latency for the banking services. and 1 second for the information service. 3.2 Identifying the Policy Domain Patterns The next step in the architectural refinement of the policies is to identify the architectural patterns that will be relevant for the policy domains and resources Page 78 of 94 SOA Policy Reference Architecture . We will also need to divide up the overall service level budget between these two types of service and thus associate individual SLA policies with each service.2. Taking the SLM Solution Policy and refining it.1. • A banking service which identifies how the ATM can interact with the local bank systems to handle cash withdrawals and uses the above information service. the solution policies focus on Quality of service routing and we need to identify the particular services that will contribute to the overall business goals and KPI’s.

These patterns represent capabilities that are already deployed in the infrastructure and allow policies to be quickly applied to the solution resources using SOA principles. Figure 27 – Use of Policy Points to implement Domain Patterns In our example there is an existing pattern for implementing Service Level Agreements as shown in Figure 28 below. Page 79 of 94 SOA Policy Reference Architecture .that are needed. If this pattern did not exist there would need to be a new development initiative started to develop a new pattern that would support the type of policy required. These are illustrated in Figure 27 below.

In terms of our policy tree we can now complete the next stage of our elaboration as shown in Figure 29. Page 80 of 94 SOA Policy Reference Architecture . Pattern: SLA Management Author Monitor Service Policy Repository Service SLA Performance Policies Enforce Consumer Provider ESB Figure 28 – Selected Pattern to implement SLA Policies This pattern provides the following essential capabilities that we will need for the SLA policies and the associated KPI metrics: • An ESB that can assess service quality and select service endpoints that can deliver the required service level. • Each service can be monitored to obtain individual metrics. • The metrics can be aggregated to produce the dashboards used to indicate how well the customer service level policies are working. • The metrics can be used to categorize the services in terms of their latency and thus their appropriateness.

Page 81 of 94 SOA Policy Reference Architecture . This step needs to consider the Operational Layer implementations of the PEPs. This also needs to include how the KPI’s can be obtained and displayed as shown in Figure 30 below.2.3 Mapping the decomposed solution policies to the pattern The final step is to define the set of policies that will actually be needed to use the SLA pattern for each of the services. 3. PDP’s.Figure 29 – Policy Tree example after selecting domain pattern. and PAP’s that support the domain pattern.1. In this case we need to consider how the Policy Authoring can transform the solution policies into a set of policies that can be executed using the domain pattern in the Operational Layer.

Page 82 of 94 SOA Policy Reference Architecture . • A recording of the latency of each interaction to maintain statistics on whether the SLA response was met. This latency can also be used to characterize each service allowing the ESB to interpret the service level requests in the context of current service performance. Thus. we need to build a policy set containing these distinct policies. for each type of service we invoke as part of the overall interaction. Each of these configurations will be different according to the consumer invoking the service (each consumer may need a different SLA) and therefore we will require both routing policies and monitoring policies to be combined into a single policy set. In our example we require two types of operational policy: • A configuration and mapping that can route requests to an endpoint that has capacity. This policy set is the main output of the transformation stage of the policy lifecycle shown in Figure 31. This will map into a routing policy for each service.Figure 30 – Transforming the Solution Policies & KPI’s to policy sets.

Page 83 of 94 SOA Policy Reference Architecture . 3.1. 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.Architects select specific products to implement the Pattern within the Solution Context Where an operational solution implementing the pattern using policy is already deployed this stage is not required. PEP.2. However when transforming a business or extending a policy domain to a different part of the business.4 Optional . the next logical step is for the SOA architects to select the specific products required for the PAP. and PMP and finalize how these interact together if this has not yet been done.Figure 31 – Policy Tree example after mapping the solution policies to the domain pattern.

(Authentication.1.3 Operational Layer The operational policy layer provides a means to enforce and monitor the policies as part of the operational deployed solutions shown in Figure 32 below. and Page 84 of 94 SOA Policy Reference Architecture . The SOA Policy Reference Architecture identifies four key non-functional policy areas implemented in the operational layer. Name Description Example Security • Access Control Policies for access to AAA Policy runtime resources. These operational policy areas provide the non-functional building blocks used for the architectural patterns described in the last section.3. Business Policy Policy Business Policy Service Lifecycle Development Management Business Policy domains for behavior and performance Lifecycle Business Business Business Business Policies Policies Policies Policies Policy Lifecycle Service Lifecycle & Governance Policy & Governance Policy Architectural Policy Architectural Policy domains for SOA Resources Model Author Process Service Information Transform Assemble Deploy Enforce Operational Policy Monitor Manage Operational Policy domains that are non-functional Security Monitor Mediation Service Support & Policy Building Blocks Delivery Policy Figure 32 – Operational Policy Layer 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. • Message Protection Policies for Authorization.

Service • Monitoring policies monitor services Logging policies Monitoring and provide instruction to operations attached to each Policy group on actions to take. • Messaging and enrichment policy for This will be consistently filtering or transforming selected messages. service • Partner and customer gateways to implementation will extend connectivity outside of the be selected based DMZ. • Reliable Messaging Interactions to ensure messages are not lost and transactionality is maintained. information needs to be recorded in order to calculate the KPI’s and monitor adherence to the required Service Level Agreement. configure device attributes such as memory. on historic latency • Mediation Device Management to measurements. or XACML policy • Integrity Policies to ensure that data configuration is not invalid or does not become selected for each invalid. Service • Service Level Agreement policies for Routing policy Mediation throttling. implemented as • Data Protection Policies to protect WS-SecurityPolicy data at rest.Name Description Example protection of data contained in Accounting) policy messages at runtime. services do not become unavailable. • Protocol mediation policies to bridge Endpoints for the inbound and outbound protocols. each interaction. interaction • KPI monitoring and reporting into determine what service dashboards. dynamically based • Routing policy to route requests to an on the customer appropriate service based on service level in the message or status criteria. rerouting or reporting SLA configuration for Policy violations. record. Page 85 of 94 SOA Policy Reference Architecture . service interaction • Protection against Denial of Service involving customer Attacks to ensure that runtime account data.

Name Description Example
Service • Service delivery policies ensure Repeated Service
Support and availability and capacity of IT or level exceptions
Delivery service resources. should trigger
policy • Service Support policies provide provisioning of
management of provisioning, fault additional service
resolution and downtime capacity.
minimization.

Table 33 – Operational Policy Types

Operations managers leverage three key aspects of the SOA Policy Reference
Architecture shown in32:

• The Service Development Lifecycle – which defines the processes being
used by the organization to develop and manage their SOA Business
solutions. This describes how all the applications use the deployed
operational PDP’s and PEPs and thus define the deployment destination
of the policy sets to configure any particular type of interaction to realize
the policies required.

• The Architectural Policy Patterns describe the common patterns for
implementing certain types (domains) of policy enforcements. These
reusable patterns describe how the PAP’s can specify multiple different
policies (and their associated policy sets) and merge them to be enforced
by the PEPs and PMP’s.

• The SOA Policy Lifecycle management activities and tools are used by the
architects to manage and change the policies that are used to configure
the patterns and transform them into the policies and policy sets. At the
operational level the policy sets from different policies are combined at the
PEP or PDP, tested and activated in the production systems thus
delivering the business agility into the solutions.

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.

Page 86 of 94 SOA Policy Reference
Architecture

Figure 33 – Overview of Operational layer policy elaboration

Name Description Example
Collate policy The policy sets resulting from a SLA policies for
sets across particular policy directive need to be Banking service
policies for any merged with other policies that are interactions will
given interaction. already deployed to any particular need to be merged
service interactions. with existing
security policies
that protect the
customer account
data.
Map policy sets The PDP’s and PEPs used to The SLA mediation
to PDP/PEP interpret and enforce the policies will uses provider
configuration often use the policy set in association policy latency
with other dynamic information to statistics to
perform the enforcement. Introduction determine
of new terms in the policies may available
require that the configuration of the endpoints that can
PEPs, mediations, or their associated deliver the
registries be changed to support the required SLA.
updated policies.
Map monitoring The policy sets from the architectural Raise alert if the
policy sets to KPI layer will define what needs to be latency is > SLM

Page 87 of 94 SOA Policy Reference
Architecture

Name Description Example
dashboards and recorded from each interaction. Policy
alerts However the means of displaying the or a service
policy KPI’s in dashboards and utilization is >
reacting to important exception 90%.
criteria and alerts will still need to be
configured.
Table 34 – Operational Policy Decomposition

The Operational Layer provides the implementation of the various PAP’s, PDP’s
and PEPs and will usually provide the capabilities to automatically realize the
tasks described above. The remaining sections elaborate the SLA policy tree
example through the Operational layer showing the tasks that these operational
products will need to perform.

3.1.3.1 Collate policy sets across policies for any given interaction

In the Policy Tree example the main functional policy at the operational layer
relates to realizing the service level agreement on any particular interaction. The
first task is to make sure that other policies associated with the interaction are
retained. In this case the customer's account details must be protected so all
interactions with the banking service and information service will need to use
encryption. This means that the policy set provided from the architectural layer
needs to be combined with any existing policy sets associated with invocations of
these services. The combined policy set now includes operational policies in an
enforceable form (e.g. WS-Policy) for Routing, Monitoring, and the existing
security policies.

This policy set combines the service level request policy with other interaction
policies such as message protection policies to ensure that the account
information is protected by encryption.

3.1.3.2 Map policy sets to PDP / PEP configuration

While some policies (e.g. WS-Security) may be fully defined within the policy set
itself, others may use dynamic information or registry lookups for enforcement.
This means that the mediation interprets the policy in the context of the
interaction and the status of the available services. In order to meet the service
level agreement we need to make the mediation enforce the following policy:

“Select banking service where latency is less than 2 seconds"

Page 88 of 94 SOA Policy Reference
Architecture

In our example the requirement is defined by the consumer service rather than the customer which means that the mediation can retrieve the requested latency from the policy set associated with the interaction. Based on this registry information the mediation can then perform a lookup and select an endpoint that meets the requested latency. 3.So the policy will define the latency required (2 seconds). The first relates to configuring the KPI’s in a dashboard so that the Business Users (and Operations Managers) can see how well the SLA’s are being adhered to. In order to provide visibility. It is the Operational Managers task to make sure those new displays for these new KPI’s are added to the dashboards so the policies can be monitored and their impact on the business assessed. As part of the policy set associated with the interaction.3 Map monitoring policy sets to KPI dashboards and alerts The final activity in the operational layer is to configure monitoring such that the goals of the policy directives are measurable and visible. In this case. certain characteristics of the interaction will be recorded.3. The PMP is the monitoring capability in a policy domain which monitors service performance at runtime. In our example we can also consider the following conditions to be of interest: “Raise alert if latency is > SLM Policy" or "Raise alert if service utilization is > 90%”. information from the interaction would have to be used to determine if this was a gold or silver customer. or take action from this monitoring. the operational layer has to consider two aspects. Mediation designs may well cache these lookups.1. This might be dynamic based on the customer. while silver customers might have a 5 second response time. These will be managed and monitored separately and the dynamic information maintained in a registry. The service endpoints available will be dynamic and vary according to system load. In our example this could include identifying alerts to the management dashboard if a significant number of Page 89 of 94 SOA Policy Reference Architecture . Part of the design process for a domain should be to define the dashboards and means of checking the KPI’s. Monitoring Policy sets will configure the information to be recorded by the PMP. gold customers have a 2 second response time. The second aspect relates to identifying situations where an action needs to be taken as a result of what is being monitored. For example. The second part is then to route a particular service request to a particular service endpoint that can meet this latency requirement. so that requests can be routed straight to a suitable endpoint based purely on the policy.

interactions were not meeting their SLA’s. Page 90 of 94 SOA Policy Reference Architecture . These alerts could also trigger provisioning of additional resources / services to meet the need. This form of operational systems management is becoming commonplace in dynamic infrastructures and cloud. The operational policy layer is the main point at which the application policies can be easily related.

but adds user friendly policy widget for policy enforcement syntax Page 91 of 94 SOA Policy Reference Architecture . through architectural patterns being used to realize certain policy domains through to the operational deployed enforcement points that realize and monitor those original goals.4. 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.1. insight and understanding needed of the SOA policy lifecycle such that they can competently deliver the benefits of policy usage in their organization.0 Mapping of SOA Policy Architectural Elements to IBM Product SOA Policy IBM Software Release Comments Architectural Element PAP WSRR v7. The IBM SOA Policy lifecycle describes how to systematically author.3 or v7. 5. It describes how this policy lifecycle interacts with the SOA Development lifecycles being used to develop the solution services. deploy. It is hoped that this paper has provided the reader the structure.0 Conclusion 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. processes and applications. A worked example has been provided that illustrates how the layers of the SOA Policy reference architecture help decompose policies from the business goals and intents.0.2 Supports WDP v5 and WMB v8 for policy enforcement and Tivoli ITCAM for SOA v7.5.1. Finally it describes how SOA policy aligns with and supports the overall Governance processes being adopted by the organization. enforce and monitor policies as part of a solution.2 for policy monitoring WSRR v8 Same as above.

Conflict resolution is the ability to suggest changes to one or more of the policies to eliminate such conflict.0 References and Appendix 6. management and governance of the policy and its assignment to resources.3 Policy only in PAP Tivoli ITCAM for SOA Supports Monitoring v7. Object Management Group.2 Term Definitions Term Definition Conflict Analysis & Conflict analysis for policy is the ability to identify Resolution when two policies have a subset of those policies that are in conflict with each other and cannot both be enforced.omg.pdf “Business Motivation Model (BMM)” – Object Management Group.org/oceb/BMM_Overview-Core_Concepts_%5B081208%5D. May 2010.omg. http://www. http://www. 8 December 2008.1 References “Overview of OMG Business Motivation Model: Core Concepts”.1.PEP WDP v5 Full support for WS- Mediation-Policy WMB v8 Partial support for WS- Mediation-Policy PMP Tivoli ITCAM for SOA Supports Situational v7.1.org/spec/BMM/1.2 Policy in PAP and adds the Service Endpoint table 6.1/ 6. and administration of policy results during runtime. . Page 92 of 94 SOA Policy Reference Architecture . Policy Administration Provides policy capabilities that allow authoring of Point (PAP) policy.

Policy Enforcement Provides the capability to receive policy from the PAP Point (PEP) and apply the policy to a resource transaction and enforce the policy decision. Policy Impact Analysis Identifies the potential impacts to changing a policy. taking action.e. Policy Information Provides external information to a Policy Decision Point (PIP) Point.e. a management view of what’s going on in the distributed policy environment.e. Policy Association A resource (such as a service or an operation of the service) can be associated (i. A policy association indicates that the policy should be applied to the resource at runtime. or the results from a database with information that must be evaluated to make a policy decision. which enforcement or monitoring point handles which policies and resources). and give the policy management function the opportunity to assess and take action. provider service.e. or both). eligibility or validation decision or provide calculated results. at the service level. Policy Pub/Sub Provides the ability to bind policy enforcement points to operational assets (i. Policy Decision Point Evaluates participant requests against relevant (PDP) policies/contracts and attributes to render an authorization. attached) to one or more policies or policy sets.. for a consumer service. and where vulnerabilities may exist that need to be addressed.Term Definition Policy Analytics Responsible for providing information on how often policies are being accessed. how often those policies are “triggering”. such as LDAP attribute information. and management consoles and data made available for review and action. Analytics provides an overall view. operation level. Page 93 of 94 SOA Policy Reference Architecture . reports. This includes being able to identify which resources are applied to a specific policy and in what manner (i. i. Policy Audit Provides for the centralized logging of runtime activities for policies. Policy Monitoring Provides a summary of operational results for policy Point (PMP) enforcement and policy monitoring of transactions with appropriate queries.

Term Definition Policy Resource Provides the ability to identify the current status of a Analysis resource with respect to policies. and operational. This means being able to query what resources the policy is applied to and where the resource/policy pair is being enforced. delete) and any subsequent action to them including action during the policy lifecycle such as retirement. Management and monitoring of the policies. Policy Resource Ability to define resources in such a manner as to Definition allow policy association with those resources. read. Policy Traceability Ability to keep track of the authoring of policies (create. enforcement. update. SOA Policy Lifecycle Manages the authoring. architectural. Policy Runtime Usage Validates that published policies are in fact being used as contemplated. SOA Policy Layers A vertical dimension for policy classification that provides a level of abstraction for policies including business. This enables management of policy accountability. transformation. Page 94 of 94 SOA Policy Reference Architecture . The function provides the ability to understand the specific policies which are already associated to the resource.