Getting Started

Across the software industry, projects face the challenge of satisfying ubiquitous demands for increased functionality, better quality, and reduced cycle time (time to market or field) while simultaneously ensuring that delivered software and software systems satisfy security, survivability, availability, and interoperability requirements.

While the use of component-based development promises to address the first set of demands, current processes and technologies fail to help developers predict the qualities of a system of components, resulting in expensive integration and testing efforts. Exploiting the full potential of component-based development to meet these demands requires the software industry to develop improved, enhanced, or new processes, methods, and tools for determining the properties of software systems before they are built and for confirming their "as-built" properties.

The software industry has developed numerous technologies such as .NET, Enterprise JavaBeans (EJB), and the Common Object Request Broker Architecture (CORBA) to assemble systems from components that are created in isolation. Significant economic and technical benefits from component approaches have accrued. However, component approaches miss the mark in being able to substantively address some of the real issues, namely, the inability to predict individual component behavior, the behavior of assembled components, and hence, the quality of the system. Component technologies available today allow system builders to plug components together, but do little to allow the builder to ensure how well they will play together. As a result, there are rampant failures with component assemblies that receive inadequate testing and expensive integration and test cycles on those that are made to succeed. Consequently, it is not surprising that there is a lack of consumer trust in the quality of software components and in the quality of assemblies that have not received extensive and expensive testing.

In short, though the component approach has helped and does hold promise, it does not now address the real challenges; software components are critical to the software industry, but the behavior of component assemblies is unpredictable. The impetus for today's component technology was inarguably the exponential growth of information technology (IT) industry needs. However, software component technology has not yet demonstrated an ability to predictably meet the requirements for scale, robustness, and performance that  information-technology-bound organizations have. The result is unpredictable and costly development, decreased assurance of how the delivered system will behave, and ultimately, slowed adoption of component technology.

The fundamental technical reasons behind these inadequacies are

  • Component interfaces are not sufficiently descriptive.
  • The behavior of components is, in part, an a priori unknown.
  • The behavior of component assemblies consequently must be discovered.

To compound these nontrivial technical reasons, there is, in general, a lack of consistency in how software industry speaks about components and consequently much misunderstanding as to what a component really is, what current component technologies provide, and where COTS components fit into the component discussion. Some equate components exclusively with COTS, while others equate component technologies with a specific vendor's offering, for example, EJBs. Of course, such inconsistencies and misunderstandings lead people to make poor decisions.

In order to effect the promised potential of component technology and to make component technology effective for the software industry, there must be focused technical leadership to crystallize component concepts and channel researchers to address their current inadequacies, to find ways to predict the behavior of an assembly of components before their development, purchase, installation, and integration and, finally, to improve the level of trust that can be associated with software components.