Déjà Vu All Over Again
David Ritter
Sometimes I wonder if we're really making any progress. At a recent Internet trade show, a vendor was hawking its new Java-based application server product by saying,
"Finally, you can deploy your applications on a single server and have the new version immediately available to all the users!" Has this guy ever heard of a mainframe? His next point was that the users don't
need special software on their PCs because the applications all run within a Web browser. Does anybody remember the 3270 terminal? To complete the picture, Oracle and others now offer centralized hosting and management
of ERP systems, charging only for actual usage. It seems that we've come 30 years into the future to arrive at timesharing systems with the dubious enhancement of pictures on the screen. End-user empowerment consists
primarily of the ability to play Solitaire in a fully distributed fashion.
It's
not that I'm nostalgic for the glory days of the IBM 3270. But it's
frustrating to see the IT community taking steps backward, sacrificing
user productivity in the process. As one IT manager in the trade
show audience noted, the productivity of his users decreased by
about 50 percent when he migrated them to a browser-based application
interface. Why? HTML is primitive, standards for extensions such
as Dynamic HTML are fragmented, and client-side Java is immature,
slow, and buggy. The resulting quality of the user interface was
poor.
Even
with all these problems, developments in thin-client computing are
important for enterprise developers. The primary benefits don't
come from force-fitting applications into a Web browser, however.
The low cost of deployment for browser-based applications is appealing,
but these incremental savings can be quickly eaten up if the quality
of the applications declines. The thin-client movement is driving
the emergence of robust, open-component architectures. For the first
time, you can partition applications across multiple tiers, using
standardized object development tools. This flexibility is the real
prize.
To
many developers, "thin client" implies that the client
system (network computer or PC) is essentially used as a terminal.
The client executes only the user interface through downloaded HTML
or Java code running in a standard browser or simple runtime engine.
All the real work is handled by servers, which may be organized
into one, two, or more additional tiers. To better understand the
opportunity for partitioning, a more general model is needed.
Table 1shows a proposal for a more
complete way to think about thin and thick.
I've
divided the functional aspects of an application into four tiers:
•
Presentation, which encompasses just the graphical display and basic
user interaction through the keyboard and mouse
•
Navigation, which defines how pieces of the user interface relate
to each other
•
Business logic, the rules controlling data flow, work flow, and
so on
•
Data management, which includes the logical and physical representation
of the persistent data used by the application.
In
this model, a typical browser-based interface would be considered
a "waif" client, the thinnest possible. The browser only
draws the screen. Every navigation step to a new page involves a
trip to the server to get the required HTML. In contrast, a "slender"
client performs page-to-page navigation on the desktop, interacting
with a server only when the user's actions actually result in some
work. Distributed object applications with dedicated client runtimes
generally fall into the slender category.
A
"robust" client is the traditional form of client/server
systems. The entire user interface and the bulk of the business
logic live on the desktop with a direct connection to an RDBMS on
the server. Stand-alone desktop applications built in Microsoft
Access or other PC database systems, are considered "epic."
In these systems, the client does all the work, including data management.
The
model in Table 1shows
that thin-client computing isn't a black or white decision. There
are many shades of gray, which lets the application designer make
the choices appropriate for a given system. Historically, it's been
difficult and expensive to create each application in its ideal
configuration. The range of different skills and technologies required
was just too broad. Proprietary protocols were required to bind
the tiers together. Recent developments in platforms and tools,
driven mostly by the evolution of the Web, make this sort of partitioning
much more achievable. Continued
Table 1:
Four degrees of client thickness. "Server" refers to both
application and database.
|
Presentation |
Navigation |
Business
Logic |
Data
Management |
Waif |
Client |
Server |
Server |
Server |
Slender |
Client |
Client |
Server |
Server |
Robust |
Client |
Client |
Client |
Server |
Epic |
Client |
Client |
Client |
Client |
|
|
