Welcome!

Java Authors: Elizabeth White, Gary Kaiser, Pat Romanski, Liz McMillan, Michael Thompson

Related Topics: Java

Java: Article

The Return of the Pig

The Return of the Pig

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?

More Stories By Joe Winchester

Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.

Comments (4) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Francis Carden 01/11/05 10:10:16 AM EST

I think you do miss a huge point. I've been involved in "screen scraping" of many forms for 15 years so speak from experience (how sad is that :) ).

Seriously, to use your same analogy. Why do you think we still have Pigs? Because there is nothing else that will give you this meat in so many guises. Bacon, Pork Chops, Pork Loin, Ham. All of these products "meat" our transactional requirements even though it's a dirty "meat" and there is no replacement on the horizon.

OK, so what do I mean. 10 years ago, everyone wanted to rewrite their "pig" applications. Some worked, some failed, some succeeded but were little better. Now we have different pigs. 5 years ago, everyone wanted a "Lipstick on a Pig", also known as a brand new composite application that scraped data from the old apps. This didn't work well as the pigs were a complex beast and never stable. Now what seems is back is to use the backend "Lip Stick on a pig" technology to enhance/speedup/simplify the end user experience. This means doing the scraping but just using the components scraped to save "time". Users have so many "pig" apps on their desk they spend 10% of their time re-keying data (or cut and paste). That 10% time saving adds up in a 5000 user customer service org. QUite simply then, screen scraping works but you have to choose how to implement it, very very carefully.

Last but not least. "What makes a PIG (legacy) application ?" - anything written more than 5 minutes ago. You see, nothing has changed. IMHO, there are more pigs today then there were 5 years ago. Today we are just putting another coat of lipstick on the same, or newer pigs.

Definately a very important subject so thanks for writing it.

Martin 01/10/05 09:20:25 AM EST

Hi Joe, thx for explanation that I fully agree with. And apologies for my initial misunderstanding of the article :)
Cheers, MAF

Joe Winchester 01/10/05 04:17:55 AM EST

Hi Martin,
Sorry if my point got buried in my diatribe. I agree that there is a lot of great benefit in having apps that do XML type comms between the layers - I've seen these in action and they marry the best of both worlds. My point is more about technology that takes a fully baked web app that was designed for an HTTP page based conversation and then try to re-package simply the GUI with a different widget set and present this as a "rich-client" app. They remind me very strongly of silver bullet screen scraping technology that was kicking around in the early 90s.
Take care,
Joe

Martin 01/07/05 08:47:56 AM EST

Not sure if I got Joe's point, but is he saying that nothing else makes sense then regular fat client/server app or crystal pure web-app with standard web-browser fed by HTML provided by the server (regardless the server technology)?

I strongly disagree, that '... requests to the user to "press retry to refresh the page" or notifications that a "session time-out occurred" have become acceptable...'. This is clearly seen from purely technical perspective, but is not true for the business end-user.

I believe there is quite a number of strong business and technical arguments why companies are looking for and implementing enriched web-browser front-ends that do eliminate the major problems of traditional web-based apps (request-response, weak validation support, ...) and communicate with centralized business logic in front-end independent format (e.g. XML).

Therefore regardless whether if such solutions are called 'rich-browser' or 'lipstick on browser', its business and technical advantages are clear and understandable.

Cheers,
MAF