 | Level: Introductory Joseph Sinclair (JosephS@iisweb.com), Solution Architect, Integrated Information Systems Inc.
01 Mar 2001 The Java platform has made some astounding progress in the past few years, but some of the most popular uses of the technology are completely different from its original design goals. While the technology began life as a way to add interactivity to Web pages through client-run applets and applications, the most popular current use is in server-based J2EE systems. As enterprise systems give way to public Internet applications, it is important to understand what new technologies are being developed to help the Java platform achieve its full potential on the client side. In this article, you'll see how a combination of old techniques and new technology can help you meet this goal. What ever happened to applets?
When the Java platform was first announced, it was heralded as the way to take the Web -- a mostly static collection of simple pages -- to a stunning level of interactivity. The primary goal of the Java initiative was to provide developers the ability to create small applications that could run on any client machine and provide highly interactive experiences using a combination of client processing and server-provided data.
Somewhere along the line, much of the Java promise on the client was lost. There were many reasons for this unfortunate turn of events, including:
- Corporate firewalls often block Java applets.
- Many clients do not provide fully compliant Java virtual machines.
- Security issues prevent applets from fulfilling many useful roles.
- The cost of downloading a complete user interface every time a page is viewed causes many users to shy away from Java applets.
- The effort required to re-implement many user interface functions (printing, file management, and a variety of similar tasks) for each system and on each different platform, causes many developers to avoid Java applets.
As Internet commerce grows, end-user processing power increases, and the demand for communication bandwidth skyrockets, the use of Java technology in client-side components again becomes enticing. However, we need to explore new ways to make use of client processing without encountering the same stumbling blocks that relegated Java applets to mostly ad-ware and scrolling news tickers. These problems can be alleviated with a combination of new technology and old techniques, some of which have been forgotten in the rush of "Internet-time."
I always wondered why they called it JavaScript
One of the most overlooked uses of Java technology on the client is the integration between Java applets and JavaScript. The JavaScript standards have long provided a method for scripts to call applet classes. Applets can also call script methods. This integration allows us to use each technology to its best advantage. We develop and maintain the required functionality and leave the user interface design totally in the hands of Web page developers. Furthermore, by exploiting this integration, we enhance the user experience while maintaining a minimal client footprint.
The LiveConnect technology in the JavaScript standard allows us to enable scripts within a page to call applet methods. We simply create the necessary Java utility classes and provide the JavaScript designers access to those methods. The com.netscape.JSObject class allows us to access the JavaScript methods and objects. It provides a means to make interesting and significant changes directly to the Web page and to call JavaScript methods from Java code. Using this connection between JavaScript and Java applets, we are able to perform activities that are not possible with JavaScript or Java applets alone, but are attainable through the integration of the two. Furthermore, integrating these technologies can often reduce the number of times that a Web page needs to be posted to the server, which in turn reduces user wait times, server processing times, and the maintenance of session state on the server side. Consider the following examples:
- Using a Java applet to look up address or telephone number information in server-side databases on a background thread while the user continues filling in a form
- Using PKI techniques to encrypt communications between systems when SSL is inadequate
- Using the DSA standard to sign requests, providing strong authentication of both the message and the sender
- Using a Java applet to submit calendar changes to a server database and update a local calendar display in the background, eliminating the need to constantly refresh the entire calendar page and vastly reducing the apparent latency of the application
- Using a combination of a Java applet and JavaScript code to display live, frequently updated content in a browser document; the combination allows the content to actually be printed without us having to write print routines for every conceivable client platform
Listing 1 demonstrates how you can use JSObject and LiveConnect to handle a telephone number validation and simultaneously reformat the telephone number into a standardized form. Note that this is example code only; I've left several necessary calls out of the server connection method to simplify the listing. This example is called from JavaScript when the telephone input field is changed. The Java applet then goes out to the server to obtain a standard-format telephone number string, which is placed back in a hidden field. A real implementation of this code would implement the validation and server connection in a background thread so that the validation is transparent to the user. This example also uses one of the other techniques that make client-side Java programming attractive: HTTP connections and integration with server-side code, specifically servlets and JSP pages.
What about server-based resources?
What about resources that must reside on the server? Such server-based resources include address validation, shipping calculations, and credit card verification. The supporting data and security-sensitive processing must stay on the server side, but much of the processing-intensive validation, data conversion, and derived-value calculations can be migrated to client systems. Some characteristics of the Java language that support this concept include:
- The Java language's intrinsic support for HTTP connections via the
HttpURLConnection object, as well as the rest of the java.net package, provides a clean and effective way of producing and packaging data for communication between server Java code and client Java code.
- Much of the Java applet code on the client will be virtually identical to the code that would be running on the server.
We are now free to split a variety of tasks between the server and client, reducing the server load and possibly reducing network connections as well. The exact distribution of tasks will depend on the type of system and the nature of the user community, but almost any system can benefit from the application of some additional client-side processing, for example:
- An applet class could convert data from a series of forms into a single XML string that is easier to process on the server.
- An applet class could perform data compression on information to be uploaded to the server and stream the information in small packets to improve reliability.
- An applet class could perform address and shipping calculations (which often require interaction with larger server-based databases) while the user is filling out check-out forms. This approach would reduce the time required for final check-out and simultaneously provide the user with accurate shipping and tax information before the order is submitted.
To take full advantage of this technique, we need some way of submitting small requests to servers that return specific data as response. Java servlets provide exactly this capability. Many developers are not fully aware that servlets can return any arbitrary data in a response, not merely HTML or XML. By returning a serialized object or a packet of compressed data, the servlet can perform tasks such as validating an address or calculating shipping and taxes, while client code hides the network latency in a background thread. Listing 2 shows a servlet that accepts an HTTP GET request with a Zip code and returns a shipping cost. Again, significant portions of the real code are left out for clarity.
Note that I used the ObjectOutputStream object to write the entire object graph to the response. The content type would need to be set to some appropriate value and a content handler distributed to the client. This approach allows a Java object to be returned with all of the important information for calculating a customer's shipping, handling, and tax charges. If this object were contacted from a background thread, the user wouldn't even be aware of a server round trip.
New techniques to save the day
All of the techniques described to this point have been available for some time, and many of them are in use in various systems around the world. I promised you some new techniques, and now it's time to deliver. The most interesting new technique for client-side Java technology is generically termed weblets. One implementation of weblets is DirectDOM from IBM alphaWorks. DirectDOM provides full access to the browser DOM tree -- DOM Level 2 according to the November 13, 2000 W3C recommendation -- from within Java code. Weblets do not have a user interface of their own and perform all of their work by manipulating the live DOM document within the browser. This approach allows a wide variety of techniques, many of which previously required complex JavaScript. It is important to note that although DirectDOM is a very enticing technology, it is still in an alpha status, requires the latest version of Internet Explorer or Mozilla (M18) to function, and is currently incomplete. This technology does, however, provide an exciting glimpse of what will be available in the near future. Some examples of what is possible will explain the excitement behind this new technology:
- A check-out Web page with rich graphics and enticing visuals. Add a weblet, and the multiple steps of check-out processing can be handled without explicit round trips to the server by literally swapping forms into and out of the page as the user progresses. When the entire check-out process is ready for confirmation, the weblet submits the entire package to the server and normal check-out processing continues from that point.
- A Web page that displays proprietary information. A weblet tags along to respond to a print or save request within the browser by blanking the page, preventing that data from being shared indiscriminately.
- The ability for a user to request a report from a Web-based application. Summary data is transmitted immediately, and a weblet is included to download report details on a background thread. If the user is interested in the details behind a line item, the weblet responds to a mouse click on that line by displaying the details below it. The user need never be aware that the details were downloaded in the background after the summary page was displayed.
A longer example highlights how a weblet might work. This example, shown in Listing 3, the HTML page delivered to the client, and Listing 4, the Java code for the weblet class, is actually functional, although certainly not suitable for use in a production environment and not entirely complete. This example downloads a long page with two forms and a weblet tag. The weblet replaces the forms with some introductory text and swaps the two forms in and out of the page as the user progresses through the demonstration.
Why does any of this matter?
Why should we be concerned with client-side Java technology? Why not just build systems that work for network computers or other extremely thin client systems and perform all of the processing on the server? To put it simply, we cannot afford it. The distributed system models (n-tier architectures) were developed because it is too expensive to install enough processing in a server room to support the huge processing load required for very large client bases. Client-side Java technology allows us to vastly improve user experiences -- through round-trip reduction, greater levels of interactivity, and improved data validation -- while simultaneously reducing the cost of operations for large systems. Client-side Java technology further allows us to accomplish tasks, such as token-based digital signatures, that servers simply cannot perform. The use of client-side Java technology in conjunction with servers supporting the Java 2 Platform, Enterprise Edition provides the most powerful architecture yet devised for a single development platform, and we would be remiss if we did not take full advantage of it.
Resources
About the author | | | Joseph Sinclair is a Solution Architect with Integrated Information Systems, Inc. in Tempe, Arizona. He has been working with computers and microelectronics in a wide variety of roles for over 10 years. Joseph can be reached at JosephS@iisweb.com. |
Rate this page
| |
