Abstract: Event notification has been widely used in computer systems. Developing Internet Scalable event notification protocols or systems has been especially important and receiving more and more attention. In this paper, the author is going to

• Give an overall summarization on large-scale asynchronous event notification service.
• Summarize briefly on some chosen Internet Event Notification Systems, pointing out things particularly.
• Study some IMPP proposals. Compare them with some analysis.

Notice that this paper is not a survey of event notification systems. Adam Rifkin has done this work and surveyed over two hundred related papers [4]. (4 of his PowerPoint slide 1, 2, 3, 4 at WISEN covered some of his classification work [6]). Neither does this paper try to abstract the event models. The author’s other essay [3] has addressed it.
 

Computer event notification started ever since the invention of computers. Operating system, computer peripheral devices all create events. The event model starting from the request-and-respond model, broadcasting model, queued event model, to the current most complicated event service model that handle filtering, authentication, access control, security, and other advanced features. The event context stays not only within a single computer, or on a sparse local area network, but also across the wide area network, where tens of thousands of events happen every second. (According to the statistics given at WISEN [1] 1998. It estimated 20,000 events per second on the Internet.)

Loosely speaking, event notification or notification management technology permeates the area of distributed computing and exists in almost all distributed application systems. Adam Rifkin has provided a list of event systems he had surveyed and the list can be found at [2]. Currently event notification is specifically useful in many Internet related areas including mobile wireless contact, instant messaging, web authoring, buddy lists, workflow, network printing, etc., and has been considered fatal important because that its design could affect the whole network performance.

Despite of numerous event notification systems, there are only a few basic event models. (A summary on the event models by the author can be found at [3].) Currently, developing focus has been on the asynchronous even service with an intermediator. Intermediator acts as a manager that takes care of temporary storage of data, access and security control, scalability issues, filtering, QoS, etc. Push technology (notifying users when event state changes) is in replace of traditional polling. Thus the push-based subscribe-notify event service model has become dominant and has been taken for granted as default in many system designs.

In this paper, we will focus on the Internet Event Notification Services. Various group efforts have been seen on Event Notification Services in the past several years.

• In July 2000, we see proposals on Presence and Instant Messaging submitted to IMPP as responses to its RFP.
• In July 2000, CORBA published its extended event service specification based on its previous 1997 release.
• In July 2000, the Printing Working Group (PWG) has extended its Internet Printing Protocol (IPP) and submitted an Internet draft for IPP Event notification.
• In March 2000, OMG issued a RFP on Real-time Event Notification Service.
• In April 1999, IMB T.J. Watson Research Center held workshop on distributed publish/subscribe system.
• In July 1998, Workshop on Internet-Scale Event Notification (WISEN) presented existing event systems, discussed requirements at the UC Irvine.
• In May 1998, a Web-based workflow workshop met in Costa Mesa, CA to discuss using notification for initiating, controlling, and monitoring work processes, and this led to the development of SWAP.

D. Rosenblum and A. Wolf had given the following definitions at WISEN ([5]). An event is the effect of the termination of an invocation of an operation on some object of interest. Events occur regardless of whether or not they are observed. Event Notification is the process of delivering of events to interested parties. Service includes protocol and infrastructure. A sample event notification protocol may have a flow of advertise-subscribe-publish-notify-unsubscribe-unadvertise. Event notification infrastructure provides storage of advertisements, subscriptions, and efficient delivery of notifications.

Event notification at application level is usually multiple-sender, multiple-receiver system. Based on architecture design, (e.g. where does a subscriber or receiver connect to), the author divides the notification into two types. As shown in the picture below.

• Universal indirect model. The client is restricted to communicate only with its own server within the domain, and it is the server’s responsibility to contact other servers to exchange information that its clients have requested. Instant messaging systems with wireless mobile requirement would use the indirect model. Other systems including email, SIENA, OpenQueue, JEDI, etc.
• Universal direct model. A client can make a request to any servers on the Internet directly. Server can make a request to another server, but in this case, the server that makes a request becomes a client. HTTP based systems use the direct model. These systems include WebDav, GENA, RVP, SWAP, etc.

Multicast is taking one of the two models above. In multicast mode, one party connects with a particular server, either within or outside of its domain (based on system design). Then the server sends messages to all the other parties. Application systems could implement a particular multicast mode besides its already exists system. For example, OpenQueue, GENA all intended to provide a multicast mode in their existing design. Multicast can either be implemented at the application layer or at the lower layer (IP). Universal direct model, universal indirect model, mix of the two, or IP multicast could be used. News protocol is multicast based. TIBCO, a middleware providing publish/subscribe technology uses un-reliable multicast (standard) and reliable multicast (PGM).

For universal direct and indirect model, it really depends on the system itself to decide which one is better.

For example, for systems such as wireless mobile related, it makes a better design for clients to use universal indirect model. The client can not contact its home tower outside of what it can physically reach. It has to contact the tower that is close to itself. Instead of making an extra request with its home tower, the requesting tower became the tower within its domain and could make a request directly with the destination.

However, it is a better design for broadcast applications implemented at the application level. All the clients (within or outside of the domain connect with the same server.) We only need to maintain n (number of clients) communication channels instead of possible n! (If all clients are at different domain) that in the indirect model. Besides each client does not have to remember the address for other clients -- the server can do this.

General pros and cons for each topology.

In direct model, each server has to maintain user ids across domains, and each user has to remember his ids, which could be different on different servers.

In indirect model, even though the server only needs to know the users within its domain, the server to server communication has to be implemented, which could be complicated. If a domain has multiple servers and relaying operations is needed, protocols between servers within a domain and across domains should both be developed. For servers across domains, constructing a communicable interface among all different servers could be extremely painful. A common interface standard should be reached, and this standard is most likely application category (e.g. instant messaging) dependent.

Indirect model is less critical than the direct model in terms of availability. Severs in the direct model tend to become the single-failure-points for all clients. While in indirect model, it only affects limited users.

Indirect model requires running servers for domains of users. For each domain and a single application, one server should be set up, and it is usually not practically applicable to combine servers from several application services. Authentication methods and level of authentication are application dependent. Some application specific features also make combination of servers disagreeable.

