Posted by larryjava
on June 24, 2012 at 6:23 PM PDT
Our first Java application (10 years ago) was a migration of a legacy application.
The legacy application consisted of a number of screens and a number of batch processes.
Migrating the screens to Java technology seemed straight forward.
In theory, they would be a direct use of the MVC pattern (EJB, JSP, Servlet). Easy.
But what about the batch processes? They didn't seem to fit the MVC pattern.
For us, a batch process had two main basic characteristics:
1) It could be invoked at any time, via the command line.
There would be no user interaction, via a screen, to do this.
2) It would have no limit on how long it could run.
It could run for many hours or even a few days.
One thing we knew for sure.
Since our legacy application contained batch processes that were critical to the application,
we were required to migrate them.
Our job was not complete until we migrated the batch processes to Java.
Our batch processes consisted of transaction processing programs.
These programs did the following: get a transaction, apply business rules, get the next transaction.
The application had thousands to millions of transactions to process daily.
We got very little advice on how to do batch processing in Java.
Our software tools vendor mentioned something they called a "batch interface".
But nothing more specific after that.
During our search for answers, we began to question whether batch processing was even an
appropriate use of Java technology! This was a real big mystery to us.
We knew that our application would use EJBs to do business logic and database access.
We wanted to continue to leverage EJBs for the batch processes in our Java application.
We discovered that by using "bean managed persistence" in our EJBs,
we could achieve near unlimited run-times by overriding the timeout parameter of
the UserTransaction object available to bean-managed EJBs. Cool.
So we began a search of available Java literature for a means of command-line access
to our EJBs. After a few days of this, we found no answers. We were stuck.
In the meantime, our 6-week Java and Object-Oriented training classes had begun!
For 6 hours a day, 5 days a week; we heard all about Java, objects, J2EE, application servers, etc.
It was during the 4th day of 6th week of this Java training, that our prayers were answered.
We learned about the "launchclient" command for starting EJBs, from the command line, on the application server.
It was a brief part of the lecture. The instructor used barely a few minutes to cover this subject.
But that was enough. It was the answer we were looking for!
It was a classic "ah-ha" moment. A moment I will never forget.
To this day, I don't believe the class instructor realized the significance of what he told us.
After further research of the launchclient command, we learned about writing J2EE Client applications.
The launchclient command would call our J2EE Client application which would call an EJB
to do the batch process on the application server.
To test this, we created a J2EE Client application that would call a "hello world" EJB.
After deploying the code to the application server, we started our first Java batch process.
We expected immediate success. But our Java batch process did not work.
It did absolutely nothing. We tried it over and over again with the same results.
What was going on?
To be continued...