next up previous
Next: Architecture and Implementation Up: XEVENTS/XMESSAGES: Application Events and Previous: Survey of existing systems

Events and Messaging: Desiderata

From the above discussion, we can arrive at a desiderata of features for an event system that intends to cater to distributed applications in the grid:

1. Language and platform independence: The design of an event system should not be tied to a particular programming language or a specific environment.

2. Interoperability: An event system should be flexible enough to interoperate with other messaging systems present in the grid.

3. Extensibility: It should be easy to extend the basic event and add new interfaces to suit the needs of different applications.

4. Ease of integration with existing infrastructure: An event system that is based on existing standards like HTTP, XML and LDAP can seamlessly integrate into existing applications.

5. Simple and flexible interface: The application writer must be provided with a simple API to publish and retrieve events as it would provide a foundation for building more sophisticated interconnections of the objects. It should also be possible to initiate event retrieval by the listener (``pull'') or by the publisher (``push'').

6. Performance: Although application events are not expected to be large and frequent, serialization and deserialization should be efficient.

7. Reliability: An event system should provide atleast a ``best-effort'' guarantee about the delivery and reception of the event since most application events are non-trivial. It would also be useful to be able to tune this to ``atleast-once'', ``utmost-once'' or ``exactly-once'' semantic depending on the application.

8. Web Services: Web Services is gaining wide spread importance and it would be advantageous if the event system exposed a Web Service interface to enable external and possibly unknown applications to make use of the service.

Other useful extensions to meet more complex application requirements include:

1. Firewall invisibility: An event system must be capable of coping with firewalls.

2. Filtering: In many cases, the listener may be interested in only some of the many events being published and it should be possible to filter the events based on various fields present in the events.

3. Persistence: It would be useful to be able to store the events on a disk or database to make it possible to perform historical queries during future analysis of the events.


next up previous
Next: Architecture and Implementation Up: XEVENTS/XMESSAGES: Application Events and Previous: Survey of existing systems
Aleksander Andrzej Slominski 2002-09-20