Thanks for the response Chris,
Nice to hear that I'm not alone in doubting that buffering of entire
SOAP messages before sending is a must at the server!
I just read something interesting ("Investigating the Limits of SOAP
Performance for Scientific Computing" found at
http://www.extreme.indiana.edu/xgws/papers/soap-hpdc2002/soap-hpdc2002.pdf)
which I think may explain why some people say that buffering of the entire SOAP
message is done at the server.
It seem to be, as you say Chris, a SOAP implementation issue. SOAP
implementations typically specify the HTTP Content-Length header in the
response message. If the response is sent in one piece, the server may
need to buffered the entire message to calculate the HTTP Content-Length
header. However, HTTP 1.1 (http://www.ietf.org/rfc/rfc2616.txt) allows
for "chunking" of a response:
"3.6.1 Chunked Transfer Coding
The chunked encoding modifies the body of a message in order to
transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer containing entity-header fields. This
allows dynamically produced content to be transferred along with the
information necessary for the recipient to verify that it has
received the full message."
So I guess that if the SOAP processor supports HTTP chunking, it should
be quite possible to read features dynamically from a database and
stream the SOAP response back to the client as chunks, ending the stream
by a zero-length chunk.
This should also work when using SOAP with Attachments (SwA) which is
recommended by OGC for responding with binary content (such as a JPEG
map to a WMS GetMap request).
By the way, a fairly recent (December 2005) and nice overview of
technologies for SOAP and binary data, "Attachments in SOAP Messages -
An Oracle white paper", can be found here:
http://www.oracle.com/technology/tech/java/oc4j/pdf/web-services/ws-attachment-pcho.pdf
Regards,
Jonas
On Thu, 2006-06-01 at 19:25 -0400, Chris Holmes wrote:
>
> Jonas Johansson wrote:
> > Hi list,
> >
> > Maybe someone here has some knowledge on SOAP. I have been looking into
> > the OGC move towards W3C Web Services standards for geospatial services
> > and I have a question regarding performance when using SOAP.
> >
> > It is mentioned by many that large data sets is a performance issue when
> > using SOAP messaging because the entire message need to be buffered at
> > the server before sending a response to a client. Is this true? In that
> > case, why?
> You know, I read something similar as well about SOAP, and I had the
> same reaction. I couldn't think of any fundamental reason that such a
> thing would be true (though there very well could be), I took it to mean
> more that it's just how most people implemented SOAP stuff.
>
> >
> > Can't a SOAP enabled WFS server simply start sending a SOAP response
> > message in a streamed fashion when responding to a WFS GetFeature
> > request to include GML that is dynamically generated from a database,
> > potentially delivering thousands of gigabytes of data encoded in the
> > SOAP message body?
> That's definitely what we're going to do with GeoServer. We'll have to
> do it for WFS 1.1, and all you do is wrap SOAP headers around your
> response. I see no reason you can't just stream out as normally - but
> perhaps OGC is doing something different than how SOAP is supposed to
> work? I don't really know, so don't go by my word, and let me know if
> you figure out that there is some limit. But I'm with you, I see no
> reason you can't just stream it in the same way.
>
> best regards,
>
> Chris
>
> >
> > Thank you for any help!
> >
> > Jonas J
> >
> >
> >
> > _______________________________________________
> > Geotools-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
