next up previous
Next: Requirement Specifications Up: An Extensible and Interoperable Previous: Introduction

Subsections

Survey of Existing Standards

Any proposed event mechanism must work with existing event standards There is no one best solution. Therefore it is important to have simple and extensible event system that can easily be molded to the needs of applications. Event systems must allow for a naming scheme, object types, security, and leverage Internet standards. Some of the existing standards for event systems can be differentiated according to their design of naming services, push/pull models, capacity to handle firewalls, type description language, language independence, extensions for security, failsafe mechanisms and performance.

CORBA Events

A CORBA [10] event channel is an intervening object that allows multiple suppliers to communicate with multiple consumers asynchronously. An event channel is both a consumer and a supplier of events. Event channels are standard CORBA objects and communication with an event channel is accomplished using standard CORBA requests. References to the event channel may be received from a naming service or from specific-to-task object protocol. CORBA supports a Naming service to locate listeners, and both a push and pull model. Event types are described using IDL, and the OMG specification describes mechanisms for load balancing and recovery.

Jini Events

The Jini [14] event system uses the Jini Lookup Service for naming which can be optionally used with JNDI [15]. An event is a Java object that can be subtyped for extensibility. The listener interface is simple and aids in the use of a flexible publisher model. Jini supports leasing and uses RMI as the communication substrate. It leverages the built-in security of Java. However, Jini events are designed to work only in the Java environment. Third party objects can handle the distribution of events using Store and Forward mechanisms, Notification Filters and Notification Mailboxes.

Java Messaging Service

The Java Message Service (JMS) [17] is a Java API that allows applications to create, send, receive and read messages. It defines a common set of interfaces and associated semantics that allows Java programs to communicate with other messaging implementations. JMS provides a loosely coupled architecture that supports asynchronous communication and guarantees reliable delivery of messages.

ECho Event Delivery System

ECho [9] is an event delivery middleware system. It is designed as an anonymous group communication mechanism. It has high performance event-delivery based middleware that transmits event data in binary. ECho supports the publish/subscribe model of communication and can interoperate with CORBA or Java-based components.

Grid Monitoring Service Architecture

The Grid Forum Performance Working Group [7] has been studying the performance of systems based on the Grid Monitoring Architecture [3]. They define an event as a structure that contains one or more items of data that relate to one or more resources. In their system an event type uniquely identifies an event and an event schema is used to describe the structure of a particular event. They have defined a set of schemas [4] to represent grid performance using XML-Schemas. The Grid Forum Performance Group plans to use LDAP [12] to interface with a directory service [4].


next up previous
Next: Requirement Specifications Up: An Extensible and Interoperable Previous: Introduction
Aleksander Andrzej Slominski 2002-02-23