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

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.

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