RE: [ebxml-bp] RE: BusinessActivityBehavior diagram

["Jean-Jacques Dubray" <jeanjadu@Attachmate.com>]

One more time, I would caution not to "tweak" the business the business
transaction protocol. The BTP was designed to guaranty state alignment
which is an absolute condition for being able to carry out business
transaction. 

By changing the nature from signal (structure known to the BSI with
explicit meaning) to message (structure unknown to the BSI with no
explicit meaning to the BSI) we are removing the ability to achieve
state alignment. If we use a message instead of a signal we will have to
"ack the acks".

So for me it is very clear that we cannot re-assess this question
without breaking the very nature of the business transaction protocol.

JJ-

-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] 
Sent: Friday, June 04, 2004 9:45 AM
To: Jean-Jacques Dubray
Cc: martin.me.roberts@bt.com; Robert.Haugen@choreology.com;
ebxml-bp@lists.oasis-open.org
Subject: Re: [ebxml-bp] RE: BusinessActivityBehavior diagram


>Dubray: I said that a collaboration is merely observed and not
executed. But
>clearly the BSI has to handle the business transaction protocol. So the
>BSI is a program that "executes". However, it does not "execute" the
>collaboration. So I think that Martin and I are in perfect agreement. 
>
>For me, the most important signal in BPSS is the "Acceptance"
>acknowledgement. The receipt acknowledgement works as a centralized
>"data scrubber" avoiding sending unnecessary data to the application
>(but this remains a non critical operation, i.e. BPSS would work just
as
>well without it, it would put more burden on the application, that's
>all). 
>
>I like the signals or errors to be explicit. I think that in general
>timeout should be reserved to identify communication problems
>(transport, end points, ...), not for generating business errors. 
>
mm1: Martin's diagrams and points, as well as JJ's, give us some good 
fodder to include in providing a 'picture' of the BSI for the 
implementers.  In addition, as Anders has indicated, we will need to 
reassess if the Acceptance Acknowledgement is a signal or a business 
message, because of its role in contract formation.  Perhaps he can 
comment on this more fully.  Thanks.

"The agreement between two parties should spell out what the times mean.
Need to outline explicitly what tests have been made when a ReceiptAck
made. Sending a ReceiptAck is a statement made by the receiver: I sign
of to have performed checks a,b,c, .........ReceiptAck is well-defined.
Addressee receives message only. Accpeptance is the problematic child
since it obsfuscates the moment when acceptance is concluded......."