Re: MAPs and SOAP

David,

If that approach is taken, wouldn't the same apply to the [relationship] 
property?
Instead of defining the IRI: http://www.w3.org/@@@@/@@/addressing/reply 
we would have to define something like a [reply-relationship] property.

The advantage of "generifying" [relationship] is that additional 
relationships such as 'callback', 'notification' etc can be defined and 
used in the MAP. A nice extensibility feature that enables various patterns.

-Anish
--

David Orchard wrote:
> I'm quite against the approach of "generifying" the MAPs.  I believe in
> names that reflect the type, ala ReplyTo and FaultTo.
> 
> I think structures of the form
> <bag type="type1">type1content</bag>
> <bag type="type2">type2content</bag>
> 
> Are not very readable and add little value.  I much prefer
> <type1>type1content</type1>
> ...
> 
> Whether type1 is re-usable in multiple MAPs has nothing to do with
> whether the type is in the instance or in the schema.
> 
> Cheers,
> Dave
> 
> 
>>-----Original Message-----
>>From: public-ws-addressing-request@w3.org
> 
> [mailto:public-ws-addressing-
> 
>>request@w3.org] On Behalf Of Anish Karmarkar
>>Sent: Tuesday, March 15, 2005 5:17 PM
>>To: David Hull
>>Cc: public-ws-addressing@w3.org
>>Subject: Re: MAPs and SOAP
>>
>>
>>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 Thursday, 17 March 2005 04:04:49 UTC