- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Wed, 16 Mar 2005 19:58:36 -0800
- To: Marc Hadley <Marc.Hadley@Sun.COM>
- CC: David Hull <dmh@tibco.com>, 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. > Does that mean then that WSDL MEP mappings would define the cardinality of the [endpoint] property as well as the values of the URIs for various messages? If so, I think this would work. > 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 Thursday, 17 March 2005 04:00:18 UTC