A walk through cyberspace

Web pages are great. I get a lot of information from Web pages, and I use them to deliver articles and other information to readers. Nevertheless, I have always had a nagging feeling that a significant portion of the Web is missing. In this article, I’ll explain what I find lacking in the current World Wide Web and suggest a way that Jini technology could help supply the missing functionality.

The document metaphor

Web pages serve as an electronic form of what people have used for a long time to transmit information: paper documents. In the real world, paper documents come in many shapes and sizes. But whether you are looking at a book, a magazine, a grocery list, a modern yellow sticky, or an ancient scroll, the document is likely to be composed primarily of text and graphics. Similarly, although Web pages can sport interactive applets and flashy animations, most Web pages, like their paper counterparts, are composed primarily of text and graphics. Because people use Web pages in many of the same ways they use paper documents, Web pages evoke a document metaphor on the network.

Web pages are extremely well suited for delivering information to people electronically. Because people are used to getting information from documents in the real world, they understand the document metaphor of Web pages.

One kind of information that Web pages are particularly adept at transmitting to people is links to resources. If you click on a hyperlink, the browser loads the referenced page. People quickly learn to use hyperlinks, in part because “point and click” is easy to understand, but also because hyperlinks bear a strong resemblance to references in paper documents. Hyperlinks and Web browsers merely automate the delivery of such external resources.

Another role a Web page can play is that of a form. For example, to subscribe to my newsletter, you can go to a Subscribe page at Artima.com that contains a small text box and a button. You type your e-mail address in the box and click the button. The browser sends your e-mail address back to the Web server, which hands it to a CGI Perl script. The Perl script adds your e-mail address to my mailing list, generates a Web page that says you were successfully added, and hands the Web page back to the Web server. The Web server forwards the Web page to the browser, which displays it for you. This response page informs you that you are now on my list and, just in case you ever change your mind, gives a link to the Unsubscribe page.

Filling in forms on Web pages is reminiscent of filling in forms on paper. The process I go through to subscribe to a print magazine, for example, is similar to the process visitors to my Web site must go through to subscribe to my newsletter. Magazines often include a subscription card that contains a form. To subscribe, I fill in my name, address, credit card number, and so on. Then I mail the card to the magazine. Because people are well versed in filling out paper forms, filling in text boxes on Web pages is a natural and easy-to-understand way for people to submit text-based information to the network.

The three fundamental aspects of the document metaphor — page units filled primarily with text and graphics, hyperlinks to external resources, and forms to fill in and submit — are very familiar to users. Interacting with Web pages feels natural to people.

Web pages and services

Another way to think of Web pages, besides thinking of them as documents, is as services. By service I mean anything that gathers information of some perceived value or distributes it to other entities. Thus, Web pages provide services to people.

A basic Web page of information offers an information service. If I need a recipe for pumpkin pie or the weather forecast for Annapolis, Md., I can probably find Web pages that provide this information.

A Web page that links to other resources on the network offers a resource organization service. If I need links to Jini resources, for example, I can visit any of several Web pages created for that purpose. By browsing these Jini resource organizer pages, I can decide which Jini resources to order from the network with just a click.

A Web page that is full of text boxes and buttons offers a form service. Whereas information and resource organization services enable me to extract information from the network, form services enable me to submit information.

These three kinds of services are usually combined in single Web pages. Most information service pages include links to other resources, which means they also offer resource organization services. Most form service pages include information service text that, at the very least, explains how to use the form service.

These capabilities of Web pages have generated a massive proliferation of higher-level services, all of which conform to the document metaphor. I can buy and sell stocks through Web pages. I can send and receive e-mail, auction off my old bicycle, do my Christmas shopping, organize my daily schedules, and get maps and directions.

So what’s the problem? What could possibly be missing from this World Wide Web, which overflows with information and services? My complaint is that the document metaphor of Web pages constrains many higher-level services, especially those that require a lot of interactivity.

Pounding round pegs into square holes

