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 11:17:52 -0500
To: David Hull <dmh@tibco.com>
Cc: public-ws-addressing@w3.org
Message-id: <f5048a4de40493cb5006ceea3ef7274f@Sun.COM>

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.

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 16:17:58 GMT

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