Create mobile apps with HTML5, JavaScript and Visual Studio

msdnmagazine.com February 2014 29

lot of money if there are many chatty devices. Furthermore, more

data means more CPU use, which means more energy, a precious

resource on a mobile device. Most battery-powered devices equipped

with a Wi-Fi transmitter and a SIM card need to enter a low-power

“sleep” mode during periods when they aren’t transmitting or

receiving data. Th e IEEE 802.11 standard defi nes this power-save

polling feature. Th e data gets buff ered when the device is sleeping.

Once it awakens, the buff ered data is delivered. Chatty networks

fi ll buff ers and prematurely awaken sleeping devices.

HTTP request/reply approaches can be ridiculously wasteful,

given the size of the payload relative to the overall HTTP request-

response infrastructure. Suppose a device simply needs to report

a number to the cloud, such as temperature, pressure or GPS

coordinate. Th at binary data is probably only a few bytes in size,

but the HTTP POST is generally at least 500 to 1,000 bytes, with

the request header alone ranging from 200 to 2,000 bytes. Sure,

some developers use tricks, like stuffi ng everything into the HTTP

header to avoid the overhead of the body part of the HTTP request.

But that isn’t suffi cient, and the size of the HTTP request only gets

bigger when you have to transmit security credentials.

Here’s some simple math to convince you. Imagine your device

has to send temperature data every 5 seconds and the payload for

the temperature data is a generous 20 bytes. In a 24-hour period,

the temperature data by itself would transmit from the device to

the cloud about 350,000 bytes. If you add in the HTTP request/

response envelope, you raise each transmission by 800 bytes, a

factor of 41, sending more than 14MB to the cloud instead of just

the 350KB of temperature data. Th is can get prohibitively expen-

sive if you’re supporting thousands of devices.

Perhaps the biggest misconception is that VPNs are inherently

safe. The reality is that VPN networks can be risky, especially

when devices connected to a VPN are outside the manufacturer’s

or operator’s immediate physical control. Once a single device is

breached, all devices connected to the same VPN are vulnerable.

Once an untrusted user gets access to a connected device, he or she

can use the device to explore and attack your internal resources.

Despite these shortcomings, VPNs are often the only option

off ered by many carriers.

The Windows Azure Service Bus Approach

Windows Azure Service Bus off ers some great solutions to these

challenges. Leveraging the Service Bus is more secure, because the

device is only an endpoint on the Internet where it can place mes-

sages into a queue. Th e device can’t reach other protected network

resources inside cloud services. In addition, using the Service Bus

for device connectivity costs less in terms of power, because the

device can sleep more oft en, waking up periodically to pull any

waiting messages from the queue.

Th e Service Bus provides even more value because it can:

• Decouple device communication and interaction from

your cloud service

• Enable load leveling and load balancing among several

instances of your back-end service

• Identify duplicate messages


• Gather messages into logical groups (called Sessions)
  
  
  • Implement transactional behavior and atomicity
  
  
  • Support ordered delivery of messages and provide a
  
  
  
  

time-to-live for each message

• Extend to publish-subscribe scenarios easily using

Topics and Subscriptions

To get a more concrete idea of how a device connects to and

communicates with the cloud back end, take a look at Figure 1,

which depicts how a special-purpose device might fi t into a bigger

architecture. We’ll use the canonical example of OpenSprinkler, an

open source, Internet-based sprinkler/irrigation valve controller

that’s capable of checking the weather before deciding to turn on

the water. It’s built using Arduino parts. Note in Figure 1 that the

Arduino controls the sprinkler system using a home network as

the Internet connection and communicates with a cloud back end.

Solving Connectivity Problems

Windows Azure Service Bus does a great job of solving the address-

ability and network connectivity challenges. Th e Arduino device

would probably sit behind some NAT layer, making it diffi cult to

reach from a cloud service. Fortunately, the Service Bus dramati-

cally simplifi es connectivity by acting as a relay service and serving

as a proxy for a cloud back end. Moreover, it can provide Queues,

Topics and Subscriptions, which enables it to act as an event hub

for messages sent between the cloud and the device. Th e decoupled

nature of a queue acting as a relay lets the device asynchronously

send and receive messages to and from the cloud, even if only occa-

sionally connected. For security, the device can be authenticated with

SharedAccessSignature, SharedSecret, SAML or SimpleWebToken.

Notice in Figure 1 that one or more worker roles may be reading

from the Service Bus message queue. Worker roles can make

Pattern Summary Example

Telemetry A client device sends

data (one way) to a

cloud service.

A device publishes messages about

the temperature to Topics. The

cloud service subscribes to some or

all of these temperature messages.

Inquiry A client device sends

a query to the cloud

service and receives

a response.

A device inquires about upcoming

weather conditions by posting

a weather inquiry to a topic.

The cloud service subscribes to

inquiries and posts a message

response to a topic of its own to

which the device subscribes.

Command A cloud service issues

a command to a

client device and

the client device

returns a success or

failure response.

The cloud service publishes a

temperature message/command

to a topic to which a device

subscribes. The device then turns

water on or off and sends a reply

back to the cloud service by

posting a response to a topic.

Notifi cation A cloud service issues

a one-way out-of-

band notifi cation to

a client device that’s

important for the

device’s operation.

The cloud service sends a time-

reset message to a device by

publishing the message to a topic

to which that device subscribes.

Figure 2 Four Patterns for Device-Cloud Service Communication