Re: MAPs and SOAP

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.

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.
>

Received on Wednesday, 16 March 2005 15:43:11 UTC