In the past, developers have used several different techniques -- cookies, CGI scripts, and LiveScript, to name a few -- to create persistence and to perform computing on the server. Unfortunately, each of these methods is lacking in one way or another. Let's take a brief look at each of these techniques before we go any further.
- Cookies are a fairly crude (and not widely supported means) to maintain state on a Web site. A cookie is simply a line of data in a file that is stored on a user's hard drive. Properly configured Web servers access and update the information stored in this file. Cookies currently cannot be shared. For many applications this is not a problem, but as users begin to create relationships with more than one application, the "selfishness" of cookies will present a challenge. Cookies also offer little security and can be stolen by rogue software.
- CGI scripts are the punch cards of the '90s -- fixed-format sets of instructions that are difficult to maintain and to extend. CGI is currently used on 40 percent of Web sites to track relationships. Unfortunately, CGI scripts do not support the core concept of object-oriented technology -- the data and the method to manipulate the data are related formally -- and places the work of designing and tracking relationships squarely on the shoulders of the designer.
- As consumer demand for interaction among Web sites increases, CGI eventually will be replaced with an architecture that supports the need to create relationships with a Web site as well as relationships among Web sites. JavaSoft's JECF framework is an excellent example of this type of architecture. How do I use information from two or three different servers to perform some activity?
- LiveScript supports communications over sockets, but without a bit of fancy programming it is not able to transmit portions of a program while the program is in operation. To do this with LiveScript (and also CGI), you would need to develop a line protocol -- a definition of how the bits and bytes move over the wire -- which is time consuming, error prone, and dangerous from a security perspective.
I've shown you the alternatives. Let me now take a moment to offer up my reasoning for why a change is in order.
When system designers and developers set out to design Internet/intranet solutions, one key factor they must take into consideration is object passing. The ability to pass around objects without having to develop a line protocol greatly reduces software costs. Remote method invocation (RMI) supports the transparent transmission of objects to other nodes on a network. Once the object has been transmitted, the data is processed by the method you called. For example, suppose you have an object containing some data you need to get to the server. RMI will magically send this object to the server by locating the Java object on the server you wish to have act on this data. This process eliminates the need to develop a line protocol. For example:
DataForServer = new DataForServer("a",1.0,3.14,2.718,new Image(), new URL().... );
.... Some steps here to locate the server
remoteServer.processData( dataForServer );
Try performing the same task with the other methods, and I think the benefits of RMI will be clear. Java 1.1 supports serialization and RMI as part of its core services. Unfortunately, many Web browsers are still months away from supporting the core because they are not written in Java. By learning to use RMI, you will be free of all the thorny capability issues with cookies, LiveScript, ActiveX. plug-ins, and other cumbersome technologies. RMI is an architecture to build on -- the others are implementations with ad-hoc architecture.
To address the lag time between the release of JDK 1.1 from JavaSoft and support of JDK 1.1 in browsers, JavaSoft's RMI group has provided a plug-in for Netscape that lets Navigator 3.01 serialize and deserialize objects, as well as communicate using the RMI protocol. Sorry Internet Explorer users: You'll have to wait for Microsoft to support JDK 1.1 (expected in the IE 4.0 release later this year).
In this article, we will:
- Compare two techniques for writing objects to a server -- using sockets and using RMI.
- Examine the reading and writing of objects to implement object-oriented databases.
- Rate the performance of RMI for saving objects.