Interesting issues concerning bindings

[Henry Lowe <hlowe@omg.org>]

Hi,

As perhaps not all of you are on the XP list, I thought I'd forward 
this message as it has some interesting use cases which impact bindings 
to underlying transport protocols.

Strictly FYI -- I'm not pushing this, but they are things we may want 
to do, too.

Best regards,
Henry
---------------------------
>Resent-Date: Wed, 20 Dec 2000 09:23:14 -0500 (EST)
>From: "John Wilson" <tug@wilson.co.uk>
>To: "'Kevin Koch'" <Kevin.Koch@realLegal.com>, <xml-dist-app@w3.org>
>Date: Wed, 20 Dec 2000 14:22:40 -0000
>Organization: The Wilson Partnership
>X-Mailer: Microsoft Outlook Express 5.00.2314.1300
>Subject: Re: SOAP spec.: HTTP binding
>Resent-From: xml-dist-app@w3.org
>X-Mailing-List: <xml-dist-app@w3.org> archive/latest/1142
>X-Loop: xml-dist-app@w3.org
>Sender: xml-dist-app-request@w3.org
>Resent-Sender: xml-dist-app-request@w3.org
>List-Id: <xml-dist-app.w3.org>
>List-Help: <http://www.w3.org/Mail/>
>List-Unsubscribe: <mailto:xml-dist-app-request@w3.org?subject=unsubscribe>
>
>
>----- Original Message -----
>From: Andy Neilson <aneilson@webplan.com>
>To: 'Kevin Koch' <Kevin.Koch@realLegal.com>; <xml-dist-app@w3.org>
>Sent: 18 December 2000 23:03
>Subject: RE: SOAP spec.: HTTP binding
>
>
>> I agree with this comment. The requirement that the HTTP binding specify
>the
>> success or failure of the request as the HTTP status limits seems to
>presume
>> a particular processing model in which you know the overall success or
>> failure status before you start returning any response (i.e., you are
>using
>> an in-memory model like a DOM).
>>
>> I have been developing SOAP processors where:
>>   - performance is critical
>>   - memory must be constrained, and
>>   - the request and/or response size may be very large.
>
>I have this problem too. Currently neither XML-RPC nor SOAP provide
>satisfactory solutions.
>
>There are at least two situations in which a server may want to start to
>send the response before having read the while of the request:
>
>1/ In memory constrained situations
>
>2/ In performance critical applications where it is necessary to minimise
>latency.
>
>As well as issues with HTTP result codes there are more general lacunae in
>the SOAP spec:
>
>a) There is no way of reporting the presence of a value in a response which
>the server is unwilling or unable to represent without returning a Fault and
>it is impossible to return a Fault if the result has been partially sent.
>
>b) It is impossible to tidily abort a response once part of it has been
>sent.
>
>One way that case a) turns up is when the  response contains an object that
>the server doesn't know how to serialise. It's possible that this isn't a
>problem to the client. However the only option the server has is to return a
>Fault. However the server has to examine the whole of the response to see if
>such a problem exists before it can send the first character of the SOAP
>response.
>
>If SOAP had a way of embedding a non fatal error in a response then it would
>be a solution to case a). (i.e. an element that said "I didn't understand
>this bit of the response, if it's a problem for you then this is a failure,
>otherwise ignore it")
>
>If SOAP had what is effectively an exception mechanism (i.e. en exception
>element followed by all the close element tags to make the document well
>formed) then this would be a solution to case b).
>
>In the absence of any help from the SOAP spec the only solution to these
>problems that I can think of is for the server to brutally close the
>connection in mid response - this is not really desirable;)
>
>It is possible that these issues arise from application domains that SOAP is
>not intended to address, of course.
>
>My own inclination is to look at something build on a subset of XML-RPC
>(with some error reporting extensions) for highly memory constrained
>applications.
>
>John Wilson
>The Wilson Partnership
>5 Market Hill, Whitchurch, Aylesbury, Bucks HP22 4JB, UK
>+44 1296 641072, +44 7976 611010(mobile), +44 1296 641874(fax)
>
>