• What is CCAT?
• Technical overview of the CCA specification
• CCAT architecture
• XML specification for components and instances
• Writing your own CCAT components
• CCAT Applications
• Glossary of CCAT Terms

This page and the links it contains describe the Indiana University, Extreme Lab implementation of the DOE 2000 and ASCI funded Common Component Architecture.

The CCA specification describes the construction ofportable software components that may be re-used in any CCA compliant runtime framework. It is expected that the CCA group will build frameworks that are tuned for a variety of application environments.    Some cases are designed for applications that run on massively parallel computers.  In these cases components may be parallel objects (multiple component instances operating in synchrony and communicating with each other with MPI) or they may be highly multi-threaded and run on large shared memory, multiprocessor servers.

In other implementations, the frameworks are designed to support applications built from components that are distributed over a wide-area "grid" of resources and distributed services.   The Indiana implementation is this type of framework.   It is based on Globus for its core security and remote task creation, and it uses Java RMI over Nexus as a communication protocol.  Currently we are extending the mechanisms to use other protocols such as SOAP.

A very brief technical overview of the CCA component specification is given here.  This includes the standard CCA interfaces and a description of their semantics.  

This current implementation is also a research vehicle.   In particular, it is a tool for the study of CCA based distributed applications and services.   These pages focus on experiments with services in CCA. Back to top

A brief technical overview of the CCA specification can be found here. The complete specification passed by the CCA forum in its December 1999 meeting is available here.

CCAT has a service architecture based on components. There are five services described here.

• Directory Service - a tool that allows a component to browse remote directories of various types.   The information in these directories is data about component specifications.
• Registry Service - a tool that allows a component to browse remote directories of various types.   The information in these directories relates to running instances of components.
• Creation Service - a tool that allows a component to instantiate another component.  The new component may be running in the same address space, or it may be on a remote host.
• Connection Service - a tool that allows one component to connect  the "ports" of one component to those of another.  This is the way applications of CCA are composed.  Given these three services it is possible to define application builders that are also components.  Consequently, such a composition tool can be run in any framework that supports these services.
• Event Service -  a tool that allows components to publish and subscribe to events.   the event model may be a point-to-point generator/listener model or it may be a push based publisher - channel - subscriber model that does type filtering.

However it must be noted that these services are not currently part of the cca specification.  They are experimental, proof-of-concept demonstrations of a possible standard.

• Component Static Information -  provides the actual DTD, description and examples for storing component static information.
• Component Instance Information -  provides the actual DTD, description and examples for storing component instance information.

How to make HPC++ components for the CCAT

How to make Java components for the CCAT