Java framework for robust, network-centric application development.

Platform(s):  AIX, Windows 95, Windows NT 4.0
Date Posted:  29 April 1997
Updated:  6 June 1997

Note: In addition to the overview, two papers on the Thin Client paradigm are now available.
  • Weighing the Thin Client by David Kaminsky
  • Metis: A Thin-Client Application Framework by Deborra J. Zukowski, Apratim Purakayastha, Ajay Mohindra, and Murthy Devarakonda. (available as a file for download, "overview.zip")

While JDK, Java Beans, and IIOP enable platform independent programming, they are only a set of building blocks. There is a need for an application framework, a set of interrelated components, that stretches from the client front-end to the spectrum of servers that provide application logic and data storage. The Thin Client Application Framework (TCAF) provides this model by enabling rapid development of robust applications written according to the thin client paradigm. It is comprised of a collection of Java classes which provide a workspace (a customizable interface), workspace management functions, and support for network-based services. The end result is a server-managed environment for the application that differentiates the thin client model from the traditional-server model.

With TCAF, application front ends rely only on network services and dynamically bind to them for fault-tolerance, manageability and flexibility. The workspace manager provides a mechanism for finding and binding network services, shared space for data and service handles, state saving and hot-restart functions, single sign on and access controls, and a basic set of service systems (i.e. print).

TCAF provides a complementary server infrastructure using an LDAP-based directory service and standard Web servers. This framework may be used with IBM frameworks such as BOSS and San Francisco as well as with the Netscape IFC.

Weighing the Thin Client
by David Kaminsky, Java Team Lead, e-Network Studies, IBM

In the past several months, we've encountered a lot of confusion among our customers regarding just what the phrase "thin client" means. Some believe that "thin client" is a synonym for "network computer," while others think that a desktop PC can be a thin client. While we know that we can't put a definitive end to the debate, we hope that this essay provides some insight into what make a client "thin."

We believe that the term "thin client" is confusing because people use it to mean different things. Is it thin because it lacks processing power? Because, as in the case of a network computer, it downloads its software from a server? Because it is managed centrally like a NetPC?

For our definition, we'll return to the reason thin clients were created in the first place: cost. Businesses found that bloated PCs were costing them far too much money. A good chunk of that cost was a result of users "futzing" (fiddling and adjusting) with their machines. The computing industry responded with the concept of a thin - "futzless -" client.

The first incarnation of thin clients were network computers. Network computers reduce costs by storing software on a server, and dynamically downloading it to the NCs. Because software isn't stored on an NC, there's nothing for the user to "futz" with, and the overall costs go down. Consequently, NCs are clearly thin. Note that some NCs have quite powerful processors, so their thinness has nothing to do with the CPU.

Feeling threatened by NCs, some in the PC industry responded with the concept of the NetPC. A NetPC is a full-function PC, complete with software. While each NetPC will have software installed, they will cost less because the software will be managed centrally. At least that's what they say -- NetPCs don't really exist yet, except on paper.

Is a NetPC thin? How about other PCs? It depends. If a user has access to the local disk, either to customize his version of the software, or to store his data, then we think not. If the user is customizing software, then he's "futzing," and that's lost productivity. If s/he's saving his information on a local disk, then it won't be available unless that particular machine is available. If the disk crashes, the company incurs the costs associated with recovery. If the user travels without the computer, and needs the information on it, s/he's less productive. If the information stored on the server, then it's available even if the client fails and a different computer is used to access it.

With that discussion in mind, we'll offer this definition of thin clients:"If the client stores no information particular to any individual user, then it is thin."

By that definition, all NCs are thin. PCs can also be thin, provided users are prohibited (by technology or edict) from changing its contents. As with NCs, data must be stored on a server where its safe and accessible, and software can't be "futzed" with.

So, if you're investigating a thin client environment, we offer the obvious recommendation: focus on costs. Cost focus will drive a number of decisions, including, we believe, installing "futzless" and dataless thin clients.


The Thin Client Application Framework whitepaper is now included in the download section for this technology.