When I’m traveling, I often read my e-mail through Yahoo! e-mail, an elaborate service offered through Web pages. But when I’m home, I use Netscape mail, which offers the same service but without the Web page document metaphor. Eudora also offers the same service without the metaphor. Why don’t these desktop incarnations of the e-mail service use the document metaphor? My feeling is that the Web page document metaphor is not the most natural user interface for many services, including e-mail. Yahoo! e-mail uses the document metaphor because it has no choice but to use Web pages to deliver services over the Internet.

My sense is that many round services are being pounded into square Web pages, just so they can be delivered across the network. A toaster service need not be elaborate to hit up against the constraints of the document metaphor. For example, imagine that you want to control your toaster’s dark-light setting. A toaster is a very simple appliance, and a remote dark-light setting is a very simple service that the toaster offers, but even this simple service would be clunky to deliver via a Web page. It could of course be done, with a form that looked something like this:

It works, but the settings would feel more natural on a slide control, which HTML doesn’t offer. Of course, I could include a Java applet in the Web page:

Now I’ve got my slider but I’m still not happy. Why not? Because my toaster’s slide control is sitting in the middle of a Web page. I can live with it, but it feels clunky.

Pages and places

In the real world, when I want to interact with my toaster, I don’t go to the bookshelf, grab a book, open it to the toaster page, and move a knob embedded in the page. Rather, I go to my kitchen, a “place,” and interact directly with my toaster, an “object.”

The way I interact with my toaster in real life is how I’d like to be able to interact with the toaster service on the network. In fact, I’d prefer to interact in a similar way with any kind of service that doesn’t mesh well with the document metaphor. I’d like to go to places on the network and interact directly with objects.

What is a “place”? A place is simply one kind of object that provides a resource organization service. An example of a place would be a chunk of network-delivered software that looks like the Macintosh Finder, a collection of network resources that can be viewed as a list, with or without details, with small icons or large icons, and so on. When I double-click on an icon, the place asks the browser to grab that resource. The requested resource could be a Web page, an object, or another place.

I believe that a space metaphor — in which people go to places on the Net and interact with objects — would be an intuitive way to use the network that augments the current dominant document metaphor. People should be familiar with space, after all, because that’s where they live.

To me, the term Web doesn’t necessarily imply a set of interlinked pages on the network, but rather a set of interlinked resources. Pages are currently the dominant resource unit on the Web, but places and objects could also conceivably participate on the Web as well. A Web of places, each of which contains links to objects, documents, and other places, yields a space metaphor that is more deserving of the term cyberspace than the current dominant metaphor used to navigate the Web. Although many people call the current Web “cyberspace,” it is really more like a “cyberdocument.”

Documents and desktops

The other constraint of the document metaphor, aside from its forcing everything onto pages, is the limited accessibility of those pages. Granted, one of the original prime selling points of Web pages was their platform independence. Unlike a lot of other things in 1994, Web pages didn’t run just on Windows. You could look at a Web page on Windows, OS/2, a Macintosh, Solaris, Linux, IRIX, and many other platforms. Web pages have a high degree of portability, which nevertheless has its limits.

Most Web pages, for example, don’t look very good on a 13-inch television screen viewed from a horizontal position at a distance of 12 feet. The text is too small, and if you increase the size of the text, you can view only a small portion of the page at a time. Similarly, Web pages don’t work very well on small displays. Viewing a Web page on a palm device is like trying to read a white paper from a yellow sticky. What’s more, Web pages are not interesting to talk to if you call them up on the phone. It is difficult to interact with Web pages if you have a speech-only access device, or if you are temporarily using your eyes for other tasks, such as driving a car.

Web pages are best viewed about two feet away from a high-resolution screen, and they’re best operated with a mouse for clicking on links and a keyboard for typing into forms. In other words, Web pages are best suited for desktop computers.

In the future, more devices in our environment will be embedded with microprocessors and connected to networks. This holds the promise that we’ll be able to access a wealth of information and services from the network at any time and any place. The document metaphor of Web pages is ill suited for the emerging hardware environment. In contrast, one of the advantages of an objects-in-places metaphor is that objects can be defined such that you can access their services in many ways from many kinds of network portal devices.

