A position paper presented at the 1998 International Workshop on Component-Based Software Engineering

Abstract

Component-Based Software Engineering or CBSE represents a new development paradigm: assembling software systems from components. This paper discusses the technology infrastructure necessary to support CBSE. In particular, we present the new techniques produced by the CBSE research project¹ conducted at Andersen Consulting.

1. Introduction

Researchers and industry visionaries in the software engineering field have long dreamed about a Lego block style of software development: building systems by assembling prefabricated, ready-to-use parts. Over the last several decades, we have seen the focus of software development shift from the generation of individual programs to the assembly of large number of components into systems or families of systems. A similar trend can be observed in the research community as research areas progressed from automatic programming and software generators to module interconnection languages (MILs), module interface specification and analysis, megaprogramming, domain-specific software architectures (DSSAs), OO frameworks and patterns, architecture description languages (ADLs), and architectures for distributed and reconfigurable systems. The two central themes that emerged from this shift are components, the basic system building blocks, and architectures, the descriptions of how components are assembled into systems.

Component-Based Software Engineering (CBSE) was a research project conducted at Andersen Consulting to develop techniques enabling an architecture-driven and component plug-and-play style of software system development. The research builds upon past as well as on-going efforts in academia and industry in the area of software components and architectures and represents a significant step forward toward an industry-strength component development environment. This paper summarizes the technical achievements of the project.

2. Component Specification Language

Central to our research is a component-based Architecture Specification Language called ASL. In ASL, the functionality of a component is defined by its interfaces. A component may have one or more provided and required interfaces. Syntactically, interfaces are similar to object class descriptions: they contain attributes and operations. Semantically, provided interfaces specify the services or capabilities that a component offers to other components. Conversely, the required interfaces specify the services that a component must receive from other components in order to carry out its own responsibilities. Object-oriented notations generally support provided interfaces but not required interfaces. However, the concept of required interfaces is an essential one. They expose operation invocations that a component makes to other components. Such invocations are otherwise embedded and hidden in a component�s implementation making the component hard to reuse.

A component can be either primitive or composite. A composite component contains other components as its sub-components, which are themselves primitive or composite. Two sub-components are connected by binding a required interface of one component with a provided interface of the other component. Architecture of a complete system can therefore be captured as a hierarchical organization of components.

Another salient feature of ASL is its support for configuration specification, which provides the information concerning components� dependencies on development environments (programming languages, object model, etc.) and execution architectures (machines, operating systems, middleware, etc.). This information can be used to automate the integration of heterogeneous component instances into an executable distributed system (see Section 4).

ASL is a strict extension of the CORBA IDL [8]. As in IDL, features such as operations, attributes, exceptions, multiple inheritance and name spaces are all supported. A more complete description of ASL can be found in [2].

3. Specification Analysis Technique

Before two components can be connected, or bound together, it must be shown that the required interface of the client component is satisfied by the provided interface of the server. The objective of specification analysis is to prove that such condition is true and assist in binding components that have interface mismatches.

In the simplest case, the provided and required interfaces are instances of the same interface, so they match exactly. Another simple case is when the provided interface specification is a sub-interface of the required interface specification. However, to truly address the plug-and-play of arbitrary components, we must be able to analyze two arbitrary interfaces to establish whether one of them, as a provided interface, satisfies the specification of the other, as a required interface. We use logical subtyping as a technique to support interface analysis. For more detailed discussions, we refer the reader to [5], [7].

In cases when two interfaces do not match exactly, we may still be able to connect them by inserting an adapter component between them. An adapter supplies the exact required interface needed, using the functionality offered by the provided interface. Most importantly, an adapter template, a partially implemented adapter can be generated automatically in our system.

4. Component Integration Technique

Component integration addresses two issues: (1) packaging components so that they can be connected at run-time, and (2) connecting, disconnecting and re-connecting components at run-time. This section describes our approach to handling these issues.

Components must be "packaged" into executables in such a way that they can inter-operate with the other components to which they are connected [4]. For example, packaging a component for CORBA requires a skeleton and a stub. The skeleton connects the component�s application logic to the middleware, while the stub connects component clients to the middleware and thus, indirectly, to the skeleton. We have built a tool, called the Packager, which determines how to package components. Simply put, the Packager:

