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:

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

Received on Tuesday, 31 January 2006 16:18:32 UTC