Here we have a scratch-pad of feature ideas under discussion for
extension of the CCA SIDL specification or of the generic
components that might be supplied to any CCA environment.
The presentation is in no particular order yet.

Event Specification Proposal
A first draft of a general CCA event specification.

Typemap extension proposal
We need more power, Scotty.

Generic distributed Event services
A general event framework. A great deal of prior art exists for this, including event bus specifications from various versions of XCAT. In the CCA context, the present gotcha is that an interprocess protocol (Babel RMI) is still under development.

In high-performance frameworks, an extra (relatively uncontrolled) thread is generally avoided. Thus call-back based in-process systems are often preferred to asynchronous event delivery systems dependent on threads.

Framework Events Service Component
A specific event framework describing happenings within a running framework (which could be built on top of a generic event potentially, if the generic framework provides guarantees about delivery and delivery order). The primary publishers would be frames or components acting as frames. Both publishers and subscribers would manage events via CCA ports. A framework which manages nearly everything with via events is possible (the Java Ccafe framework of 2001 demonstrates this), but of course requires the Framework Event component be treated as more equal than the rest of the components.

MxN Component
Data redistribution components are a high level topic, which probably deserves a CcaMxN? wiki page all its own.

MPI Component
This component at runtime will do fairly trivial things — just hand out MPI Comm dups or references to a shared communicator and handle the variations of MPI that require argc/argv be passed. Most of the value is in the data collected and exported to all downstream applications and build processes about how to compile and link components or applications with MPI in the installed Babel/CCA environment.

Advanced MPI Component
An MPI component with more detailed functionality to"simplify" constructing MPMD applications from components.

Component Registry
In much prior art this means a server process (distributed component) that provides interfaces and a mechanism for distinct applications (components) to find each other and connect (with or without including the intermediary in all subsequent calls). The assumption is that component means an already running instance.

In more SPMD-oriented frameworks (like Ccaffeine), components are instances of classes from libraries linked within a single parallel process image (spread over parallel nodes). The registry, then, describes classes available to be linked (either statically or at run-time). Various CCA-supportive XML schema/dtds have been defined for storing registry data, but none is yet in the adopted standard.

Creation Service
In the distributed context, this means a server that causes (by hook or crook) other servers (components) to be started and registered.

In more SPMD-oriented frameworks (like Ccaffeine), components are instances of classes from libraries linked within a single parallel process image (spread over parallel nodes). Creation implies calling a factory function after assuring that the corresponding library is linked in the defined process. This defined process may be a dynamic runtime or an application binary being assembled from static libraries.

Rule Processing Service Component
Given any event service, a rule processing and event filtering service can be constructed that allows applications and subsets of components to be self-assembling. A prototype exists in the Java Ccafe framework.

Command-line Processing Component
A command line convention for passing configuration values to components and a component to implement/automate that processing. Take a look at JSAP (Java Simple Argument Parsing) for anything of value.

Environment Processing Component
An environment variable convention for passing configuration values to components implemented by another service component. Much prior art exists including but by no means limited to the Windows registry, X-resource database, Java property files, Windows ini files, and the Petsc resources.

Output Management Component
At least one set of prototypes of this exists — the Printf port in Ccaffeine. In the parallel context, text and data output files are routinely an important issue. The difficulty with components for text output is that the least common denominator is printing a string optionally with a carriage return. Every language has a highly unique idiom for regular text input/output.

Ideas that may be worth investigating include:

Analogs/generalizations of Java's Log4J or output control scheme used in NWChem
Configurable tagging of output lines with process ids, timestamps, line numbers, etc. If done in XML, it might be possible to create XSLT translators to re-organize outputs by timestamp or by processor id or other attributes.

Management of large binary data input/output is historically precisely the domain of the application specialist and not a generic data managing component because I/O performance requirements may be very stringent.

GuiBuilder Service
This could be a component in the distributed computing sense. Given a detailed framework events specification, a GUI application component to drive a "remote" framework is possible. Prior art exists in Scirun/Ccaffeine/XCAT, but lacking an event standard and an RMI protocol, nothing has been defined in the CCA specification yet.

Distributed CCA Protocols
Define the protocols and conventions that would allow "live" interoperability amongst CCA frameworks. This means the ability to have a set of components on system A running in framework AA connect to another set of components running on system B running in framework BB as a single application.

User Interface APIs
Define the API's and corresponding ports for support of user interface functionality, such as that used and provided by a GUI builder component.

Package/Component CCA Description Language and Related Tools
We're interested in defining simple tools for extracting the information needed to generate, build, and package components implemented in any language from the component author. Thumb-screws are not working well.

Architecture Description Language
A standardized way to represent compositions of CCA components. Suitable for feeding to a framework (service) for instantiation, describing (hierarchical) component assemblies (for complexity management), and as part of recording provenance information for a CCA application. Q: does this need to be time-dependent, or can that be put over the top?

Application Composition Tracker Service
One of the underlying services for a provenance tracking capability for the CCA. This service logs changes to the application's composition over time, and reports them on demand. Generally, BuilderService? calls would result in updates to the internal composition information maintained by this service, and timestamped log entries. Components would supply provenance information about themselves through a yet-to-be-defined interface. The component could be queried for snapshot composition (perhaps returned in the Architecture Description Language), or historical information (in a form to be determined). It could also be queried for the provenance information based on component id.

Created by: baallan last modification: Saturday 06 of October, 2007 [17:46:15 UTC] by bernhold

similar

Online users

3 online users