Direct model is desirable for some individual service oriented application system. When the provider wants to have a tight control over who to receive his services, in an indirect system where each sub-system is operate by different parties, the provider eventually loses his control privileges. For example, the provider provides services like pay per view. When the picture is delivered from one sub-system (where services are) to another sub-system (where consumers are), the second sub-system delivers the view to that particular client, but it could also do something else. One way to get around is to design the indirect server to be content-careless. Otherwise, we need to strengthen the privacy at the application level by using encryption, etc. In both cases, indirect server becomes content-blindness, and content-based subscription and filtering schema will not work or will not work well.

Besides the pros and cons, while developing systems, we usually ended up not having much choice on the design.

There are several server topologies under the indirect model. SIENA has given a good summarization and the author is quoting and summarizing them as below. [12]

Hierarchical server topology is one-way tree-like structured. (e.g. JEDI). It is important to note that in this topology, a server does not distinguish between other servers and its clients, and thus it treats those servers as clients. Practically, it means that ‘parent’ server will be able to receive notifications, subscriptions, and advertisements from all its clients, but it will send only notifications to its clients. In acyclic topology, servers are allowed a bi-directional flow of subscriptions and advertisements as well as notifications. Generic is similar to acyclic except it allows any pattern of connections between servers instead of hierarchical.

SIENA also suggests two optimization strategies for saving communication and computation resources that can be pursued by applying these two algorithms:

• Applying filters and matching patterns upstream: this means to put filtering notifications and assembling patterns of notifications as close as possible to publishers.
• Replicating notifications downstream: this means to put multicasting notifications as close as possible to subscribers.

We focus our discussion on the client-server mode. The event notifications flow from the event publisher to the server and then from there to the event consumer.
 

Some designs of event notification systems do not need any storage. Once a persistent TCP connection is setup with the event consumer, the events are read from publishers, handled by the server, and delivered directly to the consumer. Real-time news broadcasting usually takes this model. (Some buffer is created for the flow control and QoS purposes, but is not for the purposes of storing the news that can be retrieved later.) Intermediate server acts as a dispatcher, maintaining the list of producers and consumers, knowing where to read from and write to. Also note that, event filtering itself does not require maintaining a storage space.

For a system that aims to provide more features, a storage space is usually needed. The space can store messages while the consumer is temporary off-line. If combinatory event notifications are handled, the notifications in the middle state need to be stored. With queue, it is also easy to provide many extra features like ‘send me events after certain time’, ‘return me maximally 5 notifications at a time’, etc.
 

Message grouping is important to decide whether the system is channel-based, subject-based, or content-based. In turn, it will decide the types of subscription and filtering.

CORBA based systems are usually channel-based. Event channel is set up for group of senders and receivers that have the same interest. In subject-based system, each message belongs to one or a fixed set of subjects. Publishers are responsible to label a subject, and consumers subscribe to messages by providing a particular subject. Subject-based design is simple to implement but it requires subject to be pre-defined. In content-based system, instead of giving a subject, the consumer issues a query against the content of the message published. Usually, subject-based design is mostly implemented comparing with content-based system. OpenQueue and Grypthon's initial design are all subject-based. However, content-based design is getting more and more attention because it does not require pre-define anything and is flexible to support any key word search. One disadvantage of the content-based system is that, the system can not be content-blindness. In another word, it is hard to be content-based if data is encrypted or server is designed not to care the content of the data (e.g. providing service to some particular clients)
 

Flow controls decides the data structure the server might use to manage related information.

Fan-in and fan-out factor indicates how many senders and recipients that a system allows. For multiple senders, event streams need to be merged. In usual design, messages are grouped based on recipients (otherwise sending notifications to a recipient would require a linear search through all the messages), and multiple recipients unavoidably require a single message or index to the message to be duplicated for each requesting client. Arrays, lists, storing of index or message itself needs to be decided therefore.

Ideally, a user should be able to define when, what, and how to receive notifications. ‘When’ is achieved by server maintaining a buffer and a timer. ‘What’ is achieve by notification classification and filtering. ‘How’ is dependent on system implementation. Some systems allow configuration being changed on the fly. (E.g. dynamic filtering)

Filtering could be set at the sender, the intermediator, or at the receiver. The CORBA event service does not define filtering and this usually leaves systems to implement filtering at the receiver side. This is bad in terms of wastage of network bandwidth and security reasons. Ideally, filter should be put at the sender side, and unwanted messages will not be sent out at all. However, it is not desirable for senders to know its recipients, and this very much complicates the event service architecture because the sender needs to maintain an updated list of receivers. Therefore, filtering in most systems is implemented at the intermediator. The drawback to set the filtering at the intermediate server is that this complicates the server while server is the single-failure-point. Therefore, it is important that filters should be kept as simple as possible. Sophisticated filtering that is less commonly used by most applications can be done at the application level rather than at the event system support level. Some Systems (e.g. CORBEA) are designed in the way to allow developers set filtering at any places, namely the sender, the intermediator, or the receiver.
 

There has been a great tendency to build event notification systems over HTTP and allow layering advanced capabilities such as delivery and event filtering above it (e.g. GENA framework and more). To some system, it works out just enough under this model, especially those that are request/reply based synchronous event notifications. Besides, HTTP is good for the firewall controls.

However HTTP has its drawbacks. Most obvious is that its limited request/response structure, and ‘Push technology' in HTTP has not been applicable. As an alternative, recipients have to either poll events from the server or the worst try to keep a long session with the server. Keeping a long session is O.K. but any approach will do a poor job to keep a long session under HTTP.

Also, since HTTP is using the direct topology, it is a less desirable design for some systems such as wireless-intentioned instant messaging.

Other drawbacks related to HTTP itself includes it has too much overhead; some features are not quite suitable for notification, e.g. caching.

TCP and UDP are two base protocols we use for communication. TCP is reliable but over-headed, UDP is light-weighted but un-reliable. Usually, TCP has been most commonly chosen because it is reliable and the system would be simple to implement. For system that uses multi-cast or providing multi-cast mode, (GENA, TIBCO), UDP is used. (Also read reliable Multicast RFC 2357 [47]).

