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

Re: MAPs and SOAP

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

Would the [reply endpoint] and [fault endpoint] MAPs continue to exist 
as such, and if so, why?

Marc Hadley wrote:

> 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:59:38 GMT

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