[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrf] Proposal to close WSRF Issue #41
-- Igor
Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
"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]