Skip to main content

Creating the Transaction Monitor - it's all about the message

Posted by larryjava on August 10, 2012 at 8:43 AM PDT

When my company, Amway Corp, makes a sale; somewhere, somehow a computerized transaction of that sale is created.
This transaction is sent to a number of applications at Amway for processing.
One such destination is our Java application.
We created a capability, called the Transaction Monitor (or TM) to deliver transactions to our app.

Our initial version of the TM worked well, but it was still not production ready.
To create a truly scalable, robust TM; we decided to use JMS (Java Message Service) for the first time.
This was a big step for us.

What did we expect from JMS?
The TM would become a message producer and message consumer.
We would use "messages" to pass transaction information between EJBs.
We would use "queues" to save and forward messages to the appropriate destinations.
We would use the "asynchronous coupling" of our JMS clients to have multiple EJBs running.

Extensive work was done to setup and configure the various JMS objects on the application server
(buses, messaging engines, destinations, activation specs, connection factories, JNDI names, routing rules).

While running, the TM did the following:
The main TM stateless session bean sends multiple messages (containing transactions) to multiple TM message beans.
Each TM message bean sends a message to another message bean that performs the transaction processing business logic.
Each business logic message bean sends an "I'm done" message to another TM message bean to finally "complete" the transaction.

As long as there were message beans running, the TM was collecting and delivering transactions.

By utilizing JMS, we can have multiple message beans running in as many JVMs as we want.
The size of each JVM will influence how many message beans we can have running at the same time.
The TM was now ready for production.

In production, the TM has delivered millions of transactions per month to the transaction processing engine.
Periodically, we measure throughput and tune the TM (and related application components) to make it perform better.

The Transaction Monitor. A very unique part of our application.
Another all-Java solution we have created (no third-party software used).
Our success with JMS has prompted us to use JMS elsewhere it our app.

The TM has been continuously "running" for 4 years with no end in sight. What a great message that is!