RE: MAPs and SOAP

Anish,

You keep on making what I considered unfounded and unproven claims. 

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

Yet you have not proven why an <endpoint type="replyTo"/> is somehow
more useful than <ReplyTo/>

This totally feels like change for the sake of making change, and
further makes a very common case more difficult.

The multitude of emails that do not identify a single problem with the
current design lead me to think that any issue should be closed with no
change.

Cheers,
Dave
> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: Thursday, March 17, 2005 11:15 AM
> To: David Orchard
> Cc: David Hull; public-ws-addressing@w3.org
> Subject: 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 Friday, 18 March 2005 00:15:11 UTC