- From: David Hull <dmh@tibco.com>
- Date: Wed, 16 Mar 2005 10:59:04 -0500
- To: Marc Hadley <Marc.Hadley@Sun.COM>
- Cc: public-ws-addressing@w3.org
Would the [reply endpoint] and [fault endpoint] MAPs continue to exist as such, and if so, why? Marc Hadley wrote: > On Mar 16, 2005, at 10:42 AM, David Hull wrote: > >> This might be helpful, but I still want to understand the >> distinction between having an EPR somewhere in a message with a >> given designated use, and having a MAP or SOAP property with an EPR >> as a value. >> > Yes, I was assuming we'd make similar tweaks to the abstract part of > the spec to talk about generic endpoint references in messages and > their use. > > Marc. > >> Marc Hadley wrote: >> >>> I wonder if we can solve this in a way that suits everyone: >>> >>> (i) Add a 'use' attribute to the existing EndpointReferenceType so >>> that a usage (reply, fault, from, custom extension) URI can be >>> specified. >>> (ii) Redefine the existing ReplyTo, FaultTo and From elements to >>> have types restricted from the EndpointReferenceType with a >>> defaulted use attribute. >>> >>> This way we provide the extensibility mechanism that David is >>> requesting since one can include an EndpointReference element in a >>> message with some custom value for the use attribute. We also >>> maintain the existing syntax for the predefined ReplyTo, FaultTo >>> and From elements. >>> >>> I'm not a schema guru but what I mean is something like; >>> >>> <xs:element name="EndpointReference" >>> type="tns:EndpointReferenceType"/> >>> <xs:complexType name="EndpointReferenceType"> >>> <xs:sequence> >>> <xs:element name="Address" type="tns:AttributedURIType"/> >>> <xs:element name="ReferenceParameters" >>> type="tns:ReferenceParametersType" minOccurs="0"/> >>> <xs:element ref="tns:Metadata" minOccurs="0"/> >>> <xs:any namespace="##other" processContents="lax" >>> minOccurs="0" maxOccurs="unbounded"/> >>> </xs:sequence> >>> ** <xs:attribute name="use" type="xs:anyURI"/> >>> <xs:anyAttribute namespace="##other" processContents="lax"/> >>> </xs:complexType> >>> >>> <xs:element name="ReplyTo" type="tns:ReplyEndpointReferenceType"/> >>> <xs:complexType name="ReplyEndpointReferenceType"> >>> <xs:complexContent> >>> <xs:restriction base="tns:EndpointReferenceType"> >>> <xs:sequence> >>> <xs:element name="Address" >>> type="tns:AttributedURIType"/> >>> <xs:element name="ReferenceParameters" >>> type="tns:ReferenceParametersType" minOccurs="0"/> >>> <xs:element ref="tns:Metadata" minOccurs="0"/> >>> <xs:any namespace="##other" >>> processContents="lax" minOccurs="0" maxOccurs="unbounded"/> >>> </xs:sequence> >>> ** <xs:attribute name="use" type="xs:anyURI" >>> default="http://www.w3.org/2005/02/addressing/reply"/> >>> <xs:anyAttribute namespace="##other" >>> processContents="lax"/> >>> </xs:restriction> >>> </xs:complexContent> >>> </xs:complexType> >>> >>> Marc. >>> >>> On Mar 15, 2005, at 8:17 PM, Anish Karmarkar wrote: >>> >>>> >>>> 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. >>>>> */ >>>>> /* >>>> >>>> >>>> >>>> >>> --- >>> Marc Hadley <marc.hadley at sun.com> >>> Web Technologies and Standards, Sun Microsystems. >>> >> >> > --- > Marc Hadley <marc.hadley at sun.com> > Web Technologies and Standards, Sun Microsystems. >
Received on Wednesday, 16 March 2005 15:59:38 UTC