Re: Streaming SOAP and Faults

[Brian Abbott <br...@dommoni.com>]

It seems that if an exception is thrown, the stream should stop at that 
point. So, now you've transmitted an incomplete message. It seems that 
if you want to avoid making major modifications to SOAP, you would need 
to send a fault message immediately following that would in some way 
reference the previous message where the exception was thrown.

-Brian Abbott

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
>
>  
>
>>>The problem is that if I increase the JVM memory, if the request
>>>length increases too, i will have the same problem.
>>>      
>>>
>>Understood. I still don't fully understand how this works in Axis, but
>>if you really need to solve this problem you should dive into Axis'
>>support for streaming messages.
>>
>>I haven't found all the details, but I put what I know on the Wiki.
>>If someone knows more, can they please post it here and on the Wiki?
>>
>>http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=AxisProjectPages/StreamingService
>>
>>    
>>
>
>
>  
>

RE: Streaming SOAP and Faults

[Mark Ericson <ma...@mindreef.com>]

True, but then you have no way of communicating the semantics of the fault.
"Hey, you sent me a bad account #", no the requestor just gets some local
fault stating that they were unable to parse the XML.

 

I agree that the best workaround, although not perfect, is to stream to disk
and then stream that output.  That in a way is a two phase model, streaming
to disk is your 'prepare' if any exceptions occur while streaming you
'abort' by sending a SOAP fault back, if you are successful stream the
buffered stream back as the results.

 

The downside of this approach is latency.  It would have been nice if the
requestor could start processing results before the server has completed
generating them.

 

- Mark

 

  _____  

From: Brian Abbott [mailto:brian@dommoni.com] 
Sent: Saturday, May 15, 2004 6:18 PM
To: axis-user@ws.apache.org
Subject: Re: Streaming SOAP and Faults

 

It seems that if an exception is thrown, the stream should stop at that
point. So, now you've transmitted an incomplete message. It seems that if
you want to avoid making major modifications to SOAP, you would need to send
a fault message immediately following that would in some way reference the
previous message where the exception was thrown.

-Brian Abbott

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
 
  

The problem is that if I increase the JVM memory, if the request
length increases too, i will have the same problem.
      

Understood. I still don't fully understand how this works in Axis, but
if you really need to solve this problem you should dive into Axis'
support for streaming messages.
 
I haven't found all the details, but I put what I know on the Wiki.
If someone knows more, can they please post it here and on the Wiki?
 
http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit
<http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=AxisProjectPage
s/StreamingService> &id=AxisProjectPages/StreamingService