There could be several connections set up at the same time between one client and the server. In PePP, if a message size is very big and exceeding some predefined maximum limit, a separate TCP channel is set up to pass the long message. This is a good design not to block the control message. Similar idea includes prioritize the methods and use several TCP connections to pass the prioritized category of message. For communications between servers in the indirect topology, several communication channels could also be set up at the same time. (AOL IMX instant messaging) This is simple and desirable for multithreaded or multi-processed server implementation. Of course, one single communication channel can also be used.

Flow direction in TCP is mostly asynchronize bi-directional. This means clients can send property requests without receiving any acknowledgement from the server. However, a sequence number or a tag might be assigned so that the clients understand what request (or what event) the server has handled. (IPP, PePP) This is especially important for the client to receive confirmation for a request that updates event management property on the server. Synchronous mode might also be used in some cases. For example, if an event consumer wants only to get maximum five messages at a time, the server will wait until it was requested for the another five messages. (OpenQueue)

It is really up to the system whether a persistent TCP channel should be used. For communication between servers, TCP connection is usually created on demand and semi-persistent. (As long as there is data passing between each other, the connection is kept open.) This is fairly reasonable especially for sparse message communications between the servers. For connection between client and server, there are some guidelines in choosing what to use.

Using persistent connection is much simpler to implement. Event though initiating TCP channel is slow, once the connection is set up and authenticated, no extra connecting is required. This is especially good for a client that sends out notifications frequently. Fewer transition states are needed in the system implementation, and the intermediator usually does not need to maintain storage (queue) for the recipients.

Using persistent TCP connection does not require server to know the return IP address for the client, and the server does not need to connect to the client but can still send client requests. This is desirable when client's IP address is not available.

However, persistent TCP connection is less scalable than using UDP. UDP does not require persistent connection, and this allows a server to serve a much larger number of clients, especially clients who do not receive messages very often. However, since the current UNIX server can usually maintain 10,000 socket (or more) connections concurrently, this seems not a too big problem.

TCP is not desirable to be used in application level multicasting. In a smaller system that has 3 or 4 nodes, it is o.k. But the number of connections grows close to exponentially as the number of node increases. If an event notification intends to provide multicast mode, UDP is usually used.

The last interesting question to ask is whether disconnecting or the client program quitting means the client is no longer interested in receiving events? In implementation, it is asking whether we want to have extra client status such as LOGIN and LOGOUT? (Other key words might be used, e.g. ‘TERMINATE-NOTIFY’, or some system uses SUBSCRIBE to actually mean LOGIN.) All is depend on system implementation. Generally, if the server can queue the message, it is more flexible for the client to request receiving events even if it is temporary off-line. Separating LOGIN and SUBSCRIBE states offers clients more flexibility. Despite of introducing extra states, it is very attractive to treat TCP disconnection and client's logging off differently.
 

QoS is part of the notification management. It answers questions like what service I can get. Can I get only what I have requested for? Can I post notification anonymously? However, it mainly focuses on features including notification of lost notification, report of subscriber information, reliable vs fast message delivery, priority-based delivery for particular groups of clients or for particular types of notifications, etc. QoS affects the design and implementation of the system, and QoS is implemented with costs.

As notification on event notification has become more popular to be one part of the system, it is usually treated as the regular event notifications except the server is responsible in monitoring and generating these notifications. Depending on design, systems might provide features like notification of lost notification as an alternative to queue and delivery of events reliably.

Reliability is achieved by keeping server reliable and developing protocol that keep server and client consistent. To keep server reliable is comparatively more critical in indirect topology. We are not going to address the question as how to maintain a daemon server reliable, because it is a very common question for servers in any system. In the protocol design, if TCP is used, and if the sending party received a confirmation (assume secure), reliability is achieved. Some system might have extra requirement. For example, in the OpenQueue system, it provides a feature to send message in smaller batches. To assure the receiving party received those messages once and only once, a two-phrase commit protocol is used to guarantee the integrity. If a protocol is designed above UDP, retrying is needed to guarantee notification being delivered.

Priority-based delivery among clients usually depends on clients’ priority class and access rights, which is part of the user management. Priority-based delivery for particular groups of notification depends on access rules and client’s willingness to prioritize the messages. This needs extra requirements on the expressiveness of the communication formats and classification of the messages.
 

After packaged into bit streams, events and messages can be delivered using many protocols, including those designed for emails, instant messaging, net news, file transfers, etc. For example, IPP could use emails to notify user of happening of a certain event. Physically, the bit streams could be sent through Internet, direct line, air, or even satellites.

Machine-readable binary format notification could be more efficient, but text-based human readable notification formats is preferred because of its readability, extensibility, and ease of debugging.

For human readable data format, there has been some preference using XML over simple text format. XML allows for painless growth and expansion of basic data types and almost infinite customization and extensibility anywhere within the data. It is flexible, and can be passed among different systems (consider the intermediator also uses the database systems that has an interface to handle XML. XML could simply be passed to these systems without creating a new interface.) However, there has also argument against using XML. For notification, do we need such a powerful expressive language of language in exchange with extra cost of parsing and interpretation? All we need are some key/value pairs, possibly grouped, to specify the action and some parameters. Does nested structure really that important? Not really. Consider the mobile situation where bandwidth is a concern. Why bother transferring large chunk of blocks that doesn’t express more than simple text format? Besides, simple text format is more readable. Despite of all the cons arguments, XML was chosen to use in many notification systems regardless.

There are two types of system information, notification management related, and notification message. Management information format could be standardized and indeed should be standardized in direct topology. For notification message, the intermediator could be implemented to understand the content (content-based filtering). It could also be content-blindness and leave the event publisher and consumer themselves to understand its own content. For example, OpenQueue provides storage to store the data, but it never cares what format and what content it is storing. This leaves the publisher to decide the form and meaning of the messages, which is commonly shared among its recipients and could be different every time or for each group. For content-sensitive system (pay per service), content-blindness is preferred. In some system, two types of system information could be leveraged together. For example, if the length of the client data is short, notification message can simply be an attribute defined in the management information. (IPP)

Expressive definition of data format is usually hard to compare and compute. Not many systems have really addressed the expressiveness and computability. TAO, CORBEA and some others have used some simple expression using ‘AND’, ‘OR’ operators, SIENA is the system that had defined the compatibility relations so that notifications and subscriptions can be compared according to some calculus algebra like semantics.
 

