RE: [wsrf] issue 127 - : MUST use RAP?

["Wilson, Kirk D" <Kirk.Wilson@ca.com>]

Is the requirement that the message MUST contain sufficient information
to disambiguate the resource?  Where such disambiguation is not
required, the address alone is sufficient.  Otherwise, an identifier
must be part of the message targeted to the WS-Resource.

Kirk Wilson
Architect, Development
Office of the CTO
802 765-4337
 
-----Original Message-----
From: David Snelling [mailto:David.Snelling@UK.Fujitsu.com] 
Sent: Sunday, August 07, 2005 3:02 PM
To: WSRF
Subject: Re: [wsrf] issue 127 - : MUST use RAP?

Folks,

Ian's proposal I believe addresses the issue a stated. We can go with 
it but I think we should look at a few options before jumping in.

My understanding is that, when reduced to its most fundamental, the 
only normative aspect of the WS-Resource Access Pattern is that the 
identification of the target resource MUST appear in the *message*.

Note that since the resource (or a factory for it) provides the 
reference to the resource, this normative statement is not strictly 
required for interoperability. For example, if as a WS-Resource I 
provide only a URL and do not require my identifier to appear in the 
*message*, any client with my WSDL and this URL can contact me. I don't 
see an interoperability need for the identifier to appear in the 
*message*. The address alone should be sufficient.

We should consider dropping this requirement, as it would allow the 
WSRF specs to compose more easily with other specifications.

Note: I am not opposed to Ian's proposal, I just would like to know it 
it is actually required.

Thoughts?

On 5 Aug 2005, at 21:49, Ian Robinson wrote:

>
>
>
>
> This pulic review issue states:
> Line 372 (and others) says, "The GetResourcePropertyDocument request
> message MUST follow the WS-Resource Access Pattern." I'm not clear
what
> requirement this normative MUST imposes on the implementer. RFC 2119 
> says
> keywords "MUST only be used where it is actually required for
> interoperation or to limit behavior which has potential for causing 
> harm
> (e.g., limiting retransmissions). For example, they must not be used 
> to try
> to impose a particular method on implementers where the method is not
> required for interoperability." I assume, then, that the requirement
to
> follow the WS-Resource Access Pattern has something to do with
> interoperability. But the definition in WS-Resource isn't much help 
> when it
> says, "An identifier of the resource MUST appear as part of any 
> message to
> a WS-Resource to allow the WS-Resource to disambiguate the resource
> targeted by the message. We refer to this pattern of access as the
> 'WS-Resource Access Pattern'." Would it be possible to spell out more
> clearly what an implementer needs to do to satisfy the interop 
> requirements
> of WS-RAP?
>
>
>
> Use of the WS-Resource access pattern is a requirement for 
> interoperability
> but, since we went back to a single embodiment, the description of
what
> WS-RAP implies now looks a little obtuse. I propose this issue be 
> resolved
> by retaining the MUST in WSRF-RP and by re-establishing a little of
the
> text we lost from WS-Resource when removing the embodiments.
>
> Specifically, replace the bullet at line 127 of WS-Resource with:
>
> *     "An identifier of the resource MUST be represented in any 
> reference
> to a WS-Resource and MUST appear as part of any message to a 
> WS-Resource to
> allow the WS-Resource to disambiguate the resource targeted by the 
> message.
> We refer to this pattern of access as the "WS-Resource Access Pattern"
> (WS-RAP). The precise location of the resource identifier in a message

> to a
> WS-Resource depends on how the identifier is represented in the 
> WS-Resource
> reference used to access the WS-Resource and also on the 
> transport-specific
> bindings used to serialize the message."
>
> and update the definition of WS-Resource reference to:
>
> "A WS-Resource reference (or just reference) is a construct through 
> which a
> single WS-Resource can be accessed. It is represented by an endpoint
> reference, or more precisely an XML element whose type is, or is 
> derived
> (by extension) from the complexType named EndpointReferenceType 
> defined by
> the [WS-Addressing] specification. The address of the Web service 
> endpoint
> part of the WS-Resource is contained in the wsa:Address element 
> information
> item of the endpoint reference. The resource identifier MUST appear 
> either
> in the contents of the wsa:ReferenceParameter element information item

> of
> the endpoint reference or embedded as part of the wsa:Address element
> information item of the endpoint reference. In a message that is 
> conformant
> to the WS-Resource Access Pattern the resource identifier of the 
> resource
> must appear in the message according to binding-specific rules 
> outlined in
> WS-Addressing. For example, in the SOAP binding defined by 
> WS-Addressing,
> the Web service endpoint address is contained in the wsa:Address 
> element
> information item in the endpoint reference and appears in the message 
> as
> the contents of the wsa:To SOAP header, and each direct child element
> information item (if any) of the wsa:ReferenceParameter element 
> information
> item appears in the message as a separate SOAP header.
>
>
> For a given resource identifier there may be many references. The way 
> two
> references are compared for equality is implementation-specific and
not
> defined by this specification."
>
>
>
>
>
> Attached is a version of WS-Resource with change tracking to 
> illustrate the
> changes:
>
>
> (See attached file: wsrf-ws_resource-1.2-spec-issue127.doc)
>
>
>
> Regards,
> Ian<wsrf-ws_resource-1.2-spec-issue127.doc>
-- 

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE

     +44-208-606-4649 (Office)
     +44-208-606-4539 (Fax)
     +44-7768-807526  (Mobile)