Personal tools
You are here: Home → Working Groups → Event Service → Use Cases
 

Use Cases

by damevski — last modified Sep 12, 2008 12:53 PM

Discussion on a few possible event service scenarios.

  • 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. However, many of these decisions are up to the framework-specific implementation of the EventService interface.

 

  • Event Service as a GUI
    When thinking of events, it is natural to think about GUI systems. However, this 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.* topic namespace for these standard events. As the specification evolves, these topic names and the structure of the event body (as a TypeMap) will be specified as well. Any feedback on what this namespace 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.

  • Event Service in Multiple Frameworks
    Q: 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 Event Service 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 (PNNL)
    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.

    More information on FPGA applications using the CCA Event Service can be found in this short paper:
    Using CCA Events for Polygraph and FPGAs (PNNL)

  • 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.

  • Intra-component Events
    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,

  • Event Service for HPC Applications (PNNL)
    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:
    A High Performance Event Service for HPC Applications


    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.
Document Actions