Split / Join and AS4

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