Create mobile apps with HTML5, JavaScript and Visual Studio

30 msdn magazine Windows Azure Insider

decisions and issue commands back to the device. Other worker

roles might be getting weather information from other systems,

such as the National Weather Service. Worker roles may also be

saving all the unprocessed incoming events into a NoSQL data-

base, such as MongoDB.

Figure 1 also shows mobile users interacting with Web roles

to schedule watering. Mobile users can receive push notifi cations

from Windows Azure Mobile Services (WAMS), which supports

all the major notifi cation networks, such as Windows Notifi cation

Services (WNS), Microsoft Push Notification Service (MPNS),

Apple Push Notification Service (APNS) and Google Cloud

Messaging for Android (GCM). WAMS makes it easy to support

Windows, iOS and Android.

You can even envisage a machine-learning part of the archi-

tecture. Windows Azure can support Linux VMs and it’s quite

simple to configure PyMongo (a Python driver for MongoDB)

to read the event stream produced by various devices and use

machine-learning techniques in PyML to fi nd patterns or make

predictions about the event stream data. Based on certain predic-

tions or patterns, the cloud service can choose to send commands

to the device, such as turning on or shutting off the water.

A messaging system that’s the primary endpoint for sending and

receiving data is extensible, because devices can continue to send

a single message stream while new Subscriptions can be added to

a Service Bus Topic for each new system that will consume that

message stream. Th ese systems can be for real-time analytics and

machine-learning as well as other scenarios described earlier.

Communicating with the Cloud

Th ere are four patterns that can be used on the client to communi-

cate with the cloud service. Th ese are outlined in Figure 2.

All four patterns leverage Service Bus Topics and Subscriptions.

Depending on the direction of the communication (device to cloud

service or cloud service to device), the device can either subscribe

to topics or publish to topics. Topics are simply a mechanism to

send messages, while subscriptions are used to consume mes-

sages. You can create fi lter rules for subscriptions to allow more

fi ne-grained control over which messages are retrieved. Worker

roles in the cloud service can be used to publish messages to

topics or to consume messages from subscriptions.

Due to space constraints, we can’t illustrate all of the patterns

here in this article, so we’ll delve into just one. Figure 3 shows a

reference implementation of the Command pattern. It demon-

strates that devices from Buildings 1 and 2 can subscribe to messages

(Commands) and post responses back to topics. Note that worker

roles in the cloud service can publish messages to a Temperature

and Shade Command Topic and that specifi c devices can separately

subscribe to Temperature or Shade Control messages. Service Bus

Topics and Subscriptions can be used in a wide variety of combi-

nations to partition the message fl ow appropriately.

AMQP and Interconnectivity

Th e Windows Azure Service Bus team recently announced support

for the Advanced Message Queuing Protocol (AMQP) 1.0, an open

standard with a binary application layer for message-oriented

middleware. Its main value is that it’s highly interoperable and that

it uses a binary format on the wire to minimize payload size.

AMQP supports reliable message transfer, queuing, routing,

pub/sub and more. Because it’s a wire-level protocol targeting

data streaming across the network, any compliant tool can inter-

act with the data regardless of the implementation language. Th is

enables cross-platform, hybrid applications using an open, stan-

dard protocol. Th e library lets you mix and match

languages, frameworks, and OSes, supporting

.NET, Java, Python and PHP. You’ll find more

information on the Windows Azure Samples page

at aka.ms/G3izk8. Designed to be light and inter-

operable, AMQP is a good fi t for many of today’s

devices needing connectivity to a cloud back end.

However, AMQP is too much software for

today’s Arduino, which lacks the necessary memory,

storage and processing power. Running AMQP

requires support for Transport Layer Security (TLS),

a cryptographic protocol that provides com-

munication security over TCP. TLS uses X.509

certifi cates (asymmetric cryptography) to validate the

identity of communicating parties across the wire.

In addition, the Apache Qpid Proton client-based

messaging library is oft en used to integrate with the

AMQP to simplify communications across routers,

bridges and proxies. All of this raises the question:

How do you support low-end devices connecting

to cloud back ends while enjoying the benefi ts of

the Service Bus messaging infrastructure?

One option is to pay more money and get a

Figure 3 Architecture for the Command Pattern Raspberry PI. If you don’t want to do that, you’ll

Windows Azure

Building 1 Building 2

Device 3 Device 4

Worker Role

for Shade

Response

Service Bus

Temperature and Shade Response Topic

Temperature Response

Subscription

Shade Response

Subscription

Worker Role

for Temperature

Control

Worker Role

for Shade

Control

Worker Role

for Temperature

Response

Temperature Control

Subscription

Shade Control

Subscription

Temperature and Shade Command Topic

Device 1 Device 2