What does this have to do with Jini?

As this is a Jini-oriented column, you may be wondering what an objects-in-places metaphor for the Web has to do with Jini. At the second Jini Community Summit, which took place October 17-20 in Annapolis, Md., venture capitalist Ted Schein gave a talk titled “Succeeding with a New Technology.” Schein outlined several guidelines for entrepreneurs seeking venture capital. One of his guidelines for those planning to do something with Java was “Know why you are using Java.” Given that he was one of the founders of the Java Fund, Schein said applicants are often surprised when he asks “Why Java?” But, he said, Java should be used to solve only problems that it is well equipped to address.

In the case of cyberspace, Java and Jini are well equipped to help solve the technical challenges presented by an objects-in-places metaphor. Java enables the network mobility of code and objects. Jini moves the point of agreement between the parties of a distributed system from network protocols to object interfaces and provides a clean separation of functionality from the user interface.

Java applets

In my book, Inside the Java 2.0 Virtual Machine (McGraw-Hill, 1999), I spend the first four chapters explaining how Java’s architecture enables the network mobility of code and objects. In short, Java enables network mobility through the portability of the Java Platform, the homogeneous execution environment of the Java Virtual Machine and Java API, and the security capabilities built in to the platform. I consider network mobility to be the main point of Java’s architecture. As Bill Joy said at the first Jini Community Summit, “We built the JVM to let objects move around.”

Of course, Java’s mobile code capabilities are nothing new. Back in 1995, Sun released the HotJava browser, which showed how little chunks of code called Java applets could be stored on a server and flown across the network to Web browsers, where they would be executed. In 1996, the year I started my first JavaWorld column, I wrote a lot of applets, including an applet that served as an organizer for other applets. I thought about using applets as the basis for an objects-in-places metaphor but quickly learned that Java applets had two major problems. First, applets sit inside Web pages. Even if you write a client that grabs an applet directly using an HTTP URL and then runs it in its own window, the AppletContext object you must pass to the applet has methods — such as showDocument(), showStatus(), and getApplets() — that to a great extent make the assumption that the applet’s context is a Web browser. Thus, even though you could conceivably represent places with applets, such places would end up embedded in the middle of a Web page, still trapped in the document metaphor.

The other main problem with applets is that by their very nature they are user interface components. Applets are AWT (Abstract Windowing Toolkit) panels. Because the functionality of an applet is married to its user interface, it is difficult to use an applet as the primary delivery vehicle for mobile objects across the network: some of the network’s myriad computers and devices will not be able to display applets. In the end, I decided that the proper place for the Java applet was embedded in the middle of a Web page, and that its primary use was to serve as an interactive illustration for the surrounding text. The applets I wrote to accompany my first JavaWorld column and first book all played this role of interactive illustration.

Castanet channels

In the fall of 1996, the editor of JavaWorld, Michael O’Connell, invited me to sit in on a meeting in which Kim Polese and Arthur van Hoff of Marimba would reveal their soon-to-be-announced product, Castanet. Michael invited me, he said, partly because he thought I might find it interesting and partly so I could serve as a technical BS detector. Happily, I detected no BS and was very impressed by the technology. I even wrote an article about Castanet for JavaWorld that appeared in December 1996.

Castanet influenced my concept of cyberspace, because that meeting was the first time I saw mobile code represented as icons that you could double-click. In its original form in 1996, Castanet enabled chunks of Java code, called channels, to be delivered across the network and cached on a local disk. As the channel evolved over time, the local cache would be updated. Because the channel was stored locally instead of delivered on demand across the network like applets, channels could start up faster and could therefore be larger than applets. And since a channel was stored locally, an icon on the user’s desktop could represent it. To start the channel, you double-clicked on the icon.

In my JavaWorld article, I stated that Castanet freed mobile code from the “browser metaphor” in which Java applets are trapped. (I now call this the document metaphor.) Castanet enabled users to interact with network-delivered mobile code in terms of the familiar desktop metaphor, which people had been using to interact with their desktop computers for years. Unfortunately for cyberspace, however, Castanet channels are themselves trapped in the desktop metaphor, which has one major problem in the context of cyberspace: the desktop assumes a local disk.