1. analyzes a component-based architecture specification written in ASL to determine if consistent packages are feasible,
2. selects a manufacturing plan for generating the packages based on what is feasible, and
3. outputs instructions for executing the plan.

Packager is a rule-based expert system that automates the search for a manufacturing plan. For example, suppose two components are initially implemented in C++ and share a process. Later, we replace one of them with a Smalltalk component. If Smalltalk and C++ cannot share a process, we simply derive a new manufacturing plan that creates separate processes. As new, commercial tools become available, their manufacturing capabilities are added to the rule-base. Occasionally we do need to build some custom tools to bridge gaps between commercial tools. By using a rule-base to derive manufacturing plans, we can build small tools that do simple things well. The rule-base then orchestrates the new tools, together with existing tools, to generate manufacturing plans that were not previously feasible.

The second aspect of component integration is run-time integration. Our run-time requirements mainly have to do with binding the provided and required interfaces of components. Components that have required interfaces need to obtain an object that implements the interface. Similarly, components that provide an interface need to make it available. Components (clients) requiring an interface call a middleware service to locate servers. Clients maintain a reference to servers as long as they like. Servers may be safely replaced when no client has a reference to it. In this approach, we simply allow the client to decide when to look-up the server (and thus potentially obtain a newer revision) and when to release it. We do not require all clients to use some, possibly expensive, locking mechanisms such as a transaction monitor. The implementation of this run-time service will vary with specific products. For example, OMG�s factory-finders [9] and trader services [10] were designed for this purpose.

5. Architecture Design Environment

The previous sections introduced some key technology pieces that are critically important to plug-and-play software. Architecture Design Environment (ADE) developed by the CBSE project pulls all these technology pieces together under an interactive and user-oriented environment.

A primary use of ADE is supporting the specification of the component model interactively using graphical objects. Within ADE, the user can create and browse specification objects such as interfaces, components, and their instances. A file-manager metaphor is used to help user navigate through specification containment relationships.

An object in the navigator window can be dragged and dropped into a component diagram window to show its graphical representation and relationships with other objects. Inheritance between interfaces, containment, and bindings between provided and required interfaces are examples of such relationships. The user may also create new objects and relationships in this window.

The interface compatibility analysis tool is invoked within ADE when a binding relationship is created between a required interface and a provided interface. If the structural or behavioral subtyping relationships fail to hold between the interfaces, the tool will report the error and generate an adapter specification.

The packaging tool is attached to the Tools menu within ADE. This tool uses the component and configuration specifications to generate a manufacturing plan. This plan can then to used to orchestrate a number of COTS tools (e.g., CORBA IDL and language compilers) and additional tools that we developed in this project (e.g., ASL to CORBA IDL code generator) to generate system executables.

6. Related Work

The research projects that are most influential to our work are the following. Polylith [11] and Regis [6] focused on the runtime environments necessary to support and connect components distributed throughout a network. These projects also involve research on advanced configuration languages (MIL in Polylith and Darwin in Regis) to complement the runtime systems. These configuration languages allow the dynamic instantiation and movement of components throughout a network, as well as specifying the connections between different components.

Another area of research in component integration is software packaging. The most representative work in this area is the software packager developed at the University of Maryland by Callahan and Purtilo [3], [4]. This packager automatically determines how to integrate a diverse collection of software components based on their types and the capabilities of integration tools available in the environment.

The architecture of software systems is another related area of research. Projects in this area include UniCon [12], and Wright [1]. These projects study the various types or roles that components and bindings can have in the architecture of a system. In particular, a formal framework for specifying component interconnections is defined for Wright. The key idea of their approach is a definition of architectural connectors in terms of a collection of protocols that characterize participant's roles in an interaction. They also show how interconnection compatibility can be checked based on semantic information.

The techniques reported in this paper can be seen as an integration and evolution of many advanced research ideas and results described above. Prototype versions of the tools supporting these techniques have been completed. The tools were tested on constructing a component-based banking application and demonstrated significant productivity gain.

Acknowledgment

As the Principal Investigator of the CBSE project, I owe special thanks to the technical members of the project, including Francois Bronsard, Douglas Bryan, W. (Voytek) Kozaczynski, Edy S. Liongosari, Ásgeir Ólafsson, and John W. Wetterstrand. Also, Professor James Purtilo of University of Maryland provided vision and technical advice as a consultant to this project.

References