In the first tutorial about JBoss ESB we have learnt the basics about the Service Bus and which are the basic components of it. In this tutorial we will learn how to use JTA Transactions within a set of ESB actions.
That most important lesson we have learnt is that all interactions between clients and services within JBossESB occur through the exchange of Messages. Message can be used to build loose coupled applications which are the basis to develop SOA applications.
If we have a look at the JBoss ESB configuration is mainly split into two pieces:
Providers: This part of the model centrally defines all the message <bus> providers used by the message <listener>s, defined within the <services> section of the model.
Services: This part of the model centrally defines all of the services under the control of a single instance of JBoss ESB.
For the purpose of learning about transactions, we will concentrate on the definition of Providers. An example of Provider is a jms-provider which listen for messages which are placed in a queue/topic:
A more advanced example of jms provider is the <jms-jca-provider>. This provider can be used in place of the <jms-provider> to enable delivery of incoming messages using JCA inflow. This introduces a transacted flow to the action pipeline, and thereby encompasses actions within a JTA transaction.
We will test this provider using an out-of-box action named EJBProcessor.
The EJBProcessor action takes an input Message and uses the contents to invoke a Stateless Session Bean. (This action supports EJB2.x and EJB3.x).
So let's modify one of the distribution ESB examples to test a JTA Transaction.
Here's a simple Stateless EJB 3 with 2 actions. Tne first one performs a Database Insert and the other rollback the transaction depending on the content of the message received:
And this is the jboss-esb.xml configuration file:
As you can see, there's a pipeline of two actions (action1 and action2) which are called sequentially.
If the action2 receives as parameter "rollback" the transaction will be rolledback. What does the trick is
the XAConnectionfactory, which enlists the actions in a JTA transaction:
If you experiment switching to a non-xa Connection factory:
you will see that the transaction is actually committed when action1 is executed.<