At its heart, Castanet aims to simplify the installation of desktop applications on desktop systems. Such simplification is important, especially in enterprises, but it does not fit an objects-in-places metaphor for the Web. Many embedded devices that will serve as network portals in the future will not have local disks. The ability to access a Web object from any kind of device, including devices that have no hard disk, is a core requirement of the emerging hardware infrastructure.

Jini services

Fast forward to the summer of 1998. I picked up a business section of the San Jose Mercury News in a coffee shop and saw an article about something new from Sun called Jini. I shook my head and said to my friend, “I can’t believe this. I think Sun may have done it again.” Java’s design had always impressed me, and Jini seemed to be yet another well-designed technology.

As I learned more about Jini, it occurred to me that several of Jini’s architectural features would be useful in cyberspace. Most of Jini’s advantages are inherent in its service object, a chunk of mobile code and object state sent from the service provider to the client. In effect, the service provider injects a small piece of itself, the service object, into the client’s address space. Jini considers anything on the network that can do something useful — whether it be a piece of hardware, a software server, a communications channel, a human, or anything else — to be a service. Each service is represented by a service object, which flies across the network and offers its service to clients via its object interface. The service object is what enables the contract between the various parties in a distributed system to be expressed in terms of object interfaces rather than network protocols, and what provides a clean separation of functionality from the user interface.

From network protocols to object interfaces

Jini’s service object raises the level of abstraction for distributed systems programming from network protocols to object interfaces, because the service provider, not the client, supplies the service object. As shown in Figure 1, a client interacts with a Jini service through the interface of the service object. If the service requires communication across a network, the service object performs the communication. Thus, the service provider controls both ends of any network communication: the service object and the server. As a result, the service provider gets to decide which network protocol is used to communicate between the service object and the server.

The service/object architecture has many advantages over the traditional client/server architecture, in which both client and server must speak the same network protocol. First of all, the service provider is free to make any changes to the implementation of the service object as long as they don’t break the semantic contract of the service object. (The semantic contract of an object is a detailed description of the range of possible behavior of the methods of a type, as defined by the creator of the type.) For example, a service provider can change the protocol that the service object uses to speak across the network to the server. A service provider can change the service object such that it implements more of the service functionality locally within the service object itself, and implements less on the server side (or vice versa). A service provider can change servers or implement a load-balancing scheme through which the service object selects one of many servers.

In addition to changing the implementation of the service object, however, the service provider can also make changes to the service object’s interface. Java has an extensive list of changes that can be made to object interfaces without breaking their binary compatibility with preexisting code. So, for example, if the service provider wants to add functionality to its service, it is free to do so. As long as it follows the rules of binary compatibility and maintains the former interface’s semantic contract, the preexisting client code will continue to work with the new service object.

The flexibility promised by the service object architecture will be very important in the emerging world of distributed systems based on diverse embedded devices, because the various pieces of these distributed systems will usually be created by different parties. The software they run will be updated at different times. I say that the flexibility is “promised” because it is not guaranteed by the service object architecture. The flexibility that enables service providers to make changes without breaking client code depends on a thorough understanding by all parties of the semantic contract of service objects and the adherence of all parties to those semantics. In a future Jiniology article, I’ll look more closely at how the difficulty of clearly specifying and communicating semantic contracts, and of verifying adherence to them, may affect the actual flexibility realized by the service object architecture. Nevertheless, so long as semantics are effectively expressed and adhered to, the service object architecture offers a great deal more flexibility than the traditional “agree on network protocol” client/server approach.

Separation of user interface from functionality

Another advantage of the service object architecture, aside from giving service providers the ability to make changes over time, is a clean separation of the user interface from functionality. As shown in Figure 2, a user interface is an add-on “user adapter” object separate from the service object, and it gives a human user access to the service.

Jini’s separation of user interface from functionality is what has been missing in Java applets, in Web pages, in Marimba channels, and, for that matter, in traditional monolithic desktop applications. In all of those forms the user interface is usually, if not always, intermingled with the functionality. In Jini, the service object is the functionality. The user interface is separate.

