Chapter010-Introduction.html

<section class="pagenumrestart" data-type="chapter" id="ch_introduction" xmlns="http://www.w3.org/1999/xhtml">
<h1>Introduction</h1>

<p class="lead">In this chapter, I present the main concepts of messaging protocols. To illustrate their use on mobile and web platforms, we will <a contenteditable="false" data-primary="messaging" data-secondary="concepts" data-type="indexterm">&nbsp;</a>write one application for each messaging protocol described (i.e., one application for STOMP and another for MQTT). This chapter provides an overview of the overall design of the two applications that will be written in the subsequent chapters.</p>

<section data-type="sect1" id="_messaging_concepts">
<h1>Messaging Concepts</h1>

<p>In the Preface, I introduced messaging protocols in two sentences and five concepts:</p>

<ul>
	<li>
	<p>An application <em>produces</em> a <em>message</em> to a <em>destination</em> on a <em>broker</em>.</p>
	</li>
	<li>
	<p>An application subscribes to this same destination to <em>consume</em> the message.</p>
	</li>
</ul>

<p>Let&rsquo;s now define these five concepts, which are illustrated in <a data-type="xref" href="img_preface_messaging_concepts">img_preface_messaging_concepts</a>:</p>

<dl>
	<dt>Message</dt>
	<dd>The data exchanged between <a contenteditable="false" data-primary="messages" data-secondary="defined" data-type="indexterm">&nbsp;</a>applications</dd>
	<dt>Destination</dt>
	<dd>A type of address that is used to<a contenteditable="false" data-primary="destinations" data-secondary="defined" data-type="indexterm">&nbsp;</a> exchange messages</dd>
	<dt>Producer</dt>
	<dd>An application that sends <a contenteditable="false" data-primary="producers" data-secondary="defined" data-type="indexterm">&nbsp;</a>messages <em>to</em> a destination</dd>
	<dt>Consumer</dt>
	<dd>An application that <a contenteditable="false" data-primary="consumers" data-secondary="defined" data-type="indexterm">&nbsp;</a>consumes messages <em>from</em> a destination</dd>
	<dt>Broker</dt>
	<dd>The server entity that will handle <a contenteditable="false" data-primary="brokers" data-secondary="defined" data-type="indexterm">&nbsp;</a>messages from producers and deliver them to the consumers according to their destinations</dd>
</dl>

<figure id="img_preface_messaging_concepts"><img alt="Diagram of the messaging concepts" src="images/mawm_0101.png" />
<figcaption>Messaging concepts</figcaption>
</figure>

<p>The simplicity of messaging can be deceiving, but it is this simplicity that allows us to use it in powerful ways.</p>

<div data-type="note">
<p>Depending on the messaging protocol or model, the <em>producer</em> is sometimes called <em>sender</em> or <em>publisher</em>. <a contenteditable="false" data-primary="producers" data-secondary="alternate names for" data-type="indexterm">&nbsp;</a>Likewise, the <em>consumer</em> may be called <em>receiver</em> or <em>subscriber</em>.<a contenteditable="false" data-primary="consumers" data-secondary="alternate names for" data-type="indexterm">&nbsp;</a></p>

<p>In this book, I will always use the general terms <em>producer</em> and <em>consumer</em>.</p>
</div>

<p>One key aspect of messaging is that it loosely couples its participants. The producer and consumer know nothing about each other.<a contenteditable="false" data-primary="messaging" data-secondary="concepts" data-tertiary="loose coupling of participants" data-type="indexterm">&nbsp;</a> When one application produces a message, it has no knowledge of when or where the message will be consumed. There may be one or many consumers that will receive the message. It is also possible that the message will not be consumed at all if nobody has registered any interest for it.</p>

<p>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).</p>

<p>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.</p>

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

<section data-type="sect1" id="_messaging_models">
<h1>Messaging Models</h1>

<p>A messaging model describes how <a contenteditable="false" data-primary="messaging models" data-see="models, messaging" data-type="indexterm">&nbsp;</a>the messages will be routed between the producer and consumers.<a contenteditable="false" data-primary="models, messaging" data-type="indexterm">&nbsp;</a></p>

<p>There are two main messaging models:</p>

<ul>
	<li>
	<p>Point-to-point</p>
	</li>
	<li>
	<p>Publish/subscribe</p>
	</li>
</ul>

<section data-type="sect2" id="_point_to_point">
<h2>Point-to-Point</h2>

