To overcome some of the limitations of standard component software approaches for scientific computing, the Common Component Architecure (CCA) Forum [4] was started in 1997 to define the standard foundations of scientific component architecture and into facilitate the adoption of CCA tools and technologies. In addition, the U.S. Department of Energy (DOE) established the Center for Component Technology for Terascale Simulation Software (CCTTSS) [13] for purposes of developing the CCA software infrastructure and demonstrating its use for complex scientific simulations.
Component programming, much like object-oriented programming, provides a model for constructing software such that units of code (components and objects) expose a ``public'' interface to the outside while hiding their internal implementation features. Components extend the object model by allowing components to dynamically discover and expose interface information, something that is statically determined at compilation time in most object-oriented languages. Fundamentally, the CCA is a specification of the component programming pattern and the interface the components see to the underlying support substrate, or framework. The CCA allows components to describe their interfaces in the Scientific Interface Definition Languaged (SIDL) [6]. Like the IDL used by CORBA, the interfaces are defined in a language independent manner and are not bound to the source code or compiled binary of a component. The IDL simply describes the public interface so that external parties can discover what services are available and how they must be called.
In the CCA, a component is defined as a collection of ports, where each port represents a set of functions that are publicly available. A port is described using SIDL, and some form of wrapper exists in the implementation to map the SIDL interface to that of the implementation language. From the point of view of a component, there are two types of ports. Those that are implemented by a component are known as provides ports, and other components may connect to and use them. Other ports that a component will expect to be connected to and call are known as uses ports. Uses and provides ports are connected together as shown in Figure 1. The act of connecting components is referred to as component composition.
When a component is instantiated and allowed to execute, it registers the provides and uses ports with the underlying framework. This information allows external components to discover what ports or interfaces are available, and ensures that expected relationships between components be fulfilled, before allowing execution. Port discovery is a service provided by the framework and is actually just another port that a component can connect to. For instance, a component can obtain a list from the framework of all components providing a specific interface or port. The component could then connect to each of the ports in the list in an iterative fashion and make calls on the methods within the connected port. Iterative access to a common set of interfaces presupposes that such a set exists. One of the primary benefits of component-based programming is the adoption of common interfaces for domain-specific purposes. This allows different teams of individuals to develop components based on this ``standard'' component API. This in turn allows users of these components to pick and choose the particular component that best fits their needs.
The CCA architecture is the operational foundation for the implementation of CCA-compliant component frameworks, but it does not by itself directly specify how requirements of high-performance component systems are met. Rather, the intent of the CCA specification is to allow the preservation of performance. This takes four primary forms. First, the performance of the functional ``core'' of a component (e.g., linear equation solver) should not suffer because it is implemented within a component. In general, this demands support for all core languages (e.g., C, C++, and Fortran 77, 90, and 95), and support for all forms of parallel execution the core software may employ. Second, component communication mechanisms should not be dictated but be selectable based on what best suits encapsulated functionality and component-component proximity (e.g., same memory space, same cluster, local network, or wide-area). Third, parallelism between components should not be restricted. This regards primarily support for parallel communication between components, but also relates to parallel component computing paradigms, as in the Single Component Multiple Data (SCMD) model [1], MxN coupling [14], and the macro-level dataflow Uintah Computational Framework (UCF) [15]. Lastly, it should be possible to select component instances and configure component compositions for performance purposes, both prior to and during execution.
