Re: MAPs and SOAP

David Orchard wrote:
> 
>>-----Original Message-----
>>From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
>>Sent: Wednesday, March 16, 2005 7:56 PM
>>To: David Orchard
>>Cc: David Hull; public-ws-addressing@w3.org
>>Subject: 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.
> 
> 
> Are you suggesting the spec is inconsistent and plan on raising another
> issue before or after last call?
> 

David Hull has already raised this as an issue. Although, I don't think 
this has been logged officially as an issue.

> 
>>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.
> 
> 
> How?  I fail to see how the current design precludes any of the
> 'callback' or 'notification' patterns.
> 

The current design does not preclude any of the patterns like 'callback' 
or 'notification'. The current design in fact enables such patterns 
through the generic [relationship] property, but creates special purpose 
properties such as [reply to] and [fault to] that are not necessarily 
useful to other patterns. Applying the same design principles to [reply 
to] and [fault to] as they are applied to [relationship] would make 
WS-Addressing very useful in the implementation of additional 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 19:15:26 UTC