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.

Note

This section focuses on the design of policies for use with Web services. It is worth noting that polices can be attached to additional types of Web resources.

In Plain English

The first thing drivers see when they pull up to our operation is a sign that explains a few things about the car wash.

The sign lists three specific points:

• After driving to the car washing area, turn the engine off and exit the car.
• Our power washing equipment can be very loud. Beware.
• We recommend that you wait inside the gas station until the car wash has completed.

The first point is a rule that customers must follow before the car washing process can begin. The second is an informational statement explaining a behavioral characteristic of the car wash. The final point indicates a preference of ours (it is safer for customers and easier for us if they stay out of the way of the workers). Each of these items expresses part of an overall policy.

 

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

Figure 7.20. The basic structure of a policy description.

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).

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.

Note

The WS-Policy language basics section in Chapter 17 provides examples of how policies are developed using the set of languages provided by WS-Policy specifications.

 

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).

Figure 7.21. Policies relating to other parts of SOA.

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.

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.

Case Study

TLS recently upgraded some of its middleware, which now provides support for the most recent version of the WS-ReliableMessaging specification. TLS wants to utilize this support but realizes that its partners still may need to continue using the previous version of WS-ReliableMessaging for some time. As a result, it chooses to support both versions by issuing a policy document containing a policy alternative.

This policy alternative states that its Vendor Profile Service will accept invoice submission sequence headers that conform to both versions of WS-ReliableMessaging, but it also expresses the fact that the newer version is preferred by TLS.

Later, TLS expands these policy assertions to include a requirement for a specific message encoding type. Regardless of which alternative is chosen by a service requestor, the same text encoding format is required.

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.