In Search of Batch - The End of the Road
In order to successfully migrate our mainframe application to a Java/application server based solution,
we had to figure out how to migrate our batch processes.
We had a very good start, in achieving this, by utilizing the LaunchClient command and J2EE Client programs.
It was just a matter of putting the remaining pieces together into a working solution.
But we were running into a lot of trouble creating a working solution.
There was no turning back or giving up. Success in creating a working Java batch process
would not only be good for our project, it would demonstrate to the rest of my
company, Amway Corp., that Java technology was appropriate for enterprise-wide applications.
So we began another search of available literature for answers to our latest issues.
After a few days of searching, we came across a sample Java program of a "splash screen" for a GUI application.
At first, the sample code seemed to have nothing to do with what we were looking for.
But upon closer examination, the sample program contained code that was exactly what we were looking for.
Hooray! So we used the code and created two client programs, BaseClient and EJBClient.
BaseClient did the following -
1) Accept input arguments: target class name, target class arguments
2) Perform client container login, catching errors if needed
3) Load the target class and get a reference to its main() method, catching errors if needed
4) Invoke the target class main() method, catching errors if needed
#3 and #4 utilized Java reflection techniques.
BaseClient would be the active J2EE Client program for the application.
All other client programs\target classes would be started by BaseClient.
EJBClient did the following -
1) Accept input arguments: JNDI name of EJB, name of EJB method to call after create(), EJB method arguments
2) Create EJB Remote Object
3) Invoke EJB method
4) If a Boolean is returned from the called EJB method; pass return value to calling program
EJBClient would be used as a generic client program to call any EJB.
We then created a J2EE Client program and several "hello world" EJBs.
After deploying the code to the application server, we started the Java batch process via LaunchClient.
We expected LaunchClient to call BaseClient, which would call the J2EE Client program,
which would call the EJB. We would use EJBClient instead of the J2EE Client program,
if calling an EJB was all that the client program would do.
It all worked perfectly! We were able to execute any EJB from any client program
without redeploying the application.
We were now free to create as many batch processes as we needed.
They would all be part of the same application or EAR. Double Hooray!
Now that we could create Java batch processes, we felt we could do anything in Java.
Our "Search for Batch" had ended!
Batch processing continues to be part of our Java\J2EE applications today.
About a year and a half ago, our application server vendor introduced a "new" feature --
called "Batch". It was an app server container for batch processing.
Eight and a half years after we created batch processing for our application,
our app server vendor finally got around to it. Too funny!