Parker Dataflow Notes

Note: This discussion originally came up in the context of the CCA2 proposal, but it seemed worth capturing them here whether or not they appear in the proposal. The original message is from Steve Parker and was transcribed into the wiki by David Bernholdt.

There are several ways to make CCA more directly support dataflow. They are listed here from smallest amount of work to largest amount of work, and also from smallest impact to largest.

1. Create a standard set of interfaces for dataflow applications. This would not require any support from existing frameworks.

2. Follow the design of Corba and add two more port types in addition to uses and provides: publishes/consumes. This would require some support in the infrastructure but would also allow the infrastructure to present this view to the user.

Both of these are "directorless" dataflow - i.e. where each component internally decides what it will and won't do. However, it is often more valuable to have a director involved that controls which components will execute at any given point in time. This avoids redundant computation and facilitates research management.

3. Use the standard dataflow interfaces combined with a set of standard interfaces for directors/controllers. No framework changes would be required, but it would require several standard "director" components.

4. Combine the Corba design above with the director component design of Ptolemy. This would make CCA look a lot like Ptolemy except it wouldn't be tied to just Java and Ptolemy doesn't have the method invocation semantics like Ptolemy does. This would require a little but of support from the frameworks but would also require a number of "standard" director components. Some director components may require the use of threads.

The most involved one (#4) would make CCA pretty powerful. As always, having a compelling use case would help calibrate the appropriate level of effort.