Re: MAPs and SOAP

David Orchard wrote:
> Anish,
> 
> You keep on making what I considered unfounded and unproven claims. 
> 

David Hull has made a very good case for this at [1], [2] and [3].

> 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/>
> 

See [4].
<endpoint> is extensible wrt to its "kind" and <ReplyTo> is not.

The exact syntax (as quoted above) is not important. What is important 
is that there be a property (like [endpoint]) which can support/enable 
all kinds of MEPs not just req-response. WSDL 2.0 allows different MEPs. 
Independent of WSDL I can create interesting SOAP MEPs. For example, 
WSDL 2.0 allows you to have an operation with one "in" and three "out" 
messages. Providing an extensible (similar to the extensibility of 
[relationship] property) WS-A property allows me to express all the 
three "out" endpoint references in the "in" message. Another example is: 
a notification producer wants to send messages to its subscribers with 
the source EPR, subscription manager EPR, EPR to access the archive of 
subscription messages and EPR for reporting abuses included in the 
message as its Addressing properties. With extensibility builtin 
[relationship] and [endpoint] (or whatever the property is called), to 
implement the above scenario all I have to do is specify the URI/IRIs 
for all the different kinds of URIs and relationships between messages.

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

I just don't see how this makes the common case difficult? No more or no 
less than the fact that having to include the URI 
"http://www.w3.org/@@@@/@@/addressing/reply" in the [relationship] 
property makes the common case 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.
> 

The only concern against this, that I have seen is at [5]. I find that 
position inconsistent, as it says that it is OK for [relationship] 
property to be extensible but not for [Endpoint] (or whatever it is called).

To me the benefits of making this change are quite large, the change 
itself is very small (wrt to time it would take to include this in the 
spec) and I have not been convinced that there is any drawback to this. 
It is just better design. But, as always, I'm willing to be convinced 
otherwise.

-Anish
--

[1] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0100.html
[2] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0109.html
[3] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0140.html
[4] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0150.html
[5] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0160.html

> 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:47:03 UTC