OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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)



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]