Re: Regrets for 1 Feb XMLP Telcon (was: Re: Comments on the "drop response-only" Part 2 draft)

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

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."