"Reality is asynchronous." That's what a hacker might say. Einstein would say "nonsimultaneous." Time and space are a continuum: two aspects of the same thing. That's harder to swallow. Today, synchronicity and asynchronicity are hard wired into our brains, our perceptions, and our habits. Phone conversations are synchronous; email is not. But then again, everything is relative.

Albert Einstein: Time and space are two aspects of the same phenomenon. Jim Waldo: You could say the same about communications and persistence.

Virtual Reality

The Web has impressed upon us what physicists could not. We have learned relativity from a mosaic of interconnected computer networks. It's what we do everyday. Send messages of almost  unlimited length in almost  no time across almost  infinite space. Store digitized writings, images, and sounds in databases and object repositories. Transmit electronic documents, voices, movies, and music, serially, through phone lines, coaxial cables, and satellite dishes. Reconstruct streams of bits at their point of arrival as hierarchies of interrelated digital objects. Process compound objects with mailers, telephones, video players, http clients, ftp servers, store-and-forward messaging daemons. Clone information and entire directory trees at mirrored ftp sites. Many people find themselves navigating a vast information space of virtual objects. Intuitively they hold in mind a model of a complex, dynamic scenario: a pulsating aggregate of nonsimultaneous, partially overlapping, distantly occurring, interrelated events. Reality is relative and ever-changing.

Reality Check

Is relativity relevant to Java^TM? Jim Waldo thinks so--especially when it comes to persistence. "We've been conditioned to think of data transmission and data storage as two different things. We're either dealing with a wire or a box," says Waldo.

That sounds right. You store stuff in your box. You send stuff to other boxes over a wire connected to your box. So we have our two basic divisions of computer science: networks and communications on one side; databases and persistent storage on the other. "But it's like relativity," Waldo continues. "Just as time and space are the same, so are communications and persistence."

If you think of persistent object storage as traditionally presented, what Jim says sounds as obscure as the theory of relativity. But object-oriented programming has changed the way we think about information processing. Procedural programming reinforced a static view that separated programs into data and procedures. We've learned that artificial separation of programs into data units and processing units leads to unnecessary complexity. In large programs, separation of data and procedure causes us to lose sight of important relations. Processes with local state and local procedure make more modular, extensible, and manageable systems. It makes sense to explicitly associate data with operations that affect them.

Diskless in Cyberspace

"There's a view of persistence that most people have where an application's permanent data lives on a local disk and gets pulled into a program's memory as needed," says Waldo. "We're not talking about that kind of persistence. What we're saying is data storage and data transmission can both be solved with the same approach using the same programmer interface. You don't need to worry about whether you are writing to a disk file or a communications channel."

At first this vantage point seems more twisted than coaxial cable. As programmers, we're used to thinking, "Am I dealing with a wire, or a box?" From where Waldo sits, it doesn't matter. With the ability to efficiently serialize objects and later reconstruct them, persistence need not be so narrowly defined as local storage. Your persistent data may not be on a local disk. It may not even be within a local network. It might live in a shared workspace on the other side of the globe.

Waldo's twist on persistence makes perfect sense given current trends. The telephone, the computer, and the television are losing their identities as distinct communications devices. We're seeing a proliferation of small devices interconnected through an expanded internet. Cable companies and telephone carriers are already "duking" it out for territorial rights. There's a lot of talk about diskless workstations. For example, in the near future, telephones, television, and low-cost computers may operate with local cache memory, but without local disks. Permanent storage for users of these devices will be supplied by a service provider.

The idea of remote persistence plays well into the expansion of commercial internet services. "I think of persistence as reconstruction over time," says Waldo. "The traditional view of persistence is useless on diskless workstations, and that's where we're headed. That's clearly the way Sun and JavaSoft are headed. Prototypes of Java Desktop Systems with the Java¹ Virtual Machine embedded in high speed chips have been buzzing on Java for some time now.

From Dumb Terminals to Smart Boxes

Distributed computing has become a reality--almost by accident--with the rapid growth of web servers. Traditional persistence wasn't designed for distributed computing. Current web technology deals with relatively unstructured data. Complex objects are not passed between web servers and clients. In fact, HTML is only a modest extension of the dumb terminal approach to computing. But even this older technology provides a good model for the use of persistence on the Web.

Many users access the Internet through service providers over the phone line to send and receive mail, or to maintain personal or business web pages. Low bandwidth client applications have certain advantages on low speed modem connections. Newsgroup readers, such as trn, and mail readers, such as pine and elm, allow users to read, compose, and file mail by manipulating (persistent) data on a remote server. A user types commands that are sent to the mailer, newsreader, or text editor; the mailer, reader or editor responds by sending screenfuls of information back to the user's terminal.

