Re: SOAP spec.: HTTP binding

----- 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)

Received on Wednesday, 20 December 2000 09:23:02 UTC