<p>In a point-to-point messaging model, a <a contenteditable="false" data-primary="models, messaging" data-secondary="point-to-point" data-type="indexterm">&nbsp;</a>message sent by a producer will be routed to a single consumer.<a contenteditable="false" data-primary="point-to-point messaging model" data-type="indexterm">&nbsp;</a></p>

<p>The producer sends a message to a destination identified as a <em>queue</em> in that messaging model.<a contenteditable="false" data-primary="queues" data-type="indexterm">&nbsp;</a> There can be zero, one, or many consumers subscribed (or <em>bound</em>) to this queue and the messaging broker will route incoming messages to only one of these consumers to deliver the message. As illustrated in <a data-type="xref" href="#img_intro_point_to_point">#img_intro_point_to_point</a>, when the producer sends a message to the queue, only one of the consumers that are subscribed receives the message.</p>

<figure id="img_intro_point_to_point"><img alt="Diagram of the Point-to-Point Topology" src="images/mawm_0102.png" />
<figcaption>Diagram of the point-to-point topology</figcaption>
</figure>

<p>This is also called a <em>one-to-one messaging model</em>: for <em>one</em> message sent by a producer to the queue, there is only <em>one</em> consumer that will receive it.<a contenteditable="false" data-primary="one-to-one messaging model" data-see-also="point-to-point messaging model" data-type="indexterm">&nbsp;</a></p>

<p>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 messages to <em>expire</em> 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.</p>

<p>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.</p>
</section>

<section data-type="sect2" id="_publish_subscribe">
<h2>Publish/Subscribe</h2>

<p>In a publish/subscribe messaging<a contenteditable="false" data-primary="models, messaging" data-secondary="publish/subscribe" data-type="indexterm">&nbsp;</a> model (often shortened as pub/sub), a message sent by a producer is routed to many consumers.<a contenteditable="false" data-primary="publish/subscribe messaging model" data-type="indexterm">&nbsp;</a></p>

<p>The producer sends a message to a destination identified as a <em>topic</em>.<a contenteditable="false" data-primary="topics" data-type="indexterm">&nbsp;</a> There can be zero or many consumers subscribed to this topic and the messaging broker will route incoming message to <em>all</em> these consumers to deliver the message. If there are no consumers bound to the topic, the broker may <em>not</em> retain the incoming messages. As illustrated in <a data-type="xref" href="#img_intro_pub_sub">#img_intro_pub_sub</a>, when the producer sends a message to the topic, all the consumers that are subscribed receive the message.</p>

<figure id="img_intro_pub_sub"><img alt="Diagram of the Point-to-Point Topology" src="images/mawm_0103.png" />
<figcaption>Diagram of the publish/subscribe topology</figcaption>
</figure>

<p>This is also called a <em>one-to-many</em> messaging model: for <em>one</em> message sent by a producer to a topic,<a contenteditable="false" data-primary="one-to-many messaging model" data-see-also="publish/subscribe messaging model" data-type="indexterm">&nbsp;</a> there are <em>many</em> consumers that may receive it.</p>

<p>When a message is sent to a topic in this model, we often say that it is <em>broadcast</em> to all consumers, as they will all receive it.</p>

<p>Some protocols define the notion of <em>durable subscribers</em>. <a contenteditable="false" data-primary="durable subscribers" data-type="indexterm">&nbsp;</a>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.&nbsp;</p>

<p>The publish/subscribe model is particularly suited to send updates.<a contenteditable="false" data-primary="updates, using publish/subscribe model for" data-type="indexterm">&nbsp;</a> 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.</p>
</section>
</section>

<section data-type="sect1" id="_message_representation">
<h1>Message Representation</h1>

<p>Producers and consumers exchange information using messages.</p>

<p>As illustrated in <a data-type="xref" href="img_intro_message_representation">Figure 1-4</a>, a message is composed <a contenteditable="false" data-primary="messages" data-secondary="parts of" data-type="indexterm">&nbsp;</a>of three separate pieces of data: destination, headers, and body.</p>

<figure id="img_intro_message_representation"><img alt="Diagram of a Message" src="images/mawm_0104.png" />
<figcaption>Diagram of a message</figcaption>
</figure>

<p>When a producer sends a message to a <em>destination</em>, the name of the destination is put inside the message.<a contenteditable="false" data-primary="destinations" data-secondary="in a message" data-type="indexterm">&nbsp;</a> 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 subscribed to many destinations, as it helps identify the exchanged data.</p>

