Requirement Specifications

Application and component level events in the Grid environment need to work in heterogeneous environments. Interoperability between disparate systems is a key requirement for distributed component architectures in the Grid. CORBA requires an ORB implementation that conforms to its extensive event specification, while Jini requires the Java environment. It is desirable to draw from these specifications a set of requirements to specify minimal standards for a simple event system. It should be possible to extend this framework to work with CORBA, Jini, JMS or other event systems.

Requirements for Event-Systems

We can extract from the intended uses and the capabilities of existing event systems the requirements which any event system should satisfy:

• Language and platform independence: The design of an event system should not be based on a particular programming language or a specific environment. It should work with both compiled and interpreted (scripting) languages.
• Interoperability: Some systems in the Grid may be optimized to solve a specific set of problems. An event system should be flexible enough to interoperate with such systems.
• Extensibility: It should be easy to extend the basic event types and add new interfaces to suit the needs of different applications.
• Ease of integration with existing infrastructure: An event system that is based on existing standards like HTTP, XML, JNDI and LDAP can seamlessly integrate into existing applications.
• Lightweight Publishers: Standard libraries providing access to network I/O (sockets) and string manipulation should suffice to publish simple events.
• Simple Listener Interface: The listener interface for even reception should be simple. Such a definition for event sinks provides an ideal foundation for building more sophisticated interconnection of publishers, event channels and listeners.
• Performance: although the speed of any communications framework is dependent upon highly dynamic network environments, creating events and turning them into runtime objects upon reception should take at most a few milliseconds.

Useful Extensions

Although the previous list specifies minimal requirements for an event system, it should also be easily extended to meet other requirements of complex applications. Most of these extensions are realizable if the event model allows third-party objects to disseminate events. Such third party objects are often implemented as event channels which decouple the direct connection between publishers and subscribers. These extensions include:

• Firewall invisibility: An event system should be aware and capable of coping with firewalls.
• Filtering: A listener may be interested in only a specific set of events generated by a publisher. Filtering mechanisms can be put in place to send only those events that a listener has registered interest in.
• Event persistence: A third party object should maintain a list of undelivered events in permanent storage such as disk. This obviates the need for listeners to be connected to the system at the time the event was generated.
• QoS: An event system should provide guarantees about the delivery of events as conforming to at-least-once, at-most-once or exactly-once semantics.

Because a primary use of events is in debugging and long-term performance monitoring, robustness is critical. A leasing mechanism can help maintain this robustness since a leasing-publisher need not keep a persistent list of event recipients. So restarting a publisher need not require restarting all the listeners. Finally, security considerations should be designed into the event framework.