Title: RE: [ebxml-msg] Re: Use cases for messageOrdering
Jacques:
Let me quote one particular subsection in the RNIF 2.0
specification:
2.6.6 Handling Retries and Late
Acknowledgments
As established earlier, the trading partner sending an
action message retries the message until either a Signal (Receipt Acknowledgment
or Exception) is received or a timeout condition occurs. Hence, the receiver
MUST be prepared to receive the same action message more than once. In such a
case, if the action requires a ReceiptAcknowledgment, the Receipt Acknowledgment
(or Exception if there is a failure)MUST be resent. Also, as mentioned earlier,
the PIP choreography is independent of the transfer or transport mechanisms.
Therefore, it is possible that for a given request, the Receipt Acknowledgment
can arrive after the response message. This MUST NOT be deemed as an
out-of-order message. If the response is received before the Receipt
Acknowledgment and the request action requires non-repudiation of receipt, then
any of the following suggested approaches MAY be followed.
A response that arrives before the Receipt Acknowledgment
MAY either be queued for processing until the Receipt Acknowledgment is received
or processed immediately. If the response is processed immediately, then the
process SHALL NOT be completed until the Receipt Acknowledgment is received,
since the Receipt Acknowledgment contains the digest information for
non-repudiation of receipt. These approaches are suggestive only and the
implementer is free to choose a similar approach as long as the result is the
same (i.e., the response SHALL NOT be rejected unless a timeout occurs waiting
for the Receipt Acknowledgment).
Thus, the RosettaNet Implementation Framework does not assume
that messages will always arrive in the same order as being sent. The receiver
is expected to do some bufferring to deal with messages that arrive out of
sequence, rather than raising exceptions immediately.
The sequence diagrams you have seen in RosettaNet PIP
specifications are with respect to a single instance of that PIP's execution. I
don't recall PIP specifications stating whether multiple instantiations can be
active concurrently but I believe typical implementations would allow concurrent
instantiations of the same PIP.
Regards,
-Arvola
-----Original Message-----
From:
Jacques Durand <>
To:
'Arvola Chan' <>; Martin W Sachs <>
Cc:
<>
Date:
Friday, November 30, 2001 4:24 PM
Subject: RE: [ebxml-msg] Re:
Use cases for messageOrdering
Comments in line,
Jacques D.
-----Original Message-----
From:
Arvola Chan [mailto:]
Sent: Friday, November 30, 2001 12:03 PM
To:
Martin W Sachs
Cc:
Subject: [ebxml-msg]
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.
<JD> --- I guess the case for RosettaNet is more an
implementation one:
a PIP implementor may interpret
the exchange diagrams as having a strict
sequence
order semantics: so s/he may define a business process that actually
expects to receive the Receipt of the previous action,
before receiving
and processing the Response Action
from the same party (I would not blame her for this).
Shouldn't then RosettaNet spec be
more explicit
that this (total) order does not have to be respected? there is
some ambiguity here. After reviewing my PIP cases, I
agree that order here
is actually not required for a
sound business semantics.
Remains that, if I am not
mistaken, there is room for a strict interpretation
(and that alone makes a case for ordering...)
As for other detailed "ordering" use cases, some have been reported
by
SonicSoftware in previous mails, I must have lost
these. </JD>
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
-----Original Message-----
From:
Martin W Sachs <>
To: Arvola
Chan <>
Date: Friday, November
30, 2001 11:02 AM
Subject: Use cases for
messageOrdering
>
>Arvola,
>
>I hope that you will look over and
reply to this morning's thread among
>Shimamoto-san, Dan Weinreb, Jacques Durand and me since RosettaNet
examples
>have been given.
>
>Are there valid use cases where a
sequence of messages within a
>conversation is sent
without responses but the recipient must receive them
>in the order in which they were sent? Why wouldn't business-level
responses
>be prescribed for such a
situation?
>
>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
>***************************************************************************
**********
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