<p>A message may also contain <em>headers</em>. <a contenteditable="false" data-primary="headers" data-secondary="in messages" data-type="indexterm">&nbsp;</a>Messaging protocols use headers to add metadata information to the messages.<a contenteditable="false" data-primary="metadata in message headers" data-type="indexterm">&nbsp;</a> This metadata can be read by the consumers and gives additional contextual information to a message. Examples of such metadata include message identifiers (that uniquely identify a message for a broker), timestamps (the date and time it was sent by the producer), and redelivered flags (if the message is being delivered again after a failed first attempt). Headers are specific to messaging protocols. Some messaging protocols (such as STOMP) allow the producer to set application-specific headers in addition to the headers defined by the protocol.<a contenteditable="false" data-primary="application-specific headers in messages" data-type="indexterm">&nbsp;</a> Other protocols (such as MQTT) do not allow producers to set application-specific headers. In that case, the producer has to put any application-specific information in the message payload.</p>

<p>Finally, a message can have an optional <em>body</em> (or payload) that contains the data exchanged between the producer and consumer.<a contenteditable="false" data-primary="body (messages)" data-type="indexterm">&nbsp;</a> The type of body depends on the messaging protocols, some defining text <a contenteditable="false" data-primary="payload" data-see-also="body" data-type="indexterm">&nbsp;</a>payload (such as STOMP) or binary (MQTT). A payload is an <em>opaque blob of content</em>. The broker does not read or modify it when it routes a message.</p>

