What is CCAT?

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


Technical overview of the CCA specification

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.

Back to top

CCAT Architecture

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.
Each of these services has been designed to avoid extending the core CCA model.  Consequently each service appears to each CCA component as just another component that has been connected to four "pre-registered" ports.   In the case of the Event Service, it only uses  the connection services and is otherwise a completely portable CCA component.

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.

Back to top

XML specification for components and instances

The structure of the XML documents used is governed by the the following specifications. Back to top

Writing your own CCAT components

  • How to make HPC++ components for the CCAT
  • How to make Java components for the CCAT
  • Back to top

    CCAT Applications

    Coming soon!
    ccat@cs.indiana.edu