- From: Tom Rutt <tom@coastin.com>
- Date: Fri, 12 Nov 2004 12:28:24 -0800
- To: Francisco Curbera <curbera@us.ibm.com>
- CC: Marc Hadley <Marc.Hadley@sun.com>, Martin Gudgin <mgudgin@microsoft.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Francisco Curbera wrote: > > > >Tom, > >Aren't the flexibility and optimization concerns you bring up covered >within the scope of issue 6? > >Paco > > > > If the sender has to put a wsa:reply to if there is a wsdl response, then it cannot be removed even if the wsdl request/response is mapped to soap/http post request/response. The optimization I refer to is for that case. Tom > > > Tom Rutt > <tom@coastin.com> To: Martin Gudgin <mgudgin@microsoft.com> > Sent by: cc: Marc Hadley <Marc.Hadley@sun.com>, public-ws-addressing@w3.org > public-ws-addressing-req Subject: Re: i028: Implications of the presence of ReplyTo > uest@w3.org > > > 11/12/2004 12:22 PM > Please respond to tom > > > > > > > > >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 >>> >>> >>> >>>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 am speaking of an environment where the flexibility of EPRs is >desired, but the day to day >infrastructure in use is in an exclusively soap/httpPost environment. >As an optimization, the sender may know >the environment it is using, and does not need to send stuff that is >unnecessary. > > > >> >> >>>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 ). >> >> >> >> >I want a world where extraneous stuff not needed for a particular >application of WS:addressing must be sent. > >Some Fujtisu product people desire the ability to optimize and tune for >performance in tighly constrainted infrastructure >environments. > > > > >>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 > > > > > > > > -- ---------------------------------------------------- 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 20:30:39 UTC