Event Specification Proposal

event specification sidl


event specification overview document

• GUI component

When thinking of events, it is natural to think about GUI systems. However, the CCA event system is not intended to replace event support in the GUI toolkit. Instead, it provides its own means for distributing events to components in a framework. Of course, there are a number of events that occur that may need to be reflected in a GUI.

We are working on a common set of events that are of use to any CCA framework. Most of these are in the area of component lifecycle and discovery.

In the event specification, we reserve the cca.* event topic namsepace for these standard events. As the specification evolves, these topic names and the structure of the event body (as a TypeMap? or XML) will be specified as well. Any feedback on what this namspace should look like is very useful.

While it would be possible to implement the CCA event service on top of a GUI event framework, it wouldn't be an optimal choice, as the usage patterns are too different.

• multiple frameworks

Q:In this case let's consider several instances of (possibly) the same framework and the "main()" program appears as a component in all of them. When main() calls framework specific methods (e.g. anything on Services) then the event bus associated with that framework gets serviced. But if those methods are not called then the events will not get serviced. It seems conceivable that this could lead to a deadlock. It could be that the event service _should_ be a singleton to prevent this.

A: The EventService? is indeed a singleton, or unique to a given framework. For several instances of the same framework, it is up to the implementation to decide if all the framework instances share the same service instance or not. Each case has advantages and disadvantages.

As for different frameworks, there seems to be more general interoperability issues that need to be addressed before one can discuss passing events between differing frameworks.

• FPGAs and other heterogeneous environments

With respect to FPGAs, the main need is to be able to asynchronously call a method that will execute on an FPGA and when it is finished, the calling process should be notified. Hardware-accelerated methods (FPGA) will require the participation of a partner processor to handle all OS and framework system calls, the FPGA itself can only provide the computation with a restricted placement of the input data (i.e. it has to be on the FPGAs SRAM, or it has to be on certain window within the partner processor's main memory). The partner processor should, of course, be the processor which is physically closest to the FPGA itself in order to minimize overhead. Synchronous execution on the FPGAs should also be supported with semantics similar to a regular method call. (More details to come...)

The model of providing FPGA support is very platform dependent. In most cases, a driver will be needed to setup access to the FPGA and to place data and calls to it. To raise a CCA event when the FPGA computation completes, it will probably be necessary to write platform and framework-specifc code that interacts with that driver to raise events based on low-level callback mechanisms (signals, callback functions, etc.) that the driver and OS platform provide.

Using CCA Events for Polygraph and FPGAs

• Event Service for HPC applications

A prototype implementation of the initial CCA Event Service specification was implemented at PNNL on a Cray XD-1 using ARMCI as the event transport. A paper describing this work has been published at the Software Engineering for HPC Workshop held in minneapolis in May 2007.

SE-HPC 2007 paper

We have now implemented the modified specification (from January 2007 CCA meeting) on the XD-1 and have increased the performance of event delivery by redesigning the event service internals. We have test ed this in a prototype application by using the event service as an abstraction to distribute work to a collection of FPGA-based analysis components from a mass spectrometry application.

We have submitted a paper to the journal Concurrency & Computation: Practice and Experience, describing in full details the design and implementation of a high-performance event service on HPC platforms. The paper also discusses the use of the event service for distributing work on a mass spectrometry application executing on a heterogeneous CPU/FPGA cluster.

The paper is titled "Design and Implementation of a High-Performance? CCA Event Service". A summary of the paper is:



We'll be able to post the paper as soon as it is accepted by CCPE...

An evolving document describing use cases at PNNL for the HPC version of the event service is:

HPC Event Service use cases

• distributed environments

It is up to each component to decide how an event is distributed inside a component; the event service just insures that the every component gets the events it subscribes to, and can send events to all components. It is up to the framework implementation to provide those semantics, but the semantics of intra-component distribution is not specified.

If using a standard CCA event service model to distribute events in a single component is desired, then it can work on that. The main issue is that intra-component events may be able to use optimizations that inter-component events can not. For example, if the component is in a single address space, one could create a simple event bus based on callback functions, allowing arbirtary objects in the language to be passed back and forth,

• Management and Monitoring

One common use of an event-based system is often used as the backbone of management and performance tools. Tools like HP Openview, Tivoli and Microsoft Operation Manager use a large set of events that correspond to various events in a running system (for example, process creation, abnormal termination, user login/logout, etc.) Also, there is a set of events associated with performance (memory usage, page file system, etc.)

It seems that a discussion of create a standard set of CCA performance and management events that are optionally available to CCA components is worth exploring. However, it can not be understated that the collection and distribution of these events is not easy to scale. All the above companies have significant IP and technologies that allow the detection and distribution of system events with minimal overhead and maximum scalability.

• Appropriate Use of Events

It is vital to note that events are not a replacement for remote method calls or other methods of communication. Defining the appropriate level of events, how often events are raised and processed is vital for events to be used successfully. The framework can only process events as best they can.


An event-based frame management (component wrangling) system has been prototyped for Ccaffeine (the ccafe04 framework implementation). The event delivery model is synchronous callbacks (on a local basis in a multi-process environment). The javadoc of the events and listeners in this prototype is available at Ben's cca-forum web site.
Compared to the 'everything is a string' approach, this prototype leverages the existing CCA defined handles (ComponentID, ConnectionID, TypeMap, ComponentClassDescription) in the event payloads. Once a component receives the event, it has everything it needs to interact with the BuilderService in response to the event. See particularly ccaffeine.ports.ContextEvent*Service and the package ccaffeine.ce. A ComparisonWithCcaffeineFrameworkEvents reveals some efficiency issues both in coding and runtime performance.