<p>In most cases, we will only use the message body to pass information using a variety of formats (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.</p>
</section>

<section data-type="sect1" id="_examples">
<h1>Examples</h1>

<p>To illustrate the use of messaging protocols on mobile and web platforms, we will build two sets 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 will use MQTT.<a contenteditable="false" data-primary="iOS applications" data-secondary="Locations application using STOMP (example)" data-type="indexterm">&nbsp;</a></p>

<section data-type="sect2" id="ch_introduction_stomp_example">
<h2>Locations Application Using STOMP</h2>

<p>Suppose that we work for a delivery company that uses a fleet of trucks to deliver packages to its clients.<a contenteditable="false" data-primary="STOMP" data-secondary="Locations application using (example)" data-type="indexterm">&nbsp;</a></p>

<p>Each truck is responsible for the delivery of packages and the drivers receive orders from the company's headquarters. To efficiently manage all the trucks, the company wants to monitor the truck&rsquo;s positions and be able to adjust the orders as necessary.</p>

<p>We will build a very simple application named Locations that looks similar to this example (see <a data-type="xref" href="img_example_app_1">img_example_app_1</a>).</p>

<p>The &quot;truck&quot; will use an iOS application to broadcast the device&rsquo;s geolocation data using its GPS sensor and display text messages that it receives from the headquarters.&nbsp; The &quot;headquarters&quot; will use a web application to display the location of all the trucks on a map.<a contenteditable="false" data-primary="web applications" data-secondary="Locations application (example)" data-type="indexterm">&nbsp;</a> It will also be used to send text messages to a given truck on their devices:</p>

<ul>
	<li>
	<p>In <a data-type="xref" href="#ch_mobile_stomp">#ch_mobile_stomp</a>, we will write the Locations iOS application using the STOMP protocol to send GPS data and receive text from an iOS device.</p>
	</li>
	<li>
	<p>In <a data-type="xref" href="#ch_web_stomp">#ch_web_stomp</a>, we will write the web application using the STOMP protocol over Web Sockets to receive GPS data in a web browser and send text to the devices.</p>
	</li>
</ul>

<p>Before introducing STOMP, the messaging protocol that will be used by the application, we can already define the application&rsquo;s messaging models and how the different parts of the application will exchange messages.</p>

<section data-type="sect3" id="ch_introduction_stomp_example_topology">
<h3>Messaging models for the Locations application</h3>

<p>In this application, we will use two destinations, one with a<a contenteditable="false" data-primary="publish/subscribe messaging model" data-secondary="in Locations application (example)" data-type="indexterm">&nbsp;</a> publish/subscribe model to<a contenteditable="false" data-primary="models, messaging" data-secondary="in Locations application (example)" data-type="indexterm">&nbsp;</a> broadcast the device GPS data and one with a point-to-point model <a contenteditable="false" data-primary="point-to-point messaging model" data-secondary="for text messages in Locations application (example)" data-type="indexterm">&nbsp;</a>for the text messages:</p>

<ul>
	<li>
	<p><code>device.XXX.location</code> is the <em>topic</em> to broadcast its GPS geolocation data where <code>XXX</code> is the device identifier (publish/subscribe model)</p>
	</li>
	<li>
	<p><code>device.XXX.text</code> is the <em>queue</em> to receive simple text messages (point-to-point model)</p>
	</li>
</ul>

<p>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&rsquo;s text as only one single device will consume messages from this destination.</p>

<figure id="img_example_app_1"><img alt="Diagram of the Locations application with two devices, AAA and BBB, and two web applications" src="images/mawm_0105.png" />
<figcaption>Diagram of the Locations application with two devices, AAA and BBB, and two web applications</figcaption>
</figure>


<p>Each device (identified by a unique identifier <code>XXX</code>) running the Locations application will be:</p>

<ul>
	<li>
	<p>A <em>producer</em> of messages to the topic <code>device.XXX.location</code></p>
	</li>
	<li>
	<p>The only <em>consumer</em> of messages from the queue <code>device.XXX.text</code></p>
	</li>
</ul>

<p>Conversely, the web application will be:</p>

<ul>
	<li>
	<p>A <em>consumer</em> of messages from <em>all</em> the topics of the form <code>device.XXX.location</code></p>
	</li>
	<li>
	<p>A <em>producer</em> of message to <em>all</em> the queues of the form <code>device.XXX.text</code></p>
	</li>
</ul>
</section>

<section data-type="sect3" id="ch_introduction_stomp_example_message">
<h3>Message representation for the Locations application</h3>

<p>There will be two types of <a contenteditable="false" data-primary="messages" data-secondary="in Locations application (example)" data-type="indexterm">&nbsp;</a>exchanged messages:</p>

<ul>
	<li>
	<p>One to represent GPS data (exchanged on the topics <code>device.XXX.location</code>)</p>
	</li>
	<li>
	<p>One to represent orders (exchanged on the queues <code>device.XXX.text</code>)</p>
	</li>
</ul>

<p>The Locations iOS application will send the GPS data using a JSON representation in <a contenteditable="false" data-primary="JSON" data-secondary="message payload in Locations iOS application" data-type="indexterm">&nbsp;</a>the message payload (<a data-type="xref" href="ex_example_gps_data">ex_example_gps_data</a>).</p>

<div data-type="example" id="ex_example_gps_data">
<h5>Geolocation message payload</h5>

<pre data-type="programlisting">
{
  &quot;deviceID&quot;: &quot;BBB&quot;, <a class="co" href="#callout_ch1-co-1" id="co_ch1-co-1"><img alt="1" src="images/callouts/1.png" /></a>
  &quot;lat&quot;: 48.8581, <a class="co" href="#callout_ch1-co-2" id="co_ch1-co-2"><img alt="2" src="images/callouts/2.png" /></a>
  &quot;lng&quot;: 2.2946, <a class="co" href="#callout_ch1-co-3" id="co_ch1-co-3"><img alt="3" src="images/callouts/3.png" /></a>
  &quot;ts&quot;: &quot;2013-09-23T08:43Z&quot; <a class="co" href="#callout_ch1-co-4" id="co_ch1-co-4"><img alt="4" src="images/callouts/4.png" /></a>
}</pre>

<dl class="calloutlist">
	<dt><a class="co" href="#co_ch1-co-1" id="callout_ch1-co-1"><img alt="1" src="images/callouts/1.png" /></a></dt>
	<dd>
	<p><code>deviceID</code> is the identifier of the device that sends its position</p>
	</dd>
	<dt><a class="co" href="#co_ch1-co-2" id="callout_ch1-co-2"><img alt="2" src="images/callouts/2.png" /></a></dt>
	<dd>
	<p><code>lat</code> is a number representing the position&rsquo;s <em>latitude</em></p>
	</dd>
	<dt><a class="co" href="#co_ch1-co-3" id="callout_ch1-co-3"><img alt="3" src="images/callouts/3.png" /></a></dt>
	<dd>
	<p><code>lng</code> is a number representing the position&rsquo;s <em>longitude</em></p>
	</dd>
	<dt><a class="co" href="#co_ch1-co-4" id="callout_ch1-co-4"><img alt="4" src="images/callouts/4.png" /></a></dt>
	<dd>
	<p><code>ts</code> is a string representing the time when the position was taken (using the <a href="http://en.wikipedia.org/wiki/ISO_8601">ISO 8601</a> format)</p>
	</dd>
</dl>
</div>

<p>The text messages that will be consumed by the Locations iOS application will be represented as a simple plain-text string, as shown in .</p>

<div data-type="example" id="heading_to">
<h5>Text message payload</h5>

<pre data-type="programlisting">
&quot;Where are you heading to?&quot;</pre>

<p>A more realistic representation of this message would also contain additional information such as the identifier of the headquarters sending the message. We are using a plain-text version, because this format is sufficient for our preliminary example.</p>

<p>With the messaging topology and data representation known, we can now refine the Locations application diagram (<a data-type="xref" href="img_example_app_2">img_example_app_2</a>).</p>

<figure id="img_example_app_2"><img alt="Diagram of the Locations application" src="images/mawm_0106.png" />
<figcaption>Diagram of the Locations application with its messaging models and representations</figcaption>
</figure>
</div>
</section>
</section>

<section data-type="sect2" id="ch_introduction_mqtt_example">
<h2>Motions Application Using MQTT</h2>

<p>Most mobile devices contain a sensor that allows for tracking the device motions (and to a certain extent, the motions of the user).<a contenteditable="false" data-primary="MQTT" data-secondary="Motions application using (example)" data-type="indexterm">&nbsp;</a> Using additional sensors, we could even conceivably monitor the user&rsquo;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 send alerts to the user when necessary.</p>

<p>Following this model, we will write a simple application called Motions to illustrate the use of the MQTT protocol. The iOS application will track the device motion and change its background color to advise its user when an alert message is received.<a contenteditable="false" data-primary="iOS applications" data-secondary="Motions application (example)" data-type="indexterm">&nbsp;</a></p>

<p>Device motion will be represented by three values corresponding to<a contenteditable="false" data-primary="pitch, roll, and yaw values" data-type="indexterm">&nbsp;</a> its pitch, roll, and yaw values, as shown in <a data-type="xref" href="img_mqtt_example_app_0">img_mqtt_example_app_0</a>.</p>

<figure id="img_mqtt_example_app_0"><img alt="The pitch, roll and yaw values represents the device motion" src="images/mawm_0107.png" />
<figcaption>The pitch, roll, and yaw values represent the device motion</figcaption>
</figure>

<p>The pending web application will display the motions of all devices that broadcast them and be able to send alert messages to them (<a data-type="xref" href="img_mqtt_example_app_1">img_mqtt_example_app_1</a>):</p>

<ul>
	<li>
	<p>In <a data-type="xref" href="#ch_mobile_mqtt">#ch_mobile_mqtt</a>, we will write the Motions iOS application using the MQTT protocol to send data about the device motions and receive alerts.</p>
	</li>
	<li>
	<p>In <a data-type="xref" href="#ch_web_mqtt">#ch_web_mqtt</a>, we will write a web application <a contenteditable="false" data-primary="web applications" data-secondary="Motions application (example)" data-type="indexterm">&nbsp;</a>using the MQTT protocol over Web Sockets to receive all the device motions data and display them. The web application will also send alert messages to any devices sending its motions data.</p>
	</li>
</ul>

<figure id="img_mqtt_example_app_1"><img alt="Diagram of the +Motions+ application" src="images/mawm_0108.png" />
<figcaption>The Motions application with two clients, AAA and BBB, and two web applications monitoring them</figcaption>
</figure>

<section data-type="sect3" id="ch_introduction_mqtt_example_topology">
<h3>Messaging models for the Motions application</h3>

<p>In this application, we will use two<a contenteditable="false" data-primary="publish/subscribe messaging model" data-secondary="in Motions application (example)" data-type="indexterm">&nbsp;</a> destinations <a contenteditable="false" data-primary="models, messaging" data-secondary="in Motions application (example)" data-type="indexterm">&nbsp;</a>with the publish/subscribe model:</p>

<ul>
	<li>
	<p><code>/mwm/XXX/motion</code> (where <code>XXX</code> is the device identifier) is the topic to broadcast the device motion data (publish/subscribe model)</p>
	</li>
	<li>
	<p><code>/mwm/XXX/alert</code> is the topic to exchange alert messages for a given device (publish/subscribe model)</p>
	</li>
</ul>

<p>Each device running the Motions application will be:</p>

<ul>
	<li>
	<p>A <em>producer</em> of messages to the topic <code>/mwm/XXX/motion</code></p>
	</li>
	<li>
	<p>A <em>consumer</em> of messages from the topic <code>/mwm/XXX/alert</code></p>
	</li>
</ul>

<p>Conversely, the web application will be:</p>

<ul>
	<li>
	<p>A <em>consumer</em> of messages from all the topics of the form <code>/mwm/XXX/motion</code></p>
	</li>
	<li>
	<p>A <em>producer</em> of message to all the topics of the form <code>/mwm/XXX/alert</code></p>
	</li>
</ul>

<div data-type="note">
<p>MQTT only supports the publish/subscribe messaging model. Ideally, the alert destination would be better modeled as a queue (one per device). MQTT <a contenteditable="false" data-primary="queues" data-secondary="MQTT and" data-type="indexterm">&nbsp;</a>does not have support for queues, so we will work around that by using one topic for each device and only have the corresponding device subscribe to it.</p>
</div>
</section>

<section data-type="sect3" id="ch_introduction_mqtt_example_message">
<h3>Message representation for the Motions application</h3>

<p>There will be two types of<a contenteditable="false" data-primary="messages" data-secondary="in Motions application (example)" data-type="indexterm">&nbsp;</a> exchanged messages:</p>

<ul>
	<li>
	<p>One to represent device motion data (exchanged on the topics <code>/mwm/XXX/motion</code>)</p>
	</li>
	<li>
	<p>One to represent alerts (exchanged on the topics <code>/mwm/XXX/alert</code>)</p>
	</li>
</ul>

<p>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&rsquo;s pitch, roll, and yaw values (<a data-type="xref" href="ex_example_motion_data">ex_example_motion_data</a>).</p>

<div data-type="example" id="ex_example_motion_data">
<h5>Device motion message paylaod</h5>

<pre data-type="programlisting">
&lt;&lt; 1.6 -0.1 0.8 &gt;&gt; <a class="co" href="#callout_ch1-co-5" id="co_ch1-co-5"><img alt="1" src="images/callouts/1.png" /></a>
</pre>

<dl class="calloutlist">
	<dt><a class="co" href="#co_ch1-co-5" id="callout_ch1-co-5"><img alt="1" src="images/callouts/1.png" /></a></dt>
	<dd>
	<p>The message is composed of three 64-bit floats for the pitch, roll, and yaw values.</p>
	</dd>
</dl>
</div>

<p>The alert messages that <a contenteditable="false" data-primary="alert messages consumed by Motions iOS application (example)" data-type="indexterm">&nbsp;</a>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 temporarily change its background color to alert the user (<a data-type="xref" href="ex_example_alert_data">ex_example_alert_data</a>).</p>

<div data-type="example" id="ex_example_alert_data">
<h5>Alert message payload</h5>

<pre data-type="programlisting">
&quot;red&quot; <a class="co" href="#callout_ch1-co-6" id="co_ch1-co-6"><img alt="1" src="images/callouts/1.png" /></a></pre>

<dl class="calloutlist">
	<dt><a class="co" href="#co_ch1-co-6" id="callout_ch1-co-6"><img alt="1" src="images/callouts/1.png" /></a></dt>
	<dd>
	<p>The message is composed of a string containing the name of a simple color.</p>
	</dd>
</dl>
</div>

<p>With the messaging topology and data representation known, we can now refine the Motions application diagram (<a data-type="xref" href="img_mqtt_example_app_2">img_mqtt_example_app_2</a>).</p>

<figure id="img_mqtt_example_app_2"><img alt="Diagram of the Motions application" src="images/mawm_0109.png" />
<figcaption>Diagram of the Motions application with its messaging models and representations</figcaption>
</figure>
</section>
</section>
</section>

<section data-type="sect1" id="_summary">
<h1>Summary</h1>

<p>In this chapter, we learned 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).</p>

<p>We also took a look at the two applications that will be written in the subsequent chapters&mdash;the Locations application (which uses STOMP) and the Motions application (which uses MQTT)&mdash;and established the messaging models and representation that they will use.</p>

<p>In the next chapter, we will start writing the Locations iOS application. If you are more interested in learning about MQTT, you can go directly to <a data-type="xref" href="#ch_mobile_mqtt">#ch_mobile_mqtt</a> to start writing the Motions application.</p>
</section>
</section>