Overview

The Common Component Architecture (CCA) Forum is a group of researchers from national labs and academic institutions commited to defining a standard component architecture for high performance computing.

Component Programming Model

Traditionally, high-performance scientific applications are assembled from large blocks of hand-crafted code into monolithic applications. Software reuse is obtained by linking with software libraries obtained either from third parties, or created in house, from scratch. A major disadvantage of this approach is that software boundaries (function interfaces and global symbols) are frequently not well thought out. This can lead to internal code dependencies which make the monolithic application difficult to modify and to maintain. Unfortunately, in this regard, scientific software must be frequently modified in order to perform the next model run or scientific study.

Components, on the other hand, are designed with standard, clearly defined interfaces which tend to protect them from changes in the software environment outside their boundaries. Applications are composed (assembled) at run-time from components selected from a component pool. Because components communicate only through well-defined interfaces, when an application needs to be modified, a single component can be modified (or exchanged for a similar component), without fear of disturbing the other components making up the application.

The component programming model is the end of a natural progression, starting from the monolithic application, and moving toward applications built from increasingly more modularized pieces, with one addition, the framework.

Framework

The framework provides the glue that binds components together. It is used to compose (combine) separate components from a component pool into a running application. It allows components to be linked together and to make calls on specific component interfaces. Additionally, the framework can provide information about the run-time environment.

Putting It All Together

The picture below depicts the elements of the CCA standard and their relationships. The elements with gray background depict elements pertaining to a specific implementation of a component architecture. As outlined in the CCA Component Architecture Model, such elements can include a communication framework, a builder, a repository or individual components. The elements with white background depict elements of the CCA standards necessary for component-level interoperability of components developed within different frameworks.

As shown in the picture components interact with each other, and with a specific framework implementation through standard CCA interfaces. Each component defines its inputs and outputs in Scientific IDL; these definitions are deposited in, and can be retrieved from a repository by using the CCA Repository API. In addition, these definitions serve as input to a proxy generator which generates component stubs: the component-specific parts of GPorts (white box in the picture). The components can also use framework services directly through the CCA Framework Services Interface. The CCA Configuration API ensures that the the components can collaborate with different builders associated with different frameworks.

A framework which conforms to those standards, ie. provides the required CCA services, can express component functionality in scientific IDL, and implements the required CCA interfaces is CCA compliant. Different components will require different sets of services to interoperate; for example some may require remote communication while some don't. Because of this the CCA standard will define different degrees or flavors of compliance; each component will specify a minimum degree of compliance required of a framework within which it can interact.

We will now describe the elements of the CCA standard in more detail:

• CCA Scientific IDL describes the input and output types of components as well as their relationships. This part of the architecture is needed to provide and share component descriptions across different framework implementations. Component descriptions are deposited, and can be retrieved from the Repository through the CCA Repository Interface (see below). Furthermore, component descriptions are used by the proxy generator to provide the "component stubs" element of Gports.
• Gports are a CCA standard encompassing all the functionality necessary to organize component interactions within any CCA compliant framework. The purpose of this standard is to define a uniform model of CCA component interaction. There are two parts to Gports:
• A library of general, framework-specific, but component-independent functionality pertaining to component interaction; this includes such functionality as for example adding a listener to an object, and has the same interface for every component.
• Code implementing component-specific, but framework-independent functionality; it is generated by a proxy generator based on the component definition expressed in CCA Scientific IDL, and will be referred to as a component stub. A component stub contains for example an implementation of an output port, the implementation of marshaling functions in a distributed environment, and provides meta-services such as introspection. The component stub is implemented in terms of standard CCA Framework Services which makes the stub framework-independent. Furthermore, a component stub is expressed in terms of a mapping from the CCA Scientific IDL to a particular language or framework of implementation of the component (for example C++, C, Fortran, Java).
• CCA Framework Services present a framework abstraction which can be used in the component stub implementation as well as by the components themselves directly. This element of architecture is needed for two reasons: in order to abstract certain services which may be used by components directly, and in order to standardize the implementation of component stubs. Furthermore specifying CCA framework services provides a clear definition of the services a CCA framework needs to implement in order to to be CCA compliant, in other words ensure a common platform to components. The following services have been identified so far: communication, security, thread creation and management, memory management and error handling.
• CCA Configuration API encompasses the functionality necessary for the component to interact with the builder and vice versa. This includes such functions as notifying components that they are added to a scenario or deleted from it, redirecting interactions between components. or notifying the builder of a component failure.
• CCA Repository API defines the functionality necessary to search a framework repository for components (as defined in CCA scientific IDL), as well as manipulate components within the repository.

Motivation

The idea of using component frameworks to deal with the complexity of developing interdisciplinary HPC applications is becoming increasingly popular. Such systems enable programmers to accelerate project development through introducing higher-level abstractions and allowing code reusability, as well as provide clearly specified component interfaces which facilitate the task of team interaction. These potential benefits encouraged research groups within a number of laboratories and universities to develop, and experiment with prototype systems. Consequently, there is a need for an interoperability standard.

The need for component programming has been recognized by the business world and resulted in the development of systems such as CORBA, DCOM, Active X and others. However, these systems were designed primarily for sequential applications and do not address the needs of HPC. Their most important shortcoming from the point of view of HPC is that they don't support abstractions necessary for high-performance programming, and don't stress enough what is often the most important factor in scientific programming: performance. In addition, the existing systems are often invasive, that is, they require substantial modifications to existing applications which may not be acceptable to the developer of high-performance components.

In view of these problems it is critical to develop a standard which will address specifically the needs of HPC community. It is our hope that a clear understanding of our needs, and an exploration of our possibilities will result in a system enabling faster and more efficient programming in the future.

Advantages

Component programming offers many advantages over the conventional programming model based on subroutines. The most important are:

• Components provide a clear specification of the inputs needed from other components or elements of the system.
• Well-designed components have the potential for encapsulating parallelism better than simple procedure calls.
• A multi-component application allows for the integration of components implemented in different languages.
• Components may have state.
• Components can be replaced, added to or deleted from an application at run-time via dynamic linking. Component interchangeablity enables graceful software evolution, as you can substitue one conponent with another, more efficient one.
• Components can be customized at the time an application is built through configuration parameters or properties.
• A component may have multiple different interfaces.
• A component can be easily moved to a remote location without recompiling other parts of the application, in particular other components that interact with it directly.
• If a call does not need return values, component programming allows for multicasting such calls.