Sun Java Communications Suite 5 Event Notification Service Guide

Event Notification Service Architecture

On the Solaris platform, ENS runs as a daemon, enpd, along with other daemons in various calendar or messaging server configurations, to collect and dispatch events that occur to properties of resources. On Windows platforms, ENS runs as a service, enpd.exe.

For ENS, an event is a change that happens to a resource, while a resource is an entity such as a calendar or inbox. For example, adding an entry to a calendar (the resource) generates an event, which is stored by ENS. This event can then be subscribed to, and a notification would then be sent to the subscriber.

The ENS architecture enables the following three things to occur:


ENS notifies its subscribers of an event by sending a notification. Notify is also referred to as “publish.” A notification can contain the following items:

The optional application-specific data is referred to as the “payload.”

There are two kinds of notifications:

See Publisher API for more information.


ENS receives a request to be notified of events. The request sent by the event subscriber is a subscription. The subscription is valid during the life of the session, or until it is cancelled (unsubscribed).

A subscription can contain the following items:

See Subscriber API for more information.


ENS receives a request to cancel an existing subscription. See Subscriber API for more information.

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. 


How Messaging Server Interacts with ENS

Figure 1–3 shows how ENS interacts with Messaging Server. In this figure, each oval represents a process, and each rectangle represents a host computer running the enclosed processes.

The ENS server delivers notifications from the Messaging Server notification plug-in to ENS clients (that is, iBiff subscribers). There is no guarantee of the order of notification prior to the ENS server because the events are coming from different processes (MTA, stored, and imapd).

Notifications flow from the iBiff plug-in in the MTA, stored, and imap processes to ENS enpd. The ENS client subscribes to the ENS, and receives notifications. When iBiff is enabled, Messaging Server publishes the notifications with the iBiff plug-in, but no Messaging Server services subscribe to these notifications. A customer-provided ENS subscriber or client should be written to consume the notifications and do whatever is necessary. That is, Messaging Server itself does not depend on or use the notifications for its functions, and this is why ENS and iBiff are not enabled by default when you install Messaging Server.

The Messaging Server architecture enforces that a given set of mailboxes is served by a given host computer. A given mailbox is not served by multiple host computers. There are several processes manipulating a given mailbox but only one computer host serving a given mailbox. Thus, to receive notifications, end-users only need to subscribe to the ENS daemon that serves the mailbox they are interested in.

Messaging Server enables you to have either one ENS server for all mailboxes—that is, one ENS server for all the computer hosts servicing the message store—or multiple ENS servers, perhaps one ENS server per computer host. The second scenario is more scalable. Also, in this scenario, end users must subscribe to multiple ENS servers to get the events for mailboxes they are interested in.

Thus, the architecture requires an ENS server per computer host. The ENS servers and the client processes do not have to be co-located with each other or with messaging servers.

Figure 1–3 ENS in Messaging Server Overview

ENS in Messaging Server overview.