Sendify : An XMPP based Notification System

Developers working on Mobile or web applications need to set up suitable databases (create custom tables and schema) to create custom notification systems as one of the features of an end product. The end product, hence, will actually be a set of APIs and SDKs for certain platfor

ms (Javascript and Android) which they can integrate with ease into their systems and create an entire notification system with a few lines of code.

Sending simultaneous push notifications in a low-latency way to millions of mobile users, and handling real world requirements such as localization, multiple platform devices, and user personalization is a hard task.

The main reason this is challenging is that push notifications are delivered to the devices by platform-specific services. For instance, you have to use the Apple Push Notification service (APNs) for iOS, Google Cloud Messaging (GCM) for Android and WebSockets (Browser).

All these platform services work by having the device app request a user-, device-, and app-specific ChannelURI and then store it somewhere in the app back-end. Then, when sending a notification, the app back-end posts the notification payload to the ChannelURI in order to reach that particular device. To complicate matters, the ChannelURIs expire (and thus have to be continuously re-uploaded to the back-end) and multiple ChannelURIs can be active at the same time for the same device. When coding multi-platform apps, this problem is intensified because each platform handles push notifications in a slightly different way.

Assuming we have to send notifications about breaking news, and each user can subscribe to different categories, you will inevitably end up managing various information and details as a database table.

It’s clear that if you want to allow users to have multiple devices, and if you want to start handling localization and user preferences, this approach can quickly become problematic. If you have thousands of devices to notify, having a process go through a for loop won’t give your users a great experience. This means, for example, the latency of the notification will quickly become unacceptably long, and you won’t be able to recover in case something happens to your back-end in the middle of a push. Clearly, while you can solve these problems by storing your device information in multiple databases (i.e. sharding), creating multiple virtual machines that send notifications in parallel, and periodically saving your progress to persistent storage while sending notifications to large numbers of devices, it’s a hard task to implement these patterns in yet another part of your back-end!

Summarizing, we just saw how implementing a real world push notification solution in your app can quickly become large and complex. The biggest challenge is managing device information (especially for cross-platform and/or localized apps) and scaling up of the push infrastructure to handle up to millions of devices

We have solved all these problems. On the back-end stack, we have used ejabbered and MySQL for database. Our push notification will be based on sockets/XMPP.

Sendify is a new, self-contained product intended for use on the ‘Web’ as well as the ‘Android’ platforms.

The system has two types of clients - publishers and subscribers - also referred to as producers and consumers respectively. Publishers communicate asynchronously with subscribers by producing and sending a message to a topic, which is a logical access point and communication channel. Subscribers (that is, web servers, email addresses, et al.) consume or receive the message or notification over one of the supported protocols (that is, HTTP/S, XMPP, et al.) when they are subscribed to the topic. The following diagram illustrates the above mentioned interactions between the system and its clients, that is, the publishers and subscribers:

Push Notifications – Overview

Once you're provisioned, your application can submit a notification to Sendify's service. Sendify pushes your notification to the appropriate platform for routing to the end user's device. You can submit notifications individually, to a list of instances or to groups, and to either to an individual network or to both.

How Sendify Push Notifications works

By integrating developer’s application with Sendify Push Notifications, you can send a notification to a target application on an end user's device. The process of sending a notification involves these functions:

1. Registration of the application instance with Sendify Push Notifications.

2. A POST call is submitted to Sendify to send the push notification to one or more

destinations, or to a group of destinations.

3. Sendify returns a ticket ID and sends the notification to the specified destination(s).

Registering the application instance: Registration of an application instance, and management of that information, involves supplying Sendify with the destination ID, and optionally group membership information. You can design your application to self-register by supplying the registration information directly to Sendify, or your application can provide the information to your servers which then pass it on to Sendify. Regardless of how you design your application, you use the same APIs.

Specifying the destinations: You have a couple options for how to specify the target destination of a push notification. You can submit a request to send a notification to one destination—one application instance. You can also define one or more groups of destinations, which gives you the ability to send a notification to multiple destinations. This capability is useful if you want to segment your customer base. You can also send a notification to a group defined as "all", which results in the notification being sent to all registered application instances that are enabled.

Steps in the process

1. The end user launches an application that he previously downloaded to his device. (When he installed the application, he configured it to allow push notifications.) The application obtains a destinationId from the network and returns it to your servers.

2. Your system calls PUT New Application Instance to register the destination ID with Sendify Push Notifications.

3. Sendify responds with a success or fail, and if successful, returns the instance ID.

4. Upon successful device registration, your system submits a POST Notification to Sendify.

5. Sendify returns a ticket ID.

6. Your service can, as an option, call GET Notification Status to retrieve the state of the notification. Sendify will return the status, appId, instanceId, ticketId, createdDate, and processedDate.

7. If the notification's state is "failed", Sendify returns a failure reason.

How your application interfaces with Sendify and external networks

The server side of your application is the sender of a push notification. To route a notification to an application instance through Sendify, you first get provisioned to use Sendify Push Notifications. For Apple devices, this involves obtaining security certificates that Sendify will use to connect to APNS (Apple Push Notifications Service) environments. GCM requires a Google account, which Sendify uses to connect to the GCM interface.

User Classes and Characteristics

(i) Publisher:

• Publisher will be recognized in the system by a unique ID.

• Publisher can use any of the platforms - web, or mobile for publishing.

• Publisher will have the option to change the notification even though it has been delivered to the subscribers. In such a case a separate notification will be sent to those who have seen the notification and the notification will be updated in those cases where the subscribers haven’t seen the notification.

• Publisher can only add a subscriber. He can neither see the list of all subscribers subscribed to the topic, nor terminate the subscription of a particular subscriber.

(ii) Topic Owner:

• Any user in the system (either the developer or the customer) can create a topic. He will be called as the topic owner.

• There can be many publishers for a topic but there will only be a single topic owner.

• Topic owner has an option to add/delete the users to the topic himself or let the users to subscribe/unsubscribe to the topics on their own. In the earlier case, the user has to confirm his subscription/unsubscription.

• Only the Topic owner can delete a topic.

• Topic owner can see who all are subscribed to a topic.

• Topic owner can add publishers to a topic.

The code for the project can be found at :https://github.com/chennavamshi/sendify

For more information about the design of the APIs and applications built using the project, please feel to contact me through email.