The transaction Web Service provides operations to enforce the transaction requirements of BPEL activities.
7.5.1
The interface
The transaction Web Service provides a port type for atomic transactions [137] as shown in Listing 7.9.
boolean begin( String transactionID )
String participate ( String transactionID , String soapMsg) boolean commit(String transactionID )
void rollback ( String transactionID )
Listing 7.9: The atomic transaction port type
The operation begin starts a new transaction and creates a new coordination context as defined in WS-Coordination [63]. This operation takes a parameter transactionID that is used to relate messaging activities to the created transac- tion. The returned boolean signals if the creation of the transaction succeeded. The operation participate allows a messaging activity to participate in a previously created transaction. This operation takes the transaction identifier and the SOAP message of the messaging activity as input parameters. It returns the SOAP message after enhancing it with a transaction header that includes the coordination context.
The operation commit runs the completion protocol of WS-AtomicTransaction to commit the transaction that is passed as parameter. The operation rollback rolls back the transaction.
7.5.2
Usage by the process container
To enforce the transactional requirements of a structured activity, the process container intercepts the start and termination of that activity as well as the execution of its nested messaging activities. At these points, the container calls appropriate operations on the transaction Web Service.
Figure 7.10 illustrates the interaction of the process container and the trans- action Web Service to execute the sequence activity debit credit as an atomic transaction.
Four aspect types are involved in the execution of this sequence activity as an atomic transaction: the aspect type for creating a transaction, the aspect type for adding a message to a transaction, the aspect type for transaction commit, and the aspect type for transaction roll back (cf. Table 7.3).
When the sequence activity starts, the begin transaction aspect calls the operation begin on the transaction Web Service and uses the name of the parent scope (the parameter id) of that sequence as a transaction identifier.
Then, for each invoke activity, a container aspect calls the operation partic- ipate and passes the SOAP message of each activity as parameter in addition to the transaction identifier. The transaction Web Service enhances that mes- sage with a transaction header, which includes the coordination context of the transaction that has the identifier id.
TXWS participatebegin Process Container <process> ... <sequence> <invoke operation=“debit“/> <invoke operation=“credit“/> </sequence> ... </process> <invoke operation=“debit“/> <invoke operation=“credit“/> Begin Aspect Partner 1 Partner 2
Aspects Middleware Services
commit Participate Aspect Commit Aspect <sequence> <sequence> </sequence> id id id, SOAP id, SOAP SOAP + context Rollback Aspect fault rollback id
Figure 7.10: Interaction of the container and the transaction service
When the sequence activity completes, a commit aspect calls the operation commit on the transaction Web Service. Consequently, the coordinator of the atomic transaction initiates the 2-Phase-Commit protocol to decide on the out- come of the transaction.
When a fault is raised during the execution of a transactional activity (e.g., in the execution of the invoke activity that calls the operation credit ), a container aspect catches that fault and calls the operation rollback on the transaction Web Service to undo the transaction (as shown in Listing 7.3).
7.5.3
The implementation
The transaction Web Service consists of two main components: the coordination framework, which implements WS-Coordination and WS-AtomicTransaction and the transaction framework, which manages the transactions internally.
Apache Kandula [10] is used for the coordination framework. It is an Open Source implementation of WS-Coordination and WS-AtomicTransaction on top of Axis. Kandula provides a set of Web Services such as the activation ser- vice, the registration service, and the coordinator. Apache Geronimo [9] is used for the transaction framework. Apache Geronimo implements the package javax.transaction.
When the operation begin is called, the transaction Web Service creates a transaction object using the transaction framework. Moreover, it creates a new distributed activity using the activation Web Service of Kandula. Then, it stores the coordination context returned by the activation service in the created transaction object, which is put into a map with the transaction identifier as key.
When the operation participate is called, the transaction Web Service re- trieves the transaction object from the map. Moreover, it enhances the SOAP message parameter with the coordination context of that transaction.
When the partner Web Service receives the enhanced SOAP message, it registers as participant for Durable2PC at the registration service. The latter returns a reference to the coordinator.
When the operation commit is called, the transaction Web Service retrieves the transaction object and uses Kandula to register for the completion protocol. The registration service returns a reference to the coordinator, to which the transaction Web Service sends a commit message. Once the coordinator receives that message, it runs the 2-Phase-Commit protocol with all previously registered participants. After that, either all participants commit or the transaction is aborted. Finally, the transaction object is removed from the map so that the respective transaction identifier can be used by other transactions.