Objects versus components

Let us look at the definition of software component given in  [Szyperski97]:

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

This definition was the result of an ECOOP96 Workshop on Component-oriented Computing. Notice that the definition itself contains a reusability requirement, in mentioning composition by third parties. The requirements of explicit context dependencies, the absence of inherent state and contractually specified interfaces only strengthen this.

In contrast, an object is not a unit of deployment, but a unit of instantiation. Objects are not used in isolation. Objects, do have state and identity. Deploying an object or a collection of objects, moreover, is often subject to (implicit) assumptions concerning the interaction of objects.

Components as better objects

 [Szyperski97] mentions that there is a debate whether inheritance is of relevance for component technology. No doubt, inheritance, although somewhat overrated, is an invaluable mechanism, both interface inheritance, to define hie-rarchies of types, and code reuse or implementation inheritance, to allow for incremental development.

Reconsidering the definitions given, I tend to think of the distinction between components and objects as a distinction between perspectives. From a deployment perspective we need components. From a developer's perspective we might prefer to speak about objects. Unfortunately, matters are not that easy. But we need to take a closer look at the technology to find out why.

The technology matrix

It is worth mentioning that the three major technologies have a rather different origin. Microsoft (D)COM is primarily a desktop technology, with Office as its killer application, whereas CORBA originated from the need to have an enterprise-wide solution for distributed objects. Java is a special case. It started as a Web-based language, but rapidly took position in the desktop and enterprise world as well.

Java distinguishes itself from the other technologies both with respect to mobility and reflection. As a Web-based language, Java allows for downloading code dynamically, that is class descriptions for instantiating new objects. True mobile objects, that is instantiated objects that migrate themselves, are only possible when using a system such as Voyager, or any of the other Java-based agent ORBs. Java also provides a powerful Reflection API, which allows for various kinds of meta-programming, including the creation of new classes. In comparison, meta-programming facilities of the two other technologies are limited to querying the availability and functionality of interfaces, dynamic method invocation and some dynamic typing.

Trends -- interoperability

An interesting project in this respect is the K-Office project, which aims at developing an Office Application Suite for the Unix/X11 desktop. It is built upon the KDE GUI environment, and employs a CORBA-based component technology, (nick)named KOM, to interconnect (embed and link) the various document components and their associated tools. See http://koffice.kde.com .

Component myths

And, as indicated in slide myths, do not underestimate the complexities of developing such applications. Given the failure of many OO projects, as described in  [Surviving], component-oriented solutions which involve client/server aspects are not likely to be better off, see  [CS2001]. Another area that needs to be studied is the performance of such systems, see for example  [CorbaPatterns].

Yet, in conclusion, just as object orientation may be regarded as a natural evolution from data-oriented approaches, we may look at component-oriented approaches as a natural evolution from object orientation into the realm of distributed systems.

draft version 0.1 (15/7/2001)