- From: Tom Rutt <tom@coastin.com>
- Date: Fri, 12 Nov 2004 09:17:04 -0800
- To: Martin Gudgin <mgudgin@microsoft.com>
- CC: Marc Hadley <Marc.Hadley@sun.com>, public-ws-addressing@w3.org
Martin Gudgin wrote: > > > > >>-----Original Message----- >>From: Tom Rutt [mailto:tom@coastin.com] >>Sent: 12 November 2004 17:02 >>To: Marc Hadley >>Cc: Martin Gudgin; public-ws-addressing@w3.org >>Subject: Re: i028: Implications of the presence of ReplyTo >> >>I think the acknowledged PO operation, followed by a later >>Invoice, is >>an application specific protocol, where we >>are working on an "infrastructure" protocol. >> >>What I mean by this is that, the "callback" address for the >>supplier to >>deliver the later invoice to (which can occur months later for >>a complicated Purchase) is an application level data Item, >>and belongs >>in the purchase order itself (in the soap body), not in a soap header. >> >>So I now am thinking that the "wsa:replyTo" should only be >>scoped to a >>single MEP (i.e. the request response for the orginal PO request, with >>the response being the ack with the Vendor's POID. The wsa:replyTo >>should not be used by the application for the callback to send >>the future invoice to. >> >> > >Why should the scope of wsa:* headers be limited to a single MEP? I >don't see any reason to bring in such a restriction, it will make >WS-Addressing much less useful. > > > I really think we all need to understand each other's requirements for ws:addressing. With my purchase order example, the address to send the future invoice to (in a subsequent and separate MEP) belongs as "application" data. Thus it should be in the WSDL input message, bound to the body in the soap binding. I guess my mental model holds the thought that soap Headers are not necessarily made availalbe to the user application above the web server's communication stack. Maybe some implementations can make it available to a savvy user to find soap header info from a request message, but in any design I would do I would make sure such application critical information is embedded in the application message of the request. Tom Rutt >>Also, if there is no need for transport independence, the >>message should >>not have to send wsa:reply to when a wsdl request/response is bound >>to a request/response transport (e.g., soap http/post binding). >> >> > >How does the crafter of a message determine whether there is a need for >transport independence or not? I might be adding WS-Addressing headers >to a message at a layer that is unaware of the binding in use. And the >layer processing the WS-Addressing headers on the receiver side might >not know what binding the message came in on. > > > >>I >>would say wsa:replyTo is only required to be send when the request / >>response >>is bound to a one way underlying transport. >> >> > >I really believe this would be a mistake. I really want a world where >the set of headers is NOT dependant on *how* the message is transmitted >( or how some future message will be transmitted ). > >Gudge > > > >>Tom Rutt >> >>Marc Hadley wrote: >> >> >> >>>On Nov 12, 2004, at 6:08 AM, Martin Gudgin wrote: >>> >>> >>> >>>>>On Nov 11, 2004, at 3:01 PM, Martin Gudgin wrote: >>>>> >>>>> >>>>> >>>>>>>So it sounds like you'd be in favor of saying that presence >>>>>>>of ReplyTo >>>>>>>implies a request is expected and that absence >>>>>>> >>>>>>> >>indicates a one-way >> >> >>>>>>>message ? >>>>>>> >>>>>>> >>>>>>Nope. I think that if you expect a reply, you MUST specify [reply >>>>>>endpoint]. So in request-response style MEPs [reply >>>>>> >>>>>> >>endpoint] would >> >> >>>>>>always be specified in the request message. However, I >>>>>> >>>>>> >>>>>don't think that >>>>> >>>>> >>>>> >>>>>>specifying [reply endpoint] necessarily means you expect >>>>>> >>>>>> >>a reply (in >> >> >>>>>>request/response stylee). Does that make sense. I'm saying >>>>>> >>>>>> if a then b >>>>>> >>>>>>but I'm NOT saying >>>>>> >>>>>> if b then a >>>>>> >>>>>> >>>>>> >>>>>I understand what you mean but I'm not sure it makes >>>>> >>>>> >>sense ;-). If we >> >> >>>>>could say that presence of ReplyTo indicates that a reply >>>>> >>>>> >>is expected >> >> >>>>>then that would seem like a useful semantic. What's the >>>>> >>>>> >>purpose of a >> >> >>>>>ReplyTo in a message that isn't expected to generate a reply ? >>>>> >>>>> >>>>OK, it depends on what you mean when you say 'generate a >>>> >>>> >>reply'. Do you >> >> >>>>mean >>>> >>>>a) 'generate a reply as part of the same WSDL MEP' >>>> >>>> >>>> >>>Yes. >>> >>> >>> >>>>b) 'generate a reply, not necessarily part of the same WSDL MEP' >>>> >>>>I have certain protocols that do specify a [reply >>>> >>>> >>endpoint], do expect >> >> >>>>(hope?) that a reply to be sent at some point, but NOT as >>>> >>>> >>part of the >> >> >>>>same WSDL operation as the initial message. >>>> >>>> >>>> >>>That's the kind of scenario I was getting it when I raised >>> >>> >>issue i015 >> >> >>>about redirection. E.g. if a responder in a request >>> >>> >>response MEP sends >> >> >>>back a ReplyTo header, do we expect that to apply to subsequent >>>interactions between the requester and responder. I.e. what is the >>>scope of the effect of a ReplyTo, is it scoped to an instance of a >>>particular MEP or something wider ? Till now I'd been assuming the >>>former, are you suggesting it should be the latter ? >>> >>>Cheers, >>>Marc. >>> >>>--- >>>Marc Hadley <marc.hadley at sun.com> >>>Web Technologies and Standards, Sun Microsystems. >>> >>> >>> >>> >>-- >>---------------------------------------------------- >>Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com >>Tel: +1 732 801 5744 Fax: +1 732 774 5133 >> >> >> >> >> > > > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
Received on Friday, 12 November 2004 17:19:11 UTC