Sunday, March 31, 2013

STM, vert.x and the Pi Part 1

Given other priorities (aka 'my day job'), I'm slowly working my way through another pet project I've had for a while: adding transactions, and specifically STM, to vert.x. Of course at the moment I also try to add an influence from my other pet project, the Raspberry Pi, so I'm doing it on the Pi as much as possible. OK, it may not be the fastest machine on the block, but it's a lot of fun!

We've had STM in Narayana for a while, so I won't cover the basic again. I'm also not going to cover any Pi-related set up: by this point you should know enough to do this yourself. So let's start with cloning the most recent version of Narayana:


Make sure your path and JAVA_HOME are set so we're using JDK 7:

 
Next let's build the components we need for STM:


Don't forget that this is going to take a while, so maybe time to go grab a coffee, read a book, play with your kids, or watch an episode of Lost.


With that build complete, we've already run a lot of STM examples in the form of unit tests. However, let's take a simple example:

import java.io.IOException;

import org.jboss.stm.annotations.Transactional;
import org.jboss.stm.annotations.ReadLock;
import org.jboss.stm.annotations.WriteLock;
import org.jboss.stm.internal.RecoverableContainer;

import com.arjuna.ats.arjuna.AtomicAction;

/**
 * @author Mark Little
 */


public class Example
{  
    @Transactional
    public interface Atomic
     {
     public void change (int value) throws Exception;
       
     public void set (int value) throws Exception;
       
     public int get () throws Exception;
    }
   
    @Transactional
    public class ExampleSTM implements Atomic
     {  
        @ReadLock
     public int get () throws Exception
     {
         return state;
     }

        @WriteLock
     public void set (int value) throws Exception
     {
         state = value;
     }
       
        @WriteLock
     public void change (int value) throws Exception
     {
         state += value;
     }

     private int state;
    }
   
    public void testExample () throws Exception
    {
        RecoverableContainer theContainer = new RecoverableContainer();
        ExampleSTM basic = new ExampleSTM();
        Atomic obj = null;
       
        try
        {
        obj = theContainer.enlist(basic);
        }
        catch (final Throwable ex)
        {
        ex.printStackTrace();
           
        return;
        }
       
        AtomicAction a = new AtomicAction();
       
        a.begin();
       
        obj.set(1234);
       
        a.commit();

    System.out.println("Should get() 1234 after commit: "+obj.get());
       
        a = new AtomicAction();

        a.begin();

        obj.change(1);
       
        a.abort();

    System.out.println("Should get() 1234 after abort: "+obj.get());
    }

    public static void main (String[] args)
    {
    Example ex = new Example();

    try
    {
        ex.testExample();
    }
    catch (final Exception e)
    {
        e.printStackTrace();
    }
    }
}


Stick this at the same level of Narayana if you want to use the same CLASSPATH as here:

narayana/ext/jboss-logging.jar:narayana/ArjunaCore/arjuna/target/test-classes:narayana/common/target/common-5.0.0.M3-SNAPSHOT.jar:narayana/STM/target/core-5.0.0.M3-SNAPSHOT.jar:narayana/ArjunaCore/txoj/target/txoj-5.0.0.M3-SNAPSHOT.jar:narayana/ArjunaCore/arjuna/target/arjuna-5.0.0.M3-SNAPSHOT.jar:.

After compiling, run the example and you should see the following:


Despite what I said at the start of this entry, there's a distinct lack of vert.x involved here at the moment. That's because there are a few changes we need to make to the STM implementation to make it easier to share transactional objects between address spaces. This is all stuff that's available "natively" in TXOJ, so developers could use that API immediately. However, the STM approach simplifies a lot so once those additional features from TXOJ are integrated there, we'll have a follow up article to discuss what, how and why.

Monday, March 25, 2013

API Improvements for WS-AT and REST-AT

In this post I’ll introduce some API changes we are doing to improve the way developers use WS-AT and REST-AT.

I’m a strong believer that the internal architecture of your application, and the means by which client’s communicate with it, are two orthogonal issues. You wouldn’t want to have to change the internals of your application, just because you need to change the way clients invoke your service.

We think you should be able to develop your applications using a common Transactions API. You should then be able to invoke remote services over whatever transport is appropriate and automatically have the transaction distributed. Furthermore, you shouldn’t be restricted to having all participants use the same transport.

There really is only one option for a Java “common Transactions API” - it’s JTA. JTA is well supported in Java EE application servers and it is well understood by developers. Furthermore, there are many applications out there already using JTA.

This is what we are moving towards with each milestone release of Narayana 5.0.0. With milestone two we made it very simple for a pure JTA client to invoke a JTA application over Web Services in a distributed transaction. Take a look at the following example:

Client


@Stateless
public class OrderClient {

