Re: MAPs and SOAP

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:29:40 UTC