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

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

Received on Tuesday, 31 January 2006 22:15:15 UTC