Abstract

In this essay, the author gives a short summarization on the list of 'things to consider' for an event notification system. It takes reference from the power point slides presented at WISEN (Workshop on Internet-Scale Event Notification) in 1998 at the University of California, Irvine. (Details can be found at the site http://www.ics.uci.edu/IRUS/twist/). Note that, the essay does not aim to identify a core set of requirements for the event notification system as WISEN had tried to do, but instead try to list the 'maximum' list of things that could be considered.

Context and Overall Event Model

Answer Questions: what is the domain of the event notification model? Does it aim for small or large group of people on LAN or WAN? Is it done through satellite or regular wired network? Are people located sparsely or densely? Is it a fixed user base? How large is the user base? Any expansion requirement (scalability). Is it a generic event notification or only for a particular purpose. Any real timing requirement? Is the event notification synchronized, asynchronized, broadcast based, CORBA event service model like, a register-subscribe-notification model, etc.

Protocol and System Design

Based on model used, what are the steps how the system runs? For example, register-publish-subscribe-notification model has four steps. How each step is designed? In what format/syntax does the event notification be passed? Does it allow users to define user types that can be passed? Can notification Attributes be associated with the notification? What type of lower protocol is used? TCP or UDP? How long does the TCP session is open? Does the protocol is compatible with existing firewalls. How well it can be extended. Is the protocol blocking or non-blocking. Can complex events be handled? What notification methods are used? By email, socket programming+UI, log files, etc.

User Interface

This could vary dramatically among systems and is not quite a concern. Some questions could be asked in terms of whether it involves extra installation of software on the user side. Whether it asks every user to have an email account. Etc.

Other requirements

Is the notification delivery is reliable or not.

What Quality of service is provided? And can it be dynamically configured? Some Quality of Service examples are: deliver reliability check, requesting notification on lost event notifications, requesting a single notification for one event or repeated notification for the same event. If several objects subscribe together, who should be notified first? The receiver subscribing for some event might require information about the publisher. The publisher may request anonymity of the notification.

How well the system can scale.

How well the system uses the network and local resources.

How system handles un-normal situations? E.g. the subscriber became not reachable currently. Does the service queue the events for that particular subscriber? If not, when that particular subscriber came back to system again, do we notify that we had events sent out already? If yes, what will be the buffer size? Etc.

Can the system re-route the events among event services at different point? (Mobile requirement).

Is the system secure? Can the system allow an object to publish on the behalf of another object? Can bad guy hacks it in easily? Will user defined types be able to mess up? Who does the filtering and controls the event flow? Should we use digital sign?

Some system implementation details might include how well it handles system hang. Will one bad connection mess up the other connections?

Can the notifications being aggregated?