Columns

Finding new answers to an old question

• By John D. Williams
• July 1, 2001

What is a component? You might wonder why I ask this question when I've been writing about component development for years. When components were new, it was an easy question to answer, because we didn't have a clear picture of what components were. Several years ago, I started asking developers this question at conferences I attended. They usually answered that components were objects plus "some stuff." The "stuff" was typically a particular component technology and its standards for developing components. Fortunately, our definitions have become both more complex and more informative since then. Advances in the field and the new understanding we've gained as a community make it useful to revisit this basic question.

The publication of a new handbook on component technology spurred me to write about this question. Component-Based Software Engineering: Putting the Pieces Together (CBSE), edited by George Heineman and Bill Councill (Boston: Addison–Wesley, 2001) has 42 chapters written by 40 authors, including me. I wrote one chapter of the book and had a role in creating its definition of a component. This new definition leads me to look at what we know about component technology and what value the new definition might bring component developers.

Our understanding of components has evolved over the years. In his book, Objects, Components, and Frameworks with UML: The Catalysis Approach (Reading, Mass.: Addison–Wesley, 1999), Desmond D'Souza created a definition aligned with the CBD 96 component standard. He defined a component as "an independently deliverable unit of software that encapsulates its design and implementation and offers interfaces to the outside, by which it may be composed with other components to form a larger whole." This definition adds three new pieces to the "objects plus" definition. First, components are independently deliverable units of software. That wasn't always true with objects. It also focuses on the interfaces to the outside. While objects promote clean interfaces, interfaces don't have the same importance for objects that they do for components. It also emphasizes composition with an eye to creating larger grained components. While this isn't foreign to object development, OO development doesn't have the same sense of "assembly" that components do. In the Catalysis definition, components focus on characteristics different from those emphasized in object technology. This is a more flexible view of a component, compared to the "objects plus" definition. It opens the door to non-object types of components.

These definitions are aren't sufficient. The previous definitions actually ignore some component-based development issues, which has created a need for a newer definition. Today, a single definition isn't enough. In the CBSE book, a set of definitions is used to describe key aspects of CBD. The set begins with three definitions:

1. A software component is a software element that conforms to a component model that can be independently deployed and composed without modification according to a composition standard.
2. A component model defines specific interaction and composition standards. A component model implementation is the dedicated set of executable software elements required to support the execution of components that conform to the model.
3. A software component infrastructure is a set of interacting software components designed to ensure that a software system or subsystem constructed using those components and interfaces will satisfy clearly defined performance specifications.

These definitions emphasize not just the component, but also the relationship between the component, its infrastructure and its underlying component model. All of these play a role in CBD.

Our new definition of component is similar to D'Souza's. But ours emphasizes use without modification within a composition standard. In CBSE, composition is defined as the "combination of two or more software components yielding a new component behavior at a different level of abstraction. The characteristics of the new component behavior are determined by the components being combined and by the way they are combined." In this new view, the way components are combined is in conformance with a standard. To get the benefits of component technology from components built from finer-grained components, the assembly of the smaller components must be in accordance with a composition standard.

Although component interfaces are not mentioned explicitly in the component definition, they are an underlying assumption. CBSE defines an interface as "an abstraction of the behavior of a component that consists of a subset of the interactions of that component together with a set of constraints describing when they may occur. The interface describes the behavior of a component that is obtained by considering only the interactions of that interface and by hiding all other interactions." This is a more explicit definition of an interface and highlights its key characteristics. Constraints and encapsulated behavior are important interface characteristics.

One more definition is needed to complete our understanding of a component. A software element is "a sequence of abstract program statements that describe computations to be performed by a machine." This set of definitions helps us understand what makes a component. But, to understand CBD, we need to explore the relationship between a component, its underlying component model and its infrastructure.

Component models work at two levels. Typically, a model defines how to construct a component. For example, a component model defines what it means to be a COM component or a JavaBean. Additionally, a component model is necessary to connect components. Component models define the permitted mechanisms for assembling and integrating components. This model is an important part of CBD because without it, we couldn't build systems of interoperable components. This focus on the component model is an important issue that earlier definitions of components missed.

D'Souza's and CBSE's definitions view components as being deployable independently. We need to look closely at the relationship of the component to its model to understand how this works. The model will define how a component is configured, installed and instantiated. This means the component model can impact IT operations in the location and manner component-based applications are built and run. This definition clarifies that it is not enough to say you want to use components; understanding the underlying model is needed to appreciate the potential impacts on an organization.

There is a similar issue in the relationship of a component to its infrastructure. Components do not typically operate in isolation. They run in a defined context that may be simple or complex, depending on the granularity of the component and where it fits in an application's architecture. All components are not created equal. The more complex the component, the more complex the supporting infrastructure it needs. As we move from monolithic to n-tiered applications, there will be additional infrastructure constraints on performance. This impacts IT operations and the business case for components.

These new definitions highlight important implications for CBD. Components can no longer be thought of as simply "objects plus." Understanding components means we must also understand their underlying model and infrastructure. This growth in complexity also tells us components need a software engineering approach. Companies that adopt components are finding that they can't throw component systems together and expect them to work. Component-based systems must be engineered. This may delay some firms' adoption of components, but ultimately, they will have difficulty avoiding components, because the benefits of doing so are compelling. Purveyors of our base technology are moving in this direction and we cannot avoid making the same move without abandoning the advantages of new technology. Companies are going to have a very difficult time meeting business demands for new customer and vendor-facing systems if they don't adopt components.

So what does this all mean? Our new definitions help us better understand CBD and its implications for our organizations. This clarity can help us plan more effectively and do a better job of rolling out component technology. These definitions can also help us make a better business case for components, because we have a clearer understanding of what it means to do CBD. I hope that these new definitions serve you well in using and propagating component technology.