W3C home > Mailing lists > Public > public-ws-policy@w3.org > February 2007

WS-Policy 1.5 Attachment - Need to Reorganize Current UDDI Attach ment Scenarios

From: Prasad Yendluri <prasad.yendluri@webmethods.com>
Date: Mon, 12 Feb 2007 13:09:25 -0500
Message-ID: <497B3BF095D687408EC268A103E85E8503D3F3@ca-exbe1.webm.webmethods.com>
To: public-ws-policy@w3.org
Cc: Prasad Yendluri <prasad.yendluri@webmethods.com>, "Clement, Luc" <luc.clement@hp.com>, Rajesh Koilpillai <Rajesh.Koilpillai@webmethods.com>, "Snow, Skip [CCC-OT_IT]" <skip.snow@citigroup.com>, pauld@mitre.org, ehorst@amberpoint.com


As I worked on fleshing up the UDDI Policy Attachment Test Scenarios, I have
come to the conclusion that the scenarios need to be organized slightly

They need to be put into two different groups:


(1)     Scenarios that a UDDI registry provider would need to demonstrate
capabilities for

(2)     Scenarios that a client / user of a UDDI Registry needs to


The UDDI Registry providers need to facilitate all aspects of attaching
policies using UDDI, as defined in section 6 of the

WS-Policy 1.5 Attachment specification. That is, the UDDI registries must
support associating Policy expressions with various UDDI entities:


a.       to reference and attach references to existing remote policy
expressions to UDDI entities

b.       to directly register reusable policy expressions as distinct
tModels and then 

c.       to reference and attach the reusable local policy expressions to
UDDI entities


The tests for UDDI registry must demonstrate the ability to save and in turn
retrieve various UDDI entities, with Policy attached.

The calculation of effective policy (as identified in scenarios 37, 38 and
39) is not the functionality of the UDDI registry. 

UDDI protocol offers no support for retrieving an "effective" policy. It is
the client of the Registry that retrieves the information from the 

UDDI Registry the information on the entities of interest and then compute
the effective policy based on the retrieved information.

The tests for the UDDI client / user will encompass the client side of
publishing and retrieving the policy attached 

UDDI entities and then computing the effective policy.


This is very much like attaching policies to WSDL, where calculation of the
effective policy is the responsibility of the consumer of the 

WSDL (or the service describe by the WSDL).


The above is also in-line with what Paul Denning also pointed out:


"Most UDDI implementations provide a browser-based interface to CRUD UDDI
entries.  Such an interface is sufficient to manually add the UDDI entries
or tModels that reference policies in accordance with WS-PolicyAttachment.
So, you may find entries in private UDDI registries that refer to policies
in accordance with WS-PolicyAttachment.  I have added the three category
tModels defined in Appendix B to a UDDI server that is within MITRE, so
these "taxonomies" are available to use.


I can see there being an issue with "merging" into an "effective policy",
but the ability to reference policies from UDDI in a standard way, is of


One last point - for the UDDI registry provider scenarios or the effective
policy calculation scenarios, there is no "interop" involved. 

They are all unit tests. The UDDI registry scenarios do not go between
different UDDI registry nodes. Similarly effective policy calculation

are also unit tests, like the tests for effective policy calculation on a
WSDL entities.


I am working on the test cases to be in line with above. Hope that makes
sense to the group.




Received on Monday, 12 February 2007 18:09:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:25 UTC