Requirements for Internet scale event notifications

The goal of this session was to identify a set of requirements for an Internet-scale event notification service. More specifically, the discussion developed from minimal requirements to advanced and domain-specific requirements. Also, the tension between various domain-specific requirements led to discussing the possibility of having one single event service, usable in different contexts, as opposed to a number of separate services targeted to some particular application domain.

Core or minimal requirements define the core functionalities of an Internet-scale event notification service. These are the features that a technology must exhibit in order to qualify as an Internet-scale event notification service.

Advanced features are not mandatory parts of the core service, however they are desirable functionalities that any Internet-scale event notification service should provide either because they are of common utility for many classes of applications or because they can not be easily or efficiently implemented on top of the core services.

Core Requirements

A quite numerous list of core requirements has been proposed. Only some items were analyzed in detail, and a few comments were made on the interplay between different items.

core functionality: The main service provided by an event-based infrastructure is the notification of the occurrence of events. Objects can declare their interest in being notified of the occurrence of an event or a class of events by issuing a subscription. In other words, subscriptions can be used to select notifications. The selection is based on the content of notifications, which corresponds to the data associated with the observation of the event.
attributes of the notification service: The notification of an event is asynchronous with respect to the occurrence of the event. Event producers and consumers are decoupled, i.e., it is not necessary for producers to be aware of the existence of consumers nor of their identity, and vice-versa. Note that this principle doesn't require or imply notifications be anonymous. A notification must be reliably delivered to all the components that subscribed for it. Most of these aspects can be seen in a more general perspective in which the quality of service can be dynamically configured. For example, an object publishing a message can require anonymity of the notification. Or conversely, an object subscribing for some events might require notifications to report information about the publisher. As far as reliability is concerned, both publishers and subscribers ideally should be able to specify different levels or kinds of service. For example, one subscriber might want to receive exactly one notification for each event while others might accept repeated notifications or even lost notifications. The same service parameters could be set by publishers.
event notification protocol: In order to define the interface of the event service, an event notification protocol or an API should be defined. The choice of a protocol is preferable because a protocol is more language-neutral and it is presumably easier to agree on. Also, different implementations and vendors can provide extended APIs and language-dependent bindings that should not be included or constrained by the common interface definition.
For the design of this protocol, some extensions of HTTP have been proposed. The major requirement for an event notification protocol is to be compatible with existing firewalls. Other obvious requirements are extensibility and efficiency. It would also be possible and in some cases desirable to piggy-back the notification protocol on top of other standard protocols.
distributed architecture: Although the functionality of the service per se doesn't impose this, everyone agrees that it is necessary to have some sort of distributed architecture for the implementation of the service.

Advanced Requirements

extensions and variances of the basic service

It has been suggested as a minimalist approach that notification be idempotent. This supposedly makes the event service simpler because it is not necessary for it to avoid repeated notification. It should be clear that this is a requirement on the applications that use the event service rather than on the event service itself.

Many applications would benefit from having advanced subscription mechanisms that facilitate the selection of very specific classes of events as well as sequences of events. As an example consider a security monitor, in order to detect an intrusion, the monitor might want to receive a notification every time three consecutive failed logins occur for the same user on any machine in a subnet. Although suggested by domain-specific applications, this requirement seems to be useful in a generic event notification service.

The event notification interface, and therefore the event notification protocol, should allow for objects to be connected to the event service through proxy agents. This forces an additional de-coupling in the protocol specification in that it should be possible for an object to publish (and subscribe) on the behalf of another object.

persistence

It is clearly necessary for subscriptions to be persistent within the event service. It has also been argued that the event service should provide persistent storage of notifications. This feature is also related to the types of ``call-back'' mechanism that can be registered with subscriptions. Ideally, the event service should support various communication methods, possibly including HTTP and SMTP. Also, for every single subscription, a list of notification call-backs could be registered so that the event service could try the main one and then fall back to the other ones in case the main one is not accessible.

Persistence of notifications is also implied in case the event service supports a pull-style notification mechanism in which objects actively poll the service to check for new notifications.

There has been quite a bit of discussion on this aspect. Some think that persistence is so crucial that it would be a bad idea to retrofit it. On the other hand, others argue that persistence should not be handled directly by the event service, but instead, when required, it could be incorporated and dealt with by the call-back mechanisms. An example of a persistent call-back mechanism is e-mail. The impact of persistence should also be evaluated with respect to scalability.

mobility

Mobile computing technology allows roaming users to access their personal resources from different nodes on a wide-area network. Similarly, thanks to mobile code technology, applications can ``move'' through the net requesting services from several access points. This possibility poses an additional requirement on the event service. In fact, it is desirable that the event service support mobility by automatically re-routing notifications to follow users or applications as they move. Clearly, this would also require to augment the event service interface (and the corresponding protocol) with the appropriate mobility primitives.

Breakout Session Scribe: Antonio Carzaniga, University of Colorado, Boulder