Using objects in place of documents for server-client interaction, Part 3

Why objects are for people, not for computers

In the Object Design Workshop, an object-oriented design seminar that I teach, I always begin by claiming that "objects are for people, not for computers." Objects don't help computers run software; rather, objects help people develop software. Computers are just as happy running assembly language programs as object-oriented programs. The aim of software technology evolution, from machine language to assembly language to procedural languages to object-oriented languages, has always been to help programmers deal with complexity and change. In short, objects are tools that help programmers do their jobs.

In this article, however, I'd like to consider another possible use for objects besides being tools for programmers. What if objects were the fundamental abstraction with which people (everyday users, not just programmers) interacted with software?

TEXTBOX: TEXTBOX_HEAD: Using objects versus documents for server-client interaction: Read the whole series!

A new computer

A new computer is on the horizon, one made up of everything connected to everything. This coming change in the hardware status quo provides an opportunity to rethink the basic user-interface metaphors by which people use software. Two fundamental metaphors currently dominate most people's software experience: the desktop metaphor and the hypertext Web.

The personality of a desktop computer is its hard disk. The desktop metaphor primarily helps users manage files on disks; some of those files are applications, other files are documents, and all files are represented by icons. If you double click on an application's icon, the application launches. If you double click on a document icon, an application is launched that opens that document.

Each document on the desktop is associated with an application. The application, which is the behavior that knows how to use the document's data, can be thought of as the document's type. The document type is usually indicated in some manner external to the document file contents. On Windows, for example, the document type is indicated by the filename's three-character extension. The filename (and its extension) is known to the filesystem, but is not generally an intrinsic part of the file itself.

The World Wide Web popularized hypertext, a user-interface metaphor distinctly different from the desktop. Yet on the hypertext Web, the fundamental unit is still the file. Rather than helping users manage files on nearby disks, however, the Web helps people use files delivered by servers on the Internet. Most files, but not all, show up as HTML Webpages. As on the desktop, each file on the Web has a type, which is external to the contents of the file itself. When an HTTP server sends a file, it includes a MIME type header that indicates the file type. The browser uses the file type to decide how to present the file to the user.

The browser understands certain MIME types, such as text and HTML. For such types, the browser itself is the behavior that knows how to use the file's data. If the browser receives a file with a MIME type it doesn't understand, it looks around for a plug-in that does understand that type. If it finds a suitable plug-in, it passes the file to the plug-in, which then decides what to do. In this case, the plug-in is the behavior that understands how to use the file. In either case, the software that represents the behavior for a particular file type must already reside on the client side, either in the browser itself or as a plug-in.

Jini service objects and service UIs

In Jini, network-delivered services are represented by network-mobile objects. Each object has a class, which represents its type. In contrast to the desktop and hypertext Web metaphors, where file types are in general external to the files themselves, the object types are intrinsic to the objects because objects are bundles of behavior. Many objects carry data in instance variables, but most objects use that data to decide how to behave when their methods are invoked. The fundamental character of an object is its behavior.

To present a service object's behavior to a human user, you can insert a user interface (UI) object between the user and the service object. If the client has prior knowledge of the object's type, it can provide the UI object. Alternatively, the UI object can be delivered across the network with the service. Such network-delivered UIs are called service UIs because the service provides them. Here's a diagram from the Jini Service UI specification, which defines a standard way to associate UIs with Jini services.

Figure 1. A person using a Jini service via a service UI

Objects in places

The service UI standard shows how users can access the functionality of individual network-mobile service objects, but doesn't address how users will relate to the entire space of all network-mobile objects. The Cyberspace project at Jini.org is attempting to address this second question by enabling network-mobile objects to participate in the World Wide Web.

Currently, the World Wide Web is composed primarily of Webpages. Two main characteristics distinguish a Webpage from a traditional page, such as a page from a book or magazine. First, a Webpage is delivered across a network. Second, a Webpage contains links to other resources on the network, primarily other Webpages. Both Webpages and traditional pages offer information services, but a Webpage also offers what we might call a collection-of-links service.

The following diagram depicts the organization of the current World Wide Web. Each rectangle is a Webpage, which offers both an information service and a collection-of-links service. The links are depicted as arrows drawn from one Webpage to another.

Figure 2. Current World Wide Web organization

The Cyberspace project is currently working to define a Jini service API called Place, with which a Jini service will be able to maintain links to other resources on the network. Like Webpages, Jini service objects offer network-delivered services. Whereas an individual Webpage offers primarily an information service, a collection-of-links service, and perhaps a form service, a Jini service object is more generic. A Jini service object offers the types of services inherent in the object's class. The services themselves are available via the object's interface. Any type of service for which an interface can be defined, therefore, could be delivered across the network as a Jini service object.

