Re: [wsrf] Proposal to close WSRF Issue #47

[Steve Graham <sggraham@us.ibm.com>]

apologies, very old email for some reason
snuck into my current inbox.  email hiccup.

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

Steve Graham/Raleigh/IBM@IBMUS

10/05/2004 02:17 PM

To	"Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
cc	wsrf@lists.oasis-open.org
Subject	Re: [wsrf] Proposal to close WSRF Issue #47

1) I would be comfortable if references to "the implied resource pattern"
were replaced with "WS-Resource Access Pattern".
2) that is the WS-Resource spec, right? 
3)  we could try, but we need to wait for some sort of standards working
group to be formed 

sgg 

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

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

07/21/2004 11:20 PM

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.

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