O'Reilly logo

Mobile and Web Messaging by Jeff Mesnil

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 1. Introduction

In this chapter, I present the main concepts of messaging protocols. To illustrate their use on mobile and Web platforms, we will write two applications (one for each messaging protocol that are described, STOMP and MQTT). This chapter will present the overal design of these two applications that will be written in the subsequent chapters.

Messaging Concepts

In the preface, I introduced messaging protocols in two sentences and five concepts:

  • An application produces a message to a destination on a broker.
  • An application subscribes to this same destination to consume the message.

Let’s now define these five concepts:

  1. A message is the data exchanged between applications
  2. A destination is a type of address that is used to exchange messages
  3. A producer is an application that sends messages to a destination
  4. A consumer is an application that consumes messages from a destination
  5. A broker is the server entity that will handle messages from producers and deliver them to the consumers according to their destinations.
Diagram of the messaging concepts
Figure 1-1. Messaging Concepts

The simplicity of messaging can be deceiving but it is this simplicity that allows to use it in powerful ways.

Messaging Terminology

Depending on the messaging protocol or model, the producer is sometimes called sender or publisher. Likewise, the consumer may be called receiver or subscriber.

In this book, I will always use the general terms of producer and consumer.

One key aspect of messaging is that it loosely couples its participants. The producer and consumer know nothing of each other. When one application produces a message, it has no knowledge on when or where the message will be consumed. There may be one or many consumers that will receive the message. It also possible that the message will not be consumed at all if nobody has registered any interest for it.

Likewise, when an application consumes a message, it does not know which application sent it as they never communicate directly. The consumed message could contain enough information to identify the application but that is not required (and more often than not, it is not necessary).

Producers and consumers do not even need to be online at the same time. The producers can send a message and exit. The message will be held by the broker until a consumer subscribes to the same destination. At that moment, the broker will deliver the message to the consumer.

Producers and consumers need to know about the broker to connect to it but they may even not connect to the same broker. A set of brokers can constitute a cluster and messages would flow from one to another before they are finally delivered to a consumer.

Messaging Models

A messaging model describes how the messages will be routed between the producer and consumers.

There are two main messaging models:

  • Point-to-Point
  • Publish/Subscribe

Point-to-Point

In a Point-to-Point messaging model, a message sent by a producer will be routed to a single consumer.

The producer sends a message to a destination identified as a queue in that messaging model. There can be zero, one or many consumers subscribed (or bound) to this queue and the messaging broker will route incoming messages to only one of these consumers to deliver the message. As illustrated in Figure 1-2, when the producer sends a message to the queue, only one of the consumers that are subscribed receives the message.

Diagram of the Point-to-Point Topology
Figure 1-2. Diagram of the Point-to-Point Topology

This messaging model is also called one-to-one: for one message sent by a producer to the queue, there is only one consumer that will receive it.

If there are no consumers bound to the queue, the broker will retain the incoming messages until a consumer subscribes and then deliver the message to this consumer. Some messaging brokers allow to expire messages if they remain in the queue for a certain amount of time. This can be useful to avoid having consumers receive a message corresponding to stale data.

The Point-to-point model is best used when only one consumer must process a message. A queue can be used to load-balance the message processing across different clients and ensure that only one client will receive it.

Publish/Subscribe

In a Publish/Subscribe messaging model (often shortened as pub/sub), a message sent by a producer is routed to many consumers.

The producer sends a message to a destination identified as a topic in that messaging model. There can be zero or many consumers subscribed to this topic and the messaging broker will route incoming message to all these consumers to deliver the message. If there are no consumers bound to the topic, the broker may not retain the incoming messages. As illustrated in Figure 1-3, when the producer sends a message to the topic, all the consumers that are subscribed receive the message.

Diagram of the Point-to-Point Topology
Figure 1-3. Diagram of the Publish/Subscribe Topology

This messaging model is also called one-to-many: for one message sent by a producer to a topic, there are many consumers that may receive it.

When a message is sent to a topic in this model, we often say that it is broadcasted to all consumers as they will all receive it.

Some protocols define the notion of durable subscribers. If a consumer subscribes to the topic as a durable subscriber, the broker will retain messages when the consumer is offline and deliver the messages sent to the topic during its downtime when the consumer comes online again.