Jini’s separation of the two enables the same service to be delivered to many different kinds of computers and devices. The same service object can be used at any computer or device, but each device can select the most appropriate user interface given its capabilities and the user’s preferences to grant the user access to the service.

Handling non-Jini clients

Although Jini’s separation of functionality from the user interface enables a service to be accessible from devices with many user interface capabilities, the scenario illustrated in Figure 2 makes a big assumption: the client is Java and Jini enabled. But not every device will host a Java Virtual Machine (JVM). Not every device that has a JVM will support Jini. Those devices that support Jini may not be able to host service objects that require a later release of Java and Jini. Although user adapters extend the reach of user-accessible services to Jini-enabled devices with just about any kind of user interface capabilities, user adapters do not help services reach users who access the network via non-Jini clients.

However, Jini’s service object architecture offers one other option to facilitate the delivery of services to all devices, including non-Jini devices. A device that can’t host a Jini service object or user interface object can itself ask a service host to host the service and to place a protocol adapter object between it and the service. As shown in Figure 3, a non-Jini device talks to a protocol adapter via a network protocol. The protocol adapter talks to the service object. Similarly to the way a user adapter adapts a service to a human user, a protocol adapter adapts a service to clients that understand a particular protocol, including non-Java and non-Jini clients.

Jini service hosts can be deployed in local area environments. Non-Jini clients can discover a nearby service host and ask it to host a service and a protocol adapter. If no nearby service host exists, the non-Jini client can contact a distant service host with which it maintains a long-term relationship. Through service hosts and the appropriate set of protocol adapter objects, service providers can extend the reach of their Jini services to the non-Jini world.

Reaching human users and autonomous agents

The service object architecture gives a service provider a way to grant users of various embedded devices access to its service. By offering a rich set of user adapters, a service provider can reach users through many kinds of Jini-enabled devices. By offering a rich set of protocol adapters, the service provider can reach users through non-Jini devices.

The service object architecture gives the service provider many options on how its service will be provided. It also gives the service provider the opportunity to change the service gracefully over time. Service providers may wish to take advantage of one aspect of the service object architecture in particular and provide as much of the service as possible within the service object itself. The more the service object is able to provide the service without enlisting the help of a server across the network, the lighter the network traffic will be, the lighter the load will be on the server side, and the faster the service will appear to the client. The reason non-Jini clients would rather discover a nearby service host than use a distant one is that any computation done by the service object will be closer to the client and therefore probably faster. The main force acting on the service provider to implement the service on the back end is that persistent state must be maintained on the server side, not in the service host. But to the extent possible, service providers will usually want to push functionality off the server and into the service object.

One last place that Jini’s service object architecture allows service providers to reach is autonomous agents: software that runs independent of human supervision. Jini-enabled agents can simply use a service object directly, as shown in Figure 1. Non-Jini agents can use services through protocol adapters, as shown in Figure 3. For example, a just-in-time inventory management agent could contact a parts-ordering service at the proper time and order some parts. The parts-ordering service could also include user adapters and protocol adapters that enable people to make orders as well. Thus, Jini’s service object architecture provides service providers with flexible mechanisms for upgrading their services over time — and the means to deliver their service to human users and autonomous agents on myriad computers and devices.

A Jini service URL

The power and flexibility of Jini’s service object architecture make it an ideal technology on which to build cyberspace: an objects-in-places metaphor for the Web. But Jini, in its present incarnation, doesn’t have all the pieces that this metaphor requires. The first thing missing is a URL for accessing Jini services.

The Web is a huge set of interlinked resources, whose links take the form of URLs. Because URLs are strings, they can, to a limited extent, be remembered by humans, but to a great extent they can be incorporated in the resources themselves. What makes the Web a web is that many resources contain URLs that point to other resources.

Many people find URLs unwieldy and are puzzled by the need for so many dots and slashes. Despite this, URLs have entered the mainstream. They are given out on TV and radio advertisements, billboards, and even the sides of trucks. A Jini service URL would make it possible to advertise network-delivered services that are unconstrained by the document metaphor. A user types a URL into a browser’s location field, hits Return, and gets not a Web page, but a Jini service.

