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 by 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 IBM MobileFirst Platform Foundation server-side push notification API to process the messages.

Figure 1. JMS polling push notification architecture
In this architecture, a MobileFirst JMS adapter pulls messages from the queue and calls the IBM MobileFirst Platform Foundation server-side push notification API to process the messages
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 by 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 by using a MobileFirst JMS adapter, which functions as follows:
    • In a MobileFirst Server cluster, the single polling MobileFirst Server is selected randomly, by using the IBM MobileFirst Platform Foundation 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 you can put the messages that you want 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
This architecture relies on the enterprise backend to deliver messages to a MobileFirst Server cluster by calling a MobileFirst adapter procedure
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 you can add more servers if you must send more messages per second. Cons of this method are that every push message is a transaction on the MobileFirst Server. You 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