- From: David Hull <dmh@tibco.com>
- Date: Wed, 16 Mar 2005 13:32:29 -0500
- To: David Orchard <dorchard@bea.com>
- Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, public-ws-addressing@w3.org
- Message-id: <42387BBD.1020608@tibco.com>
I'm not sure it's as bad as all that. First, the "role", however it's expressed in XML, is not selecting type. The type is always EPR. It's not like a reply endpoint is an EPR while an alternate reply endpoint is some sort of alternate EPR. Second, I don't think making the set of EPRs in the MAPs extensible requires changing the spelling of well-known endpoints. As I said originally, I don't really care how things end up looking on the wire, as long as I can easily add my own kind of endpoints to the MAPs and thus to the SOAP properties of the message. What those SOAP properties look like on the wire is of much less concern to me. Wasn't the ability to encapsulate the details of how things look on the wire the point of having abstract properties in the first place? 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 Wednesday, 16 March 2005 18:33:08 UTC