Next: Performance Measurements Up: An Extensible and Interoperable Previous: Reference Implementation: xEvents

Examples and Testing with xEvents

We have developed two applications to validate the xEvents implementation.

Resource Monitoring

Figure 14: Example of interconnected SOAP Events system
$\begin{figure}\begin{center} \epsfig{file=setup_demo3.eps, width=12cm,height=9cm}\end{center}\end{figure}$

Figure 14 shows a resource monitoring system based on SoapRMI events. ResDat (Resource-Data) sensors in C++ and Java send resource-specific events (CPU utilization, free memory, etc.) to a filtering-event-channel. A simple test publisher sends test-events to the filtering event channel. Other event channels and listeners can be connected to the filtering event channel. The filtering-event-channel filters the events (e.g., to select only messages from a specified domain) before it sends it to the test-event-channel and resdat-event-channel.
Instant Messenger System:

Figure 15: Example of LDAP based Instant Messenger System
$\begin{figure}\begin{center} \epsfig{file=im23.eps, height=7cm}\end{center}\end{figure}$

Figure 16 shows the design of a simple instant messenger (IM) based on SoapRMI events. The clients can be written in either C++ or Java. The server acts as a registry for storing the remote references to the clients. The list of references that the server maintains keeps changing as clients continually exit and rejoin the system. The server even maintains a buddy list for each client so that once a client registers itself, all its buddies can be informed. The clients obtain remote references to their friends from the server and can directly chat with them.

Figure 16: Example of an Instant-Messenger System
$\begin{figure}\begin{center} \epsfig{file=im13.eps,width=11cm}\end{center}\end{figure}$

Figure 15 shows the design of a federated instant messenger system. The system consists of interconnected network of IM systems. Clients at boot-up time connect to a local IM server that acts as the root for its subnet. LDAP is used to store the remote references to all IM servers. Whenever a client wants to send a message to another client, it first sends it to its preferred IM server. The IM server searches LDAP to find the preferred IM server for the recipient of the message. If the IM server is online, it sends the message or else the message is buffered.
This design helps in a simple and efficient mechanism for dispersing events. A central server monitors the LDAP directory and sends a heart-beat event to each root IM server. The root IM server in turn sends the heart beat event to all its clients. If a client doesn't receive a heart beat event in a specified amount of time it initiates the election-process to elect a new IM server as root. All IM servers are expected to rebind to the LDAP directory at regular intervals.

**Figure 14:** Example of interconnected SOAP Events system
$\begin{figure}\begin{center} \epsfig{file=setup_demo3.eps, width=12cm,height=9cm}\end{center}\end{figure}$

**Figure 15:** Example of LDAP based Instant Messenger System
$\begin{figure}\begin{center} \epsfig{file=im23.eps, height=7cm}\end{center}\end{figure}$

**Figure 16:** Example of an Instant-Messenger System
$\begin{figure}\begin{center} \epsfig{file=im13.eps,width=11cm}\end{center}\end{figure}$

Next: Performance Measurements Up: An Extensible and Interoperable Previous: Reference Implementation: xEvents

Aleksander Andrzej Slominski 2002-02-23