Security includes a wide range of topics including delivering notification to the right user, privacy of content, protecting from spam, spoofing, or other evil purpose attacks. Security is an issue with any systems and there is nothing particular with notification system. Also IMPP [15], IPP [32], SWAP [37] security requirements all have addressed it. We briefly restate it here in one sentence. Generally, it is achieved by assigning identifications to users, authenticating users log in, encrypting sensitive data, maintaining system access control list, and recovering systems from mischievous attacks.

Whether allowing anonymous user to log in is usually up to the system implementation. Access control is also quite system dependent. Web-server-like access control is most often used. No theory or algorithm particular has been proposed so far.

Scalability is also non-event-notification specific and we are not addressing it here. Overall, it can be defined by metrics such as number of objects of interests, number of observers, data storage and queuing, number/frequecy/distance of events or notifications, etc. No system is infinitely scalable, but how many order of magnitude do we require a system to scale? Not many parameters we can give in order to define these. Usually, scalability is defined by number of users that can concurrently login.

In future, there could be many 'abuses' of event notification. For example, the ‘killer applications’ (news/weather/traffic report, Internet gaming, etc.) Even though TCP has been designed to avoid Internet from crashing, other prevention or control should also be developed.

IPP is a group effort from the PWG (The Printer Working Group at http://www.pwg.org/ipp/index.html). Its focus is 'to develop requirements and describe a model and semantics for Internet printing, and ultimately define a new application level Internet Printing Protocol'. Its recent event notification specification draft (July 2000) [32] extended IPP/1.0, IPP/1.1 and allowed a client to subscribe to printing related events.

The event service model is defined as the following. A client (PDA, desktop, or server) subscribes to the printer object (output device or server) for a notification and provides the list of notification recipient (might not include the client itself). When one of the specified events occurs, the printer object sends an asynchronous event notification to the recipient via some pre-specified delivery method. Similar models with some difference apply for cascade printer model (a printer object sits between the client and the destined printer object) and the distributed model (a notification service sits in between the printer object and the notification recipient.)

In all, the model is a simple asynchronous type of event service with an intermediator. Since IPP is used within relatively small area (printers on local network), the types of events or event status are easy to be defined in advance. We are usually not expecting tens of thousands printers on the network. Therefore its subscription object is defined to have template attributes for simplicity, and normally, it is not that critical for print server to communicate with other printing servers.

The biggest security concern is the abuse of notification. It would be ideal that all recipients agree on receiving notification first, but there is no requirement for IPP printing object to validate the identity of event recipients, and therefore no guarantee that recipients want to receive what they might be receiving.

Authentication of subscribing clients may be required, and is achieved by storing in one attribute of the subscription object something secrete to the client, and the implementation is system specific (e.g. system could use HTTP authentication). Privacy is also system specific, and can use HTTP/TLS privacy. Access control is achieved by the pre-given list of recipients from the notification issuer.

Workflow is useful in capturing business processes, and is in a growing acceptance by various application domains including software engineering, finance and banking, manufacturing and production, etc. SWAP is a group effort from Workflow Management Coalition (WMC at http://www.wfmc.org) to use notifications for controlling and monitoring work processes. (Creating work, starting work, being informed of exceptions, being informed the progress of the work, getting a history of execution of the work, etc). SWAP implements somewhat less obvious notification usage that to use machine-generated event notification to help human management. Obviously it would be hard to satisfy every possible type of notification need that a human wants under various work environment. It is a good idea however to integrate event notifications with the version control.

SWAP uses subscribe-notify model with an intermediator. It is based on HTTP with some new methods defined. XML is used for notification format. Transport level security is achieved through the secure mechanism available in HTTP, including HTTP authentication, SSL, etc. Application level security could be strengthened by establishment of user roles that are associated with privileges, and the use of security profiles that specify when and what security measures to be deployed, etc.

In addition to its methods for notification (SUBSCRIBE/UNSUBSCRIBE, etc), SWAP has a complete list of property management methods, as all of other HTTP based systems, including GENA, WebDave, etc. PROPFIND returns all the values of attributes of the resource. PROPPATCH sets any number of attributes of a resource simultaneously. In addition, COMPLETE, TERMINATE controls the execution of the process. Other methods include GETHISTORY, CREATEPROCESSINSTANCE, etc.

OpenQueue (supercedes the previous BLIP) is a protocol being developed as an open standard in publish-and-subscribe message queuing. (http://openqueue.sourceforge.net/) Since its core is a topic classified, content-careless queue, it can be used by different applications including news, buddy lists, monitoring, persistent chat, stock trading (personal program trading), auctions, etc. Comparing with majority of the other event notification systems, Open Queue has many of it special designs.

Overall, the event model is a simple asynchronous type of event service with a queue (server) as an intermediator. The server does not care about the contents of the message other than the topic. It is up to the clients to decide the form and meaning of the message it uses. Thus any type of MIME-based data can be passed among clients. Since each message is identified by topic, the server is able to do topic-based filtering for both publisher and receiver. OpenQueue uses URI like name addressing.

In OpenQueue, when client program logs off, it does not mean that the user is no longer interested in receiving messages. OpenQueue will store these messages until the client returns. In this case, the persistent TCP connection is not enough, extra states are needed indicating whether the user is interested in receiving notification or not. In addition, OpenQueue provides a mode called AWARE (still in 'investigation'). In this mode, the server knows the client IP address and is able to connect to the client directly. In future, OpenQueue plans to develop reliable Multicast mode based on RFC2357.

Transaction integrity is achieved using two-phase commit process. Integrity ensures that each message is sent once and only once. Batch message transferring is available, which means that the server needs to receive an 'ack' in order to send more batches. Existing messages are sent right away even when the batch maximum size is not reached.

Since OpenQueue focuses on notification and MIME-based message storage and delivery, it does not address issues like updating user access rights, queue management (prioritize, etc). Also, since it is still in the development, security, scalability issues are still need to be taking care of. Currently, the password is sent in plain text.

The former BLIP software was implemented in Java with send/receive scripts written in Perl. Clients were to run on Window95.
 

GENA Framework from Microsoft aims to build large Internet scale, lightweight subscription, high performance, generalized event notification that fits into HTTP extension framework. Its architecture graph can be found here [6].

Notice that it is really an integration of WebDav (notification management), RVP (instant messaging), XML, and HTTP with some of its own functional layers (the part that is similar to OpenQueue). UDP is also used but mainly for its AWARE method (similar to OpenQueue AWARE). Firewall management is eased because of using HTTP.

In all, the framework seems trying to rub functionality together from several current available systems under a single framework. Details however are not quite addressed but can be implied from its separate component.
 

CORBEA was developed at the University of Cambridge Computer Laboratory in the United Kingdom by Chaoying Ma and Jean Bacon (and their team). CORBEA is active (push) event driven systems in a large distributed environment, where there is potential for high volumes of even traffic. The design is based on a conventional RPC system and the implementation is using MS-RPC3, a locally developed RPC system with limited interoperability. However the framework is object-oriented. CORBEA extends the CORBA Event Service, namely by supporting the publish-register-notify mode, parameterized filtering, fault-tolerance, access control, and composite events. It also supports dynamic addition of user-defined event types, support role-based event accesses, QoS (reliable or fast, priority-based delivery).

Access control is carried out at registering time. Filtering by parameters (e.g. wildcard parameters) and by event types can be placed at an event server, a supplier, and a consumer, or can be chained among them, whichever allowing less event traffic and greater flexibility. Composite event is followed by well-defined syntax to allow standard parsing by a composite event server. A composite event algebra has also been developed that supports five operators: Without, Sequence, And, Or, and Whenever.

Funded by Boeing, NSF, and DARPA, TAO is developed by Professor Douglas C. Schmidt and his research group originally at the University of Washington. The main propose of developing TAO is to provide a high-quality, free available, open-source CORBA-compliant middleware platform that can be used effectively by both researchers and developers.

TAO is an object-oriented push-driven implementation of CORBA Event Service that is designed to meet real-time requirements, including low latency, predictability, event filtering, priority, and event correlation.

Generally, Object Oriented concept does not fit in real time system very well. TAO however provides object-oriented event dispatching and scheduling mechanisms that provide real-time guarantees. This guarantee is achieved by allowing consumers and suppliers to specify their execution requirements and characteristics using QoS Parameters (worst-case execution time, etc), which then decided by channel’s dispatching mechanism to integrate with system-wide real-time scheduling policy to determine event dispatch ordering and preemption strategies. Notice that the CORBA event service itself has no notion of QoS to specify the execution and scheduling requirements.

TAO’s event architecture is a simple CORBA event service model, where events are pushed from suppliers to the event channel and from the event channel to the consumers. The implementation focus is on the development event channels, in where event flow goes through the following layers: supplier proxies (including priority timers), subscription filtering, event correlation, dispatching module, and consumer proxies.

Consumer and supplier proxies provide interface for event provider and consumers subscribe with the event channel. Instead of broadcasting all events from suppliers to all consumers, TAO Event Channel allows consumers to subscribe for particular subsets of events through a well-defined semantics that includes fields like source ID, type, data, timestamp, etc. The channel uses these subscriptions to filter supplier events and only forward the events to interested consumers. Event correlation (composite event) is achieved using ‘AND’ and ‘OR’. Dispatching module uses a system-wide scheduling service to help determining when events should be delivered to consumers.
 

SIENA is the on-going project headed by professor David S. Rosenblum at the University of California, Irvine. SIENA aims to provide an architecture implementation for a Wide Area scalable general-purpose event service. Therefore, it takes advertise-subscription-notification event service model within a domain as a default and mainly focus on connecting event servers to achieve high level of scalability. The contributions of the work also include a formal definition of an event service that combines expressiveness with its scalability requirement.

SIENA event service uses the most common URI schemas, including mailto and http, and thus implements the communication protocols implied by each schema.

Filters define a class of event notification by specifying a set of attribute names and types and some constraints on their values. E.g. ‘float change < 0’ for float comparison whether change is smaller than 0. Composite event filter is achieved by using a pattern (a set of event filters using filter combinatory). The concept of compatibility is used between notifications and subscriptions, and between subscriptions and advertisements. The compatibility decides whether or not notifications published match any subscriptions, and thus is important in the role of filtering.

Server topologies, namely hierarchical, acyclic peer-to-peer, generic peer-to-peer, are discussed but not limited to use in SIENA. SIENA uses content-based subscription.
 

Initiated in 1997, Gryphon is the on-going project at the IBM T.J. Watson Research Center. (http://www.research.ibm.com/gryphon/) The goal of this project is to ‘design and implement an advanced content-based publish/subscribe system. The system will address the needs of current and future message brokering applications while being usable and highly scalable’.

The basic model is a typical publish/subscribe model, and the current system is content-based (initial one is subject based) using the fast, scalable routing algorithms that Gryphon had invented. Clients access the system through implementation of the Java Message Service (JMS) API. Event processing in Gryphon is described via an information flow graph. (An information flow graph is a directed acyclic graph constituting an abstraction of the flow of events in the system.) Gryphon has given special attention to the availability feature of the system. The system responds to failure of one broker in a network by rerouting traffic around the failed broker. Reconfiguration is automatic.

The current system is written in pure Java with optional native libraries for performance-critical sections. In particular, the system support non-blocking I/O socket libraries for Windows NT, Linux, and AIX.
 

We have briefly taken a look at some of the most popular event notification systems in exist. Each system is different in context, usage, and communication means. However, in terms of models, concept, they are of little difference. So far, even though each system has something particular but is not outstanding.

There are certainly lots of others built upon the same concept but with a little variation and fit into different context. Among these, Event Notification Protocol (ENP) builds upon HTTP and describe events using PL*SQL and XML (XQL). Java Event-based Distributed Infrastructure (JEDI) is built upon JAVA and RMI and had aimed to support development of business services. Wide-area event notification using satellite broadcast is also getting attention, especially in the usage of pager.

Event notification is certainly not a new topic. Many well-established protocols and systems are event-notification based, including SNMP, PSTN, Email, distributed games, etc. The publish-subscribe model is not something novel and has been taken as a default for building things upon. Several years back, if it was a culture that researchers built up various middleware type event-notification systems, they are more focus on a particular area (e.g. merging the event, study of content-based filtering) of the model in recent couple of years.

Two years back in 1998 at WISEN, we saw various event notification systems. Last year at IBM workshop on distributed subscribe/notification, we saw various approaches on particular topics. There have been several good papers from Cornell University on matching events in a content-based subscription system, merging streams from producers for atomic broadcasting system. In Michigan University, some researchers are studying secure content-based information dissemination. In Georgia Tech, people are building concept of Generalized Role-Based Access Control (GRBAC, 'a new role-based access control paradigm that allows environmental context and information content to be tightly integrated into access control decisions.')

In this section, the author is going to summarize the list of protocols submitted to the IMPP in July 2000. Since the IMPP working group had provided in advance a well-defined general frame with extensive discussions of pros-and-cons on candidate approaches regarding topics including naming, transport protocol, authentication, security, access control, message data format, etc. [15, 16, 17, 18, 19, 20]. Therefore instead of repeating them here, the author is going to briefly summarize each protocol, compare, contrast, and do some analysis with these proposals with her own thought.
 

IMPP gives the following definition. ‘Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users.’
 

Despite of how each sub-system instant messaging protocol is define, IMX has taken the design of clients-server-server-client topology as a base and concentrates on interoperability among servers across domains. However, in addition to providing some guidelines and consideration, communication detail is not much addressed.

The proposal mainly aims to achieve scalability requirement defined in [20] by allowing one server under one domain communicate with other servers under some other domains to exchange presence, messages, or other information. This design is mainly against an alternative that clients in one domain connect directly with the server under another domain (e.g. RVP does this).

Naturally, this design keeps each system of a particular domain separate and allows different incompatible systems co-exist without re-architecting each. Thus, it has backward compatibility and relatively easy to strengthen security, authentication, access control, etc. across domains.

RVP has been existing for several years, and is a GENA-based (Generalized Event Notification Architecture over HTTP) protocol for Instant Messaging. [6]

Consider itself as a strict extension of HTTP/1.1, RVP inherits some HTTP features including authentication, etc. based on HTTP, RVP has to remember status for subscribed users and has to support notification sinks. Like any protocols building on HTTP, disadvantages of using HTTP do apply, which includes heavy overhead and unwanted features like caching. RVP follows HTTP's request and reply model and allows notifications be generated and forwarded to other RVP nodes (notification sink). However, since the sink is at the server, and HTTP doesn’t go from SERVER to CLIENT, the notification is limited to server-to-server. Clients have to make a request across the network to retrieve the information from the server. Poll is needed if notification needs to be received promptly by the client.
 

Following the guidelines MIPP has provided, Greg builds up PITP and IMTP from scratch. Great effort has devoted to define URL and protocol message syntax as well as PITP and IMTP command sets based on MIPP requirements. The syntax and command sets have implied the list of operations and algorithms the server and clients need to have and the system should not be too complicated to implement.

The protocol architecture is client-server-server-client with concerns that the servers within the same domain could also communicate with each other. The difference with AOL IMX is that it requires each sub-system uses the same protocol as defined while IMX allows each sub-system to have their own which could be differently.
 

This is another client-server-server-client topology with servers communicating with one another. Follow the IMPP Privacy requirement for polite blocking, PePP uses the section based access control that allow a WATCHER to view sections of an PI message based on each section's access control list. It uses a persistent TCP connection to indicate client's interest to receive message. PePP message uses HTTP similar syntax but defines its own set of header tags, and allows request messages being sent bi-directionally. PePP has given particular attention to information privacy, including confidentiality of presence information, content encoding, etc.

Fujitsu people certainly have put great effort putting this proposal into a piece with such great detail. For example, definition of lease model for presence information, different modes of subscription, connection and backup connections, a comprehensive list of command set, ACL and message format, etc. However, it feels like X.500 Versus LDAP. Also some of its commands can be combined further. For example, since it has LOGIN/LOGOUT already, and it has NOTIFY and other methods tags to change the subscription, there is no need to define extra methods like 'SUBSCRIBE' and 'UNSUBSCRIBE'.

IMXP presence service is built upon IMXP, 'a well-intentioned effort of building a core messaging service that is across domains.' In this proposal, the message format is using XML and arbitrary MIME content with self-defined error code. Endpoints naming is using email alike address (e.g. im:local@doman). Despite of author’s line by line reading, the data flow of presence architecture is not clear. For example, two de-coupled objects, application and presence service, at the time of updating presence information both contact the relay (?), but how do they know to act together? After gaining a vague picture of its overall design, security, scalability, and authentication, the author decides to skip this one.

Based on his chat room implementation, Alexander releases his design of presence based on his understanding of the topic. This proposal is a little bit like implementing a management control for a teleconferencing. Many of his points we can shoot with (security issues, persistent TCP connection, etc.) and some of his opinions are in total conflicts with the MIPP requirements. (we skip this one)
 

Jabber is an open source project with a primary use to give existing applications instant connectivity through messaging and presence features, provide contact list capabilities, etc. It has been under two years' full-time development and has reached some substantial milestones.

One of Jabber’s goals is to ease the construction of compatible IM clients so that clients are kept separate but able to deal with various IM networks. Similar to AOL IMX effort, Jabber tries to connect with other IM network by developing special-purpose transport layer between them. Despite of how many developing resources available (since it is an open source project), building interfaces between pairs of different IM networks are tedious. Should a standardized interface be used instead of customized?

Clients and server communicates via TCP connections. Persistent TCP socket connection is required after authentication. Security can thus be achieved by SSL and application level message encrypting. Traffic on the TCP connection is bi-directional, but only Client can issue a TCP connecting request to the Server.

XML is used to define basic data types. Users are defined by email-alike syntax, and URI is also used to identify resources. Sever is assigned an ID but not quite see how it is used.
 

This is another client-server-server-client approach with Intra-domain clustering. In addition, to enable co-existence of different services (for example, Presence services, wireless devices, etc), GATEWAYS are set up to translate among protocols. Good approach.

TCP is used in client-server, and server-server connections. Persistent TCP connection is required for client-server, and need-based connection is used for server-server. To make sure an operation is carried out, synchronous model is used. Two level of connections are defined, transport layer and operation layer. Information sharing is defined in the PRESENTITY's Privacy Control List.

Email address format is used for principal identifiers. XML is used for data representation.
 
 

Among the Eight approaches we have examined and six to discuss about, there are two topologies, indirect and direct (see section 3).

In direct topology (RVP), each presentity connects directly with the presence service, even when that presence service is at another domain (network). There is no need for the communication among the presence servers, at least not for the presence server to be as a representative of a client that is under its domain.

For indirect topology (all proposals other than RVP), a client only communicates with its home servers, and only a server can communicate with another server within or across domains.

The indirect topology divides the whole network into sub-networks. Unlike the direct approach, it does not require the presentity client to have access to all the other domains. This is a natural topology in mobile and wireless environment, where mobile clients might not be able to contact its base tower but the nearest tower because of it current geographic position. Since protocol that is suitable for mobile wireless is a shared requirement defined by IMPP Working Group, the indirect topology becomes 'superior'.

Several details to consider for indirect topology.

How do we glue sub-systems together? We do not really care about how each sub-system is implemented but the interface that connects them together. (Note that asking every sub-system to be the same is not reasonable.) Also, as a good software engineering strategy, we should not to implement a unique interface for each pair of sub-systems. Instead, we define a unique interface requirement and each sub-system should be responsible to build up an interface that is compatible with the requirement. Only when this interface is built up can a sub-system be able to communicate with the other sub-systems, and therefore be said a ‘complete’ system.

As a result, defining the unique interface is very important. In order to do so, the core set of operations/methods for one sub-system has to be defined. Realize that the core does not mean to be minimum. As long as the interface of the sub-system can resolve the larger set, there is no need to push each sub-system itself to be able to handle that larger set.

GATEWAY is needed to connect IM system (including many IM networks) to other types of service (e.g. other types of presence service), which is most likely running different protocol. Unlike our IM system server interface, GATEWAY should not aim at unique for all types of services. For two different services, we can build a GATEWAY particular to these two types.

There might be a need for either intra-domain clustering, re-direct under the same domain, or a special server-to-server communication within the domain. On one hand, this could be addressed by hardware approach, on the other, we could provide software level dispatching. However, we are not to discuss it here.

To summarize, we have just reached an architecture very similar to those proposed by Network Projects, Greg’s, and Jabber. Network Projects has not mentioned the unique interface among all sub-systems except saying they need to connect. Jabber does not have GATEWAY among different systems, and it glues the sub-system by a transport layer, which translating between the Jabber XML protocol and the protocol used on another IM network. There might be many different transport layer implementations based on the pair of the sub-systems connecting. PePP, Greg’s proposal, and IMX all proposed for the indirect architecture and only IMX has been focused on the interoperability. However, except listing out some ideal features, requirements, concerns, only general guidelines are provided. Also note in IMX, its Gateway that is used to relay information between server of the same service is really the server interface we are talking about here.

It is a pity that we do not see any proposal for server to server protocol. (IMX only provided some guidelines). Under the topology of client-server-server-client, each individual IM system could encapsulate itself as long as they have an interface and a sub set of attributes they can communicate with. In all, each IM could be a black box to the other IM system, and therefore to define a communicatable interface becomes most important, but is not addressed by any proposal.

The author believes that there is no need to define client-server standardization but server-server interface. One is that there are already many instant messaging systems, and it is not wise and not necessary to re-built them to force it be standardized. Secondly, all it matters is really the interface. Therefore, why do we force each IM system to be the same? Why not keep it as a black box that is convenient for the builders, hard for the intruders, and full-featured for the users (otherwise, poor IM systems loose users)?

Despite of the author's belief, in the following section, we are to summarize the proposals because we have put effort into looking at each of them.
 

All the proposals have chosen TCP as the primary base protocol. For Jabber, server to server communications can use any protocol or communication means available. Related issues (for IM) are summarized in the table as below.
 
   

As we can see, for connection between client and server, client always initializes the connection, and the connection has to be persistent. Otherwise, the server has to initialize the connection in order to push the notification, and thus the server has to maintain the client’s IP address, which conflicts with IMPP’s requirements. As a result, the client needs to initialize and maintain a long-lived connection with the server until it does not want to receive any notifications. From the server, a disconnecting from the client does not mean the client wants no more notification. If the client is not specifically specify its login out, the server will queue the message for the client.

RVP is based on HTTP and does not have direct control over TCP. Since HTTP is request/respond pair based and the server can not initialize a push to the client. Unavoidably, RVP entity has to use poll to simulate server notifies client. All proposals have provided their own high-level transport protocol, and we summarize the method as below.
 

Basically, there are at least two sets of methods. One is related to notification, and one is related to property information. In addition, some other management related methods can be added, such as LOGIN, LOGOUT, PING, etc. Details including whether the request should be followed by a respond, how property is managed, what error code to return, and how to update it by presentity are not addressed in the papers but rather left with each system implementation.

Following MIPP’s requirement that ‘PRESENCE INFORMATION MUST be formatted in a reasonable subset of XML’ (4.2.3 in presence information data format for IMPP), majority of the proposals are using XML like syntax for protocol and message. Greg has defined his own non-XML protocol syntax, and IMX did not address this detail.
 
 

Three pieces of information we really need in addressing, the protocol, a unique id under a domain, and the domain. Any format that minimally and maximally contains these three elements would be desirable. For example, format like im:joe@domain.com seems desirable. '@' is preferred by many people than '//'. If one character can be used, why bother using two characters (‘//’). Besides, ‘//’ format is misleading -- the address is like a physical or virtual directory path instead of an id.

Since instance message is just one type of presence, and most likely these two can not really be merged. Appending the protocol type is important especially later at the gateway when we need to exchange information between two protocols. Using ‘pepp’ or ‘jabber’ as protocol name is too personalized and hard to distinguish which protocol it refers to. Person’s full names could be used as an id in the display but not in the addressing to guarantee the uniqueness within a domain.

Using the path like ‘im://im.example.com/instmsg/aliases/joe’ is not good. If it (‘instmsg/aliases/<user_id’) is an absolute path, it could be different on each site, and would be hard to remember. If the path is a fixed format like ‘<domain/instmsg/aliases/<user_id’, where there is no need to put ‘instmsg/aliases/’ in the middle. Notice that RVP is using this format only because it is using ‘http://’ and has to have at least something (‘instmsg/aliases/’, even though more than necessary) in the middle to distinguish that this is for instant messaging.
 
 

For majority of the designs, since at least one persistent TCP connection is used, Clients are protected from direct attack or identified by the third party.

Authentication is done at each connecting time.

Supporting anonymous is usually not defined and rather leaves to system implantation.

Error handling is also system dependent and share some common set of error situations, including ‘domain unknown’, ‘destination unreachable’, ‘presentity unknown’, ‘permission denied’, etc.

Handling of ‘out of control’ is not quite addressed. In Network Project, the system treats the client as ‘out of control’ when it sends command that needs an 'ack’ but does not receive it within pre-configured time.

Privacy is provided by defining the access control list to control who can read the messages. Bcc issues are not addressed by the proposals.
 
 

1. Scalability Factors PowerPoint presentation, Alexander Wolf, John Mathon, WISEN, 1998. (http://www.ics.uci.edu/IRUS/twist/wisen98/presentations/Summary-Scale/)
2. adam list of event systems. (http://www.cs.caltech.edu/~adam/isen/event-systems.html)
3. Summary of CORBA Event Services by Fang Cheng( http://www.columbia.edu/~fc144/summer/essay1.html )
4. adam list of event papers (http://www.cs.caltech.edu/~adam/isen/event-papers.html)
5. David S. Rosenblum, Alexander L. Wolf, WISEN 1998 ‘Internet Scale Event Notification’ powerpoint. (http://www.ics.uci.edu/IRUS/twist/wisen98/presentations/Rosenblum/)
6. Adam Rifkin, Rohit Khare The evolution of Internet Scale Event Notification Services PowerPoint, WISEN, 1998. (http://www.ics.uci.edu/IRUS/twist/wisen98/presentations/Rifkin/)
7. DHCP (RFC2131)
8. SMTP (RFC821)
9. http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-04.txt
10. Simple Workflow Access Protocol (SWAP) by Keith Swenson, WISEN, 1998. (http://www.ics.uci.edu/IRUS/twist/wisen98/presentations/Swenson/)
11. Matt Jensen BLIP slides, WISEN, 1998. (http://www.ics.uci.edu/IRUS/twist/wisen98/presentations/Jensen/)
12. SIENA: Wide-Area Event Notification Service. Antonio Carzaniga, David S. Rosenblum, Alexander L. Wolf, WISEN, 1998 (http://www.ics.uci.edu/IRUS/twist/wisen98/presentations/Carzaniga/)
13. Gryphon Site (http://www.research.ibm.com/gryphon/workshop, http://www.research.ibm.com/gryphon/)
14. Adam’s Internet draft (expires 1999/02) titled Scenarios for an Internet-Scale Event Notification Service(ENS). (http://www.cs.caltech.edu/~adam/isen/draft-khare-notify-scenarios-01.txt)
15. Security Framework for Instant Messaging and Presence Protocol
16. Message Information Data Format
17. Transport Protocol for Presence Information/ Instant Messaging
18. Presence Information Data Format for IMPP
19. A Model for Presence and Instant Messaging (RFC 2778)
20. Instant Messaging / Presence Protocol Requirements (RFC 2779)
21. The IMXP (draft-mrose-imxp-core-00.txt)
22. Privacy enhanced Presence Protocol (PePP) (draft-sugano-impp-proposal-pepp-00.txt)  
23. Instant Message and Presence Transfer Protocols (draft-hudson-impp-transfer-proposal-01.txt)
24. RSVP-PP: Real-Time Messaging Transport Protocol v130 (draft-fanti-impp-rsvp-pp-2.txt)
25. The IMX Architecture -- Interoperability with America Online's Instant (draft-aol-imx-00.txt)
26. Jabber (draft-miller-impp-jabber-00.txt)
27. OneIM: An Architecture and Protocol for Presence and Instant Messaging (draft-networkprojects-impp-proposal-01.txt)
28. RVP: A Presence adn Instant Messaing Protocol (draft-osbone-rvp-01.txt)
29. Strawman Protocol (draft-stracke-impp-straw-protocol-00.txt)
30. Simple Instant Messaging and Presence 1.1 Protocol (draft-ramsdell-simp-protocol-01.txt)
31. Internet Printing Protocol (IPP): IPP Event Notification (http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-04.txt)
32. Internet Printing Protocol: Requirements for IPP Notifications (http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-04.txt)
33. IPP web site (http://www.pwg.org/ipp/index.html)
34. SWAP Working Group (http://www.ics.uci.edu/~ietfswap/)
35. Requirements for Simple Workflow Access Protocol (http://www.ics.uci.edu/~ietfswap/swapreq.txt)
36. Simple Workflow Access Protocol (http://www.ics.uci.edu/~ietfswap/swap-prot.txt)
37. Workflow Security Consideration -- White Paper (http://www.aiim.org/wfmc/standards/docs/secure1.pdf)
38. Workflow Management Coalition Site (http://www.wfmc.org)
39. OpenQueue Site (http://openqueue.sourceforge.net/)
40. OpenQueue Technique Overview (http://openqueue.sourceforge.net/techoverview.php3)
41. Achieving Scalability and Expressiveness in an Internet-Scale Event Notification Service by Antonio Carzaniga, David S. Rosenblum and Alexander L. Wolf (http://www.ics.uci.edu/~dsr/podc2000.pdf)
42. Design of a Scalable Event Notification Service: Interface and Architecture by Antonio Carzaniga, David S. Rosenblum and Alexander L. Wolf ( http://www.ics.uci.edu/~dsr/siena-design.pdf )
43. The Design and Performance of a Real-time CORBA Event Service
44. GENA framework by Josh Cohen at WISEN. (http://www.ics.uci.edu/IRUS/twist/wisen98/presentations/Cohen/Cohen.PPT)
45. COBEA: A CORBA-Based Event Architecture (http://www.usenix.org/publications/library/proceedings/coots98/full_papers/ma/ma_html/ma.html)
46. Multicast & Publish - Subscribe used to build Event Notification on IP. (http://www.ics.uci.edu/IRUS/twist/wisen98/presentations/Mathon/Mathon.PPT)
47. IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols (http://www.normos.org/ietf/rfc/rfc2357.txt)