Posts: 5,362
Threads: 2,998
Joined: Feb 2011
[attachment=12700]
Abstract
The Common Component Architecture (CCA) provides a means for software developers to manage the complexity of large-scale scientific simulations and to move toward a plug-and-play environment for high-performance computing.
In the scientific computing context, component models also promote collaboration using independently developed software, thereby allowing particular individuals or groups to focus on the aspects of greatest interest to them. The CCA supports parallel and distributed computing as well as local high-performance connections between components in a language-independent manner. The design places minimal requirements on components and thus facilitates the integration of existing code into the CCA environment. The CCA model imposes minimal overhead to minimize the impact on application performance.
The focus on high performance distinguishes the CCA from most other component models. The CCA is being applied within an increasing range of disciplines, including combustion research, global climate simulation, and computational chemistry.
1. Introduction:
Historically, the principle concerns of software developers for high-performance scientific computing have centered on increasing the scope and fidelity of their simulations, and then increasing the performance and efficiency to address the exceedingly long execution times that can accompany these goals. Initial successes with computational simulations have led to the desire for solutions to larger, more sophisticated problems and the improvement of models to reflect greater levels of detail and accuracy.
At the same time, the computer industry has continued to create ever larger and more complex hardware in an attempt to satisfy the increasing demand for simulation capabilities. These architectures tend to exacerbate the complexity of software running on these systems, as in nearly all cases, the increased complexity is exposed to the programmer at some level and must be explicitly managed to extract the maximum possible performance. In scientific high-performance computing, relatively little attention has been paid to improving the fundamental software development process and finding ways to manage the ballooning complexity of the software and operating environment.
Simultaneously, in other domains of software development, complexity rather than runtime performance has been a primary concern.
2. CCA FORUM:
The CCA Forum was founded in January 1998, as a group of researchers from national DOE labs and academic institutions committed to defining a standard Component Architecture for High Performance Computing. The CCA Forum noticed that the idea of using component frameworks to deal with the complexity of developing interdisciplinary HPC applications was 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. However, these prototypes do not interoperate. The need for component programming has been recognized by the business world and resulted in the development of systems such as COMA, DCOM, Active X and others. However, these systems were designed primarily for sequential applications and do not address the needs of HPC.
Objective :
The objective of the CCA Forum is to create a standard that both a framework and components must implement to define a minimum set of conditions needed to allow high performance components built by different teams at different institutions to be used together, and to allow these components to interoperate with one of a set of frameworks, where the frameworks may be built by teams different from those building the components. The CCA forum members are developing implementations of the standard as well, both components and frameworks.
3. The Common Component Architecture
Formally, the Common Component Architecture is a specification of an HPC-friendly component model. This specification provides a focus for an extensive research and development effort. The research effort emphasizes understanding how best to utilize and implement component-based software engineering practices in the high-performance scientific computing arena, and feeding back that information into the broader component software field. In addition to defining the specification, the development effort creates practical reference implementations and helps scientific software developers use them to create CCA-compliant software. Ultimately, a rich marketplace of scientific components will allow new component-based applications to be built from predominantly off-the-shelf scientific components.
Philosophy:
The purpose of the CCA is to facilitate and promote the more productive development of high-performance, high quality scientific software in a way that is simple and natural for scientific software developers.
The CCA intentionally has much in common with commodity component models but does not hesitate to do things differently where the needs of HPC dictate. High performance and ease of use are more strongly emphasized in the CCA effort than in commodity component models. However, in principal no barriers exist to providing an HPC component framework based on commodity models, or to creating bridges between CCA components and other component models, e.g.,Web Services.
Objectives:
The specific objectives that have guided the development of the CCA are:
1. Component Characteristics: The CCA is used primarily for high-performance components implemented in the Single Program Multiple Data (SPMD) or Multiple Program Multiple Data (MPMD) paradigms. Issues that must be resolved to build applications of such components include interacting with multiple communicating processes, the coexistence of multiple sophisticated run-time systems, message-passing libraries, threads, and efficient transfers of large data sets.
2. Heterogeneity: Whenever technically possible, the CCA must be able to combine within one application components executing on multiple architectures, implemented in different languages, and using different run-time systems. Furthermore, design priorities must be geared toward addressing the software needs most common in HPC environment; for example, interoperability with languages popular in scientific programming, such as Fortran, C, and C++, should be given priority.
3. Local and Remote Components: Components are local if they live in a single application address space (referred to as in-process components in some other component models) and remote otherwise. The interaction between local components should cost no more than a virtual function call; the interaction of remote components must be able to exploit zero-copy protocols and other advantages offered by state of the art networking.Whenever possible local and remote components must be interoperable and be able to change interactions from
local to remote seamlessly. The CCA will address the needs of remote components running over a local area network and wide area network; distributed component applications must be able to satisfy real-time constraints and interact with diverse supercomputing schedulers.
4. Integration: The integration of components into the CCA environment must be as smooth as possible. Existing components or well-structured non-component component code should not have to be rewritten substantially to work in CCA frameworks. In general, components should be usable in multiple CCA-compliant frameworks without modification (at the source code level).
5. High-Performance: It is essential that the set of standard features contain mechanisms for supporting high performance interactions. Whenever possible, the component environment should avoid requiring extra copies, extra communication, and synchronization, and should encourage efficient implementations, such as parallel data transfers. The CCA should not impose a particular parallel programming model on users, but rather allow users to continue using the approaches with which they are most familiar and comfortable.
6. Openness and Simplicity: The CCA specification should be open and usable with open software. In HPC this flexibility is needed to keep pace with the ever-changing demands of the scientific programming world. Related and possibly more important is simplicity. For the target audience of computational scientists, computer science is not a primary concern. An HPC component architecture must be simple to adopt, use, and reuse; otherwise,any other objectives will be moot.
4. CCA Concepts:
The central task of the CCA Forum is the development of a component model specification that satisfies the objectives above. That specification defines the rights, responsibilities of individual elements and the relationships among the elements of the CCA's component model, including the interfaces and methods that control their interactions.
Elements of CCA Model:
• Components:
An individual component is a software package or a module that encapsulates a set of related functions (or data). They are units of software functionality and deployment that can be composed together to form applications.
Components encapsulate much of the complexity of the software inside a black box and expose only well-defined interfaces to other components.
Features of Component:
• modular and cohesive: All system processes are placed into separate components so that all of the data and functions inside each component are semantically related (just as with the contents of classes). Because of this principle, it is often said that components are modular and cohesive.
• Encapsulated:
With regard to system-wide co-ordination, components communicate with each other via interfaces. When a component offers services to the rest of the system, it adopts a provided interface which specifies the services that can be utilized by other components and how. This interface can be seen as a signature of the component - the client does not need to know about the inner workings of the component (implementation) in order to make use of it. This principle results in components referred to as encapsulated.
• Substitutable:
Another important attribute of components is that they are substitutable, so that a component can replace another (at design time or run-time), if the successor component meets the requirements of the initial component (expressed via the interfaces). Consequently, components can be replaced with either an updated version or an alternative for example, without breaking the system in which the component operates.
Techniques used:
When a component is to be accessed or shared across execution contexts or network links, techniques such as serialization or marshalling are often employed to deliver the component to its destination.
Reusability is an important characteristic of a high-quality software component. A software component should be designed and implemented so that it can be reused in many different programs.
Needs to be componetinized:
It takes significant effort and awareness to write a software component that is effectively reusable. The component needs to be:
i. fully documented
ii. thoroughly tested
a. robust - with comprehensive input-validity checking
b. able to pass back appropriate error messages or return codes
iii. designed with an awareness that it will be put to unforeseen uses
• Ports:
They are the abstract interfaces through which components interact. Specifically, CCA ports provide procedural interfaces that can be thought of as a class or an interface in object-oriented languages, or a collection of subroutines; in a language such as Fortran 90, they can be related to a collection of subroutines or a module. Components may provide ports, meaning they implement the functionality expressed in the port (called provides ports), or they may use ports, meaning they make calls on a port provided by another component (called uses ports). It is important to recognize that the CCA working group does not claim responsibility for defining all possible ports. It is hoped that the most important ports will be defined by domain computational scientists and be standardized by common consent or de facto use.
• Frameworks:
They manage CCA components as they are assembled into applications and executed. The framework is responsible for connecting uses and provides ports without exposing the components' implementation details.
The framework also provides a small set of standard services that are available to all components. In order to reuse concepts within the CCA, services are cast as ports that are available to all components at all times