A user may also click on a link embedded in a page. A Jini service URL would make it possible for a link such as this to appear in the source code of a Web page:

My Email

The csp prefix stands for cyberspace protocol. On this Web page in a cyberspace-enabled Web browser, you’ll see My Email in a different color and underlined. Click on My Email, and — poof! — you get a Jini service.

Although URLs are unwieldy, they are key to adding Jini services to the existing Web. Were you to solve the problem of URL manageability, you could create an alternative Web of Jini services, but not one that blends into the existing Web. By creating a Jini service URL, you could augment the existing Web with Jini services. Because augmenting the Web will be far easier to sell than replacing the Web, a URL for Jini services is appropriate.

A cyberspace protocol

To retrieve a resource when given a URL, a Web browser breaks the URL into four basic parts: a protocol, a host, a port number, and a name. These four parts appear like this:

protocol://host:portnum/name

The browser uses the protocol portion to determine which network protocol to use to request the resource. It uses the host portion — which can be in domain name form (such as www.artima.com) or quad form (such as 127.0.0.1) to determine which network host to contact via the protocol. It uses the port number to determine at which port on the host the server is running. If the port number isn’t included in the URL, the browser uses a well-known default port number for the protocol. The browser contacts the server running at the specified host and port number and, in some protocol-dependent way, passes the name to the server. The server, also in a protocol-dependent way, returns a resource with that name.

To support a Jini service URL, therefore, a network protocol needs to be defined, one that enables a Web browser or other client to (at a minimum) pass a name to a server and get back the Jini service object, if any, associated with that name.

Often, however, the client may want to receive more than just a service object. A client may, for example, want a user interface object to grant a user access to the service. It may want a protocol interface object to grant a non-Jini device access to the service. Therefore, the client may need to pass more than just the service object name in its request. It may also need to pass information about what other kinds of objects it wants. Similarly, along with the service object, the server may return other objects as requested by the client.

Figure 3 shows the basic form of this cyberspace protocol. The client sends the service request, which includes a service name plus data that request any other objects or items besides the service object that the client is interested in. The CSP server (or Jini name server) responds with the service bundle, which includes the named service object and other objects requested in the service request.

Objects that could be returned in the bundle are user interface factories or protocol interface factories; attribute sets associated with a factory; attribute sets associated with the service object; and an attribute-set browser object that enables the client to go back to a server for more attributes associated with the service object. The service bundle could even include jar files containing source code likely to be needed by the client. The service bundle itself could be a jar file that may be compressed.

The service bundle may include more than one user interface (or protocol interface) factory because the service request may not provide the CSP server with enough information to select only one factory. If multiple factories are returned, the client can look at the factories and their attributes and pick the best one. If none of the returned factories are adequate, the client can use the attribute-set browser object to search through all the attributes associated with the service object.

Place services

A Jini service URL, and a protocol to support it, would enable human users and autonomous agents to access Jini services on demand. However, they wouldn’t by themselves create a space metaphor for the Web, which would enable users to go to cyberspace places and use cyberspace objects. The cyberspace objects could be implemented by Jini services. The Jini service object would represent an abstraction of the cyberspace object. (For example, the service object for a Jini toaster service would be an abstraction of a toaster — it would express “what it means to be a toaster.”) User adapters would grant users access to the cyberspace object and give it an appropriate look and feel (or sound and feel, etc.). Protocol adapters would further extend the reach of the cyberspace object by enabling the object to be used via non-Jini devices.

But what about places? In cyberspace, a place is merely an object that serves to store links to other objects and enables users to interact with and request those objects. Therefore, a Jini place service is needed to fully realize cyberspace.