The Publish/Subscribe model is particularly suited to send updates. A producer will send a message on the topic with its updated data and any consumer that is subscribed to the topic will be notified of the updates.

Message Representation

Producers and consumers exchange information using messages.

A message is composed of three separate data: destination, headers, and body

Diagram of a Message
Figure 1-4. Diagram of a Message

When a producer sends a message to a destination, the name of the destination is put inside the message. When a consumer receives this message, it can use this information to know which destination held this message. This is especially useful when a consumer is subscribes to many destinations as it helps identify the exchanged data.

A message may also contain headers. Messaging protocols uses headers to add metadata information to the messages. These metadata can be read by the consumers and give addition contextual information to a message. Examples of such metadata are message identifiers (that uniquely identify a message for a broker), timestamp (the date and time it was sent by the producer), redelivered flag (if the message was delivered unsuccessfully a first time and is delivered again), etc. Headers are specific to messaging protocols. Some messaging protocols (such as STOMP) allows the producer to set application-specific headers in addition to the headers defined by the protocol. Other protocols (such as MQTT) does not allow to set application-specific headers. In that case, the producer has to put any application-specific information in the message payload.

Finally, a message can have an optional body (or payload) that contains the data exchanged between the producer and consumer. The type of body depends on the messaging protocols, some defining text payload (such as STOMP) or binary (MQTT). A payload is an opaque blob of content. The broker do not read or modify it when it routes a message.

In most cases, we will only use the message body to pass information using a variety of format (JSON string, simple plain string, array of float values, etc.). However if the protocol permits it, we will also set additional headers to the message to give metadata information about the body (its content type, its length, etc.) or activate some broker features.

Examples

To illustrate the use of messaging protocols on mobile and Web platforms, we will build two set of applications in this book. Each set will be be composed of an iOS application and a web one. The first application will use STOMP and the second one MQTT.

Locations Application Using STOMP

Suppose that we work for a delivery company that uses a fleet of trucks to deliver packages to its clients.

Each truck is responsible for the delivery of packages and they receive orders from their headquarters. To efficiently manage all the trucks, the company headquarter want to monitor the truck’s positions and be able to send them orders on-the-go.

We will build a very simple application named Locations that looks similar to this example.

The “truck” will use an iOS application to broadcast the device’s geolocation data using its GPS sensor and display text messages that it receives from the headquarters. The “headquarter” will use a Web application to display the locations of all the “trucks” on a map. It will also be used to send text messages to a given truck on their devices:

  1. In Chapter 2, we will write the Locations iOS application using the STOMP protocol to send GPS data and receive text from an iOS device.
  2. In Chapter 3, we will write the Web application using STOMP protocol over Web Sockets to receive GPS data in a Web browser and send text to the devices.
Diagram of the Locations application with two devices, AAA and BBB, and two web applications
Figure 1-5. Diagram of the Locations application with two devices, AAA and BBB, and two web applications.

Before introducing STOMP, the messaging protocol that will be used by the application, we can already define the application’s messaging models and how the different parts of the application will exchange messages.

Locations Messaging Models

In this application, we will use two destinations, one with a Publish/Subscribe model to broadcast the device GPS data and one with a Point-to-Point model for the text messages:

  • device.XXX.location is the topic to broadcast its GPS geolocation data where XXX is the device identifier (Publish/Subscribe model)
  • device.XXX.text is the queue to receive simple text message (Point-to-Point model)

A topic is used to send the GPS data as this allows potentially many consumers to receive the information. However a queue is used to handle the device’s text as only one single device will consume messages from this destination.

Each device (identified by an unique identifier XXX) running the Locations application will be:

  • a producer of messages to the topic device.XXX.location
  • the only consumer of messages from the queue device.XXX.text

Conversely, the Web application will be:

  • a consumer of messages from all the topics of the form device.XXX.location
  • a producer of message to all the queues of the form device.XXX.text

Locations Message Representation

There will be two types of exchanged messages:

  • one to represent GPS data (exhanged on the topics device.XXX.location)
  • one to represent orders (exchanged on the queues device.XXX.text)

The Locations iOS application will send the GPS data using a JSON representation in the message payload:

Example 1-1. Geolocation Message Payload
{
  "deviceID": "BBB",1
  "lat": 48.8581,2
  "lng": 2.2946,3
  "ts": "2013-09-23T08:43Z"4
}
1

