To fund my music habit, I've been struggling with both technologies for years.
Web apps...
- Use the web server as the client to business logic objects and databases.
- leverage the browser for user interface, thus eliminating the need to code such things as an event handler for window resize, etc.
- Don't readily support all kinds of custom UI behavior.
- Do require the programmer to work in several programming languages at once, to provide client-side data verification (j-script), UI (html), server-side data verification as well as business logic (server languages), and data (SQL)
- pose special security issues (because nothing can be assumed about the desktop client, not even that it will ever dispose of cached credentials).
- Have no need for a desktop packaging and distribution process.
- May leave confidential information on the end-user's screen long after a session has timed out on the server.
- Are not always a good match for real-time applications, e.g. music applications, multi-user dungeons/games, status monitors, instant messengers.
- Are a good match for some discrete transaction services, bulletin boards (like this one!), and ---especially --simple non-interactive presentation of results.
- Are still often dependent on the pixel size of the desktop (i.e. may have to be rewritten especially for PDAs and cell-phones).
- Make relatively scant assumptions about the capabilities and hardware of the desktop.
Client-server apps...
- Require the custom coding of all client behavior.
- Can use the full power of the desktop's UI.
- Can be built in a reduced set of programming tools, e.g. SQL for a database plus a single language (e.g. C, C#, Java, etc.) for both client and server applications.
- May be coded so that a portion (internally obfuscated) of the client application uses custom security code and guarantees appropriate user credentialling and expiration of credentials.
- --but may expose the desktop to reverse-engineerable custom security code.
- Must be packaged and installed on every desktop where it is to be used.
- Can force-exit upon loss of session.
- Are often a good match for real-time applications (e.g. streaming media, MUDs, etc.) and polling applications (monitors, IMs, etc.).
- are capable of handling discrete transaction services, too.
- Require the maintenance of separate code bases for each client platform (various versions of native Windows, .Net, each supported flavor of native Unix including MacOS X, earlier forms of MacOS, PalmOS, Java, etc.)..
Now, web service concentrates all the application-specific code on the server (modulo short j-scripts for faster user feedback). That gives it many of the characteristics of mainframe applications of old. Any architecture which does this is now called by the buzzword
application service.
Another kind of application service which should be explored alongside these is presentation service. In presentation service, everything--including the graphic user interface--of the application runs on the central box, and the code on the desktop is just a generic piece which paints widgets on the screen and passes user input through to the central box.
I'm using "central box" and "desktop" here instead of client and server for a reason which I'll explain shortly.
The two major players in presentation service are X11 (X-windows) and Indpendent Computing Architecture (ICA -- Citrix Metaframe). X11 calls the desktop component the "service", and serves the user up to "client" applications running on remote boxes; ICA calls the desktop component the "ICA client", and serves "published applications" to the user. Because these two main players disagree about which end is "server" and which end is "client", I have to be careful how I phrase things.
X11 melds the application's UI with client-side UI components designed to blend with the desktop's native look and feel, so when, for instance, an X11 application runs on a Linux box but is accessed from a Macintosh, it takes on Macintosh-style buttons and window-frame widgets.
ICA literally passes pixels to the desktop, so e.g. a Macintosh user might suddenly have what appears to be a native Windows application running amid their Macintosh applications. The Windows app will have Windows-style buttons and widgets.
The UI of X11 apps must be specially written for X11. ICA can be used to serve virtually any application to anywhere, so long as that application stores its characteristics on a per-session/user basis rather than a per-machine basis (e.g., on Windows, using the HKLUser instead of HKLMachine registry).
For both of these players, desktop components exist for a wide variety of devices, including, intriguingly, Java-enabled web browsers.
X11 exists in the open-source world; ICA is currently Citrix Corp.'s rather pricey property.
Citrix has gotten rather agressive about marrying ICA to web services and web-based XML services to do things like auto-populate the desktop's menu with icons to ICA sessions, make a user's portal environment and applications available anywhere in the world, and enable pass-through authentication and authorization.
Presentation service also has a well-defined concept of a "disconnected session", making it possible for a user to leave their environment running on the server while logging out of the desktop. It may even be possible for the user to reconnect to and resume the same session from a totally different device. Where life gets interesting is when the remote application is asked to print, or to save data to the end-user's hard drive--there may be a lot of initial configuring and security-planning involved.
Citrix's hard-sell has long been, and basically remains, that if you switch to running literally EVERYTHING via ICA, you can stop upgrading desktop machines since all they need to be able to do is run a small, generic GUI application. But Citrix Corp. admits that certain applications--those involving realtime media like movies and music--are still not appropriate for ICA.
By the by, the term
thin client refers to a very distinct and significantly different technology. The "leanness" is not of desktop processing capability but of desktop network capability. For instance, a "thick" client may have an Oracle database instance as its server side, but if you try to run that client over T1, modem, or across continents, you may find it constantly getting disconnected from the server due to time-outs and the sheer bandwidth needed to move data across the network. ICA fares better, generally requiring only 16k or about 1/4 the bandwidth of a modem, to keep a session connected and fully responsive. And web apps generally use a much tinier bandwidth. In exchange for that bandwidth, you have to establish a solid connection between your application server (ICA server or web server) and your database, but that connection is typically between racks in your data center. Thin client technology isn't right for everything--streaming video is a classic case where it just won't cut it--but it does have important uses.
Edited to add--When I sat down to answer this, I didn't realize I was going to write a white-paper. But I did know that in my environment we suddenly went from writing a .Net app in 25 pages of sourcecode plus a security plug-in, to writing the same app in Fusebox-for-Coldfusion as 3 pages of sourcecode plus a security plug-in (the security plug-in is reused across many applications and thus doesn't count as part of the effort). Where an application is needed for some really simple capability, php and cf are pretty much ideal. For instance, here's the code in either of them to the hello, world application:
Hello, World!
(i.e. text not tagged as code is static output text). About the shortest competitor is probably any .Net language, which looks like this:
System.MsgBox("Hello, World!")
The difference in coding requirements for UI gets exponential when the output is variable length and appears in a resizeable window.
