Split / Join and AS4

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

Hi,

The Split / Join feature of ebMS3 Part 2 (CS May 2011) specifies that " Message fragments are individually secured and sent reliably. Message acknowledgments, retries and duplicate elimination apply at the level of message fragments."  At the time we assumed protocols like WS-Reliability and WS-ReliableMessaging would be used for reliable messaging, which provide acknowledgments for sequence (rather than individual messages) and add their own message identifier headers.  Since sequence acknowledgments do not provide NRR, it still specified that ebMS3 Receipts be used to provide non-repudiation of receipt of the ebMS3 message, after reassembly.

With AS4,  the ebMS3 receipts are still used for NRR but have a second purpose to control reliable resending and duplicate elimination, which Core and Part 2 saw as reliable messaging functionality.   The market reality today is that (outside of Japan) all ebMS3 deployments are based on AS4 and use AS4 reception awareness instead of a Web Services reliable messaging protocol.   Some are also using or looking at Split / Join. For this reason there is a need to clarify how Split / Join would work in conjunction with AS4 reception awareness as RM replacement.  Here is a start:

1)  The AS4 Message Retry and Duplicate Detection features apply at fragment level,  as they are replacing the corresponding features of Web Services reliable messaging (also see figure 18 in Part 2) that are not used with AS4.   This means that AS4 Receipts need to be generated and processed for message fragments too,  and not just for the large source message.   The source message and the fragments all have distinct ebMS3 message identifiers,  so there is never any confusion about which message a receipt relates to and whether a receipt relates to a fragment or a source message.

2) Reception Awareness error handling applies at source message level.  This means that an error is generated and returned to the Producer if the large source message is not acknowledged.  One (but not the only) possible reason for such a failure is a situation in which one of the fragments fails, in which case the R-MSH cannot reassemble the source message as it doesn't have all the necessary parts.  Separately from the source message receipts, an S-MSH may also track missing receipts for fragments (if only for trouble shooting),  but such errors are not returned to the producer. They are lower-level, and Producer and Consumer don't even need to know there is any Splitting and Joining.

3) Split / Join specified use of NRO at fragment level, and indirectly at source message level, as the combined set of fragment signatures provide content commitment for the source message.  By contrast, the specification in Part 2 still positioned NRR at the level of the large source message.  This was because Web Services receipts do not provide NRR.  AS4 improves on this and signed NRR receipts for fragments provide large message NRR indirectly, just like using XML Signature with fragments provides indirect NRO for the large source.  This is more consistent and therefore seems cleaner.  The ebMS3 receipt for the large source message is still necessary, but when we have signed AS4 NRR fragment receipts, a Reception Awareness receipt for the large message is sufficient as it only needs to report successful processing by the R-MSH.  This differs from the Part 2 specification assuming Web Services reliable messaging that required a separate NRR for the (possibly very large) source message.  This has an additional practical advantage that the Pmode[].Splitting.FragmentSize now helps provide an upper bound for memory use of the WS-Security module, without requiring any streaming or other memory optimization in the WS-Security implementation.

The above is based on discussion with some implementers (in three continents),  most of which had independently come to the same conclusions.  I'd be interested to know if the TC agrees .. 

Pim van der Eijk