JDBC Brings the Fat Client to Java

Java has been hyped as "thin client", "client/server done right", "true distributed computing", and "the ultimate 3-tier solution". While there is some truth behind each of these sentiments, the fact remains that Java is only a part of the puzzle for each of these. In this technical brief, I consider the role Java will play in promoting thin client architectures.

Which Thin Client?

Thin client has at least two meanings, as discussed in Distinguishing the Mulitple Meanings of Thin Client and Fat Client. The first, which refers to physical platforms, is not what is considered here. Rather, this brief concerns itself with physical software architectures. In this context, thin client implies that only the user interface and minimal application logic reside on the desktop. The bulk of application logic and the database access component are deployed on servers. Thin client architectures are useful for a variety of systems, especially those that include significant business logic that may be shared with other systems or which may change frequently. This architecture can also be scaled effectively, and it is generally easier to manage the configuration.

Thin client architectures by no means require Java or a Web browser. In fact, they pre-dated both of these technologies. Virtually any tool can be used to create thin clients, including notorious "fat client tools" such as PowerBuilder and Visual Basic. It is at the discretion of the architects and designers of an application as to whether thin client is the proper model to implement.

JDK 1.02

By itself, JDK 1.02 did not provide database access from Java. Using native method calls, it is possible to use APIs such as ODBC to read and write databases from Java applications; applet security requirements deny the use of native calls.

The lack of a means to directly access client/server RDBMS engines from Java is probably the greatest barrier of entry for corporate IT shops evaluating Java for application development. The bread-and-butter architectural style for these departments is, as characterized by Gartner Group, remote data management. To use Java as implemented in the JDK 1.02 requires a 3-tier architecture, with the accompanying slimmer (although not necessarily thin!) client. While more sophisticated shops have been evolving in this direction already, most are not ready to take the plunge.

JDK 1.1

JDK 1.1 includes support for JDBC, a native Java interface for RDBMS access. Several database vendors (e.g. IBM, Sybase and Borland) and ODBC driver providers (e.g. Intersolv) are providing drivers for this interface to use. Following this are tools such as Symantec Visual Cafe Pro and Mojo that will provide "data aware" Java widgets that can be wired to JDBC data sources. This removes the corporate barrier of entry. Of course, it does this by supporting the application architecture that is familiar and comforting, remote data management, also known as fat client.

Evolving Beyond Fat Client

A programming language is not sufficient to move development groups away from the architecture with which they are comfortable. Java alone is not enough. One key will be tool support. Java will need development environments that support application partitioning. These must move away from wiring widgets to data sources. Instead, widgets should be wired to objects (class instances), and objects should be wired to databases (with hooks available for applying serious logic to the wiring). To support partitioning, object proxying must be transparently available. An ultrathin client would consist of user interface widgets and proxy objects. The proxies would mirror the state of the "real" objects on a server, which in turn would be wired to data sources either directly or indirectly. Java's RMI may or may not be the right technology for proxying; ideally, the proxying mechanism would be "hot", so that the server objects would push any state changes to the proxies, rather than require that the proxies poll for changes.

Ideally, of course, the development environments will support functions traditionally associated with deployment and operations. Take a look at Forte if you'd like to see how far the environment can be stretched.

More important than development tools is knowledge. Development groups must learn about more advanced architectures, and evolve their development processes to include architecture evaluation and feasibility prototypes. These activities may also have tool support, with vendors including SELECT Software, Rational Software and soon tools based on Microsoft's repository.