BPEL and transactions - part 5 (last part)

About transaction standards and protocolls. Here is part 5 of "BPEL and transactions".

Transaction standards and protocols

The execution of distributed transactions poses new requirements to a transaction environment. Services have to be executed and managed in heterogenous systems.

Most transactions standards are based on the Distributed Transaction Coordinator Model.Those standards are distinguished from another by the length of the transaction. Some standards are suited for short-lived transactions, because during execution resources are blocked. Others are more suited for long transacton times.

Identification of a transaction by transaction context

The context of the transaction has to be managed during the existence of the transaction and also it must be broadcasted to all engaged systems.

The occurence of an error may not lead to inconsistencies in many different systems.

Transaction standard:  Web Service Atomic Transaktion (WS-AT)

With the adoption of WS-AT the ACID properties can be implemented over distributed services on different application servers. As resources are locked during execution, WS-AT is only suitable for short-living processes. The WS-AT standard is supported by different middleware manufacturers.


Web Service Atomic Transaktion (WS-AT) in Oracle SOA Suite

The Oracle Weblogic Server 11gR1 (10.3.3) and Oracle SOA Suite 11g R1 PS2 (11.1.1.3) support the WS-AT standard version 1.2. For being able to use WS-AT on a WLS, the domain must be configured for WS-AT. The start of the transactions has to be set through a property in the BPEL process and at the references WS-AT has to be activated. When calling external references the transaction participation has to be transfered.

Transaction participation

Never: the service executes in an own transaction
Supports: the service participates at the transaction
Mandatory: the service participates at the transaction. If there is no transaction available, an exceptio message/fault is thrown.

Other error options:

-system errors
-deadlocks
-protocol errors
-network errors
-hardware errors
-timeout

Error handling when the coordinator fails

Before the sending of the prepare message, all participants must be logged. The response message of all participants must also be logged. With the logs the coordinator can restart at the point of failure.

Error handling when a participant fails

All requests are logged, just like the response messages.With the logs the coordinator can restart at the point of failure.

Summary

With the adoption of WS-AT the ACID properties can be implemented over distributed services on different application servers. All participants must support the WS-AT standard. If possible distributed transactions should not be too complex. Frequently a transaction, which is distributed over different heterogenous systems and products is complex and error-prone. Local transactions should be use where it is possible.