streaming and message storage [Re: Streaming SOAP and Faults

[Aleksander Slominski <as...@cs.indiana.edu>]

Mark Ericson wrote:

> 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.
>
hi Mark,

if the probability of fault happening during serialization/streaming is 
very low (as in case when you send response generated by "always" 
correct generator) then it may be worth risk to have streaming. and this 
is in the matter of fact how i did this in XSOAP1 - if on the sending 
side there was a serialization error (you were sending a bad bad Java 
Bean) it just closed connection and logged locally a fatal error. it 
worked well but never was an ideal solution ...

anyway streaming is much much harder to do with WSS and i think pretty 
much impossible with WS reliable messaging/delivery if you want 
immediate connection w/ streaming (as you need first to store message 
before you start sending it) but at least in this case sending can be 
async, streamed, and even pipelined when actual sending happens (as you 
know how many messages will go to the endpoint an exactly how messages 
will look).

>  
>
> I agree that the best workaround, although not perfect, is to stream 
> to disk and then stream that output. 
>
another way is to store messages in DB and stream them from there

> 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.
>
yes. i expect this to be typical for WS-ReliableMessaging (and 
friends/foes) implementations ...

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

this is less of concern when you do async communication right?

thanks,

alek

>  
>
> ------------------------------------------------------------------------
>
> *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&id=AxisProjectPages/StreamingService <http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=AxisProjectPages/StreamingService>
>>
>> 
>>
>>    
>>
> 
>
> 
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay