Recently I was having a discussion with a colleague about traditional versus Web clients. Instead of hearing the usual defense about how much easier it is to deploy and manage a thin client application, his point was that client/server fails because fine-grained transactions don't work.

With a browser-based application, when collecting data the typical workflow is the user inputting data on a number of pages and completing the transaction with a final Submit button. The flow of navigation is tightly controlled by the program that may create a session EJB to capture the data entered by the user. Since all the pages that users can enter their information on are known and controlled, the session bean has knowledge of all the data it needs to collect as part of the overall process. It also has a very obvious transaction boundary with the final "Submit" request where the changes become permanent.

By contrast, a traditional client application tends to have more freestyle navigation. Users are presented with tables or lists of queried information and from there they open additional detail screens to manipulate and enter information. The problem arises because on an edit screen the values of these objects can be changed. Having confirmed this by closing the window, does this mean that the update is confirmed to the database or just locally to the JVM to be committed as part of a larger transaction? If the value is captured just in-memory, then everyplace that same object is shown to the user should also be affected, including the original list that possibly shows the name in a table column. Any additional screens that might be used to reedit the same object or show its details should also be affected by the change. This means that the object must be uniquely identified within the Java program, so some kind of single instance management is required.

What if during the transaction the user performs another object query? The user could expect this to be a mixture of persistent data merged with any local changes he or she has made (as yet uncommitted). Including uncommitted newly created objects in the list is difficult as these must be woven between the persistent ones at the correct sort order positions. The problem is further compounded by the fact that within an overall transaction in freestyle GUI entry mode, the user might launch another multiscreen process to enter a new code and then decide not to commit this on the final screen. Alternatively, if the user does decide to commit this second process, it should be confirmed only into the world in which the original (still yet uncommitted) objects live. Nested transactions are required to support this, and apart from being very tricky to program, they are arguably confusing to the user as to which parts of the data are persistent and which aren't.

The following are two solutions that can be employed.

First, use a persistence framework. Several good ones exist such as Cocobase, TopLink, or Solarmetric. If you want, you can always roll your own framework, although be warned it's a tough task to undertake. The danger is that you'll spend too many cycles building your killer framework and fall easily into the trap (as I once did in a previous life) of spending too long polishing your silver bullet while losing focus on the real business problem you're trying to solve.

The second solution is the one that I find that in my older years I tend to use more and more: solve a problem by avoiding it. The freestyle mode of client GUIs works well for navigation, but for data entry it keeps the user down a specific path. This is essentially what wizards do with their back and next buttons and a final "Finish" page, and it's obvious to the user that by not confirming, the final screen loses the whole process; and since it's modal there is no danger of having to merge objects into ones that are read freshly from the persistent back end.

What is interesting about adopting a wizard or a rigid or modal dialog style of data entry is that this is essentially what a browser does. Instead of the server dealing with atomic and essentially unpredictable requests for data updates, the scope of what is being changed is predetermined and known to the session. It is an easier programming model to deal with, and the fact that the browser does it well doesn't mean that traditional GUIs can't adopt it as well. There is still a large functional value that results from giving the user a client that can perform local validation and has the high usability function point that client windows offer; however, there is also a lot to be said for simplifying the input programming model to be based around a constrained workflow.

Several years ago I was with a customer who was building an entire client application framework in Swing that was being specifically designed to emulate a browser (complete with back and forward buttons). The customer's argument was that their users were comfortable with the browser. While I originally dismissed their project as dumbing down the power of what a proper GUI could do, I think there's a lot to be learned by looking at the mechanics of how a browser-based application does its persistence and using this session-based programming model for more traditional clients.

Resources