|
|
|
|
Sponsored Link •
|
|
Advertisement
|
Summary
In this document I look at the benefits and drawbacks of using web pages to deliver services across the network. I propose a way to augment the current web with Jini services to address the constraints of using a document metaphor to deliver highly-interactive services. (1,700 words)
Web pages are great. I get a lot of information from web pages, and I use web pages myself to deliver articles and various other forms of information to readers. Nevertheless, since my early days using the web I have 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 World Wide Web as we currently know it, and suggest a way that certain aspects of Jini technology could help supply the missing functionality.
Web pages serve as an electronic form of something people have used for a very 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 newspaper, a white paper, a grocery list, a phone message, a modern yellow sticky, or an ancient scroll, the document you are looking at is likely composed primarily of text and graphics. Similarly, although web pages can sport interactive applets and flashy animations, most web pages, like their paper document 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 give a document metaphor to the network.
Web pages are extremely well-suited for the job of delivering information to people electronically. Because people are used to getting information from documents in the real world, the document metaphor of web pages is a natural way for people to get information from the network.
One kind of information that web pages are particularly adept at transmitting to people are links to resources. If you click on a hyperlink on a web page, the browser loads the referenced page. Hyperlinks are very easy for people to learn how to use, in part because point and click is easy to understand, but also because hyperlinks bear a strong resemblance to something people are used to seeing in paper documents. Many documents include references to other documents, links to more information. Hyperlinks and web browsers merely automate the delivery of these external resources to the readers of web pages.
Another a role 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 an edit box and button. You type your e-mail address into the box and press 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 this web page back to the web server. The web server forwards the web page on 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 have historically gone through to subscribe to a 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 to a magazine, I take the card (which is like a small document) and fill in my name, address, credit card number, and so on. Then I send the card in the mail to the magazine, and I've subscribed to the magazine. Because people are quite well-versed in filling out paper forms, filling in edit 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, hyperlink pointers to external resources, and forms to fill in and submit -- feel very natural to users. Because people interact with web pages much like they interact with paper documents in the real world, web pages are very effective at transmitting and collecting information across a network.
Another way to think of web pages, besides thinking of them as documents, is as services. By "service," I mean anything that offers and provides some perceived value to other entities. Thus, web pages provide services to people.
A web page that is a basic page of information offers an "information service." If need a recipe for pumpkin pie, I can likely find a web page on the internet that provides one. If I need to know the weather forecast for Annapolis, I can go to a web page and get it.
A web page that is full of 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 up from the network with a click.
A web page that is full of edit 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 to the network.
These three kinds of services are usually put together in various combinations in single web pages. Most information service pages also 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 to provide information, resource organization, and form services have enabled a massive proliferation of higher level services on the web, all of which use the document metaphor. I can buy and sell stocks through web pages. I can send and receive e-mail through web pages. I can auction off my old bicycle, do my Christmas shopping, organize my daily schedules and do lists, and get maps and directions through web pages.
So what's the problem? What could possibly be missing from this World Wide Web, which overflows with information and services? My complaint with the current state of the web is that for many higher level services, especially those that require a lot of interactivity, the document metaphor of web pages is constraining.
When I'm traveling, I often read my e-mail through Yahoo e-mail, which is a quite elaborate service that's 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 kind of service, but once again not via a web page document 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 metaphor for many services, including e-mail. Yahoo E-mail uses the document metaphor because they currently have no other choice but use web pages if they want to deliver services over the internet.
My sense is that many round services are currently being pounded into square web pages, just so they can be delivered across the network.
This works, but what would feel more natural is a slide control, which HTML doesn't currently offer. Of course, I could include a Java applet in the web page that has a slider:
Now I've got my slider, but unfortunately, 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.
In the real world, when I want to interact with my toaster, I don't go to the bookshelf, reach up and 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 happens to provide 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 go grab that resource. The requested resource could be a web page, an object, or another place.
My belief is 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. Web pages are currently the dominant resource unit on the web, but web places and web objects could also conceivably participate. 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."
The other constraint of the document metaphor, aside from forcing everything onto pages, is the limited accessibility of those pages. Granted, one of the prime original selling points of web pages was their platform independence. Unlike a lot of other things in 1994, web pages didn't just run on Windows. You could look at a web page on Windows, OS/2, a Macintosh, Solaris, Linux, IRIX, and many other platforms. Thus, web pages have a high degree of portability. But nevertheless, the portability of web pages does have 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 only to view a small portion of the page at a time on the screen. Similarly, web pages don't work very well on a palm computer that has a small display. 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 very 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 temporarily can't use your eyes to interact with a device with graphics capabilities, such as when you are driving a car.
Web pages are best viewed from about a foot away from a high resolution screen, and 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 and more items in our environment will become 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 on any kind of embedded, network-connected device. The document metaphor of web pages is not well-suited for the emerging hardware environment, because many different kinds of devices with vastly different capabilities, not just desktop computers, will serve as portals into the network. One of the advantages of an objects-in-places metaphor for the network, by contrast, is that objects can be defined such that the services they provide can be accessed in many ways from many different kinds of network portal devices.
As this is a Jini-oriented column, you may be wondering what a objects-in-places metaphor for the web has to do with Jini. At the second Jini Community Summit, which took place October 17 to 20 in Annapolis, venture capitalist Ted Schein gave a talk entitled, "Succeeding with a New Technology." During his talk he outlined several guidelines for prospective entrepreneurs seeking venture capital. One of his guidelines for those entrepreneurs planning to do something with Java was: "Know why you are using Java." Schein said applicants are often surprised when he asks the "Why, Java?" question, given that he was one of the founders of the Java fund. But, he said, it is important that you are using Java to solve a real problem that Java is well-equiped to help you solve.
In the case of cyberspace, Java and Jini are well-equiped to help solve the technical challenges presented by an objects-in-places metaphor for the web. 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 user interface.
In my book, Inside the Java 2 Virtual Machine, I spend the first four chapters explaining in detail how Java's architecture enables 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 into 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 build the JVM to let objects move around."
Of course, Java's mobile code capabilities are nothing new. Way 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 fly across the network
to web browsers, where they would execute. 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 goes and grabs an applet directly using an HTTP URL
and run it in its own window, the AppletContext object you must
pass to the applet has methods such as
showDocument(), showStatus(), and
getApplets(),
which to a great extent make the assumption the applet's context is a web
browser.
The other main problem with applets is that by their very nature they are user interface components. Applets are AWT 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 to myriad computers and devices, some of which may 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.
In the fall of 1996, the editor of JavaWorld invited me to sit in on a meeting in which Kim Polese and Arthur van Hoff of Marimba would reveal to JavaWorld their soon-to-be announced product Castanet. The editor 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 their technology. I even wrote an article about Castanet for JavaWorld, which appeared in December 1996.
Castanet influenced my concept of cyberspace, because that meeting with Kim Polese and Arthur van Hoff 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 the local disk. As the channel evolved over time, the local cache would be updated. Because the channel was stored locally instead of being 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, it could be represented by an icon on the user's desktop. To start the channel, you double click 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. 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 heart, Castanet aims to simplify the process of installing desktop applications on desktop systems. This is very important, especially in enterprises, but not a good fit for an objects-in-places metaphor for the web. Many embedded devices that will in the future serve as network portals 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.
Fast forward to the summer of 1998. I picked up a business section of the San Jose Mercury News in a Starbuck's, and there was 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." I had always been impressed by how well-designed Java was, 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 to cyberspace. Most of Jini's advantages are inherent in its service object, which is a chunk of mobile code and object state that is 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 user interface.
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 what network protocol is used to communicate between the service object and the server.
Figure 1. A client uses a service via the service object
interface.
The service object architecture has many advantages to 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 that doesn't break the semantic contract of the service object interface. (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 with which the service object speaks 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 less on the server side (or vice versa). A service provider could change servers, or implement a load balancing scheme through which the service object selects one of many servers. In short, service providers can unilaterally make any change to the implementation of the service object that doesn't violate the service object's semantic contract, without breaking client code.
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 binary compatibility with pre-existing 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, pre-existing 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 sytems 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 the flexibility 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 adherence by 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 verifying adherence to them, may affect the flexibility realized in practice 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.
Another advantage of the service object architecture, aside from the ability it gives to service providers to make changes over time, is a clean separation of user interface (UI) from functionality. As shown in Figure 1, a user interface is an add-on "user adapter" object, separate from the service object, that gives a human user access to the service.
Figure 2. A UI object "adapts" a service to a human user.
Jini's separation of user interface and functionality is what was missing in Java applets, in web pages, in Marimba channels, and, for that matter, in traditional monolithic desktop applications. In all of these 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 user interface and functionality 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.
Although Jini's separation of functionality and user interface enables a service to be accessible from devices with many different kinds of user interface capabilities, the scenario illustrated in Figure 2 makes a big assumption -- the client is Java and Jini enabled. Of course, 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.
As luck would have it, 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 and UI object itself can 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 a non-Jini device talks to a protocol adapter via a network protocol. The protocol adapter talks to the service object. Similar to the way a user adapter adapts a service to a human user, a protocol adapter adapts a service to clients, including non-Java and non-Jini clients, that understand a particular protocol.
Figure 3. A Protocol Interface object "adapts" a service to a
non-Jini client.
Jini service hosts could be deployed in a local area environments. Non-Jini clients could discover a nearby service host and ask it to host a service and protocol adapter. If no nearby service host exists, the non-Jini client could 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 could extend the reach of their Jini services to the non-Jini world.
The service object architecture provides a service provider with a way to grant access to its service to users of the many different kinds of embedded devices that will be unleashed on the world in the coming years. By offering a rich set of user adapters, a service provider can reach users through many different 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 also gives the service provider many options on how its service will be provided, and gives the service provider the opportunity to change the service gracefully over time. One aspect of the service object architecture that service providers may wish to take advantage of is providing as much of the service as possible within the service object itself. The more the service object itself is able to provide the service without enlisting the help of a server across the network, the less network traffic is required, the less the load on the server side, and the faster the service will appear to the client. The reason non-Jini clients would prefer to discover a nearby service host as opposed to using a distant one is that any computation done by the service object will be closer to the client, and therefore likely 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 which 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 evolving their services over time, and the means to deliver their service to human users and autonomous agents on a myriad of computers and devices.
The power and flexibility of Jini's service object architecture makes it an ideal technology on which to build cyberspace: an "objects in places" metaphor for the web. But Jini, in its current incarnation, doesn't have all the pieces required to give this objects-in-places metaphor to the web. The first thing missing is a URL for accessing Jini services.
The web is a huge set of interlinked resources on the internet, where the links take the form of URLs. A URL is how you uniquely identify a resource on the web with a single character string. Because URLs are strings, they can to a limited extent be remembered by humans, but can to a great extent 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 as to why they have to have so many dots and slashes. Despite their unwieldiness, however, URLs have entered the mainstream. URLs are, for example, often given out on advertisements over the radio, on TV, on billboards, and even on the sides of trucks. The advertisers hope you will remember these URLs and eventually type them into your browser's location field. A Jini service URL would make it possible to advertise network-delivered services that aren't constrained by the document metaphor. You hear a URL on the radio, you type it into your browser's location field, hit return, and get not a web page, but a Jini service.
Besides typing URLs directly into a browser's location field, you also use URLs when you click on a link embedded in a page. In the source code of the web page, each link is associated with a URL. The browser uses the URL associated with the link to figure out how to get the resource you requested with your click. A Jini service URL would make it possible for a link such as this to appear in the source code of a web page:
<A href="csp://www.artima.com/my_email">My Email</A>
The "csp:" prefix stands for "cyberspace protocol." When you look at this web page in your cyberspace-enabled web browser, you'll see My Email in a different color and underlined. When you click on "My Email," poof!, you get a Jini service.
Although URLs are unwieldy, they are the key to adding Jini services to the existing web. Were you to solve the unwieldiness problem of URLs, 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 likely be far easier to sell than "replacing" the web, a URL for Jini services is appropriate.
To retrieve a resource given a URL, a web browser breaks the URL up into four basic parts: a protocol, a host, a port number, and a name. These four parts appear in the URL like this:
protocol://host:portnum/name
The browser uses the protocol portion to determine what network protocol to use to request the resource. It uses the host, which can either be in domain name form (such as "www.artima.com") or quad form (such as "127.0.0.1") to determine which host on the network 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.
What needs to be defined to support a Jini service URL, therefore, is a network protocol with which a web browser or other client can (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. Because the client may want more than just a service object, it may need to pass more than just the service object name in its request. Besides the name, the client may need to pass information about what kind of other objects it wants along with the service object. 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 a "service request," which includes a service name plus data that requests any other objects or items besides the service object that the client is interested in. The CSP server (or Jini Name Server) responds with a service bundle, which includes the named service object and other objects requested in the service request.
Figure 4. A client interacts with a Jini name server.
Some possible objects returned in the bundle could be user interface factories or protocol interface factories; attribute sets associated with the factories; attribute sets associated with the service object; and an "attribute set browser" object that enables the client, if it so chooses, to go back to some server for more attributes associated with the service object. The service bundle could potentially even include JAR files containing source code likely needed by the client. The service bundle itself could be a JAR file, which could optionally 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 the all attributes associated with the service object.
A Jini service URL, and a protocol to support it, would enable human users and autonomous agents to access Jini services on demand, but 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 -- 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. To fully realize cyberspace, therefore, what is needed is a Jini place service.
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, list, details, and 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 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. (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.
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 to do so. We are already surrounded by embedded devices. In the future, more and more items will become embedded devices and more of these devices will become connected to networks. Ultimately, this trend will lead to this result: the environment will become the computer. Everything around us will offer up services and information across the network. By representing objects in the real world by objects in cyberspace, and places in the real world by places in cyberspace, navigating cyberspace becomes analogous to navigating the real world.
For example, imagine that in the future, technical books contain tiny chips in their spines that serve up the contents of the book 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 by coincidence, 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 travelling 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 smartcard, 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 voice mail 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 that is 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.
For another example, imagine I want to program my VCR, which is sitting in my living room, from my desktop computer at my office. 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 up 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.
A couple months back I walked past several computers at the Public Library in Pleasanton California. One of them had a plain sky blue background on which was sitting a few icons that had the usual text name beneath them. The computers in that library are network terminals. Their sole use is to allow patrons of the library to get information from the internet. As I passed that computer screen, I though 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 has been 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 the article was 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 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. This article is intended to serve as the starting point, not the end point.
To discuss the ideas presented in this article, visit:
http://www.artima.com/jini/jf/cyberspace/index.html
|
Sponsored Links
|