Expand Collapse
Just a second...

Push Notification Bridge

The Push Notification Bridge is a Diffusion™ client that subscribes to topics on behalf of other Diffusion clients and uses a push notification network to relay topic updates to the device where the client application is located.

The Push Notification Bridge comprises the following files all located in the pushnotification directory of your Diffusion installation:
pn_bridge.jar
This JAR file contains the Diffusion Java™ client that acts as a bridge between Diffusion and push notification networks.
pn_bridge.bat and pn_bridge.sh
These scripts can be used to start the Push Notification Bridge.
PushNotifications.xml
This XML file is used to configure the Push Notification Bridge.
PushNotifications.xsd
This XSD file defines the schema of the PushNotifications.xml file.

How the Push Notification Bridge works

A client sends a JavaScript Object Notation (JSON) message through a request topic to the Push Notification Bridge, requesting push notifications for a specific topic.

The topic that notifications are received for must be a single value topic.

Figure 1. Requests to the Push Notification Bridge The request flow through Diffusion to the Push Notification Bridge.
  1. The client sends a request message to the service topic path that the bridge listens on.

    This topic path is defined in the PushNotifications.xml configuration file. For more information, see Configuring your Push Notification Bridge.

    The request message is in JSON format. For more information about the request message format, see Request and response JSON formats.

  2. The Push Notification Bridge receives the message through the service topic path.
  3. The bridge attempts to subscribe to the topic.
  4. If the subscription is successful, the bridge stores the association between the topic and the push notification destination. This can be represented by either an Apple Push Notification Service (APNS) device token or a Google Cloud Messaging (GCM) registration ID. The destination is the combination of the client application and the device on which the client is hosted. It is not the same as a client session.

    The association between topic and destination is stored in memory, by default. You can persist this information by implementing your own persistence solution. For more information, see Push Notification Bridge persistence plugin.

  5. The bridge sends a response message to the client through its service topic path.

    The response message is in JSON format. For more information about the response message format, see Request and response JSON formats.

  6. The client receives the response message and can act on it.
The client can also request to be unsubscribed from receiving push notifications for a topic.

When an update is received on a subscribed topic, the bridge sends a push notification to the destinations associated with that topic.

Figure 2. Notifications from the Push Notification Bridge The notification flow from the Push Notification Bridge to the destination.
  1. The topic is updated.
  2. The Push Notification Bridge receives topic update and transforms the update into JSON according to the template that is configured for the topic.

    For more information about the JSON format of notifications, see Push notification JSON format. For more information about configuring templates, see PushNotifications.xml.

  3. The bridge looks up the destinations that have subscribed to receive push notifications for this topic.
  4. The bridge sends the push notifications to the push notification network.

    The push notification network that the bridge uses depends on the transport prefix in the destination URI provided in the subscription request message.

  5. The push notification network sends the notification to the destination.
If the client is active when the topic update occurs and is subscribed to that topic, the update is received twice: once through the Diffusion server and once through the push notification network. It is the responsibility of the client to handle any duplication.

This page last modified: 2017/02/05