Messaging patterns

Fan out broadcast

One publisher device publishes a message to a topic string. The messages have many subscriber devices.

An example usage of this pattern is broadcasting reference data. For example, broadcasting an updated price list.

For an example implementation of this pattern, see Scenario: Fan out broadcast.

Fan in per device notification

Many publisher devices publish messages to a topic string. The messages have one subscriber device.

An example usage of this pattern is receiving data from a number of sensors. For example, receiving data from earthquake sensors.

For an example implementation of this pattern, see Scenario 2: Fan in per device notification

Fan out per device notification

One publisher device publishes messages to many topic strings. Each message has only one subscriber device.

An example usage of this pattern is sending control commands to a device. For example, sending a command to an application to activate a feature.

For this messaging pattern, each subscriber must subscribe to a unique topic. By using the unique user ID, group ID or client ID of the subscribing application in the topic string, you can ensure that each topic is unique. For example, a subscriber application instance that connects with a client ID of 123 subscribes to RESPONSE/123. A subscriber application instance that connects with a client ID of 456 subscribes to RESPONSE/456. A subscriber application instance with a client ID of 789 subscribes to RESPONSE/789.

//Generate clientID
String clientID = String.format("%-23.23s", UUID.randomUUID().toString()).trim().replace('-', '_');

//Create an MQTT client with the generated clientID
MqttClient mobileClient = new MqttClient("tcp://MessageSightHostName:MessageSightEndpointPort", clientID);

//Subscribe to the RESPONSE/${ClientID} topic
mobileClient.subscribe("RESPONSE/"+clientID, 0);

To ensure that subscribers cannot access the topics of other subscribers, you can use the topic string variable substitution available in the Eclipse Amlen messaging policies. By using topic string variable substitution you can create a messaging policy with single topic string that includes a user ID, group ID or client ID variable. This substitution ensures that applications can subscribe only to the topic string that matches their user ID, group ID or client ID. For example, a topic string of RESPONSE/${ClientID} is specified in the messaging policy. The application with a client ID of 123 is allowed to subscribe to RESPONSE/123, but is not allowed to subscribe to RESPONSE/456, or RESPONSE/789 because the client ID does not match. For more information about messaging policies and variable substitution, see Authorizing client messaging.

For an example implementation of this pattern, see Scenario 3: Fan out per device notification.

Fan out per device request-reply

One publisher device publishes messages to many topic strings. Each topic string has only one subscriber device. Each subscriber device publishes reply messages on a separate topic string. The publisher device subscribes to all the reply topics.

An example usage of this pattern is a control center that interrogates the state of a device. For example, requesting a temperature reading from a sensor.

For an example implementation of this pattern, see Scenario 4: Fan out per device request-reply.

Fan in per device request-reply

Many publisher devices publish messages to many topic strings. A single subscriber device subscribes to all of the topic strings. The subscriber device publishes reply messages on separate topic strings for each publisher device.

An example usage of this pattern is a device polling a control center for information updates. For example, polling for information about firmware updates.

For an example implementation of this pattern, see Scenario 5: Fan in per device request-reply.