deviceID is the identifier of the device that sends its position

2

lat is a number representing the position’s latitude

3

lng is a number representing the position’s longitude

4

ts is a string representing the time when the position was taken (using the ISO 8601 format)

The text messages that will be consumed by the Locations iOS application will be represented as a simple plain text string.

Example 1-2. Text Message Payload
"Where are you heading to?"

A more realistic representation of this message would also contain additional information such the identifier of the headquarter sending the message, etc. We are using a plain text version as this format is enough to provide a first version.

With the messaging topology and data representation known, we can now refine the Locations application diagram.

Diagram of the Locations application
Figure 1-6. Diagram of the Locations application with its messaging models and representations

Motions Application Using MQTT

Most mobile devices contain sensor that allows to track the device motions (and to a certain extent the motion of its owner). Using additional sensors, we could even imagine having access to the owner’s health data (heart rate, hydration, blood glucose level, etc.). This type of information could be sent to a centralized application that would be able to track the data and extract personal information about them to report to the owner.

We will write a simple application, Motions that follows this model to illustrate the use of MQTT protocol. The iOS application will track the device motion and change its background color to “alert” its user when an alert message is received.

Device motion will be represented by three values corresponding to its pitch, roll and yaw values as shown in the illustration below.

The pitch
Figure 1-7. The pitch, roll and yaw values represents the device motion.

The pending Web application will display the motions of all devices that broadcast them and be able to send alert messages to them:

  1. In (to come), we will write the Motions iOS application using the MQTT protocol to send data about the device motions and receive alerts.
  2. In (to come), we will write a Web application using MQTT protocol over Web Sockets to receive all the device motions data and display them. The Web application will also be able to send alert messages to any devices sending its motions data.
Diagram of the +Motions+ application
Figure 1-8. The Motions application with two clients, AAA and BBB and two Web applications monitoring them.

Motions Messaging Models

In this application we will use two destination with the Publish/Subscribe model:

  • /mwm/XXX/motion (where XXX is the device identifier) is the topic to broadcast the device motion data (Publish/Subscribe model)
  • /mwm/XXX/alert is the topic to exchange alert messages for a given device (Publish/Subscribe model)

Each device running the Motions application will be:

  • a producer of messages to the topic /mwm/XXX/motion
  • a consumer of messages from the topic /mwm/XXX/alert

Conversely, the Web application will be:

  • a consumer of messages from all the topics of the form /mwm/XXX/motion
  • a producer of message to all the topics of the form /mwm/XXX/alert

Note

MQTT only supports the Publish/Subscribe messaging model. Ideally, the alert destination would be better modeled as a queue (one per device). Since MQTT does not have support for queues, we will work around that by using one topic for each device and only have the corresponding device subscribes to it.

Motions Message Representation

There will be two types of exchanged messages:

  • one to represent device motion data (exhanged on the topics /mwm/XXX/motion)
  • one to represent alerts (exchanged on the topics /mwm/XXX/alert)

The Motions iOS application will send the device motions data in a binary message where its payload will be composed of three 64-bit floats representing the device’s pitch, roll and yaw values.

Example 1-3. Device Motion Message Paylaod
<< 1.6 -0.1 0.8 >> 1
1

The message is composed of three 64-bit floats for the pitch, roll, and yaw values

The alert messages that will be consumed by the Motions iOS application will be represented as a simple plain text string corresponding to a color. The Motions application will use this payload to change temporarily its background color to alert the user.

Example 1-4. Alert Message Payload
"red" 1
1

The message is composed of a string containing the name of a simple color.

With the messaging topology and data representation known, we can now refine the Motions application diagram.

Diagram of the Motions application
Figure 1-9. Diagram of the Motions application with its messaging models and representations.

Summary

In this chapter, we learnt about the messaging protocols and how they differ from request/reply protocols. We introduced two messaging models - Point-to-Point and Publish/Subscribe - and the parts that compose a message - destination, headers, and payload.

We have also described the two applications with their messaging models and representation that will be written in the subsequent chapters: the Locations application that uses STOMP and the Motions applications that uses MQTT.

In the next chapter, we will start writing the Locations application running on iOS devices. If you are more interested by learning about MQTT, you can go directly to (to come) to start writing the Motions application.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required