Architecture of the Exchange Event Service

The Event Service is implemented as a Microsoft Windows NT service that receives notifications from server-based folders about the state of folder items. The service architecture is structured like this: the service—events.exe—passes events, such as the creation of a new message in a folder, to the correct event handler—an agent—with some information about the source of the event, the message, and the folder that caused the event. This architecture is shown in Figure 12-1.

How does the Event Service know when an item is added, changed, or deleted in a particular folder? The Event Service is built on the same technology that Microsoft Outlook uses to perform local replication from the Exchange Server to your Outlook client. This technology is called Incremental Change Synchronization (ICS). ICS allows the client—in this case, the Event Service—to query the information store on the server and request information about all changes that have occurred in a particular folder since the last synchronization. By using ICS, the Event Service never misses an event, even if it is taken offline. When the Event Service goes back online, it will query for any changes to the folders it is monitoring and then fire the correct events to the corresponding event handlers for that folder.

Figure 12-1 The Exchange Event Scripting Agent architecture.

The Event Service fires events when an item is added, changed, or deleted in a folder, or according to time intervals. The events for adding, changing, and deleting items are self-explanatory, but the fourth event, the timed event, requires a little bit more explanation. You specify intervals indicating when to fire the timer event. These intervals can be hourly, daily, or weekly, depending on the needs of your application—for example, every 15 minutes, every 3 hours, or every week on Monday at 3:00 pm. In the application in this chapter, you will see how to use an interval to check the status of items in a folder.

The items that cause these folder events can be of any message class. For example, dragging and dropping a Microsoft Word document into a monitored public folder will fire the new message event. Notice that I say public folder. The Event Service can monitor only folders stored on an Exchange Server. It will not monitor folders stored on the local machines of users. So you can monitor events on Public Folders and in user mailboxes if the user mailboxes are stored on an Exchange Server. If you are using .pst files to store the mail of your users, you cannot monitor them for events. Most developers wonder whether .ost files are able to fire events because they are also stored on the client. They can if a user synchronizes her .ost file using the built-in capabilities of the Outlook client. When changes made in her .ost file are replicated to the server, the Event Service can fire events on those changes.

Once the Event Service realizes a change has occurred, it fires an event. Then it looks for a corresponding event handler in the folder. Associating an event handler with a specific event and folder is called binding. The Exchange Event Service ships with one prebuilt event handler, named the Exchange Event Scripting Agent, that you can bind to events. As you would guess by its name, the Event Scripting Agent is an event handler that allows you to write both Microsoft Visual Basic Scripting Edition (VBScript) and JScript scripts to perform actions when specific events occur. These scripts can automatically call Microsoft Collaborative Data Object (CDO) functions. The scripts are passed a pre-logged-on CDO session, which we'll learn more about later in this chapter. From these scripts, you can also call other COM components such as ActiveX Data Objects (ADO), Active Directory Services Interfaces (ADSI), or even your own custom COM components that are written using Microsoft Visual Basic or Microsoft Visual C++.

NOTE

---

In addition to developing your own custom components to call in scripts, you can write your own event handlers. These custom event handlers must implement the IExchangeEventHandler interface, as well as register themselves with the COM category CATID_ExchangeEventSink. Currently, custom handlers can be authored using only C/C++ and are beyond the scope of this book. If you are interested in developing custom handlers, you should look at the help file named Agents.hlp, which is included with Microsoft Exchange Server 5.5.