Creating the Transaction Monitor - humble origins
We began creating our second Java application five years after we began the first app.
We were hoping the second application would give us a chance to use additional Java technologies.
We began by gathering all of the known functional requirements and matched them to the various
Java-related technologies we knew of.
The result was a high-level technical architecture of the application.
This architecture accounted for all known functionality related to the user interface, reports,
and batch processes.
But there was still something missing from our application architecture.
One of the functional requirements for this app was to accept "transactions" from an external source
and process them according to business rules.
The app needed a mechanism to deliver transactions to a transaction processing engine.
We wondered, what kind of "delivery mechanism" was needed to do this?
It was not a web page. Not a report. It didn't sound like a typical batch process.
We knew it had to be always running, looking for transactions to deliver.
It also had to respond to results from the transaction processing engine.
So we did some research. Surely this was functionality other apps had to do.
Soon, we found some inspiration that provided us with the basic ideas for our "delivery mechanism".
figure 1 - inspiration for TM
figure 2 - inspiration for TM
We decided to call this portion of our application the "Transaction Monitor". Or "TM" for short.
The TM consisted of a stateless session EJB and a number of helper classes to handle database access,
transaction delivery, and responses to transaction processing.
The TM used the Timer feature in EJB 2.1 to ensure that it was "always" running.
The TM EJB would be initially started with a Java Client app.
When it finished executing, it would create a timer object to start itself again.
This was good enough for the TM's "always running" requirement.
We would store TM parameter and statistical information in the database.
By changing the TM's parameter data, we could alter the behavior of the TM while it was running.
While running, the TM did the following:
- call a helper class to collect available transactions (we called this "scooping")
- call a helper class to merge similar transactions together
- call another EJB to perform the transaction processing business logic
- call a helper class to respond to results from the transaction processing engine,
a valid response would be to create more transactions to process (we called this "respawning")
The first version of the TM was built over a weekend. Our first test results looked good.
But there was still something missing from the TM to make it truly scalable.
To achieve this, we needed to use a particular Java technology for the first time.
Enter JMS - Java Message Service!
To be concluded...