JDJ 10-1.indd - sys-con.com's archive of magazines - SYS-CON Media

Desktop Java ViewpointJoe WinchesterDesktop Java EditorThe Return of the PigJoe Winchester is asoftware developerworking on WebSpheredevelopment tools forIBM in Hursley, UK.joewinchester@sys-con.comThe key to building a distributedapplication successfully lies in asensible partition of work acrossthe different boundaries anddevices. With a client/server program,one of the advantages it offers over amore traditional thin client is that foreach task, instead of having to wait forthe server to page the application backinto memory, process the results of thedisplay buffer, and prepare output, thePC is able to offload some of the validationand processing locally.Not only is this more responsive tothe user, but it makes sense to have aphysical division of responsibilities inwhich code logic is executed closest towhere relevant resources lie. Field-levelvalidation, defaulting, and completionof values can all be done on the client.Even where such processing requirestrips to the server, an atomic call to theserver on a text field’s focus-changeevent can easily validate an entry againsta database. By scheduling the displaythread this way the GUI can remainresponsive. Another benefit of using theclient’s windowing subsystem fully is theability to open multiple shells or dialogssimultaneously and have the user move,size, and arrange them to make the bestuse of the available space.In a presentation to users or a salespitch to potential customers, the eyecandyof a windows program will alwayswin over a terminal-based application.In chapter one of the client/serverwars, those with a lot of investmentin back-end technology required aquick fix to counter the glitterati of theGUI, and one technique that arose is“screen scraping.” This is where thedata stream intended for the server’sterminal is interpreted and re-presentedon the desktop using a best guess setof controls and widgets. From the backof a dimmed room in a demo or onthe noisy floor of a software booth at aconference, it looks pretty impressive.It’s no more than a fool’s shiny silverbullet, however, as all that it gains is theglitter of the GUI without any accompanyingdepth. The transactional modeof the application remains with logicbeing done on the server; simultaneousmultiple windows don’t occur as theworkflow is restricted to merely coloringin the terminal’s display, and an extralayer of processing has been added tothe previously working program for verylittle perceived benefit.One metaphor often used to describescreen scraping is “lipstick on a pig,”perhaps loaded slightly unfairly with theimplication being that the original applicationshares its characteristics with asnorting, mud-loving suidae beast. Whatis correct with the analogy is that skindeepcosmetics don’t change the truemakeup of the underlying subject.Screen scraping fortunately hasn’ttaken root in serious application development,instead the Web browser hasbecome the modern terminal; HTML,the display format; and users have beendelivered the graphical interface theyyearned for. While true client/serverdevelopers were wrestling, solving issuessuch as systems management anddistribution in a heterogeneous world,the Web filled in the software spacecreated by the growth in the PC marketand the availability of faster and cheapernetworks.Web applications still suffer fromsome of the problems that any pagebasedserver GUI has, including thetransactional nature of the screens,round-tripping for validation not deliveringa highly responsible application,and the difficulty of working with multiplewindows simultaneously. Most ofthe problems that plagued client/serverdevelopment have been solved and severalcustomers I talked to are reassessingthe desktop because their applicationshave reached the physical boundariesof what a traditional J2EE program candeliver. There are more tools availablenow such as Java Web Start, better Swinglibraries, and the Eclipse Rich ClientPlatform.History has a habit of repeating itself,and in the past few months I’ve beenalarmed to see demos of and read aboutseveral new ways to create a “rich desktopapplication” from within J2EE. All of theseeloquently outline the current problemsand limitations of the Web programmingmodel from a user standpoint and preachthe advantages of maximizing the powerof the desktop. What is disturbing is thata lot of these then present a solutionthat is no more than 21st century screenscraping. Some of these offer solutions inwhich the same presentation markup canbe rendered in a browser as a portlet orelse in a desktop engine as the same GUI,but with native controls.The debated advantages to this arethat the investment in existing technologyis preserved, and the same programcan be deployed into a browser or tothe user’s desktop with the flick of aswitch. My fear regarding these kindsof programs is that on the desktopthey won’t look and feel and behaveas a true client program should, andbecause they falsely use adjectives suchas “rich” or “desktop” to describe them,they’ll somehow dilute these terms andmake it hard for users to distinguish adressed-up Web application from a trueclient one.One of the advantages of having thebrowser shell is that every thing thatlies within it is expected to operate ina certain way, and requests to the userto “press retry to refresh the page” ornotifications that a “session time-outoccurred” have become acceptable. Disguisingthe browser with native controlsbut not offering any of the advantages ofa properly constructed client program offersa thin veneer that is no different fromthe screen scraping techniques of yore.When the same server program cankick out a browser and rich GUI, is thisan elegant solution that is going to meetthe user’s requirements, or is it justsomething that is technically elegantand demos well, but behind the robes isno more than lipstick on a browser?42 January 2005www.SYS-CON.com/JDJ