• Article

Event Notifications

Topic Last Modified: 2008-07-15

Exchange Web Services in Microsoft Exchange Server 2007 includes an event notification subsystem. The purpose of this subsystem is to notify server and client applications of events that occur in mailboxes on a computer that is running Exchange 2007. Clients subscribe to the notification subsystem and can specify the events for which they want to receive notifications. Exchange Web Services allows for the following types of notifications:

  • Pull event notifications   Notifications that are requested by the client applications.
  • Push event notifications   Notifications that are sent by the notification subsystem.

Event Notification Clients

Exchange Web Services Event notification clients are either loosely coupled or tightly coupled. The following are the characteristics of loosely coupled clients:

  • They are connected to the Exchange server through firewalls and/or multiple networks or are otherwise topologically distant.
  • They are not IP addressable from the Exchange 2007 computer on which the Client Access server role is installed.
  • They are not reliably connected to the network.

The following are the characteristics of tightly coupled clients:

  • They are usually on the same network as and frequently in close logical proximity to the Microsoft Exchange server.
  • They are IP addressable.

Pull notifications are generally more appropriate for loosely coupled clients. Push notifications are generally more appropriate for tightly coupled clients.

Pull Event Notifications

Client applications that subscribe to pull event notifications specify particular events for which to be notified and periodically request accumulated notifications from the Client Access server. Because the clients are not called directly by the Client Access server, but instead reestablish connections to the server as necessary based on their requirements, pull notifications are best used for loosely coupled clients.

Pull Event Notifications Topology

In a standard pull event notification scenario, loosely coupled clients interact with a Client Access server by using a marginally reliable, fast, and quickly reestablished connection, such as a wireless LAN. These clients can connect to the Client Access server as needed; they do not have to maintain open connections to the server. However, they are frequently inaccessible to inbound IP connections because of firewalls and to changes in dynamic IP addresses.

The following figure shows a standard pull event notification scenario.

Loosely coupled clients that have quickly established, low-cost connections to the Client Access server
Pull subscription with loosely-coupled clients.

The following figure shows a variation of the standard pull scenario. In this figure, the client is connected directly to a network that is connected to the Client Access server. Clients that are connected directly to the network usually have a stable IP address or a stable DNS name. However, in a modern enterprise network topology, where each client carries its own software firewall, these clients are unlikely to be able to host a Web service or open arbitrary IP ports for servers to access. In this scenario, the pure pull notification system is required.

Tightly coupled client that has high-speed, reliable connection to the Client Access server
Pull subscription for a tightly-coupled client.

Push Event Notifications

Push event notifications enable client applications to subscribe to particular events and provide the Client Access server a callback address and a client-side Web service to which the event notifications are actively delivered. Generally, push notifications provide for smaller notification latency than pull notifications, and are frequently the best option for tightly coupled clients to which the Client Access server has reliable access.

Because servers can host a Web service, and have a stable IP address or DNS name, they are best served by push notifications. The servers can then process and redistribute notifications as needed to their clients.

For an example of how to use push notifications, see Push Notification Sample Application (Exchange Web Services).

Push Event Notifications and Proxy Servers

In networks that use a proxy server, push notifications from the server are sent to the proxy server and not directly to the URL that is specified in the subscription. To bypass the proxy for push notifications, you can set the bypasslist setting in the web.config file. The following example shows you how to bypass a proxy for push notifications.

<configuration>
   <system.net>
      <defaultProxy>
         <proxy usesystemdefault="true" bypassonlocal="true" />
               <bypasslist>
                     <add address="exchangeserver.example.com" />
               </bypasslist>
      </defaultProxy> 
   </system.net>
</configuration>

The bypass list supports multiple computers. DNS and IP address regular expressions are also allowed.