[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] RE: BusinessActivityBehavior diagram
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......."
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]