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.
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.
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 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.
Breakout Session Scribe:
Antonio Carzaniga, University of Colorado, Boulder