Notification Hubs Overview

Azure Notification Hubs provide an easy-to-use infrastructure that enables you to send mobile push notifications from any backend (in the cloud or on-premises) to any mobile platform.

With Notification Hubs you can easily send cross-platform, personalized push notifications, abstracting the details of the different platform notification systems (PNSs). With a single API call, you can target individual users or entire audience segments containing millions of users, across all their devices.

You can use Notification Hubs for both enterprise and consumer scenarios. For example:

• Send breaking news notifications to millions with low latency (Notification Hubs powers Bing applications pre-installed on all Windows and Windows Phone devices).
• Send location-based coupons to user segments.
• Send event notifications to users or groups for sports/finance/games applications.
• Notify users of enterprise events like new messages/emails, and sales leads.
• Send one-time-passwords required for multi-factor authentication.

What are Push Notifications?

Smartphones and tablets are able to "notify" users when an event has occurred. On Windows Store and Windows Phone applications, the notification results in a toast (a modeless window appearing at the top of the screen) or with tile updates on the Start screen. Similarly, on Android and Apple iOS devices, notifications appear grouped in a notification panel easily accessible from the top of the screen.

Push notifications help app backends display fresh information on mobile devices even when the app on the device is not active.

Push notifications are delivered through platform-specific infrastructures called Platform Notification Systems (PNS). A PNS offers barebones functions (that is, no support for broadcast or personalization) and the platform-specific PNSs have no common interface. For example, in order to send a notification to a Windows Store app, a developer must contact the WNS (Windows Notification Service). To send a notification to an iOS device, the same developer contacts APNS (Apple Push Notification Service), and sends the message a second time. The process is similar for Windows Phone 8, and Android apps.

At a high level, all platform notification systems follow the same pattern:

1. The client application contacts the PNS to retrieve its handle. The handle type depends on the system. For WNS, it is a URI or "notification channel." For APNS, it is a token.
2. The client application stores this handle in the app backend for later usage. For WNS, the backend is typically a cloud service. For Apple, the system is called a provider.
3. To send a push notification, the app backend contacts the PNS using the handle to target an instance of a specific client application.
4. The PNS forwards the notification to the device specified by the handle.

The infrastructure required to implement this flow is fairly complex and mostly unrelated to the main business logic of the app. Some of the challenges in building an on-demand push infrastructure are:

• Platform dependency. In order to send notifications to devices on different platforms, you must code multiple interfaces in the backend. Not only are the low-level details different, but also the presentation of the notification (tile, toast, or badge) is platform-dependent. These differences lead to complex and hard-to-maintain back-end code.
• Scale. Scaling this infrastructure has two aspects:
  • Per PNS guidelines, device tokens must be refreshed every time the app is launched. This leads to a large amount of traffic (and consequent database access) just to keep the device tokens up to date. When the number of devices grows (possibly to millions), the cost of creating and maintaining this infrastructure is nontrivial.
  • Most PNSs do not support broadcasting to multiple devices. As such, a broadcast to millions of devices results in millions of calls to the PNSs. Being able to scale these requests is nontrivial, because app developers usually want to keep the total latency low (for example, the last device to receive the message should not receive the notification 30 minutes after the notifications has been sent, because for many cases it would defeat the purpose of having push notifications).
• Routing. PNSs provide a way to send a message to a device. In most apps, however, notifications are targeted at users and/or interest groups (for example, all employees assigned to a certain customer account). As such, the app backend must maintain a registry that associates interest groups with device tokens in order to route the notifications to the correct devices. This overhead adds to the total time to market and maintenance costs of an application.
• Monitoring and Telemetry. Tracking and aggregating the outcomes of millions of notifications is not trivial, and it is usually an important component of any solution that uses push notifications.

Using Notification Hubs

Notification Hubs eliminate one major complexity: you do not have to manage the challenges of push notifications. Instead, you can use a Notification Hub. Notification Hubs use a full multiplatform, scaled-out push notification infrastructure, and considerably reduce the push-specific code that runs in the app backend. Notification Hubs implement all the functionality of a push infrastructure. Devices are only responsible for registering PNS handles, and the backend is responsible for sending platform-independent messages to users or interest groups, as shown in the following figure:

Notification Hubs provide a push infrastructure with the following advantages:

• Multiple platforms:
  • Support for all major mobile platforms (Windows/Windows Phone, iOS, Android).
  • No platform-specific protocols. The application only communicates with Notification Hubs.
  • Device handle management. Notification Hubs maintains the handle registry and feedback from PNSs.
• Works with any back-end. Cloud or on-premises, .NET, PHP, Java, Node, etc.
• Scale. Notification Hubs scale to millions of devices without the need of re-architecting or sharding. Available in all regions.
• Rich set of delivery patterns. Associate devices with tags, representing logical users or interest groups.
  • Broadcast: allows for near-simultaneous broadcast to millions of devices with a single API call.
  • Unicast/Multicast: push to tags representing individual users, including all of their devices; or wider group; for example, separate form factors (tablet vs. phone).
  • Segmentation: push to complex segment defined by tag expressions (for example, devices in New York following the Yankees).
• Personalization. Each device can have one or more templates, to achieve per-device localization and personalization without affecting back-end code.
• Security. Shared Access Secret (SAS) or federated authentication.
• Rich telemetry. Available in the portal and programmatically.

Summary

• Push notifications have become an integral part of any modern application, as they increase user engagement for consumer apps and the utility of enterprise apps.
• Notification Hubs provide an easy-to-use, multiplatform, scaled-out push infrastructure, which significantly reduces the coding and maintenance of app back-end code.
• Notification Hubs can be used from any back-end (cloud or on-premises) to send push notifications to all major mobile platforms (Windows/Windows Phone, iOS, Android).

Source from
http://msdn.microsoft.com/en-us/library/jj927170.aspx