Java RMI

I've been looking at various strategies for rearchitecting our current system.  The architecture of our current system reminds me of the Winchester Mystery House: astonishing, amazing, incoherent, and unsuitable to a sane inhabitant.  It is well worth visiting, but it is not a preferred method of building a home.

The current system consists of:

1. Thin client: Internet Explorer 7 loads JavaServer Pages (JSPs) from a server.  The JSPs use Struts to communicate with the server.  

2. The server consists of a vast swarm (think: angry wasps) of classes running under Tomcat that accept requests to load data for display, and insert, update, or delete particular rows from the database.  The requests from the JSP call various methods in what are called Action classes.  Typically, there is an Action method called list which loads rows of data by calling an Implementer class for this data type.  The Implementer has a load method that communicates this load request via JDBC to an Informix database.  The Implementer load method feeds the rows coming back from the database into an ArrayList of objects, which are displayed to the user as a list of rows.  This again is done by loading a JSP for displaying the list.  The user may edit or add a row, which sends a request to the Action edit or add method, which stores the object into a Form specific to that class, and loads a JSP on the browser that displays this object.  When the user hits Save in this screen on the client, the Action save method is called, which in turn calls the Implementer save method, to send a request to the Informix database.

3. The Informix database has thousands of tables (many of which seem to be unused), some of which have hundreds of thousands of rows of data.

This thin client model by which a server feeds JSPs makes a lot of sense in a conventional enterprise level system, where you may have hundreds of thousands of customers, many of whom contact you once to order something, and you do not want them to have to download and install anything complicated.  For security reasons, a customer should be wary of downloading and installing anything just to order a widget.  Even for customers that regularly order from you, having to do a fresh download of client software even weekly is obnoxious, and consumes a lot of resources for the server.

This is not that situation.  We have a limited number of PCs that need to access this system.  They are all guaranteed return customers; no one makes a one-time connection to our system.  If they did, it would likely be a security breach!  Regularly pushing new thick client applications every week or so won't cost much.

Browser-based clients lead to several annoying problems.  The most obvious is that users hit Back and Forward, leading to interesting and unexpected transactions.  Yes, you can disable that toolbar in most browsers, but there is still right mouse click available to go Back.

A second problem is that browser compatibility is still surprisingly complicated, and Javascript, jQuery, and similar really clever tools reveal such headaches with surprising frequency.  An upgrade from IE7 to IE8 means a substantial amount of testing.  (And don't even think about Chrome or Firefox.  Nothing wrong with them--but too many things work differently from IE7.)

A third problem is that the JSP approach using Struts is a flaming nuisance to debug.  If you misspell methods or members on the JSP, you will not get a useful error message in IE7.  Sometimes, you will just get a blank screen.  Chrome has some very cool debugging facilities for this--but there are many features that we use that Chrome does not support, so some pages can't be debugged except by deleting stuff until the page starts working again.

A fourth problem is that while Javascript in a JSP gives you the ability to do considerable validation of input data, it is a somewhat limited environment.  You can execute server-side Java to validate input data, but each such action involves a bit of traffic back and forth--as the description at 2 above shows.

One possible solution is to use Java RMI (Remote Method Invocation), which allows a Java client to make RPC (Remote Procedure Calls) to methods located in the server.  The advantage of this approach is that it allows us to reuse existing server classes without having to start from scratch (and in a system with more than a million lines of Java, you don't want to do that).

Any thoughts from my readers?