Browse Prior Art Database

Collapsing Policy Alternatives

IP.com Disclosure Number: IPCOM000124545D
Original Publication Date: 2005-Apr-26
Included in the Prior Art Database: 2005-Apr-26
Document File: 3 page(s) / 46K

Publishing Venue

IBM

Abstract

This article seeks to describe the issues associated with Policy Intersection and Merge, as stated in the current Web Services specifications. More particularly, it describes an effective method for overcoming these issues so that a workable implementation of a Policy aware invocation framework can be created.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 31% of the total text.

Page 1 of 3

Collapsing Policy Alternatives

A couple of the many specifications in the burgeoning arena of Web Services deal with the expression of capabilities and requirements of Web Services, termed WS-Policy; the specifications being "WS-Policy Framework" and "WS-Policy Attachments". The specifications not only define the form of WS-Policy and its association with a particular Web Service, but they also define how WS-Policy is processed and netted down into a single instruction set which will be applicable at an invocation site. More specifically, a Policy may contain choices called Policy Alternatives, where a Policy Alternative may contain zero or more Policy Assertions. A Policy Assertion is considered to be a single piece of, what is termed here as, Policy Domain specific information which may be processed in a particular Web Services invocation. For example, in the WS-SecurityPolicy Domain, an Assertion could be an instruction to encrypt a request message along with the details as to how to perform the particular encryption. In order for a Web Services requestor to successfully invoke a Web Services provider there has to be some commonly agreed behavior as far as Policy is concerned. This requires a mutually compatible Policy to be determined which both requester and provider can support; the operation performed to achieve this is termed Policy Intersection. The result of this processing is a potentially reduced set of Alternatives that both sides agree on, where each Alternative in this new Intersected Policy contains a set of Assertions that are essentially the instructions to the infrastructure to perform various tasks. The Policy Domain specific instructions can then be passed to infrastructure components to act upon; here termed Policy Domain Handlers. In addition to Policy Intersection the specifications refer to a Policy Merge operation. Merging is used by a single end of an interaction to construct the complete set of Alternatives that comprise a single Policy, based on information gathered from potentially many sources. The form and function of Intersection and Merge is described in the referenced specifications and this article does not seek to repeat that information, however it does seek to provide some additional guidance on overcoming some of the possible problems in implementing the processing needed to support Intersection and Merge, which will be highlighted below.

    The defined processing models for the Merge and Intersection operations could result in compatible Alternatives which contain two or more duplicate copies of each Assertion; an Assertion being typified by a unique QName. This is not unexpected since if there is to be any compatibility between the requester and provider Policies the same Assertion must appear at least once in each Policy. However, the Intersection process does not verify that the resulting Alternatives are valid; it is possible that the Intersected set may contain supportable but contradicto...