OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Title: 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>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC