Behavior of compensating transaction under "initiator" and "participant" role

A question about how "orchestration" and "co-ordination" work together.

Within a BPEL/BPML process, you can put a transaction scope around a block 
of activities, and also attach another block of activities called 
"compensating transaction", which is supposed to undo the "transaction".  I 
would like to compare the behavior of this process when it is playing the 
"transaction initiator" role vs the "transaction participant" role.

If this process is the "TRANSACTION INITIATOR" (ie: the top-level 
transaction), then when this block is entered, the orchestration engine 
will make a call to the transaction co-ordinator to create a new 
transaction and obtain a transaction id.  For every <invoke> within the 
block, the transaction id will be embedded in the SOAP header.  Also, the 
"compensating transaction" will never be invoked automatically by the 
orchestration engine.  It can only be invoke "explicitly" by another 
application-level flow (e.g. by the exception handling flow logic).

However, if this process is the "TRANSACTION PARTICIPANT" (ie: being 
invoked by another application which already have a transaction context), 
then when this block is entered, the orchestration engine will make a call 
to the transaction co-ordinator to enroll itself as a participant of the 
outer transaction.  Lets say after some time the transaction coordinator 
start the 2-phase commit handshaking protocol.  When the transaction 
co-ordinator ask for "prepare", the orchestration engine will simply 
respond a "prepared" without doing anything.  When the transaction 
co-ordinator ask for "commit", the orchestration engine will just respond a 
"commited", again without doing anything.  However, when the transaction 
co-ordinator ask for "cancel", the orchestration will execute the 
"compensating transaction" and then respond a "cancelled".  One key 
difference is now the "compensating transaction" will be automatically 
invoked by the orchestration engine as part of the 2 phase commit 
handshaking.  The compensating transaction shouldn't be invoked by the 
application flow explicitly.

Is this a correct understanding of how orchestration and co-ordination work 
together ?

On the other hand, can a BPEL process participating in an outer transaction 
specify a block of activities for "prepare", another block for "commit", 
another one for "cancel" ?

Thanks in advance,

Best regards,

Ricky

Received on Friday, 7 February 2003 01:15:53 UTC