You can use both the EWS Managed API and Exchange Web Services (EWS) to subscribe to receive notifications when events occur in a mailbox, or in one or more of the folders in a mailbox. Three subscription types are available: streaming notifications, pull notifications, and push notifications. Each of these subscription types uses different techniques to receive or retrieve the notifications.
EWS Streaming notifications
Notifications that are sent by the server through a connection that remains open for a specified period of time.
Streaming notifications are generally recommended for most applications. They’re similar to pull and push notifications, and offer the best of both worlds. After you establish your notification subscription, the connection remains open for up to 30 minutes to allow the server to push notifications back to the client. No need to request updates, like you would with a pull subscription, and you don’t have to create a web service listener application like you would with a push subscription.
Notifications that are sent by the server through a connection that remains open for a specified period of time.
Streaming notifications are generally recommended for most applications. They’re similar to pull and push notifications, and offer the best of both worlds. After you establish your notification subscription, the connection remains open for up to 30 minutes to allow the server to push notifications back to the client. No need to request updates, like you would with a pull subscription, and you don’t have to create a web service listener application like you would with a push subscription.
Streaming notifications rely on a hanging get request on the server to keep a streaming subscription connection open, so that any events that occur while the connection is active are streamed to the client immediately. Multiple notifications can be sent over the course of a single connection, and the connection stays open until the interval expires, or for a maximum of 30 minutes. After the connection expires, the client sends the hanging get request again.
 |
| EWS Streaming notification work flow |
EWS Pull notifications
Notifications that are requested (or pulled) by the client.
Pull notifications are generally most appropriate for loosely coupled clients, where the client is not reliably connected to the network. Pull notifications can create excess traffic between the client and the server because the client is sending frequent requests to the server to retrieve notifications, and not all requests result in notifications retrieved.
Notifications that are requested (or pulled) by the client.
Pull notifications are generally most appropriate for loosely coupled clients, where the client is not reliably connected to the network. Pull notifications can create excess traffic between the client and the server because the client is sending frequent requests to the server to retrieve notifications, and not all requests result in notifications retrieved.
Pull notifications rely on the client asking for the notifications on an interval that the client manages. This can result in GetEvents responses with no notifications.
 |
| Pull notification work flow |
EWS Push notifications
Notifications that are sent (or pushed) by the server to a client-side web service via a callback address.
Generally, push notifications provide for smaller notification latency than pull notifications and are suited for tightly coupled clients to which the server has reliable access and the client is IP addressable. However, push notifications have fallen out of favor since the advent of streaming notifications in Exchange 2010. If possible, we recommend that you use streaming notifications instead of push notifications going forward. Push notifications require that you write a listener application, which is where the notifications are pushed to. This has a slight benefit over pull notifications in that it reduces wire traffic, but it adds overhead by requiring a separate application.
Push notifications rely on the server pushing notifications back to the client. There’s only traffic if there’s a notification. Figure 4 shows how push subscriptions and push notifications work.
Generally, push notifications provide for smaller notification latency than pull notifications and are suited for tightly coupled clients to which the server has reliable access and the client is IP addressable. However, push notifications have fallen out of favor since the advent of streaming notifications in Exchange 2010. If possible, we recommend that you use streaming notifications instead of push notifications going forward. Push notifications require that you write a listener application, which is where the notifications are pushed to. This has a slight benefit over pull notifications in that it reduces wire traffic, but it adds overhead by requiring a separate application.
Push notifications rely on the server pushing notifications back to the client. There’s only traffic if there’s a notification. Figure 4 shows how push subscriptions and push notifications work.
 |
| Push notification work flow |
No comments:
Post a Comment