|The Common Component Architecture Forum|
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.
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:
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.
Component programming offers many advantages over the conventional programming model based on subroutines. The most important are:
|© Copyright 2002-2004|