he hype during the mid-to-late 1990's over Java's utility to run swarms of autonomous applets was greatly exaggerated. This early enthusiasm (and marketing) for Java as a language with which developers could develop cross-platform applets was doubly unfortunate. Not only did it fail to deliver the applets promise because of weaknesses in the platform's technology, but these failures also shifted Java development away from applet-rich "thick" clients and toward server-centric, thin-client solutions, even in relatively homogenous intranet environments. Developers seemed to forget the fact that because Java is very portable across multiple platforms it is very suitable for developing distributed thick clients.

Today, in addition to client portability considerations, the need for platform-independent protocols is growing. The increasing use of XML-based technologies such as SOAP allows the developer to concentrate on the representation of data without worrying as much about the underlying hardware or network. Additionally, the text-based nature of XML-based protocols allows simpler debugging, although this comes with a speed tradeoff.

Because most of my work involves interfacing rather closely with the machine, my first inclination for addressing portability typically is to use Perl. Although Perl is a good all around language that offers portability to a wide variety of platforms, Java has advantages. It offers a well-defined set of graphical widgets, digital signatures, and a mechanism to deploy applications across multiple clients, namely Java Network Launching Protocol (JNLP).

When my database server vendor added a SOAP-based API to what had been a purely PHP-based interface, I decided to take the plunge into Java thick-client development with SOAP. I developed a small client to interface with the underlying database via documented SOAP methods. This enhanced functionality also enabled me to develop some much-needed administrative tools and explore intranet-deployed clients using Java Web Start.

Figure 1. The Apache Axis TCPmonitor Utility

I began by combining Java Web Start and SOAP (using JAX-RPC) to develop a centrally deployed proof-of-concept client. I designed a client that connected to the SOAP server and then authenticated, retrieved, deserialized, and displayed an array of data structures from the server. Other developers could then use this program as a template, adding more general-purpose features as needed.

Laying the Groundwork
XML-based messaging has been a hot topic for several years now, and a lot of effort has been made to develop classes and libraries to facilitate the uniform deployment of XML-related technologies. The developers at Sun have been hard at work adding new features to Java—version 1.4 of the Java Standard Edition SDK comes in at about 93 megabytes uncompressed. It should come as no surprise that Java includes a fairly complete toolset to simplify program development. Included among these tools is JAX-RPC (Java API for XML-based Remote Procedure Call). Additionally, I downloaded the Apache Axis toolkit, another SOAP RPC API, which provides important extras such as the tcpmonitor utility (See Figure 1).