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

Makes sense to me to have the two groups.

The "directly register" is a little fuzzy.

Any UDDI implementation will provide a save_tModel operation, but it 
is not up to the UDDI registry to take in the URL of a policy 
document and create the tModel.

Some UDDI products will add that type of "cataloging" capability, for 
example, for WSDL.  You give it a WSDL and it will retrieve the WSDL, 
parse it, and publish the appropriate tModels in accordance with the 
Technical Note [1].  An API to expose this is not required by the UDDI spec.

Building the tModel would be in the client group (2).  The registry 
would need to provide the save_tModel operation (or equivalent web 
GUI) under group (1).

[1] 
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm

Paul

At 01:09 PM 2007-02-12, Prasad Yendluri wrote:
>Folks,
>
>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 differently.
>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 demonstrate
>
>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 value."
>
>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 scenarios
>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.
>
>Regards,
>Prasad
>

Received on Monday, 12 February 2007 18:41:11 UTC