Streaming versus Store-and-Forward

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Streaming versus store-and-forward

The decision to "stream" or to "store-and-forward" can be considered
an implementation aspect that doesn't need to be standardized, as
Jacques noted in
http://lists.oasis-open.org/archives/ebxml-msg/200802/msg00047.html in
response to Ian's message on node types in
http://lists.oasis-open.org/archives/ebxml-msg/200802/msg00043.html
Here is some discussion on the relevant advantages of "streaming"
versus "store-and-forward".  

Here's an attempt to compare the two:

Advantages of streaming (compared to store-and-forward):
- The intermediary only needs to provide a routing function, it does
not need to provide temporary storage for messages. The more data
flows through the intermediary, the leaner the system that provides
the ebMS intermediary function can be. 
- The intermediary can start forwarding the message immediately after
having scanned the SOAP header for ebMS routing data. If the message
is very large (and not "chunked" using some to be defined message
chunking protocol) and/or there are multiple cascaded
intermediaries, this reduces end-to-end latency.  
- The intermediary can act as a "synchronous" intermediary, using the
back-channel on the incoming HTTP connection to relay incoming content
on the outgoing HTTP connection.  This content can include SOAP
faults, any other protocol error messages, HTTP status codes, SOAP
header responses, and even response business messages. Note that 
streaming does not imply, but enables synchronous (see separate note).

Advantages of store-and-forward (compared to streaming):
- The intermediary can act as a buffer.  When there is much less
bandwidth for the outcoming connection than there is for the incoming
connection, the intermediary can temporarily queue the incoming
messages. In the extreme case where the outgoing connection can not be
established or is dropped, the intermediary can act as a temporary
buffer and provide transport-level retries to forward the incoming
message as and when the next MSH becomes accessible. 
- Disaster recovery: assume a disaster happens to an ebMS 3.0 endpoint
that receives incoming messages via an intermediary. Its reliable
messaging component may have acknowledged some messages that it has
not yet delivered to its backend applications.  Suppose a stand-by MSH
takes over within some SLA-defined interval. It can notify the
intermediary to adapt its routing tables and request it to resubmit
all recent messages to ensure they are all processed.  (Alternatively, the
Receiver could ask all its trading partners to resubmit messages, but
if the failed MSH receives messages from hundreds or thousands of
other message handlers, reloading them from the last intermediary is
more convenient). 

Note that "MEP Bridge" from push (from sender to intermediary) to pull
(by receiver from intermediary) requires "store-and-collect"
functionality. So I assume most ebMS 3.0 intermediaries to implement
and support temporary storage at the intermediary, and if they need to
support if for store-and-collect they might as well support it for
store-and-forward. The "streaming" mode seems to be an optimization
in general but is a pre-requisite for synchronous intermediaries.