RE: MAPs and SOAP

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 Wednesday, 16 March 2005 16:44:08 UTC