Possible MobileFirst push notification architectures

IBM MobileFirst Platform Foundation supports two different methods of implementing push notifications, which are based on how the enterprise back end provides the messages to the MobileFirst Server.

Two common ways exist to create an IBM MobileFirst Platform Foundation push notification architecture:

• The Java Message Service (JMS) polling method, in which messages are pulled from the JMS message queue and sent by the MobileFirst Server

• The enterprise back end method, in which an enterprise back end uses a MobileFirst adapter to deliver messages to a MobileFirst Server cluster

JMS polling architecture

This architecture relies on the enterprise backend to deliver messages to a single instance of MobileFirst Server using a JMS message queue. The developer must create an IBM MobileFirst Platform Foundation JMS adapter, which pulls messages from the queue and calls the MPF server-side push notification API to process the messages.

Figure 1. JMS polling push notification architecture

When this architecture is used, the flow is as follows:

1. Messages are put into the JMS queue by the enterprise backend.

2. The MobileFirst Server polls the JMS queue using the JMS adapter, retrieving messages in short batches and sending them to the push providers.

3. A single MobileFirst Server instance pulls from the JMS queue and sends the push notifications. Even in a MobileFirst Server cluster, only one MobileFirst Server polls.

4. The process is implemented using a MobileFirst JMS adapter, which functions as follows:

   • In a MobileFirst Server cluster, the single polling MobileFirst Server is selected randomly, using the MPF cluster-sync mechanism.

   • If the server that pulls from the JMS queue is shut down, another server takes its place.

This is the standard architecture. Pros of this method are that it involves an asynchronous queue, into which we can put the messages to send. These messages are then processed and pulled later by the MobileFirst Server. Cons of this method are that only one server is sending the push notifications, so the maximum messages-per-second throughput is fixed.

Enterprise backend calling the MobileFirst Server architecture

This architecture relies on the enterprise backend to deliver messages to a MobileFirst Server cluster by calling a MobileFirst adapter procedure.

Figure 2. Enterprise backend push notification architecture

When this architecture is used, the flow is as follows:

1. The request is routed to one of the MobileFirst Server instances, which sends a push message to a provider.

2. In this flow, all MobileFirst Server instances can send push notifications, but for a specific request only one of the server instances performs the task.

3. The enterprise backend initiates calls to the load balancer.

Pros of this method are that all MobileFirst Server can be used to send push notifications, so we can add more servers if we must send more messages per second. Cons of this method are that every push message is a transaction on the MobileFirst Server. We can mitigate this overhead by sending a number of messages together or by having the MobileFirst adapter procedure that is invoked call the backend for a batch of messages rather than single messages.

Parent topic: Push notification