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:
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.