W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2006

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

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
Message-ID: <Pine.GSO.4.64.0602022037220.2145@gnenaghyn.vaevn.se>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:21 GMT