W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2005

Re: MAPs and SOAP

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Wed, 16 Mar 2005 10:53:14 -0500
To: David Hull <dmh@tibco.com>
Cc: public-ws-addressing@w3.org
Message-id: <fe8806ec6720f4c24335358a2350cb73@Sun.COM>

On Mar 16, 2005, at 10:42 AM, David Hull wrote:

> This might be helpful, but I still want to understand the distinction  
> between having an EPR somewhere in a message with a given designated  
> use, and having a MAP or SOAP property with an EPR as a value.
>
Yes, I was assuming we'd make similar tweaks to the abstract part of  
the spec to talk about generic endpoint references in messages and  
their use.

Marc.

> Marc Hadley wrote:
>
>> I wonder if we can solve this in a way that suits everyone:
>>
>> (i) Add a 'use' attribute to the existing EndpointReferenceType so  
>> that  a usage (reply, fault, from, custom extension) URI can be  
>> specified.
>> (ii) Redefine the existing ReplyTo, FaultTo and From elements to have  
>>  types restricted from the EndpointReferenceType with a defaulted use  
>>  attribute.
>>
>> This way we provide the extensibility mechanism that David is   
>> requesting since one can include an EndpointReference element in a   
>> message with some custom value for the use attribute. We also  
>> maintain  the existing syntax for the predefined ReplyTo, FaultTo and  
>> From  elements.
>>
>> I'm not a schema guru but what I mean is something like;
>>
>>     <xs:element name="EndpointReference"   
>> type="tns:EndpointReferenceType"/>
>>     <xs:complexType name="EndpointReferenceType">
>>         <xs:sequence>
>>             <xs:element name="Address" type="tns:AttributedURIType"/>
>>             <xs:element name="ReferenceParameters"   
>> type="tns:ReferenceParametersType" minOccurs="0"/>
>>             <xs:element ref="tns:Metadata" minOccurs="0"/>
>>             <xs:any namespace="##other" processContents="lax"   
>> minOccurs="0" maxOccurs="unbounded"/>
>>         </xs:sequence>
>> **      <xs:attribute name="use" type="xs:anyURI"/>
>>         <xs:anyAttribute namespace="##other" processContents="lax"/>
>>     </xs:complexType>
>>
>>     <xs:element name="ReplyTo" type="tns:ReplyEndpointReferenceType"/>
>>     <xs:complexType name="ReplyEndpointReferenceType">
>>         <xs:complexContent>
>>             <xs:restriction base="tns:EndpointReferenceType">
>>                 <xs:sequence>
>>                     <xs:element name="Address"   
>> type="tns:AttributedURIType"/>
>>                     <xs:element name="ReferenceParameters"   
>> type="tns:ReferenceParametersType" minOccurs="0"/>
>>                     <xs:element ref="tns:Metadata" minOccurs="0"/>
>>                     <xs:any namespace="##other" processContents="lax"  
>>  minOccurs="0" maxOccurs="unbounded"/>
>>                 </xs:sequence>
>> **              <xs:attribute name="use" type="xs:anyURI"   
>> default="http://www.w3.org/2005/02/addressing/reply"/>
>>                 <xs:anyAttribute namespace="##other"   
>> processContents="lax"/>
>>             </xs:restriction>
>>         </xs:complexContent>
>>     </xs:complexType>
>>
>> Marc.
>>
>> On Mar 15, 2005, at 8:17 PM, Anish Karmarkar wrote:
>>
>>>
>>> It seems to me that providing a general mechanism (such as   
>>> wsa:associatedEndpoint) would enable implementors to implement   
>>> patterns beyond simple request-response. Request-response is  
>>> certainly  a very important usecase that must be supported, but by  
>>> providing a  framework where users plug in URIs for specific "roles"  
>>> in an  interaction pattern seems like a win-win situation. We can  
>>> define a  'reply' and 'fault' URI which would mean that there is a  
>>> built in  support for the oft-used req-response pattern. The ability  
>>> to reuse an  MAP (btw, this set is *not* extensible) to enable  
>>> various interesting  interactions lower the bar for supporting  
>>> additional interactions.  With such a generic mechanism all that is  
>>> required for new interaction  patterns is to define a new URI and  
>>> associated semantics as opposed to  a new SOAP header/module/feature  
>>> that then has to be processed by all  SOAP stacks. I agree that  
>>> providing such extensibility is a good thing  for the same reason  
>>> that providing extensibility for [relationship] is  a good thing.  
>>> Most people view ws-addressing as a fundamental building  block and  
>>> providing the right extensibility hooks in our spec would go  a long  
>>> way.
>>>
>>> -Anish
>>> --  
>>>
>>> David Hull wrote:
>>>
>>>> I've been going back through the core and SOAP specs after today's   
>>>> discussion, and I'm still concerned about the difference between   
>>>> reply/fault and any other kind of endpoint.  I also have an at  
>>>> least  partially worked out example below the horizontal line,  
>>>> which I'd  encourage everyone to look through and comment on even  
>>>> if the  concerns below hold no interest.
>>>> To take Dave O's example, as I understand it, if I have a MEP  
>>>> that's  basically request/reply but also has an alternate reply,  
>>>> then two of  the three endpoints are considered MAPs, have  
>>>> properties defined for  them in the SOAP addressing module, and  
>>>> appear in the wsa:namespace.   The third is just some random SOAP  
>>>> header.
>>>> While it is true that one can always put an EPR wherever one wants,  
>>>>  whether as a header or in some distinguished place in the body, or  
>>>>  someplace out of band for that matter, it still seems strange to  
>>>> have  such an asymmetry instead of somehow allowing for an  
>>>> extensible set  of endpoints.  It seems particularly strange when  
>>>> we explicitly make  [relationship] extensible.  We could just as  
>>>> well have (and maybe  once did have?) an [in-reply-to] property and  
>>>> depend on SOAP  extensibility for anything further.
>>>> I would think that the reasons for making [relationship] extensible  
>>>>  are the usual ones: People are bound to define relationships other  
>>>>  than in-reply-to, and we would like to give them a standard place  
>>>> to  put those, in such a way that a processor could generically  
>>>> gather  "all related messages" from a message without having to  
>>>> understand  what in-reply-to and whatever other headers mean.  I'm  
>>>> not precisely  sure what the use case would be for this, but it  
>>>> seems like a good  thing overall.
>>>> I'm hard-pressed to see why it wouldn't be equally good to do the   
>>>> same thing with associated endpoints.  As with [relationship], one   
>>>> could then generically determine what endpoints might be expected  
>>>> to  receive messages due to a given message, without having to  
>>>> understand  what my custom "alternate-reply" header means (or  
>>>> assume that any  unknown EPR in a header is liable to carry ongoing  
>>>> traffic).  This  might make routing easier, or help predict traffic  
>>>> volume, or have  entirely other uses.  If anything, this seems like  
>>>> it might be more  directly useful than handling [relationship]  
>>>> generically.
>>>> If nothing binding documents for new interactions might be somewhat  
>>>>  easier to read.  Along those lines, here is a draft of what an   
>>>> "in-out-alternateOut" MEP might look like under the status quo.   
>>>> I'm  neither endorsing nor disparaging this version (at this  
>>>> point).  I'm  more interested in whether this looks about right so  
>>>> far as what  would be required.  Any feedback would be welcome.
>>>> -------------------------------------------------------------------- 
>>>> -- --
>>>>         XXX. In-out-alternateOut
>>>> This is a two-way MEP. A reply is expected hence mandating [reply   
>>>> endpoint] in the request message. The response message might be a   
>>>> fault.  */In addition, an alternate reply may occur, hence  
>>>> mandating  [alternate reply endpoint] in the request message.  The  
>>>> [alternate  reply endpoint] property is an abstract property like  
>>>> the standard  Message Addressing Properties.  If present, it MUST  
>>>> be mapped to the  SOAP yatns:AlternateReply header, analogously to  
>>>> the mapping of  Message Addressing Properties described in sections  
>>>> 3 and 4 of the  WS-Addressing SOAP binding.
>>>> /*
>>>> */When formulating an alternate reply, follow the rules in section   
>>>> 3.2 of the WS-Addressing Core Spec (Formulating a Reply Message),  
>>>> but  with rule 1 carrying the following additional clause:
>>>> /*
>>>>     * */If the reply is an alternate reply message, select the EPR   
>>>> from
>>>>       the incoming message's [alternate reply endpoint] property. If
>>>>       none is present, the processor MUST fault./*
>>>> */
>>>> /*
>>>> Table xxx-1. Message addressing */and other /*properties for in   
>>>> message. Property     Mandatory     Description
>>>> [destination]     Y     Provides the address of the intended  
>>>> receiver of  this message
>>>> [action]     Y     Identifies the semantics implied by this message
>>>> [source endpoint]     N     Message origin. Unused in this MEP, but  
>>>> may be  included to facilitate longer running message exchanges.
>>>> [reply endpoint]     Y     Intended receiver for the reply to this  
>>>> message.
>>>> /[alternate reply endpoint]/
>>>>     /Y/
>>>>     /Intended receiver for alternate replies to this message./
>>>> [fault endpoint]     N     Intended receiver for faults related to  
>>>> this  message. May be included to direct fault messages to a  
>>>> different  endpoint than [reply endpoint].
>>>> [message id]     Y     Unique identifier for this message. Used in  
>>>> the  [relationship] property of the out message.
>>>> [relationship]     N     Indicates relationship to a prior message.  
>>>> Unused  in this MEP, but may be included to facilitate longer  
>>>> running message  exchanges.
>>>> */
>>>> /*
>>>> Table xxx-2. Message addressing /*and other */properties for out   
>>>> message. Property     Mandatory     Description
>>>> [destination]     Y     Provides the address of the intended  
>>>> receiver of  this message
>>>> [action]     Y     Identifies the semantics implied by this message
>>>> [source endpoint]     N     Message origin. Unused in this MEP, but  
>>>> may be  included to facilitate longer running message exchanges.
>>>> [reply endpoint]     N     Intended receiver for replies to this  
>>>> message.  Unused in this MEP, but may be included to facilitate  
>>>> longer running  message exchanges.
>>>> /[alternate reply endpoint]/
>>>>     /N/
>>>>     /Intended receiver for alternate replies to this message.   
>>>> Unused in  this MEP, but may be included to facilitate longer  
>>>> running message  exchanges./
>>>> [fault endpoint]     N     Intended receiver for faults related to  
>>>> this  message. Unused in this MEP, but may be included to  
>>>> facilitate longer  running message exchanges.
>>>> [message id]     N     Unique identifier for this message. Unused  
>>>> in this  MEP, but may be included to facilitate longer running  
>>>> message  exchanges.
>>>> [relationship]     Y     Indicates that this message is a response  
>>>> to the  in message using the in message [message id] value and the  
>>>> predefined  |http://www.w3.org/@@@@/@@/addressing/reply| IRI.
>>>> */
>>>> /**/
>>>> /*
>>>> Table xxx-3. Message addressing /*and other */properties for   
>>>> alternateOut message. Property     Mandatory     Description
>>>> [destination]     Y     Provides the address of the intended  
>>>> receiver of  this message
>>>> [action]     Y     Identifies the semantics implied by this message
>>>> [source endpoint]     N     Message origin. Unused in this MEP, but  
>>>> may be  included to facilitate longer running message exchanges.
>>>> [reply endpoint]     N     Intended receiver for replies to this  
>>>> message.  Unused in this MEP, but may be included to facilitate  
>>>> longer running  message exchanges.
>>>> /[alternate reply endpoint]/
>>>>     /N/
>>>>     /Intended receiver for alternate replies to this message.   
>>>> Unused in  this MEP, but may be included to facilitate longer  
>>>> running message  exchanges./
>>>> [fault endpoint]     N     Intended receiver for faults related to  
>>>> this  message. Unused in this MEP, but may be included to  
>>>> facilitate longer  running message exchanges.
>>>> [message id]     N     Unique identifier for this message. Unused  
>>>> in this  MEP, but may be included to facilitate longer running  
>>>> message  exchanges.
>>>> [relationship]     Y     Indicates that this message is a response  
>>>> to the  in message using the in message [message id] value and the  
>>>> predefined  |http://www.alternate.org/addressing/alternateReply|  
>>>> IRI.
>>>> */
>>>> /*
>>>
>>>
>>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> Web Technologies and Standards, Sun Microsystems.
>>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Wednesday, 16 March 2005 15:53:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:04 GMT