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] Proposed resolution to issue 127






William,
The first bullet establishes a WS-A EPR as the means to reference a
WS-Resource. The second bullet establishes that the resource identifier,
required to disambiguate which resource is to be used in the processing of
the message, must be represented in the EPR and in any message addressed to
the WS-Resource. These 2 bullets could be collapsed into a single bullet,
but removing the information contained in the 2nd bullet altogether would
weaken the definition of WS-Resource.
The definition of WS-Resource always required the resource identifier to be
represented both in WS-Resource references and in any messages to
WS-Resources - this was previously defined using the abstract term
"WS-Resource access pattern" and further defined in a more concrete fachion
in each embodiment thereof. Now we have consolidated on a single embodiment
(WS-Addressing) we have this opportunity to go straight to the concrete
definition but this does not mean we should weaken the definition we have
previously agreed upon.


Regards,
Ian Robinson
STSM, WebSphere Messaging and Transactions Architect
IBM Hursley Lab, UK
ian_robinson@uk.ibm.com


                                                                           
             "Vambenepe,                                                   
             William N"                                                    
             <vbp@hp.com>                                               To 
                                       Ian Robinson/UK/IBM@IBMGB,          
             12/08/2005 21:41          <wsrf@lists.oasis-open.org>         
                                                                        cc 
                                                                           
                                                                   Subject 
                                       RE: [wsrf] Proposed resolution to   
                                       issue 127                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Hi Ian,

In section 2.3 of your proposed modified WS-Resource doc, what does the
second bullet add that the first one doesn't already say?

First bullet:
A reference to a WS-Resource 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.

Second bullet:
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. The precise location of the resource identifier in a message to
a WS-Resource is dependent on the protocol binding used to interact with
the WS-Resource endpoint but is normatively defined in the appropriate
WS-Addressing binding specification. For example, [WSA - SOAP] defines
the binding of message addressing properties for the SOAP protocol.

Also, at the end of that same section, shouldn't "for a given resource
identifier there may be many references" be "for a given resource there
may be many references"?

Regards,

William

-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@uk.ibm.com]
Sent: Friday, August 12, 2005 9:27 AM
To: wsrf@lists.oasis-open.org
Subject: [wsrf] Proposed resolution to issue 127





During the discussion of the proposed resolution to issue 127, I took an
AI to produce drafts of the specs that replaced the term "WS-RAP" with
text that requires the use of WS-Addressing for consideration by the TC.
I have also produced an example of how this would affect the
WS-ResourceProperties specification - if we accept this approach as the
resolution to issue 127 then there are a small number of similar changes
to make in WSRF-RL and WSRF-SG.

(Updated) proposed resolution text to issue 127 >>>>>>>>>>>>

Previously all message exhanges defined by the WS-RF specifications
stated that the request messages "MUST follow the WS-Resource Access
Pattern.".
The intent of this statement is a normative requirement for the use of a
WS-Addressing EndpointReference, containing the resource identifier, to
represent the reference to a WS-Resource. The precise location of the
resource identifier in a message to a WS-Resource is dependent on its
location in the EPR and on the protocol binding used to interact with
the WS-Resource endpoint but is normatively defined in the appropriate
WS-Addressing binding specification.
This issue has been resolved by a clarification to the WSRF-RP, WSRF-RL
and WSRF-SG specifications that replaces the normative reference to
WS-RAP with a normative reference to the WS-Resource definition in the
WS-Resource specification. The WS-Resource definition states the
normative requirement to use WS-Addressing EPRs.

<<<<<<<<<<<<<<<<<<<<<<<<

(See attached file: wsrf-ws_resource-1.2-spec-issue127.noRAP.doc)(See
attached file: wsrf-ws_resource_properties-1.2-spec-pr-01.127.noRAP.doc)


If we decide we prefer to retain the normative term WS-RAP, then we
still also have the original proposed resolution:
http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200508/
msg00003.html

Regards,
Ian Robinson
STSM, WebSphere Messaging and Transactions Architect IBM Hursley Lab, UK
ian_robinson@uk.ibm.com




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