The key to making this work on a slow network or serial connection is the smallest amount of information (derived from the persistent data on the remote machine) being sent to the user. In the past, the natural unit of data transfer has been a screenful of data (where a screen is defined as the number of rows and columns of text used by the terminal program).

Although modern Web browsers appear to be more sophisticated than dumb terminal applications on the surface, GUI browsers extend the basic dumb terminal model only slightly. GUI browsers provide a more powerful local application that runs on the user's machine, but the idea of sending only handfuls of data at a time remains at the core of the interface. Instead of servers sending screens  of ASCII text, they send pages  of HTML code mixed with ASCII text. The HTML code may indicate that graphic data (static images or movies) or sound data are available and intended to be displayed at a given point on a page. But the browser is free to ignore this information, and displays only text with headings and hypertext links. When network traffic is heavy, many Web surfers elect to turn off graphics altogether to reduce the bandwidth of communication taking place between client and the server.

Beyond HTML

For more complex data, a more powerful persistence mechanism is required, both for storage and transmission. Instead of a remote server letting you run a mailer, it might let you run a CAD program, or help you put together a slide show for a business presentation using clip art and graphics residing on the server. Such applications frequently involve complex data structures with hierarchies of binary objects with internal cross links and references that can be difficult to break down and reconstruct.

Ironically, the answer to the problem comes from research that was originally intended to streamline local storage and access to small pieces of a large database residing on a local disk. The technology of object databases was orginally thought to solve a problem of local persistent storage. But the serialization of objects required to store complex data in object databases turns out to be useful for breaking down application data, sending it across a communications line, and reconstructing it at the other end.

Object serialization lets complex hierarchies of objects be flattened, serialized, spewed across a serial line, and reconstructed at the receiving end. This is what Waldo is referring to when he talks about "persistence on a wire." Let the service providers provide the storage. Let small diskless devices proliferate, thereby saving the user the cost of hardware and the headaches of system administration.

JavaSpace: Persistence on a Wire

What really gets Waldo going is JavaSpace. JavaSpace takes advantage of remote persistence while viewing communications and persistence as two distinct representations, or phases, of the same data. Ice and steam are different phases of water. Consider the problem of getting a block of ice from one room to another room located a mile away when the only available communications channel is a long hose or pipe. You could melt the block of ice, turning it to water, send it through the pipe, capture it in a mold in the remote room, then freeze the water to reconstitute its original structure. Ice to water to ice is a crude model for persistence on a wire.

JavaSpace takes these basic operations much further, and allows networks of objects in a single container to be sent back and forth between a server and a client, without the programmer having to worry about the structure of the data or having to monitor data transmission. If an object is successfully transferred, normal program flow of control continues. Otherwise an exception is thrown to indicate that the object should be sent again.

"A JavaSpace is somewhere between a database and a file," says Waldo. "In effect, a JavaSpace is an unordered collection of objects." While a JavaSpace does allow associative lookup, it does not provide the full-blown convenience of a database query language. You can search for objects in a JavaSpace by keyword, but you will retrieve only the first object found for which the keyword matches. You do not have the convenience of a database query language for easy iteration over all objects in the data space that match a given set of criteria. But a JavaSpace does not require powerful data access and lookup mechanisms. All of a user's working objects can easily be given unique keys much like filenames given by a fully-qualified directory path

JavaSpaces will be invisible to users. Users should not be conscious of where or how CAD drawings, slide shows, or persistent desktops are stored or transferred to their local machines or remote servers. JavaSpaces, like Dictionaries, HashTables, and Stacks, provide powerful abstractions that application programmers and service providers can use to turn normal applications into distributed applications with very little programming overhead.

Get Serial

The code for the DrawTest applet included here (DrawTest.tar, 11k; DrawTest.zip, 3.5k) shows how object serialization can be added to existing Java programs to make it easy to save and restore application data with little effort. This is true even when issues of saving and restoring data are not considered during the design of the program interface.

Object serialization technology is now available for Java (JDK 1.0.2 or later). It will be provided as a standard part of the JDK 1.1 Java distribution. To run the DrawTest applet with earlier versions of Java, download the appropriate files from the JavaSoft Web server at Java Systems East.

It's a Small World After All

The power to persist changes reality. Java support for object serialization makes it easy to add persistence to any application. JavaSpaces show one of many ways persistence opens access to the wired world, allowing users to beam complex object structures across networks, phone lines, satellites, and throughout the evolving space-time continuum of cyberville.