The key to building a distributed application successfully lies in a sensible partition of work across the different boundaries and devices. With a client/server program, one of the advantages it offers over a more traditional thin client is that for each task, instead of having to wait for the server to page the application back into memory, process the results of the display buffer, and prepare output, the PC is able to offload some of the validation and processing locally.

Not only is this more responsive to the user, but it makes sense to have a physical division of responsibilities in which code logic is executed closest to where relevant resources lie. Field-level validation, defaulting, and completion of values can all be done on the client. Even where such processing requires trips to the server, an atomic call to the server on a text field's focus-change event can easily validate an entry against a database. By scheduling the display thread this way the GUI can remain responsive. Another benefit of using the client's windowing subsystem fully is the ability to open multiple shells or dialogs simultaneously and have the user move, size, and arrange them to make the best use of the available space.

In a presentation to users or a sales pitch to potential customers, the eye-candy of a windows program will always win over a terminal-based application. In chapter one of the client/server wars, those with a lot of investment in back-end technology required a quick fix to counter the glitterati of the GUI, and one technique that arose is "screen scraping." This is where the data stream intended for the server's terminal is interpreted and re-presented on the desktop using a best guess set of controls and widgets. From the back of a dimmed room in a demo or on the noisy floor of a software booth at a conference, it looks pretty impressive. It's no more than a fool's shiny silver bullet, however, as all that it gains is the glitter of the GUI without any accompanying depth. The transactional mode of the application remains with logic being done on the server; simultaneous multiple windows don't occur as the workflow is restricted to merely coloring in the terminal's display, and an extra layer of processing has been added to the previously working program for very little perceived benefit.

One metaphor often used to describe screen scraping is "lipstick on a pig," perhaps loaded slightly unfairly with the implication being that the original application shares its characteristics with a snorting, mud-loving suidae beast. What is correct with the analogy is that skin-deep cosmetics don't change the true makeup of the underlying subject.

Screen scraping fortunately hasn't taken root in serious application development, instead the Web browser has become the modern terminal; HTML, the display format; and users have been delivered the graphical interface they yearned for. While true client/server developers were wrestling, solving issues such as systems management and distribution in a heterogeneous world, the Web filled in the software space created by the growth in the PC market and the availability of faster and cheaper networks.

Web applications still suffer from some of the problems that any page-based server GUI has, including the transactional nature of the screens, round-tripping for validation not delivering a highly responsible application, and the difficulty of working with multiple windows simultaneously. Most of the problems that plagued client/server development have been solved and several customers I talked to are reassessing the desktop because their applications have reached the physical boundaries of what a traditional J2EE program can deliver. There are more tools available now such as Java Web Start, better Swing libraries, and the Eclipse Rich Client Platform.

History has a habit of repeating itself, and in the past few months I've been alarmed to see demos of and read about several new ways to create a "rich desktop application" from within J2EE. All of these eloquently outline the current problems and limitations of the Web programming model from a user standpoint and preach the advantages of maximizing the power of the desktop. What is disturbing is that a lot of these then present a solution that is no more than 21st century screen scraping. Some of these offer solutions in which the same presentation markup can be rendered in a browser as a portlet or else in a desktop engine as the same GUI, but with native controls.

The debated advantages to this are that the investment in existing technology is preserved, and the same program can be deployed into a browser or to the user's desktop with the flick of a switch. My fear regarding these kinds of programs is that on the desktop they won't look and feel and behave as a true client program should, and because they falsely use adjectives such as "rich" or "desktop" to describe them, they'll somehow dilute these terms and make it hard for users to distinguish a dressed-up Web application from a true client one.

One of the advantages of having the browser shell is that every thing that lies within it is expected to operate in a certain way, and requests to the user to "press retry to refresh the page" or notifications that a "session time-out occurred" have become acceptable. Disguising the browser with native controls but not offering any of the advantages of a properly constructed client program offers a thin veneer that is no different from the screen scraping techniques of yore.

When the same server program can kick out a browser and rich GUI, is this an elegant solution that is going to meet the user's requirements, or is it just something that is technically elegant and demos well, but behind the robes is no more than lipstick on a browser?