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
