Introduction
Exchange 2007 introduced a new programming model by using Web Services. The API is called Exchange Web Services (EWS). The new programming model is easy to use, has a nice documentation in the SDK, and also a nice learning curve.
Notifications
Notification is an event raised when a specific activity occurs to a specific resource in Exchange. The most obvious situation is when you want to monitor a specific mail box. Exchange has two methods of notification; passive and active notifications:
- Pull Notifications (Passive approach): You build your application so that it asks Exchange every specific period of time about any events occurred to the desired resource.
- Push Notifications (Active approach): Exchange will notify you about changes that has occurred and sends the notification to your application via a custom Web Service (a web service that you built).
Either of these (Pull or Push) notifications requires you to subscribe to the required events so that Exchange can generate the desired notifications which will be sent to your application.
EWS Programming and Types
EWS differentiates between two types of resource folders and items. An item could be a message, contact, task, etc… So, the notification in this sample monitors the Inbox folder.
Programming against EWS is done by Request and Response.
You create the (Request). Then, using ExchangeBindingService
, you send the request and return the (Response) which you test for success.
Motivation
The Push notification sample included in the SDK has a subscriber project and a client web service project to consume the Exchange notifications.
Thinking that you may not have IIS installed or that you have to build a web service to have a bridge between your application and the Exchange notifications made me uncomfortable about the situation. EWS uses SOAP messages all the time. So, I figured out that using a WCF service will be a nice feature to interact with the notifications. WCF services could be hosted in any application, and it will integrate with the rest of the pieces in your software.
Notes
The Push notification client has Interfaces.cs which is generated from NotificationServices.wsdl included in the SDK. To regenerate the same file, you have to borrow the Messages.XSD and Types.XSD from the Exchange folder in the server.
Wsdl /si NotificationService.wsdl Messages.xsd Types.xsd
But to generate WCF code, you need to run svcutil.
Svcutil NotificationServices.wsdl Messages.xsd Types.xsd
Your class will inherit the class generated in schemas.microsoft.com.exchange.services.2006.messages.cs.
public class Notification : NotificationServicePortType
NotificationServicePortType
is different than the class in Interfaces.cs in the sample, but don't panic; it is a wrapper to the desired type. WCF will handle all the issues once we adjust the EndPoint configuration.
Running the Demo
You should be aware that your WCF could be running on another computer.
- You should add exceptions in the Windows firewall for the chosen port or disable the firewall.
- Refer to the computer names if Exchange and the WCF service are in separate machines; else use localhost.
- Make sure that the /EWS folder exists in IIS and that its website is running, and make sure of the port it uses.
- A lot of errors will be related to the URLs most of the time.
How WCF Acts like a Web Service
The EndPoint configurations have to be configured accurately to make the WCF act like a Web Service and to let the Exchange call the SendNotification
method correctly.
See this part in the App.config file:
<endpoint address=""
contract="NotificationServicePortType"
binding="basicHttpBinding"
bindingName="NotificationServiceBinding"
bindingNamespace="http://schemas.microsoft.com/exchange/services/2006/messages"
/>
History