Sun Java Communications Suite 5 Event Notification Service Guide

How Calendar Server Interacts with ENS

Figure 1–1 shows how ENS interacts with Calendar Server through the alarm queue and two daemons, csadmind and csnotifyd.

Figure 1–1 ENS in Calendar Server Overview

ENS in Calendar Server overview.

Calendar Server Alarm Queue

ENS is an alarm dispatcher. This decouples alarm delivery from alarm generation. It also enables the use of multiple delivery methods, such as email and wireless communication. The csadmind daemon detects events by sensing changes in the state of the alarm queue. The alarm queue’s state changes every time an alarm is placed in the queue. An alarm is queued when a calendar event generates an alarm. The following URIs represent these kind of events:

for events:


for todos (tasks):



The publisher csadmind dequeues the alarms and sends notifications to enpd. The enpd daemon then checks to see if anyone is subscribed to this kind of event and sends notifications to the subscriber, csnotifyd, for any subscriptions it finds. Other subscribers to alarm notifications (reminders) can be created and deployed within an Calendar Server installation. These three daemons interacting together implement event notification for Calendar Server.

Calendar Server Daemons

Calendar Server includes two daemons that communicate to the ENS daemon, enpd:

Alarm Transfer Reliability

To ensure that no alarm ever gets lost, csadmind and csnotifyd use the RENL feature of ENS for certain types of alarms. For these alarms, csadmind requests an end-to-end acknowledgment for each notification it sends, while csnotifyd, after successfully processing it, generates a notification acknowledgment for each RENL alarm notifications it receives.

For these RENL alarms, should the network, the ENS daemon, or csnotifyd fail to handle a notification, csadmind will not receive any acknowledgment, and will not remove the alarm from the alarm queue. The alarm will, therefore, be published again after a timeout.

Calendar Server Example

A typical ENS publish and subscribe cycle for Calendar Server resembles the following:

  1. The event subscriber, csnotifyd, expresses interest in an event (subscribes).

  2. The event publisher, csadmind, detects events and sends notification (publishes).

  3. ENS publishes the event to the subscriber.

  4. The event subscriber cancels interest in the event (unsubscribes). This step happens implicitly when the connection to ENS is shut down.

Figure 1–2 illustrates this cycle and Table 1–1 provides the narrative for the figure.

Figure 1–2 Example Event Notification Service Publish and Subscribe Cycle for Calendar Server

Example event notification service publish and subscribe
cycle for Calendar Server.

Table 1–1 Sample ENS Publish and Subscribe Cycle


ENS Response  

1. The csnotifyd daemon sends a subscription request to ENS.

ENS stores the subscription in the subscriptions database. 

2. The csadmind daemon sends a notification request to ENS.

ENS queries the subscriptions database for subscriptions matching the notification. 

3. The csnotifyd daemon receives a notification from ENS.

When ENS receives a notification from a publisher, it looks up its internal subscription table to find subscriptions matching the event reference of the notification. Then for each subscription, it relays a copy of the notification to the subscriber who owns this subscription. 

4. Currently, csnotifyd does not bother sending cancellation requests to ENS.

Because the subscriptions store is in memory only (not in a database), all subscriptions are implicitly unsubscribed when the connection to ENS is shutdown.