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

Re: MAPs and SOAP

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Tue, 15 Mar 2005 17:17:24 -0800
Message-ID: <42378924.9020104@oracle.com>
To: David Hull <dmh@tibco.com>
CC: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>

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.
> 
> 
> */
> /*
Received on Wednesday, 16 March 2005 01:25:43 GMT

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