[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 |
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]