TR: Comment

[MERCEY Jacques <JMercey@MEGA.com>]

>  -----Message d'origine-----
> De : 	LONJON Antoine  
> Envoyé :	lundi 10 juillet 2000 13:41
> À :	MERCEY Jacques
> Objet :	
> 
> Bo Haugen made a very interesting comment about the management of long
> transaction. I took the position that this should not be the focus of
> ebXML. I would like to clarify the point. As far as I can understand, the
> current meta-model offers two levels of contractual exchange: Transaction
> and Business Process definition + Step.
> Transactions define information flows and Partner Roles responsibility in
> managing theses flows. At this level, each party has agreed on what to do.
> This allows both sides to manage their state of the conversation based on
> the contract defined by the Transaction: A customer has sent a Purchase
> Order, he is waiting for an acknowledgment or a refusal (Purchase order
> state: sent). On the other side, the vendor is ready to carry out Purchase
> Order and to send back and acknowledgment or a refusal (Purchase order
> state: received).
> Of course, at the TR&P level, there is a need to manage the identity of
> the current long conversation as a Business Service can carry out multiple
> transactions at the same time. This is where we could find a place for
> long transaction. On both part, there is a need for software that can
> handle TR&P requests and that manages transaction identity. 
> Concerning Business Process Definition, they define Steps. But nobody is
> declared to be responsible to the triggering and management of theses
> Steps. In short, there is no contract between parties to manage the steps.
> Who is responsible to launch the next transaction? In such a case, there
> would be a need of some shared state of the conversation as Bob Haugen
> underlined in his previous comments 
> It seems to me that the attempt to add another concept above Business
> Transaction is the need for an overview that represents what could be done
> (scenario) with an assembly of Transaction. For instance, Offer Goods
> Transaction then Payment Transaction then Delivery Transaction. The “then”
> is not contractual here. No party is responsible of it. It is just a
> proposal to assemble different Business Services.
> The Transaction based contract is more loosely coupled. The common
> implementation between parties is kept at the TR&P level. The step further
> (Business Process Definition) needs an extra coordination feature that
> lives between both parties.
> 
> 
> Antoine LONJON
> Chief Architect
> MEGA International
> 33.1.42.75.40.30
> ALonjon@Mega.com <mailto:ALonjon@Mega.com>
> 
>  
> 
>