RE: [wsrf] Proposal to close WSRF Issue #41

wsrf message

What is relevant, though, is that WSRF-RP does not defined anything in the body of the GetResourceProperties message to identify the resource properties instance document of the target service. So I think this statement is more an observation that the implementation of the implied resource pattern should not be specified than that the implied resource pattern itself is not needed.

I just don't think that definition of GetResourceProperty operation has anything to do with where and how I disambiguate where this operation is invoken on.

Basically the way it is right now it says: one must use WS-Addressing and implied resource pattern and WS-R qualified endpoint reference to disambiguate. Why? Why can't I use some another mechanism to disambiguate and just use the operation signature? See an example I've presented before http://www.oasis-open.org/archives/wsrf/200407/msg00019.html.

What is the purpose of trying to separate the notion of the WS-Resource from the rest of the WSRF? WS-Resource is the very core of WSRF so the issue as stated does not make any sense to me.

Nobody actually meant that WS-Resource goes away. Just that specifications that define operational signatures don't need to depend on use of WS-Addressing and implied resource pattern definition to disambiguate. Such pattern and use of WSA is part of the WS-RF set of specs, only not part of every spec there is. If one wants to do it that way they can use it.

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

From: Ian Robinson [mailto:ian_robinson@uk.ibm.com]
Sent: Sunday, July 25, 2004 4:32 PM
To: Sedukhin, Igor S
Cc: wsrf@lists.oasis-open.org
Subject: Re: [wsrf] Proposal to close WSRF Issue #41

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

Lets break this down. From the service's perspective, it understands how the specific resource properties document instance should be located in order to satisfy, for example, a GetResourceProperties request. You say "Whether or not such message exchange patterns involve use of WS-Addressing or presence of particular headers in the messages is irrelevant". What is relevant, though, is that WSRF-RP does not defined anything in the body of the GetResourceProperties message to identify the resource properties instance document of the target service. So I think this statement is more an observation that the implementation of the implied resource pattern should not be specified than that the implied resource pattern itself is not needed. This is essentially the point being made by Issue WSRF40. Do the GGF 11 folks agree?
Some Web services will only ever have a single resource properties instance document but that is just the special singleton case of the implied resource pattern.

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

We certainly need a normative description - either in another document or in-line in one or more of the existing documents.

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

Is that a WSDM requirement? Perhaps this is how WSDM will clarify Issue WSRF47 .

Regards,
Ian Robinson

"Sedukhin, Igor S" <Igor.Sedukhin@ca.com>

22/07/2004 04:20

To: <wsrf@lists.oasis-open.org>
cc:
Subject: [wsrf] 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.

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