RE: MAPs and SOAP

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

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

> 
> -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 05:01:18 UTC