Tuesday, May 29, 2012

A transactional Android example

OK, so as I announced a couple of days ago, the initial code that allows transactional applications to be written on Android is available. There's even an example demo. Therefore, I thought I'd go through the application and its associated configuration in case people wanted to give it a try in its current state. Also rather than try to address all of the idiosyncrasies of the various Android handsets out there, we'll focus on using the Eclipse emulator this time around.

OK, so let's get started. I'll assume that you've checked out the source for the example (it comes with everything you need, so although you can also check out the source for JBossTS, it's not strictly necessary). As a result, you should have something that looks like:

Now before we take a look at the application code, it's important to remember that we're trying to add transactions to these applications. I won't reiterate all of what this means (I'll leave it as an exercise to the reader to either look through the other articles in this blog or check out transactional resources elsewhere). However, for the purposes of this entry it's important to remember/realise that a transaction needs a durable location where it can store the log to be used in the event of a failure and recovery. In the case of Android, we'll assume this is on an SD card somewhere. In terms of the application and the Android emulator, this has an impact. First, for the emulator we need to create an Android Virtual Device (AVD) and ensure it has an emulated SD card. You can do this easily using the AVD creator:

As you can see, in this case we've selected 512 Meg for the storage. That should be plenty of room for quite a few transactions, especially as most of the time the logs will be created and almost immediately deleted. So you don't have to go overboard with the amount of storage allocated.

Now for the application we need to ensure that it is allowed to access the SD card (external storage). We do that by editing the AndroidManifest.xml:

In this configuration we also need to allow the application to access the internet. This is because JBossTS needs to access the IP address of the device in order to create unique transaction identifiers. We'll look at whether this is something we can change later, but it shouldn't be an issue at this stage.

We're now ready to look at the application. If you've read this blog for a while then you'll know about ArjunaCore and the transactional toolkit within. Not only is it the basis for the work we're doing on STM, but we're using it here to create our application. I won't go into details, because the transactional object is your standard transactional int AtomicObject derived from LockManager and providing operations to read and write the state. It uses nested transactions as well!

So how do we use instances of this transactional int?

Pretty simple. As you can see above, we simply create a new transaction via AtomicAction; create an instance of the AtomicObject; start the transaction and modify the state of the object before committing the transaction. If all goes according to plan, when you deploy this application and run it, you should first see something like:

And then see output similar to below (your transaction id will be different):

That's it! Fairly simple and straightforward. At some point in the hopefully not-too-distant future, I'll get the JBossTS code changes into the mainline code in github and look at a more complex application. This one doesn't cover recovery for instance, and I'd like to more tests. But for now it shows what's possible and the direction in which we're heading. Enjoy!

Sunday, May 27, 2012

Transactional android applications

OK, so it's taken me longer than I expected, but I finally found some time to commit the transactional Android code that I mentioned back in January. Thanks to my JBossWorld keynote preparation, a lot of EAP 6 work and too many meetings to count, I still haven't had enough time to actually commit these changes to the trunk of JBossTS (Narayana). However, rather than continue to delay things, I've decided to check in my edited source to the JBossTS svn repository along with a quick example.

I'll post another article soon to walkthrough the example and its configuration, but if you're interested in checking out the JBossTS source then it's available via svn at https://svn.jboss.org/repos/labs/labs/jbosstm/workspace/mlittle/android and the example at https://svn.jboss.org/repos/labs/labs/jbosstm/workspace/mlittle/TxAndroid. Of course you can build the JBossTS source if you want, but for the sakes of convenience I've included the necessary jars in the example directory.

Friday, May 18, 2012

Running a WS-AtomicTransaction Enabled Web Service on Openshift

We recently published a video showing you how to deploy a WS-AT enabled Web service on Openshift. The focus of this video is to provide a very simple example that introduces the WS-AT technology and the basics of deploying it to Openshift. The video is based on the wsat-simple quickstart  which ships with the JBossAS7 quickstart project. This quickstart and the accompanying video are a great place to start when learning WS-AT. This video also shows you how to enable Web services and WS-AT in Openshift.

In order to keep this quickstart simple, I have focused on demonstrating how the WS-AT protocol works and the Java API to it. As a result, I needed to omit several features that you would expect in a real application. The XTS demonstrator provides a much fuller example of how to use WS-AT. Although more complete, it has a steeper learning curve for those new to WS-AT.

The limitations are as follows:

1. No backend resource. In a real application, it is likely that your Web service will be manipulating some transactional state. For example, it could be updating a database or sending a JMS message. This quickstart uses a mock resource that is neither transactional nor persistent. For an example of how to write and interface with transactional resources, you can take a look at the XTS demonstrator.

2. No WS-AT to JTA bridging. Using the JBossTS TXBridge technology, WS-AT transactions can be seamlessly bridged onto backend JTA transactions (and vice versa). This allows you to use WS-AT as in integration technology for creating a distributed transaction. WS-AT has proven interoperability with many vendors and in some situations it is the only way to create a distributed transaction in a heterogeneous vendor environment. WS-AT also uses SOAP over HTTP as the transport, which can overcome some integration problems that, say a binary protocol, cannot. The TXBridge is currently a technology preview and will not be supported in JBoss EAP 6.0. Therefore it could not be used in this quickstart. The TXBridge does ship with both JBossAS 7.x and EAP 6.0 so you can try it out. For an example, please see the TXBridge quickstart.

3. No recovery. The quickstart does not implement the required hooks to support crash recovery. This is a complex subject and one that is covered by the XTS demonstrator.

4. Multiple Services. WS-AT is a consensus protocol which implies that it is designed to support multiple parties. This quickstart only uses a single service, but could quite easily be modified to use multiple. Again the XTS demonstrator provides an example of this in action.