1.6 Muddying the waters

Having disparate services residing on different machines and implemented in different programming languages is not the sole domain of component technology. Servers and clients have communicated using well-specified protocols long before the advent of component technology.¹ Nor is reuse an innovation introduced with component technology. Desktop applications have successfully reused functionality from class libraries, procedural libraries and the operating system on which they run for years. Thousands of dynamically linked libraries have been developed and sold, and nary a software component, as defined in section 1.3, has been in use. Component technology is at its most pure an attempt to standardize some of the infrastructure that has been continually reinvented over the years, an ambitious attempt to create standards for everything from what an object looks like in memory, to the protocol used when two objects communicate over a network, to the declarative attributes used to safely store data in a database. Component technology as a term is thus nearly all-encompassing, and some implementations are as a result very complex.

The definitions adopted for this thesis deliberately exclude many successful forms of software reuse. In a sense, the operating system and its applications make up the most successful component ecosystem in existence: standardized components in the form of processes that communicate with the component model implementation—the operating system—using well-defined standards—system calls (Weinreich and Sametinger 2001). Dynamically linked procedural libraries are a very successful form of reuse, and provide robust language independence by standardizing procedural invocations (Szyperski et al. 2002:209).

Despite their successes, none of the aforementioned entities qualify as components under the definitions adopted at the beginning of this chapter. Applications are too coarse-grained and too project-specific to be considered components—applications are built by composing components, they are not themselves components. Dynamically linked libraries provide a useful platform on which to build component technology (as detailed in Chapter 4), but cannot in themselves be considered components, as they provide no vendor-agnostic support for objects, and different versions of the same library cannot easily be loaded simultaneously, as they have no identity at runtime.² Component technology lays down the standards that enable the properties mentioned in this chapter, including rich reuse, support for object-orientation, language- and platform-neutrality, location-transparent invocations and declarative services.

Footnotes

1. Indeed, component technology’s support for location-transparent invocations grew out of traditional remote procedure calls.
2. A dynamically linked library can certainly have an identity at runtime, if loaded explicitly and not implicitly. Combining explicit loading with a way to retrieve the version number from a library, multiple versions of a library can be loaded simultaneously. Adding object semantics on top of procedural invocations is also possible, and with these additions, a dynamically linked library would qualify as a software component. These issues are discussed in Chapter 4.