- From: David Hull <dmh@tibco.com>
- Date: Wed, 16 Mar 2005 12:27:45 -0500
- Cc: public-ws-addressing@w3.org
Marc Hadley wrote: > 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. This may very well work for me. Again, the key is that the set of endpoints associated with the MAPs is extensible. > > 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 17:28:18 UTC