- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Wed, 16 Mar 2005 11:17:52 -0500
- To: David Hull <dmh@tibco.com>
- Cc: public-ws-addressing@w3.org
On Mar 16, 2005, at 10:59 AM, David Hull wrote: > Would the [reply endpoint] and [fault endpoint] MAPs continue to exist > as such, and if so, why? > I think we'd have a [endpoint]: (endpoint reference, URI) (0..unbounded) property that would replace [reply endpoint], [fault endpoint] and [source endpoint]. We'd define the URIs for source, reply and fault (using some of the text from the obsoleted sections) and leave it open for definition of other URIs elsewhere. We'd need to make similar changes to the SOAP and WSDL binding docs. Marc. > 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. >> > > --- Marc Hadley <marc.hadley at sun.com> Web Technologies and Standards, Sun Microsystems.
Received on Wednesday, 16 March 2005 16:17:58 UTC