As mentioned earlier in this article, one kind of place service could be a service that looks and acts much like the Macintosh Finder. Such a place service could pop up in its own window and give the user several ways to view the links it contains: big icons, small icons, lists, details, and so on. This kind of place service would make navigating the Web a bit more like the way people have been navigating their desktops for years. If you want to run a program or view a document on the desktop, you go to the folder in which the icon for that program or document sits and double-click on the icon. Then you get the program or document. Similarly, if you wanted to use an object in cyberspace, you could open the place service that contains the icon for that object and double-click on the icon. If the object is a Jini service, you get a new window in which to interact with the service. If the object is a document, it shows up in a Web browser window.

But place services need not look like the Macintosh Finder. They could look like anything else. (Or they could look like nothing. They could be something you interact with via speech.) A place is any kind of object in cyberspace that enables users to interact with or request other objects.

Navigating cyberspace

The point of the place service is to give a space metaphor to the Web. To use the Web, I go to places and interact with objects.

Although places in cyberspace need not represent any place in the real world, it will often make sense for them to do so. Embedded devices already surround us. In the future, more items will become embedded devices and more of these devices will be connected to networks. Ultimately, this trend will lead to this result: the environment will become the computer. Everything around us will offer services and information across the network. By representing objects in the real world with objects in cyberspace, and places in the real world with places in cyberspace, navigating cyberspace becomes analogous to navigating the real world.

For example, imagine that in the future, every technical book will contain a tiny chip in its spine that serves up the book’s contents across the network. Such a book would offer an information service both physically, in the real world, and virtually, in cyberspace. Say I buy such a book at an old-fashioned bookstore and bring it to work. I slide the book into my bookshelf, which also happens to be an embedded device. (My bookshelf offers a place service across the network.) When I slide my book into the bookshelf, the book spontaneously contacts the bookshelf and registers its information service with the bookshelf.

If I need to refer to the book when I’m sitting in my office, I grab it from the bookshelf and use it directly. But if I’m traveling and haven’t carried the book with me, I could get the information across the network. First, I’d go to my office place, the place service that represents my office in cyberspace. I’d have to present credentials, such as a password and smart card, to get into my office. Once there, I’d see icons for several objects that happen to be sitting in my real office. I could click on my fax inbox icon to look at my faxes, or my voicemail icon to listen to my messages. But since I’m after information in a book sitting on my bookshelf, I click on the bookshelf icon. Up pops the place service offered by my bookshelf. But this place service doesn’t look like a Macintosh Finder; it looks like a bookshelf. The objects in this place are all books, and they look like books. By reading the titles on the spines, I locate the book I’m looking for and click on its spine. Up pops a Web browser window in which the information contained in the real book is presented across the network.

As another example, imagine that from my office desktop computer I want to program the VCR sitting in my living room. I could go to my home place, present my credentials, and get in. The place service representing my home contains links to several place services representing the rooms in my house. I click on the living room icon, and go to the living room. Among the icons representing the objects in my living room is an icon for my VCR. I click on that icon and am presented with the service offered by my VCR that allows me to program the VCR remotely.

And of course, if I want to set the dark-light setting on my toaster across the network, I go to my kitchen, a place, and interact with my toaster, an object.

Conclusion

A couple of months ago I walked past several computers at the public library in Pleasanton, Calif. One of them had a plain sky-blue background on which were sitting a few icons that had the usual text names beneath them. The computers in that library are network terminals. Their sole purpose is to allow library patrons to get information from the Internet. As I passed that computer screen, I thought to myself, “Those icons should represent network objects.” In the future, I think that one way or another, they will. The purpose of this article is to stimulate discussion and thinking in the Jini and Java communities about how Jini and Java technology could help make that happen.

The article is also meant to serve as a starting point for discussion in the cyberspace project at Jini.org. The cyberspace project was created to serve as a central point for the Jini community to discuss the possibilities described in this article and to delve into the details. I left many details out of this article, in part because it is already long enough, but also because I don’t know all the details. How will the cyberspace protocol actually work? Could the Jini lookup server also serve as the CSP server? How do you get Jini services through firewalls? What are the client-side conventions? What does it mean to be a place? These are some points of discussion for the cyberspace project mailing lists. If the cyberspace project does end up making some solid proposals, they may look very different from the ideas presented here. As I noted, this article is intended to serve as a starting point, not the end point.