Place is a Jini service interface that will enable service objects, in addition to other services provided via the objects' interface, to offer a collection-of-links service. Place aims to enable network-mobile objects to participate in the Web, yielding the organization depicted in the following diagram. In this diagram, the rectangles are Webpages, the circles are Jini service objects, and the arrows show links from a page or object to another resource.

Figure 3. Proposed organization of the Web, with participation by network-mobile objects

Although Place is an interface implemented by service objects, not service UIs, Place's motivation is user interface. Place is an attempt to define a simple, overarching user-interface metaphor for the emerging new computer. Jini's view of the world is that everything on the network is a service represented by a mobile service object. Place provides a way in which service providers and users can organize the user's relationship to those objects. To do something on the network, a user would go to a place and use an object.

Herein lies the simplicity of this metaphor for users: everything is a conceptual object. Conceptual objects are implemented as network-mobile service objects, accessed by users via network-mobile service UIs. Every object has an intrinsic class, which defines the types of services it offers. Users organize objects by placing links to those objects in places. The existence of places on the network continues the "everything is an object" metaphor, because a place is just another object type -- an object used to organize user relationships to other objects.

Therefore, in this proposed user-interface metaphor, the fundamental abstraction with which human users interact with services on the network is the object. This contrasts with the fundamental abstractions of the desktop and hypertext Web. For the desktop, the fundamental abstractions are the application and the document. For the hypertext Web, the fundamental abstraction is the page, which is really a kind of document. In the remainder of this article, I'll compare the advantages and disadvantages of users interacting with network-delivered services via objects and documents.

Disadvantages of an object-based user experience

I'll start with the disadvantages of objects compared to documents from a user's perspective, then look at the advantages.

Disadvantage 1: Java isn't for the faint of heart

One of the main disadvantages of the object approach, in my opinion, is that HTML is a lot easier to write than Java. The release of Mosaic, the first browser to support graphics in Webpages, unleashed an explosion in Webpage creation. I wouldn't expect that the release of a Cyberspace client, such as a browser plug-in that understands objects and places, would unleash a similar explosion in the creation of object-based services. I believe one significant hindrance to the growth of a Web of objects is simply that writing an object-based service is harder than writing a Webpage-based service.

Object-oriented programming is a difficult and time-consuming skill to learn, much more so than learning HTML. Moreover, you need to learn a lot about Java and Jini before you can write your first Jini service, but you can create a simple Webpage after learning just a few HTML tags. In addition, even for experienced Java programmers, writing a Jini service and its associated service UIs can be quite tricky. Programmers need to understand the unique demands of network-mobile objects and how best to separate the user interface (encapsulated in the service UI objects) from functionality (encapsulated in the service object). Programmers used to writing desktop applications are likely to mix user interface code with functionality code. Such programmers will need to adjust their mindsets when writing object-based network services to separating the functionality from the user interface. And finally, programmers need to understand how to divide an individual service into constituent object parts, each of which is delivered separately across the network. The division of services into many Webpages is more commonly understood. Programmers accustomed to designing monolithic applications will need to acquire a new mindset when designing object-based network-delivered services.

On the other hand, few people nowadays write HTML by hand. Most people use HTML editors. I believe the same will ultimately be true of object-based services. As tools that help people create object-based services become more prevalent and powerful, the ability to create those services will become accessible to more people.

Disadvantage 2: Download time

Another potential disadvantage of objects compared to documents, from the user's perspective, is download time. One of the early complaints about Java applets was that they took too long to download when compared to Webpages. Network-delivered Jini services could easily inspire similar complaints.

Of course, the type of the file being downloaded does not affect download time. Java class files do not inherently fly across networks more slowly than HTML files. The download time of a Java applet, Jini service, or Webpage depends upon the number of socket connections that must be made, the speed of the network traffic, and the total number of bytes transferred. The dirty little secret of Webpage-based services is that they actually take a long time to download; this isn't immediately obvious, however, because download time is spread out and users are trained to wait a few seconds for each individual page.

Yahoo, for example, is a rather huge network-delivered service, but when I point my browser to http://www.yahoo.com, its homepage pops up in about 4.5 seconds over my 56K modem. When I click on "Mail," I have to wait a few more seconds for the main Yahoo Mail page to show up. When I type in my name and password and press the submit button, I have to wait a few more seconds for the next page to show up. If I spend twenty minutes going through my email, I may end up spending three or four of those minutes waiting for pages to download across the network. But I don't notice it, because the wait time is spread out.

1 2 3 Page 1
Page 1 of 3