At today’s highly distributed network, non-predictable events happen everywhere and event notification technology permeates every part of the Internet. A good design of an event notification system could save unnecessary wastage of the network bandwidth and achieve the best usage of the system resource on the clients, server, or peers.

Event notifications, no matter where they exist (printing system, operating system, application level stock exchange system, wireless communication, etc), no matter in what protocol they could be defined (HTTP, SMTP), they follow patterns. Among all these patterns (broadcasting, or synchronize event notification, CORBA event service models, etc.), the optimal ones to use are system dependent.

In this essay, the author writes about her random thoughts after reading Surendra’s proposal titled ‘Event Notification Protocol’ and the proposal ‘SIP For Presence’ by J. Rosenberg and H.Schulzrinne. Overall, the author looks at event notifications in two dimensions, horizontally or vertically. Horizontally is when people identify events from applications, and vertically is when events are classified into models. The pluses and minuses are discussed when some standardization happens starting from these two dimensions.

1. Perceive events horizontally or vertically

The event system can be perceived in two dimensions, horizontally and vertically. In communication protocols or application systems, when we provides the event notification service, define the protocol or system semantics that identifies different states for the event system, we say we are looking at events horizontally. The semantics defined for event notifications in this system might not be suitable to the other systems. In short , one or more particular event models are chosen and embedded into the systems.

Surendra’s paper, even though entitled to define an event notification protocol, is really an extension of HTTP, in where he adds extra tags as he adds his subscribe-advertise-notification event notification model in the HTTP protocol. Therefore, we can perceive his proposal as from horizontal perspective of event notifications.

On the other hand, when we classify event models across various applications, protocols or usage, we say we are thinking of events vertically. An event model, varying differently on presenting semantics, defines eventually one workflow on how to handle this event. Some common models of event notifications systems include synchronized, asynchronized, event service (e.g. CORBA event service), publish-register-notify, etc. Event notification protocols could be defined based on an event model and is not as part of any other system.

The author looks at SIP Presence protocol as a vertical definition of the subscribe-publish-notification model even though ‘SIP for Presence’ system is based on SIP. SIP Presence protocol has the extreme similar architecture as that of SIP, and is really a re-apply of SIP architecture rather than an extension of SIP. In another word, one can not really run the event model and the SIP concurrently. (The server function would be different.) Besides, while SIP is usually used at the session set up time, the presence protocol could be used all through at any time whenever there is an event change.

One irrelevant thought with this essay: since SIP has defined semantics and thus a concrete protocol. The concept behind really defines a model/models that can be applied at other places, including application systems, network protocols, or alone but in other areas (e.g. the presence protocol). The pluses and minuses of applying it to the other system or alone would be similar as we discuss the pluses and minuses for the horizontal and vertical event notification definitions. In all, SIP is not only a protocol, but could be a concept and a standard.

2. Cons and Pros

2.1 vertical

Ideally, the event service if to be standardized should support various communication methods (HTTP, SMTP, NNTP, etc) and if to be implemented should be across many applications. As a result, vertical approach seems rather appealing because of its definition as 'fit for all'.

However, the vertical approach is rather impossible when need to rub two protocols together (e.g. HTTP and an event notification protocol based on certain model) because both protocols should be on for the whole process. In this case, either we can embed the event notification model into HTTP protocol and extend the HTTP (the horizontal approach) or we can 'piggy-back the notification protocol on top of other standard protocols' (to be investigated).

If no other protocol is needed but the event notification protocol itself, we have no above problems. Indeed, various independent event notification protocols have been designed. For example, SIP Presence, Simple General Awareness Protocol (SGAP), Basic Lightweight Information Protocol (BLIP), etc.

These protocols are not an extension of HTTP or any other existing protocols, and have rather limited places of usage. Divide the event further, they are based on different event models and have their own semantics, and thus fit in even more limited area. Despite whether we should standardize each in its own particular area or come up one that fits in relatively more situations (more desirable), it is more important for the models behind the protocols (models + semantics) be studied and applied by application system when fit.

When talking about whether we could come up one that fits in more situations, it depends on how well we can rub several event notification models together. Ideally, we want to accommodate as much event models as possible. One advantage is that, we then have much more simplified client interface that decides which servers the clients should contact.

Another advantage of starting from vertical side is that since each model is well studied, and then well implemented, event states and other little details could be well considered and therefore event notification could handle errors more elegantly and the system be more immune to attacks.

On the other hand, in applying this fixed well-developed event notification system to a particular application system, extra overhead, unnecessary condition guard, and inability to combine some of the design elements could drag the application system's system performance.

2.2 Horizontal

Majority of the implementations or proposals starts horizontally. As event notification permeates every area, no surprise it is implemented in various systems and protocols.

Since events in horizontal system is not designed for across protocols or applications. The semantics is different and the implementation could be embedded into the whole program of that system instead of being modularized for re-use. As a result, it is costly to implement event system separately for different application systems.

On the other hand, the system implemented is more efficient. The semantics could be designed to best fit the system. The event models could be modified to achieve the best performance. For some systems that want to support several event models, it has fewer hassles to get several fixed event model systems to work together and all compatible with the firewall. Therefore, for well-established and most popular 'host' system, such as HTTP, adding the event system by extending that 'host' system is necessary.

2.3 some suggestions

Even though it is hard to say which is the ‘right’ way (whether we start from horizontally or vertically) to go with the internet event notification system, some suggestions from the author: 1. If it is a single system, o.k. to just apply models, and go vertically. 2. If it is a complicated system, better to go horizontally, and define the rules within that protocol or system.