  @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
  public void orderItem(String item, String address, double amount) {

    AccountService as = //Lookup AccountService WS client
    WarehouseService ws = //Lookup WarehouseService WS client

    ws.shipItem(item, address);
    as.invoiceCustomer(address, amount);
  }
}


Here the client is using a regular Stateless Session Bean. The method ‘orderItem’ is invoked in a JTA transaction that is committed if the method succeeds and rolled back if it fails.

The calls to the Warehouse and Account services automatically use WS-AT to distribute the JTA transaction. The middleware knows to do this because a JTA transaction was present when the Web Service call was invoked.

Transaction propagation can be configured, but that’s the subject of another blog post (stay tuned).

Service


@Transactional //Currently required, will be removed soon https://issues.jboss.org/browse/JBTM-1468
@Stateless
//JAX-WS annotations omitted for brevity
public class WarehouseServiceImpl implements WarehouseService {

    @PersistenceContext
    protected EntityManager em;

    @WebMethod
    public void shipItem(String item, String address) {
        // Use the Entity Manager to 
        // add an item and shipping address to DB
    }
}

Again the service is implemented as a simple Stateless Session bean that just happens to be offered as a Web Service. Here the application is using JTA to make a database update. The middleware automatically handles the mapping between the incoming WS-AT transaction and the JTA transaction.

What About Other Transports?

With milestone two we already support transparent propagation over Web Services (via WS-AT), Corba (via JTS) and JBoss Remoting. We hope to have REST-AT support in a subsequent milestone release (see JBTM-1468).

Getting Started

Hopefully you are now eager to try this out. The best place to look is at this quickstart, which demonstrates the new API in action.


Acknowledgements

I'd like to say a big thank you to Alessio Soldano and the JBossWS team. They provided a lot of advice and also added new features to the JBossWS SPI to support this feature.

Thursday, March 21, 2013

Narayana and BlackTie 5.0.0.M2 Released!

I am very proud to be able to announce the availability of version 5.0.0.M2 of the Narayana and BlackTie projects which has been a significant release for us on many levels.

One of the greatest achievements for this release is that it is the first version of Narayana (JBoss Transactions 5) that has been consumed by the AS8 project. This means you can start using it straight away by downloading the latest nightly build of AS8!


Narayana's integration with the app server contains the usual bits and pieces from JBoss Transactions (JTA, JTS, XTS) alongside our new APIs for using XTS. It also provides a suitable base line to deploy the BlackTie and REST-AT server-side components. With future milestone releases of Narayana we will add full out-of-the-box support for these extra components.

Some other features that have been added in this version (release notes here and here) which I would like to pick out are:
  • Added a significantly improved API for using XTS in the app server (see separate blog posts for more details)
  • Early release of a new API for compensation-based transactions
  • JDBC Object Store
  • Simplified BlackTie client library (without TAO dependency)
  • Windows 2008 Server support for BlackTie
  • The usual set of enhancements for our documentation and quickstarts

So, where can you download the software from? For Narayana standalone, you can download the software here:
https://www.jboss.org/jbosstm/
For BlackTie, it is available here (a Linux 64 bit distribution and a Windows 32 bit one are provided):
https://www.jboss.org/blacktie/
For a build of AS8 containing Narayana:
https://ci.jboss.org/hudson/job/JBoss-AS-latest-master/lastSuccessfulBuild/artifact/build/target/jboss-as-8.x.zip

As I mentioned on a previous blog, we are going to be merging the BlackTie and Narayana repos/Jira instances/blogs etc in the M3 timeframe, so in future everything will be available from the existing Narayana locations:

Source:
https://github.com/jbosstm/narayana (plus documentation and quickstart )

Issue management:


https://jira.jboss.org/browse/JBTM (use the blacktie component if raising a blacktie issue)

Please do let us know what you think of the release either in the comments on our blog (http://jbossts.blogspot.co.uk/) or forum (https://community.jboss.org/en/jbosstm/?view=discussions).

Happy evaluating!

Friday, March 1, 2013

Merging BlackTie and Narayana

Guys,

We would like to merge the BlackTie and Narayana projects together. As you will know, BlackTie is a C++ API onto the Narayana transaction manager and as such features are being developed which require changes in both components. Furthermore, Narayana already provides support for several other APIs within the main Narayana project so collecting them all together seems to make the most sense.

The changes would be two phase:

Phase 1:
1. Merge the blacktie github repo into the narayana github repo
2. Use a single blog: http://jbossts.blogspot.co.uk/
3. Use a single jira instance: https://jira.jboss.org/browse/JBTM
4. Use a single chatroom: jbossts@irc.freenode.net
5. Use the single community space on jboss.org: https://community.jboss.org/en/jbosstm/

Phase 2:
Merge our web site https://www.jboss.org/blacktie/ into the existing https://www.jboss.org/jbosstm pages

Please do let us know if you have any objections or can see a problem with this,

Tom