OASIS ebXML Messaging Services TC

 View Only

[ebxml-msg] Re: Use cases for messageOrdering

  • 1.  [ebxml-msg] Re: Use cases for messageOrdering

    Posted 11-30-2001 16:01
    
    Thanks, Arvola, that's what I assumed.  So RosettaNet is not a use case
    that demonstrates the need for message ordering in the MSH.
    
    Given that the UMM and BPSS permit design of BusinessTransactionActivities
    that have no business level signals/responses can you say anything about a
    design practice that doesn't use business level signals but expects that
    the messages will be received in the order sent? In other words, are there
    valid use cases (including good design practice) for this that justify the
    message ordering function in the MSH?
    
    Regards,
    Marty
    
    *************************************************************************************
    
    Martin W. Sachs
    IBM T. J. Watson Research Center
    P. O. B. 704
    Yorktown Hts, NY 10598
    914-784-7287;  IBM tie line 863-7287
    Notes address:  Martin W Sachs/Watson/IBM
    Internet address:  mwsachs @ us.ibm.com
    *************************************************************************************
    
    
    
    "Arvola Chan" <arvola@tibco.com> on 11/30/2001 03:03:19 PM
    
    To:    Martin W Sachs/Watson/IBM@IBMUS
    cc:    <ebxml-msg@lists.oasis-open.org>
    Subject:    Re: Use cases for messageOrdering
    
    
    
    Marty:
    
    RosettaNet PIPs conform to business transaction patterns defined in the
    UMM.
    They make use of business signals (Receipt Acknowledgments) to indicate
    successful receipt of business documents. Sometimes, the Receipt
    Acknowledgment signal also serves the function of providing non repudiation
    of receipt.
    
    All asynchronous RosettaNet PIPs that I am aware of make use of Receipt
    Acknowledgments. The only synchronous PIP in existence, PIP2A9, fits into
    the UMM query-response pattern, so there is a synchronous response.
    
    When using BPSS to model binary collaborations, transitions and guards
    govern the order in which BusinessTransactionActivities are executed.
    Typically, one BusinessTransactionActivity would have to be successfully
    executed before another one is started (except when the fork construct is
    used).
    
    If the RequestingBusinessActivity and/or RespondingBusinessActivity within
    a
    BusinessTransactionActivity specifies a timeToAcknowledgeReceipt, then
    ReceiptAcknowledgments will have to be used and the
    BusinessTransactionActivity cannot be considered successful until the
    Receipt Acknowledgment has been returned.
    
    With UMM and BPSS, it is possible to design BusinessTransactionActivities
    that have no business level signals/responses (especially when there are no
    NRR requirements). In practice, all RosettaNet PIPs have business level
    signals/responses.
    
    Regards,
    -Arvola