CCAIN

CCAIN work has been discontinued. Ease of use work has rolled into bocca and onramp developments.

The CCA INtegration Framework

Overview: What is CCAIN?
CCAIN is a very light-weight framework for supporting component-based programs written in a mix of C, C++, and Fortran 2003. It implements a subset of the Common Component Architecture (CCA) specification. The facilities that it provides support the basic operations of creating, connecting, and calling components. By using C only for implementing the framework, CCAIN itself does not require any tools beyond a C compiler and the compilers for the components that make up user applications. This removes the dependence of the component framework from compiler features and tools that increase the complexity of the component toolchain. Avoiding this complexity decreases build time, removes potential difficulties in porting between platforms, and makes code less susceptable to incompatibilities between tools as their individual versions evolve. CCAIN is based on static linking of components, which eliminates portability issues due to support for dynamic linking of component-based programs at runtime. Although other frameworks support static linking quite readily, their support for dynamic linking increases their cost for porting to new platforms. CCAIN supports sequential, multi-threaded parallel, and distributed memory parallel (ala MPI, ARMCI, etc...) programming. Distributed programs based on remote method invocation, grid computing, and other non-traditional approaches to parallel programming are not supported. Other frameworks exist that can be used if these programming models are desired.

The key points to associate with CCAIN are summarized as:

* Language interoperability via C API.
* Static component linking.
* Thread-level and message-passing parallelism internally within components.
* Minimal toolset required for framework - make and a C compiler.

Documentation
Currently the best place to learn about CCAIN is the Doxygen documentation from the code, the examples included with the distribution, and the little readme files in various places. Documentation will grow over time.



CCAIN Design?
Component:

/**
* This is here only as a way to declare the base of a component, and
* any user's components would expand on this. This allows the framework
* to perform a cast operation to access fields w/in the component.
*/
typedef struct CcainBaseComponent?
{
/* the local services object for this component, which itself contains
* a reference to the centralized service structure.
*/
CcainLocalServices_t *myServices;

/* function pointer for the setServices function given by a component */
void (*setServices)(struct CcainBaseComponent *comp,
CcainLocalServices_t *myServices);

void (*addRef)(struct CcainBaseComponent *comp);
void (*deleteRef)(struct CcainBaseComponent *comp);
}CcainBaseComponent_t;

Questions:
1) Should deleteRef() return the current reference count to allow the caller to free the memory if there are no more references?
2) Is the framework responsible for freeing the memory?
3) Who frees the memory?
4) Does a Port need an addRef() and deleteRef() also?
Answers:
1) no. generally only the object knows how to delete itself. For ALL objects, add/del ref come first in the struct and we have a base struct type CcainCountable { addRef; deleteRef; } (where i'm omitting proper C syntax in Countable at the moment.)
2) The framework is responsible for using create/addref/deleteref appropriately.
3) objects know how to delete themselves (or not) inside their deleteref impl.
4) Ports should be refcounted like all other objects. We can choose to make a special exception for ports that are advertised to the framework with as uncounted eg addProvidesPort(CcainCountable *portInstance, const char *myPortInstName, const char *myPortType); and addVoidProvidesPort(void *portInstance, ...etc); The contract on void* ports is as in ccaffeine: the framework will hold the pointer until removeVoidProvidesPort is called, and then it will be returned to the remover that presumably was also the provide caller and knows how the memory of the particular void* is managed. Void* ports will be non-proxyable.

CCAIN Development?
CCAIN Downloads?
CCAIN SourceForge Site
CCAIN Documentation?