Objects versus components

subsections:

Definitions
The technology matrix
Component myths

As observed in [Szyperski97], there is some confusion between the notions of object and component. In this section we will look at the definition of component and compare it with what we know of objects. We will further explore the technology matrix, which classifies a selection of the available (component) technologies. Finally, we will discuss some of the software engineering issues involved in component-oriented development, and do away with some of the myths that surround component technology.

Definitions

Object orientation has not quite fulfilled its promise with respect to reuse. One of the reasons for this is that objects are generally not as modular as they might appear. Or, in the words of [Szyperski97], objects are not a suitable unit of deployment.

Component

substitutability

unit of independent deployment
unit of third party composition
no persistent state

Object

identity

unit of instantiation
(persistent) state
encapsulation of state and behavior

slide: Definitions

[Szyperski97] proposes components as a suitable unit of deployment instead, and advocates a component-oriented approach to deliver reusable `off-the-shelf' components for a composing large applications.

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

From the characterization above it might appear that components are just better objects. To some extent this is true, but there are some important differences. First of all, in practice, there is a difference in granularity. Components are usually large grain, such as a text editor or database component. Objects, on the other hand, may be small grain, such as dates or text fields. Secondly, components are opaque, `binary units' of functionality, interchangeable with units that deliver the same functionality. Objects, in contrast, carry a state and may be regarded as the living building blocks of an organic system.

[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

The component technology field is currently dominated by three players: Microsoft (D)COM, OMG CORBA, and (the youngest player) Sun Microsystems Java. When comparing these technologies with respect to attributes such as distribution, mobility, language and platform independence, and reflective capabilities, we see that there are many differences. First of all, notice that component technology does not automatically mean distribution. For example, JavaBeans and Microsoft COM do not support distribution. Secondly, whereas language independence seemed to be of importance in the pre-Java era, that is for (D)COM and CORBA, it is not so for the Java-based solutions. Finally, platform independence is hard to achieve. But, fortunately, it is on the agenda of all three technologies, including (D)COM.

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

It is hard to predict the outcome of the `battle of component technologies'. However, one can observe a convergence of technologies, that is bridges between Java and CORBA, CORBA and (D)COM, and Java and (D)COM/ActiveX. Each of these technologies sets a standard for interoperability. So, eventually some new standard may arise that encompasses them all. In the meantime, we may study the strengths of each of these technologies and establish what major challenges lie ahead. For example, Microsoft COM has demonstrated itself in an unescapable way in Microsoft Office. A related technology, OpenDoc, failed to gain a market position, but is nevertheless taken on by the OMG as document-oriented component technology.

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

Component software engineering may be characterized as an approach that relies on the availability of reusable `off-the-shelf' components that may be composed into applications. This includes applications for banking, medical services, corporate management, entertainment, etcetera.

Components: myths and reality

component-ware allows for combining components

if semantical issues can be resolved

component-ware simplifies software distribution and maintenance

development becomes more complex

component-ware supports mega applications

it affects performance significantly

component-ware is a revolution

wrong, it is an evolution from OO and C/S

unknown source

slide: Components: myths and reality

From a market perspective, a successful component-based approach requires interoperability between components from different vendors, and standards with respect to the services components offer. Such standards are necessary to insulate clients (i.e. corporations) from vendor-specific, proprietary solutions. Clearly, on the technology side, this surpasses the mere wiring or plumbing standards that form part of (D)COM, ORBs and JavaRMI. In addition, suitable component standards are required for components to interact, as for example offered by ActiveX, JavaBeans or OpenDoc, as well as general services, as for example defined by the OMG, to manage such systems.

Software engineering perspectives

From a software engineering perspective, we encounter a number of unsolved questions, as phrased in [Szyperski97]:

How to describe the interaction between components?
How to manage variety and flexibility?
How to guarantee critical system-wide properties?

In addition, we need to deal with the practical aspects of developing component-oriented applications, that is master the distributed (object) technology involved, and manage multi-tier architectures.

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.

[] readme course(s) preface I 1 2 II 3 4 III 5 6 7 IV 8 9 10 V 11 12 afterthought(s) appendix reference(s) example(s) resource(s) _

You may not copy or print any of this material without explicit permission of the author or the publisher. In case of other copyright issues, contact the author.