|
Streaming Notifications |
Pull Notifications |
Push Notifications |
Description |
Notifications that are sent by the Exchange Server through connections that are created by Riva and re-created as soon as they time out. |
Notifications that are pulled (=requested) by Riva every UCD sync cycle through connections that are created by Riva. |
Notifications that are pushed (=sent) by the Exchange Server to the Riva Exchange Push Listener Web Service through connections created by the Exchange Server as need arises. |
Requirements |
Office 365, Exchange Online, or Exchange Server 2013 SP1 or higher. |
Office 365, Exchange Online, or Exchange Server 2010 or higher. |
Office 365, Exchange Online, or Exchange Server 2007 SP3 or higher.
For a non-Office 365 hosted Exchange environment, check with the service provider to confirm whether Push Notifications are supported. |
Riva 2.4.53 or higher for Office 365 OAuth connections.
Riva 2.4.42 or higher for the other connections. |
Riva 2.4.52 or higher for Office 365 OAuth connections.
Riva 2.4.49 or higher for the other connections. |
Riva 2.4.53 or higher for Office 365 OAuth connections.
Riva 2.4.42 or higher for the other connections. |
Exchange Impersonation. |
Exchange Impersonation or Delegate Access. |
Exchange Impersonation or Delegate Access. |
- Ability for Riva to establish HTTP connections to the Exchange server.
- HTTP connection timeout that is greater than 30 minutes.
- EWS Auto Discover Service to retrieve Exchange Grouping Information.
|
- Ability for Riva to establish HTTP connections to the Exchange server.
|
- Ability for the Exchange environment to establish outbound HTTP communications used to push the notifications to the Riva Exchange Push Listener Web Service.
|
Environment |
Ideal for most environments and requires the least setup and configuration. |
Usually more appropriate for loosely coupled environments. |
May be ideal for tightly coupled environments such as corporate networks. |
Process |
Based on the grouping information, Riva initiates a number of HTTP connections. The Exchange Server keeps any HTTP connection open until changes are detected or 30 minutes have passed. Every time a connection is closed, Riva immediately opens a new one, and the cycle repeats indefinitely. |
When a mail UCD cycle occurs, Riva creates subscriptions on the Exchange server and requests notifications. That requires one API call per user per UCD sync cycle. |
A subscription to EWS is created. When a change occurs in a mailbox, the Exchange Server establishes an HTTP connection to Riva's listener and sends a change notification. |
Connections |
Multiple connections. In ideal conditions, an HTTP connection can monitor changes in 200 mailboxes. The actual number of mailboxes can easily be 50% or 60% less, depending on how Exchange manages the grouping based on the number of mail store servers. |
No long-running HTTP connections remain open. There is no need to keep open HTTP connections between mail UCD cycles. Riva can reuse HTTP connections, which saves time. |
No long-running HTTP connections remain open. |
Scalability |
Less scalable than pull or push notifications, because streaming notifications require a number of HTTP connections to remain open. |
More scalable than streaming modifications, because pull notifications do not require a number of HTTP connections to remain open. |
More scalable than streaming notifications, because push notifications do not require a number of HTTP connections to remain open.
Can be used in large enterprise environment, for example more than 50,000 mailboxes. |
Data flow |
Does not change.
Details: The streaming or pull HTTP connection is initiated by the synchronization service. Thus, the data flow does not change when switching from an EWS poll-based sync to UCD based on streaming or pull notifications. The synchronization service continues to establish all network connections. |
The data flow is reversed.
Details: The Exchange environment establishes a connection to push a notification message that is received by the Riva Exchange Push Listener Web Service. The flow of this notification originates from Exchange, which is the opposite of the typical data flow that originates from the synchronization service. |
As far as the data flow is concerned, no changes are required for the network, firewall, or security controls. |
The data flow pattern change may require additional network-layer configurations, firewall changes, and — depending on the environment — security reviews. |
Major consideration |
The duration of each HTTP connection and the number of open connections. |
The possibility of excess traffic between Riva and the server because of Riva's frequent requests to the server to retrieve notifications. |
The data flow pattern change may require firewall and network changes. |
Deployment simplicity |
The deployment simplicity is about the same for streaming and pull notifications. |
Push notifications are not as simple to deploy because of the data flow pattern change. |