I wrote a sample application quite a while ago showing how to write a push notification client using WCF. This seemed a little complex to me, and I have now got another sample that uses the managed API and a custom listener (taken from SOAPe) to respond to the notifications. The listener form has been expanded so that it now raises events that can be handled by another form. The main window (showing the listener window behind, which just shows and logs the event XML as received from Exchange) looks like this:
The Unsubscribe button doesn’t actually do anything currently, as Unsubscribe has not been implemented in the managed API. I will implement an Unsubscribe at some point, though it is not overly important as once the listener is closed, the subscription will timeout after a while when Exchange does not receive a response (or cannot connect) to the listener end-point.
As a push notification is an event that requires a response (so that the server knows that the event has been successfully received), that part of the routine should be as quick as possible. If you want to retrieve more information for an item when you receive an event (and this would normally be the case), then it is important to ensure that obtaining such further information does not impact any response to Exchange. In this sample application, I have done this by spawning a new thread to retrieve further information for an event, with the notification handler then returning immediately. If Query extra info and Include MIME are both selected (they are by default), then for each event the application will then retrieve the entire MIME content for the affected message – if the message had a large attachment, this could take some time (also dependent upon the network connection). Once the information is retrieved it is shown in the event window (in this case, nothing useful is done but the MIME length is shown to prove it was retrieved).
Note that when an item is deleted, it is not possible to bind to it (so further information cannot be obtained). This applies to hard-deleted items (soft-deleted items are actually a move of the item to the user’s Deleted Items folder), and so this application doesn’t attempt to obtain further information in that case (it will just show the parent folder, if possible). For Exchange 2010, it would be possible to retrieve the information by locating the item in the dumpster, assuming it is enabled.