CCA Frameworks

A component framework is the set of services that are required to instantiate and manage components and the communications among components. The CCA standard does not specify a single framework but instead specifies a minimal set of services required to be CCA compliant. Adding to the potential confusion, many of the frameworks are themselves built using CCA components - but to prevent infinite recursion they typically are self-instantiating.

Because of the wide range of scientific component research that CCA addresses, multiple frameworks have been developed with differing capabilities and restrictions. Some of them are designed as research vehicles to explore particular aspects of CCA, while others are built as production systems. Ultimately all of the capabilities will be combined, either by augmenting one or more existing frameworks, or by specifying bridges between frameworks. Recent work has concentrated on the second approach, since it allows users to access features from other frameworks while continuing to work with the framework with which they are most comfortable. A major division is between direct-connect and distributed frameworks. With some exceptions, direct-connect frameworks do not have the ability to manage components distributed on a wide area network, while distributed frameworks do not have the ability to connect non-isocardinal parallel components (e.g., to address the MxN problem). (Note that "distributed framework" means one which supports distributed components, and does not imply that the framework itself is distributed code.)

Another major division is whether or not the framework uses the Babel run-time system. The reason not all CCA frameworks use Babel is that some preceded Babel, and some use capabilities which Babel does not yet provide.

Until framework bridging is completed, end users need to select a framework. This guide is meant to help in that task.

CCAFFEINE is a Sandia product, and possibly the most commonly used one for complex applications. Ccaffeine supports parallel components running in the same memory space, and can use Babel, or be used without Babel (the "classic" version of Ccaffeine). It does not yet support WAN distributed parallel components.

DCA is an Indiana University research framework for exploring the semantics of parallel remote method invocation (PRMI) and working on the MxN problem. DCA provides an MPI-like interface for parallel transfers and handles one-dimensional array data redistribution. Because DCA involves experimenting with the semantics of PRMI, it is not a production framework. DCA has a partial implementation of a SIDL parser.

DECAFF is a Livermore framework originally developed to understand the CCA specification and to verify SIDL and Babel. Decafe is a direct-connect framework and uses Babel as its run-time system. Current work is bridging between Decafe and the distributed frameworks Scirun2 and XCAT-C++.

CCAIN (note: this link may not work yet it is awaiting approval by LANL) is a Los Alamos framework that emphasizes light-weight rapid development of components with few requirements on the part of the component writers. It uses the Fortran 2003 interoperability specification to bridge to C, and from there to Python and C++ via the usual extern "C" name demangling mechanism.

XCAT-JAVA is an Indiana University distributed framework which currently supports only Java components and does not support parallel components. XCAT-Java uses the grid standard of web services for the distributed component interactions and is a production framework.

SCIRUN-2 is a distributed framework that supports parallel components using a restricted subset of MxN interactions, and handles data redistribution automatically. This production framework is also being bridged to Babel and hence to other CCA frameworks.