This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I was hoping somebody could help me vet the following please. I've been put in charge of writing a small Java program. My Java skills are modest and unfortunately I don't have any peers to assist in brain storming and reviewing my proposed solution. My experience in Java to this point has been writing MVC web applications using JSF and Oracle's ADF Business Components ORM, so I've limited experience in Java outside frameworks as such.
The thrust of the Java program is as follows. We have a Windows PC with 2 modems attached. An external system will connect to the first modem and transfer data. My program must intercept this transfer, interrogate the incoming data made up of a number of request types, and then via the 2nd modem make a call to a 2nd external system passing the request type.
In the process of constructing the request types, the mid-tier will also need to write the data to a database for auditing purposes. In a later version it may also need to implement business rules to interrogate the request types with data derived from the database, and log exception reports.
My thoughts at the moment is the solution has 2 components, one to read/write from the serial port using javax.comm (or the RXTX libraries), and the second is an object brokering exercise.
It was suggested to me that the solution would require a J2EE application server, but I'm not so sure. My (unformed?) thoughts are I should build a Java program with 3 threads, 1 to receive calls, 1 to send calls, and another to implement the business logic.
Alternatively I could write these as 3 separate programs with RMI calls.
I'm not sure a J2EE application server would be relevant for this application because as far as I understand it is for creating web based applications using servlets. I had a bit of a squiz at the javax.servlet.GenericServlet thinking I could use the request/response mechanism similar to that of HttpServlet, but it seemed inappropriate as it still deals with protocols, not raw data arriving on a Windows COM port.
I'd be very interested in your thoughts and guidance on the approach I should be taking please. Apologies if the above appears to be a bit of a ramble, but I'm still trying to form my thoughts.
You're getting input via a modem (not via HTTP requests). You have to send output via a modem (not via HTTP responses to where the request came from). So to me a J2EE application server doesn't seem to make any sense. It just isn't a hammer for those nails.
If the plan is for Java code on a Windows box to deal with data to and from serial ports, then RXTX is pretty much your only approach. Sun doesn't support the javax.comm implementation for Windows any more, and you can't even download it from them. You can get it from other people who resented it when Sun dropped the support, but going forward I think RXTX is a better bet.
And if it's a small program then I would agree with your initial assessment of a single program that receives, processes, and sends. If there's a chance that a second call could come in while you're still processing the first call, then the separate-threads idea would be appropriate; when you receive a call, you receive and store the request data, then start up a thread to process it. That thread could send the result also, so you'd have to synchronize to make sure that only one thread was using the outgoing modem at a time. Anyway, your MVC experience should help in designing this small program.
Joined: Mar 23, 2006
Thanks for the prompt reply Paul, you're advice is appreciated.
It's unclear at the moment if we'll be limited to 2 modems, or a bank of modems (specification pending). Potentially I could be starting multiple "incoming-modem" and "outgoing-modem" threads.
As serial communications tend to be error prone, with process hangs and time outs, do you think it would be a better approach to write 3 separate programs, incoming-modem, outgoing-modem and the object-brokering middle tier? In this way the administrator could restart the incoming-modem process if it has hung, without affecting the other 2 programs. The 3 programs would then need to communicate (I assume) by RMI?