Re: [ebxml-msg] Re: Use cases for messageOrdering

[Arvola Chan <arvola@tibco.com>]

Marty:

You are correct. Multiple concurrent instantiations should be treated as
separate conversations. They are not relevant to the message ordering issue.

Regards,
-Arvola

-----Original Message-----
From: Martin W Sachs <mwsachs@us.ibm.com>
To: Arvola Chan <arvola@tibco.com>
Cc: Jacques Durand <JDurand@fs.fujitsu.com>; ebxml-msg@lists.oasis-open.org
<ebxml-msg@lists.oasis-open.org>
Date: Friday, November 30, 2001 5:07 PM
Subject: Re: [ebxml-msg] Re: Use cases for messageOrdering



Arvola,

Thank you for providing this information.

Just one point:  Your discussion of multiple concurrent instantiations of a
PIP is presumably not relevant to the message ordering issue since (I
assume) that each instantiation would be a separate conversation.

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 07:53:39 PM

To:    Jacques Durand <JDurand@fs.fujitsu.com>, Martin W
       Sachs/Watson/IBM@IBMUS
cc:    ebxml-msg@lists.oasis-open.org
Subject:    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 <JDurand@fs.fujitsu.com>
To:  'Arvola Chan' <arvola@tibco.com>; Martin W Sachs <mwsachs@us.ibm.com>
Cc: ebxml-msg@lists.oasis-open.org  <ebxml-msg@lists.oasis-open.org>
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:arvola@tibco.com]
Sent: Friday, November 30, 2001 12:03 PM
To:  Martin W Sachs
Cc:  ebxml-msg@lists.oasis-open.org
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 <mwsachs@us.ibm.com>
To: Arvola  Chan <arvola@tibco.com>
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>





----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>