dutchman's log

« Blogging with Zoundr... | Main | Distributed transact... »
pageicon Monday Sep 01, 2008

Distributed transaction sample: part 1 - introduction

This and the next couple of entries in this log are about execution of distributed transactions involving Java CAPS BPEL, EJB web services, WCF (.NET Windows Communication Foundation) web services, and an Oracle database. System and environment setup and creation and running of a sample application will be discussed.

Java and WCF interoperability is the subject of Web Services Interoperability Technologies (WSIT) (previously known as Project Tango), a Sun-led project in which Microsoft and Sun work together to ensure web services based interoperability between the two environments. You can find more information on WCF and Java web services interoperability on the WSIT web site.


What is a transaction?

Lots of information about transactions is available on the Internet. A possible starting point for more information is Transaction Processing.

Just as a short recap:

A transaction is a unit of work which can consist of various actions. This unit of work must either be executed entirely, or not at all. A transaction must have ACID properties, that is, it must be A tomic, C onsistent, I solated, and D urable.
  • Atomic means that the transaction is executed entirely or not at all.
  • Consistent means that the data underlying the transaction is in a consistent state before the transaction and when the transaction has finished (successfully or not).
  • Isolated means that the actions in the transaction are executed in isolation. The outside world doesn't see the results until the entire transaction has finished.
  • Durable means that the effect of the transaction is persistent. It does not disappear, it survives system restarts, and will not be undone (unless by another transaction).
A simple example of a transaction is the simplified form of a money transfer. In this example, the transaction consists of two actions. In the first action the money is removed from your bank account; in the second action the money is added to the target account. These two actions must be executed in a transaction. See why this transaction must have the ACID properties:
Atomic: You would not want the money to be taken out of your account, and then not added to the target account. The bank does not want the target account to receive the money unless it is also removed from your account. The two actions must either be executed both, or no action must be executed at all. The transaction must be atomic.
Consistent: It would be bad if an amount is taken out of your account, and a different amount is added to the target account. The amounts must be the same; the data must be consistent.
Isolated: When someone looks at the two bank accounts he must either see the money on your account, or on the target account. He must never see your account with less money while the money is not yet added to the target account (I told you this is a simplified form of a money transfer...), and he must never see the money added to the target while it is not yet deducted from your account. The transaction must appear to be isolated.
Durable: Once the money is transferred, the result of the transfer must be persistent. Your account and the target account should not change (unless by another transaction). The transaction must be durable.


Distributed transactions are transactions that execute their actions in different environments, possibly (likely) running on different machines. Ensuring that distributed transactions have ACID properties is more complex than doing this for transactions that run in a single, non-distributed environment.


The sample

The sample application that will be dealt with in these log entries does not do anything useful, except demonstrate transactional capabilities involving Java CAPS 6, EJB web services, WCF, and Oracle.


The example application looks like this:



Sample Distributed Application



The sample implements a distributed transaction that is executed by several actions in several different environments.
SoapUI is used to initiate the BPEL business process in Java CAPS.

The BPEL process starts the transaction and, when all required actions are executed, ends it. The transaction can be ended successfully, in which case it will be committed, or it can be terminated with an error, in which case it will be rolled back.
The actions to be executed by the BPEL process are determined by values in the WSDL used to invoke the BPEL process. Transaction commit or rollback is also determined by a value in the WSDL.

Inside the transaction, operations provided by a WCF service are invoked. These operations do some arithmetic and store rows in an Oracle database. Every invocation of such an operation is part of the transaction started by the BPEL process. When the transaction is committed, the updates to the database should be made permanent; when the transaction is rolled back, the updates to the database should be discarded.

The various parts of the transaction will write messages to the system log (GlassFish) or the console screen (WCF). By checking these messages and the resulting data in the Oracle database, correct working of the entire distributed transaction can be verified. When the transaction is committed, the database should contain the rows written during the transaction; when the transaction is rolled back, these rows should not be present.

More details are to be found in this log, in the entries describing how the sample was built.


Working around some limitations

This example was built using the GA release of Java CAPS 6 for the Java CAPS/GlassFish part. To communicate with external web services, the BPEL module uses the HTTP Binding Component (HTTP-BC). In the version of Java CAPS used, the HTTP-BC does not support SOAP 1.2. The WCF service uses SOAP 1.2, so direct communication is not possible. To overcome this limitation, an EJB was created that implements a SOAP 1.1 interface, and is client for the SOAP 1.2 WCF service. This EJB implements exactly the same operations with the same parameters as the WCF service. It picks up the parameters of the input requests, copies them to the WCF request, and then invokes the WCF operation via SOAP 1.2. The EJB is just a proxy for the WCF service.

In the Java CAPS version used, a BPEL process can not initiate a transaction when it starts. An atomic BPEL process can participate in a transaction that is active when the process is started. This means that our BPEL process can not be the head of a transaction.

As it happens, the only place where a transaction can be started in BPEL (in the version of Java CAPS used), is when a non-atomic process executes an invoke. When an external activity is invoked by a non-atomic process, the BPEL engine will start a transaction, and the external action can then participate in that transaction. When the invoke returns, the transaction is terminated.

Combining these two properties, a way to work around the limitations described here, is to create a new BPEL process that invokes the process running our transaction. The new BPEL process is a proxy for the main process. It takes the input parameters, copies them and invokes our main process. The invoke will start a transaction and end it when the invoked process returns. The new BPEL process is a proxy for our main process.

The resulting application looks like this:




Sample working around limitations




The next couple of entries in this log will talk about how to set up a system and environment to run this application, and how to create the application itself.

Posted at 12:01PM Sep 01, 2008 by marjo in Distributed transaction  |  Comments[1]

Comments:

I can't wait to see the next entries.

Thanks a lot.

Posted by Arturo M on August 18, 2008 at 02:39 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed

« July 2009
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
       
Today

Feeds

Search this blog

Links

Weblog menu

Today's referrers

Today's Page Hits: 9

Statistics

Unique visits to the log:



view statistics