OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Proposal to close WSRF Issue #47


Title: Proposal to close WSRF Issue #47

After a round table discussion at the GGF11 in Hawaii among David Snelling, Igor Sedukhin, Heather Kreger, Villiam Vambenepe and Bryan Murray we came to a conclusion that matters related to the WSRF Issue #47 could be resolved by adopting the following proposal. This would also help WSDM TC in consistently applying WS-RF.

On the premises that addressing of a service is orthogonal to its ability to return property values and such, the following is proposed:

1) Specifications WS-ResourceProperty WS-ResourceLifetime and WS-ServiceGroup should be rewritten to remove any reference to the WS-Resource or implied resource pattern. These specifications need to define only the significant parts of the message exchange patterns corresponding to the appropriate capabilities e.g. retrieval of property values. Whether or not such message exchange patterns involve use of WS-Addressing or presence of particular headers in the messages is irrelevant to those specifications. Addressing mechanism (if needed) and the WS-RF capabilities may be composed when the actual service is implemented. The described separation is facilitating such composition, thus also providing a solution for the WSRF Issue #41.

Note that 1) *does not* prevent or restrict any of the named specifications from using WS-Addressing as a referencing mechanism. That is, for instance, EPR data structure could certainly be used in the WS-ServiceGroup to refer to the services contained in a collection.

2) Another short specification should be added to the WS-RF mix to clarify the use of the WS-Addressing to represent stateful resources. This one must clarly define WS-Resource, implied resource pattern, WS-Resource qualified EPR and deal with the EPR discovery issues (if any) or leave discovery to the WS-Addressing and beyond.

3) WS-RF TC should push a requirement that the WS-Addressing needs to explain how to indicate in the WSDL that WSA (or any "reference properties") headers are needed. In other words, it must be clear to the WSDL consumer that WSA is used and that EPR is needed (WSDL 1.1 <soap:header> in the binding or a WSA SOAP module definition for WSDL 2.0).


-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]