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 12:27:45 -0500
Cc: public-ws-addressing@w3.org
Message-id: <42386C91.7020006@tibco.com>

Marc Hadley wrote:

> On Mar 16, 2005, at 10:59 AM, David Hull wrote:
>
>> Would the [reply endpoint] and [fault endpoint] MAPs continue to 
>> exist  as such, and if so, why?
>>
> I think we'd have a [endpoint]: (endpoint reference, URI)  
> (0..unbounded) property that would replace [reply endpoint], [fault  
> endpoint] and [source endpoint]. We'd define the URIs for source, 
> reply  and fault (using some of the text from the obsoleted sections) 
> and  leave it open for definition of other URIs elsewhere.
>
> We'd need to make similar changes to the SOAP and WSDL binding docs.

This may very well work for me.  Again, the key is that the set of 
endpoints associated with the MAPs is extensible.

>
> Marc.
>
>> 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.
>>>
>>
>>
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
>
Received on Wednesday, 16 March 2005 17:28:18 GMT

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