This chapter is from the book
This chapter is from the book
This chapter is from the book
7.4 Policies
We now take a bit of a leap from the advanced messaging part of this chapter over to the WS-* extensions that provide enhanced metadata features for Web services.
Every automated business task is subject to rules and constraints. These characteristics trickle down to govern the behavior of the underlying services that automate the task.
The source of these restrictions could be:
actual business-level requirements
the nature of the data being exchanged
organizational security measures
Further, every service and message has unique characteristics that may be of interest to other services that cross its path.
Examples include:
behavioral characteristics
preferences
technical limitations
quality of service (QoS) characteristics
Services can be outfitted with publicly accessible metadata that describes properties such as the ones listed here. This information is housed in a policy (Figure 7.19).
)
Figure 7.19 Policies can express a variety of service properties, including rules.
The use of policies allows a service to express various characteristics and preferences and keeps it from having to implement and enforce rules and constraints in a custom manner. It adds an important layer of abstraction that allows service properties to be independently managed.
7.4.1 The WS-Policy Framework
The WS-Policy framework establishes extensions that govern the assembly and structure of policy description documents (Figure 7.20), as well as the association of policies to Web resources. This framework is comprised of the following three specifications:
WS-Policy
WS-PolicyAttachments
WS-PolicyAssertions
Note also that the WS-Policy framework forms part of the WS-Security framework. Specifically, the WS-SecurityPolicy specification defines a set of policy assertions intended for use with WS-Security (introduced later in this chapter).
)
Figure 7.20 The basic structure of a policy description.
Policies can be programmatically accessed to provide service requestors with an understanding of the requirements and restrictions of service providers at runtime. Alternatively, policies can be studied by humans at design time to develop service requestors designed to interact with specific service providers.
Recent revisions to the WS-Policy framework have extended the structure of a policy description and its associated terminology. The sections below provide a brief overview.
7.4.2 Policy Assertions and Policy Alternatives
The service properties expressed by a policy description are represented individually by policy assertions. A policy description therefore is comprised of one or more policy assertions. Examples of policy assertions include service characteristics, preferences, capabilities, requirements, and rules. Each assertion can be marked as optional or required.
Policy assertions can be grouped into policy alternatives. Each policy alternative represents one acceptable (or allowable) combination of policy assertions. This gives a service provider the ability to offer service requestors a choice of policies. (Each of the bullet points in our last In Plain English analogy, for example, would warrant a policy assertion.)
7.4.3 Policy Assertion Types and Policy Vocabularies
Policy assertions can be further categorized through policy assertion types. Policy assertion types associate policy assertions with specific XSD schemas. In the same manner as XML vocabularies are defined in XSD schemas, policy vocabularies simply represent the collection of policy types within a given policy. Similarly, a policy alternative vocabulary refers to the policy types contained within a specific policy alternative.
7.4.4 Policy Subjects and Policy Scopes
A policy can be associated with a Web service, a message, or another resource. Whatever a policy is intended for is called a policy subject. Because a single policy can have more than one subject, the collection of a policy’s subjects is referred to as the policy scope.
7.4.5 Policy Expressions and Policy Attachments
Policy assertions that are physically implemented using the WS-Policy language are referred to as policy expressions. In other words, a policy expression is simply the XML statement used to express a policy assertion in a manner so that it can be programmatically processed. Policy expressions are physically bound to policy scopes using policy attachments.
7.4.6 What You Really Need to Know
If your head is spinning at this point, don’t worry. Of the many concepts we just introduced, you only need to retain the following key terms to maintain a conceptual understanding of polices:
policy
policy alternative
policy assertion
policy attachment
Let’s now finish this section with a look at how policies are used by other WS-* extensions and SOA as a whole.
7.4.7 Policies in Coordination
When the WS-Coordination context coordination service generates context information for participating services, it can make the distribution of context data subject to the validation of security credentials and other forms of policy information. To enforce these requirements, WS-Coordination can incorporate rules established in policies.
7.4.8 Policies in Orchestration and Choreography
Policies can be applied to just about any subjects that are part of orchestrations or choreographies. For example, a policy can establish various requirements for orchestration partner services and choreography participants to interact.
7.4.9 Policies in Reliable Messaging
The WS-ReliableMessaging specification depends on the use of the WS-Policy framework to enable some of its most fundamental features. Policies are used to implement delivery assurances through the attachment of policy assurances to the messages that take part in reliable messaging exchanges. A further set of policy assertions is provided to add various supplemental rules, constraints and reliability requirements.
7.4.10 Policies and SOA
If an SOA is a city, then policies are certainly the laws, regulations, and guidelines that exist to maintain order among inhabitants. Policies are a necessary requirement to building enterprise-level service-oriented environments, as they provide a means of communicating constraints, rules, and guidelines for just about any facet of service interaction. As a result, they improve the overall quality of the loosely coupled arrangement services are required to maintain (Figure 7.21).
Policies allow services to express so much more about themselves beyond the fundamental data format and message exchange requirements established by WSDL definitions. And policies enable services to broaden the range of available metadata while still allowing them to retain their respective independence.
The use of policies increases SOA’s quality of service level by restricting valid message transmissions to those that conform to policy rules and requirements. A side benefit of inserting endpoint level constraints is that the application logic underlying services is not required to perform as much custom exception handling to deal with invalid message submissions.
)
Figure 7.21 Policies relating to other parts of SOA.
Polices naturally improve the ability for services to achieve better levels of interoperation because so much more information about service endpoints can be expressed and published. Finally, because they increase the richness of service contracts, they open the door to dynamic discovery and binding.
SUMMARY OF KEY POINTS
The WS-Policy framework provides a means of attaching properties (such as rules, behaviors, requirements, and preferences) to Web resources, most notably Web services.
Individual properties are represented by policy assertions, which can be marked as optional or required. This allows a service to communicate non-negotiable and preferred policies.
WS-Policy can be incorporated within the majority of WS-* extensions.
Polices add an important layer of metadata to SOAs that increases the interoperability and discovery potential for services, while also elevating the overall quality of messaging within SOA.