Accommodation: The Key to Making Widely Adopted Composable Systems

John Ockerbloom

Carnegie Mellon University

All too often, software meant to enable composition is designed with the assumption that users of the software will change the way they manage data, install programs specially designed to work with the new software, and even adapt their existing data and code base to work with the new software. Designers acknowledge that these activities are all costly, but they often assume, sometimes implicitly, that the high cost of adoption can be ignored due to the benefits of the software and of the standards it defines.

This assumption is unrealistic. It is also often unnecessary.

Potential users are often rightly slow to adopt new "composable" systems. Users have three major concerns. First, the startup cost to adopt the system and adapt existing infrastructure can be high, with few benefits available before this cost is paid. Second, the overhead of ongoing maintenance of the system can also be costly, particularly when the system is complex. Third, the risk that the system will become obsolete quickly, either due to changing user requirements or the introduction of new standards, is also high.

Sufficiently powerful external pressure to adopt a particular standard can sometimes overcome user resistance to adoption. Large enough companies or coalitions can sometimes exert such pressure, as can a sufficiently revolutionary technology. But adoption by this route should be the exception rather than the rule. Successful composable systems need to accommodate the diverse needs and practices of users, rather than relying on a big set of "features" or dominant market share to overcome user resistance. There are three aspects of this accommodation requirement for composable systems:

  1. Work with what users already have. Be as compatible as possible with existing programs, applications, and data.
  2. Offer an attractive cost-benefit curve. Users should start realizing benefits after a small investment in the system, with more benefits available as they invest more. This strategy not only attracts users, but also minimizes their overhead, since they may be able to get what they need without having to pay for features they do not need.
  3. Accommodate changes in users' environments. This accommodation will make the system continue to benefit users even as they adopt new applications or standards.
The world embraced the Web, without prompting from powerful companies or coalitions, in part because the Web satisfied these requirements. The Web initially works with what users already have, allowing them to serve plain text documents from their existing file systems, using existing servers like FTP and Gopher. Greater investment yields greater benefits. With a little more work, users can install HTTP servers supporting interaction with clients, and use the simple HTML markup language to link to documents in various formats anywhere on the Internet. The Web also accommodates change. For instance, the design of HTML, where elements are clearly delimited, makes it easy for enhancements to be added to the markup language. Those enhancements are syntactically, and often semantically, backwards-compatible with earlier HTML tools. The Web became a mass medium in 1993, even though it had been invented years before, due to a widely available point-and-click user interface, and its incorporation of one of these HTML enhancements, the inlined image. This development allowed users to reap many of the benefits of viewing the Web with very little monetary or intellectual investment.

Even if one concedes that satisfying these accommodation requirements helped the Web succeed, one might argue that architectures using higher-level abstractions, such as distributed object systems, cannot realistically do the same. To the contrary, my experience in developing TOM, an object-oriented system designed to make diverse data formats widely usable, has demonstrated that higher-level systems can satisfy these requirements, and thereby attract users.

TOM is an example of interoperable componentware in use today. It is built around two familiar concepts: an object-oriented data model, and a network of mediator agents known as "type brokers". The data model describes both the concrete representation of data (its "format"), and the object-oriented abstract interface of its "type". Clients that receive data in formats they cannot themselves handle send the data to a type broker. On the client's request, the broker invokes servers either to convert the data to a format the client can handle, or to carry out operations defined in the abstract interface of the format's object type. TOM's accommodation of multiple representations of the same object type, and its substitutable subtyping model (based on the work of Liskov and Wing [1]) allows many unfamiliar formats to be operated on through a common, familiar abstract interface. New data formats, their relations to existing formats and types, and servers that can work with these formats, are also registered with a type broker, which then propagates this information to other type brokers. Further technical details on TOM can be found on the Web [2]).

TOM works with data and programs that already are widely used. Because TOM's data model describes both abstract interfaces and concrete representations, it can encompass existing data formats, even those not designed to be "object-oriented", such as HTML, word processor formats, and MIME messages. The most popular TOM application at present is the TOM Conversion Service [3], which converts documents from the Web or from user's local filesystems into formats specified by the users. The type brokers plan conversion strategies, invoking converters ranging from off-the-shelf programs to simple Perl scripts. While we have not publicized the TOM Conversion Service widely (since we do not want to overload the few type brokers now operating before the release of the broker software), users worldwide now make thousands of conversions through it every month. TOM's distributed architecture allows the conversion service to scale up more gracefully than standalone or site-specific conversion programs, when more brokers and services are added.

TOM starts offering benefits for very low cost, and greater benefits for additional investment. To use the TOM Conversion Service, users only need to visit its Web site with their browser and fill out the forms to convert documents. They need not install any software themselves, or know about the object-oriented data model TOM uses. If they install their own copy of the type broker and Conversion Service CGI script, though, they may enjoy better performance, since they can invoke services on their own network without having to visit a heavily-used remote site. If they learn about TOM's type model, they can also register their own types and formats, and establish relations between those formats and existing formats. They can also register new services, such as converters, on types and formats, after making these services callable through a simple server interface similar to the Web's CGI. Finally, with a bit of programming, they can make their own client applications invoke TOM services automatically. This need not involve large amounts of code; for example, our Unix command-line TOM conversion client is a few hundred lines of C.

TOM's accommodation of existing data formats and programs, and its support of distributed registration of new types, also allow it to handle changing environments gracefully. Consider the months of compatibility headaches on the Web when Netscape and Microsoft "frames" were introduced to HTML. The new "framed" pages that appeared were all too often incompatible with older browsers, or even with either Netscape's or Microsoft's frame implementation. I was able to define TOM data formats for the new "framed" versions of HTML, and use TOM to translate and provide navigation of "framed" web pages for older, frameless browsers, in a couple of days. [4]

TOM is not designed to handle all of the tasks a general-purpose distributed object system would, and it will not replace CORBA, Java, or OLE. Its simplified object model treats data as immutable values rather than as variables, for instance, which limits its generality but prevents TOM from imposing requirements on data stores that might limit its breadth. In future work, I hope to show how TOM can work alongside the general-purpose distributed object systems, help them transcend their limitations on data representation, implementation languages, and storage, and also take advantage of the services they offer.

In summary, successful composable software needs to accommodate user practices, and avoid requiring users to change their practices to accommodate the software. To be widely adopted, a composable system needs to work with what users already have, offer an attractive cost-benefit curve, and accommodate continued change in user environments. The World Wide Web is one well-known system with these properties. TOM is an example of a system using higher-level, object-oriented abstractions that also shares these properties.