- From: Yves Lafon <ylafon@w3.org>
- Date: Thu, 2 Feb 2006 20:40:08 +0100 (MET)
- To: Christopher B Ferris <chrisfer@us.ibm.com>
- cc: Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, xml-dist-app@w3.org
On Wed, 1 Feb 2006, Christopher B Ferris wrote: > Yves, > > Actually, I disagree. I don't see where in WSDL it allows you to > optionally > send a response when you have a wsdl:operation with both a wsdl:input and > wsdl:output Why in WSDL? If we _always_ use WSDL, then we should also remove mustunderstand from requests. If we decide that every Web Services MUST have a WSDL description, then yes, as the change is recorded there, the client should always know what to expect. > > Cheers, > > Christopher Ferris > STSM, Emerging e-business Industry Architecture > email: chrisfer@us.ibm.com > blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440 > phone: +1 508 377 9295 > > Yves Lafon <ylafon@w3.org> wrote on 01/31/2006 05:11:12 PM: > >> On Tue, 31 Jan 2006, Christopher B Ferris wrote: >> >>> Yves, >>> >>> I don't think that changing the binding specification to permit an >>> optional response >>> will necessarily change the behavior of an application, whether > described >>> by WSDL >>> or not. >> >> No but it will allow the application to change its behaviour while still > >> conforming to the same description. >> >>> >>> Cheers, >>> >>> Christopher Ferris >>> STSM, Emerging e-business Industry Architecture >>> email: chrisfer@us.ibm.com >>> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440 >>> phone: +1 508 377 9295 >>> >>> xml-dist-app-request@w3.org wrote on 01/31/2006 11:15:42 AM: >>> >>>> >>>> On Tue, 31 Jan 2006, Christopher B Ferris wrote: >>>> >>>>>>> pretty close to correct as stated, both as general philospophy and >>> as >>>>>>> specifically applied to HTTP (see especially [3]). Thanks. >>>>>> >>>>>> My position is that replacing Request/Response by something that > has >>>>>> options. If you have a program that use Request Response and is > hard >>>>> wired >>>>>> to always have a response, then changing to "ah you _may_ have a >>>>> response" >>>>>> is a big conformance change. >>>>> >>>>> Changing the **binding** to r-o-r doesn't necessarily change the >>> semantics >>>>> of the application that sits above the SOAP processing/transport >>> binding. >>>>> If the application expects a response, then clearly the application > at >>> the >>>>> other end is obligated to send one, and the binding can accomodate. >>>>> Nothing >>>>> changes there. I don't see that as a conformance change. Clearly, > the >>>>> application >>>>> would be broken if it didn't honor the application-level semantic >>> embodied >>>>> in its contract (e.g. WSDL). We aren't changing that. >>>> >>>> Well, suppose you have a financial service, doing request/response. >>>> Now you change it a bit by not always returning a reply (let's say, > if >>>> under a certain amount, no need to give an ack). The overall > behaviour >>> is >>>> the same, the contract is the same (not the wsdl level contract). >>>> But if a client expect to always have an ack, and receive nothing, > what >>>> will happen, report an error, then stop the transaction at the bank? >>>> The serve sill say "I honored the contract, as request reply is > request >>>> optional reply now, so it's the client fault" while the client will > say >>>> "no, it's is request reply so it's the server fault". >>>> >>>> >>>> >>>>> >>>>>> >>>>>> Also if we push a bit the optional request/optional response, to do >>>>>> something like request*/response*, we define a MEP that covers all >>> kind >>>>> on >>>>>> interaction that may happen between two nodes (including > multicast). >>>>>> In that case, MEPs are no longer useful and should be removed. >>>>> >>>>> I'm not going to argue with this point, because I have made a > similar >>>>> argument >>>>> in the past. But frankly, at this point they become "mostly > harmless" >>> and >>>>> hence, >>>>> to make the changes less substantial, we can, IMO, leave them be >>> without >>>>> creating >>>>> any problems. >>>>> >>>>>> >>>>>> The fact that some implementation may be using one way messaging in >>> HTTP >>>>> >>>>>> in the current framework needs to be addressed, but if it disrupts >>> the >>>>>> current understanding of MEPs, then this case needs to be addressed >>> with >>>>> >>>>>> the implementers to fix issues like the a-priori knowledge from the >>>>> client >>>>>> of the MEP used. And the fact that the one way MEP is done as "fire >>> and >>>>>> forget" or with ackowledgement that the message has been received > is >>>>> just >>>>>> a property of the "transport" used, but it doesn't change the > overall >>>>>> meaning of the MEP a the SOAP level. >>>>>> >>>>>> -- >>>>>> Yves Lafon - W3C >>>>>> "Baroula que barouleras, au tiéu toujou t'entourneras." >>>>>> >>>>> >>>> >>>> -- >>>> Yves Lafon - W3C >>>> "Baroula que barouleras, au tiéu toujou t'entourneras." >>>> >>> >> >> -- >> Yves Lafon - W3C >> "Baroula que barouleras, au tiéu toujou t'entourneras." > -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Thursday, 2 February 2006 19:43:10 UTC