Not technically -- but if it will handle larger message sizes with the constraints set by the SOAP specification with regards to fault handling, then it is a step in the right direction.
--Peter
On May 15, 2004, at 3:40 PM, Brian Abbott wrote:
If you where to do that, I dont think it's any longer considered "streaming", is it?
Brian Abbott
Aleksander Slominski wrote:
Mark Ericson wrote:
Nelso, streaming SOAP is certainly a good idea for addressing some
scalability issues. However it also introduces an interesting challenge.
Say you have a service that processes some input and starts streaming
output immediately. As it is generating the response SOAP message every
byte that is output goes almost immediately to the wire (ignoring caching
and/or framing for a second). Now say sometime into the result an error
occurs, a database exception, or perhaps a problem in the input stream, oops!
The result SOAP stream has already commited itself to be a SOAP body, it
can no longer turn itself into a fault because those bytes have gone out
over the wire.
What to do!? In some ways it would have been nice if the SOAP protocol
had put the fault at the end rather than the beginning (SOAP footers?)
SOAP 1.2 seems to allow a SOAP fault to appear within a child of the body,
but then states "the element has no SOAP-defined semantics"
There are certainly problems I would also like to use streaming for, but
what to do about faults?
Mark,
i raised this problem multiple times in past. the only reliable and interoperable solution i know is to buffer whole output :(
alek
