Connecting a device or sensor to the Internet where the data can be digested can be difficult. Indeed, great analytical tools exist, but getting data to these tools can be a daunting task. The data needs to be parked somewhere where it can be appropriately digested.

Most modern tools rely on Web services to plug directly into the extended Internet. In order to connect a device or sensor to the Internet, we need to know first where we can “park” the data, what Web services are, how to use them and how to apply Web services to a remote device or sensor.

To begin, we describe a set of functional capabilities necessary to connect the device to the needed application. Keep in mind that a device may be anything from a meter or thermostat to a engine or machine. It may also be something fixed like a tank or containment vessel used for storage and dispensing.

On the flip side, the application may be any system used for projecting data. It may be a mobile application housed on a smart phone, a Web based dashboard-style portal, an ERP system or an expert system. In any event, the challenge is to get information, or should I say the important information, about the device or asset to the application. In order to achieve this objective, we first define a set of functions necessary to create this pathway.

The first we will call “sense and connect.” This function has limited intelligence and is focused on getting the information. It includes radio modules, simple logic and the sensing technology related to the need at hand. The second function we will call “aggregation and transformation.” The key here is to effectively summarise or aggregate the data points in a manner that makes sense before attempting to ship it across a large network like the Internet.

Another key part of this function is to put the information into a common representational language. Hence, this function typically includes rule frameworks, protocol translation and mapping. It also generally includes a pathway to an IP-based network. The final function we call the device cloud. It is part of the extended Internet and has general awareness of all devices connected to remote sites.

Generally this is a hosted system which provides pass through and data storage capabilities. It also aggregates the information from all remote locations in the same way that the aggregation and transformation function pulled together disparate information at the individual device.

In the previous paragraph we used the term “device cloud” as a part of the extended Internet. As such we ascribed to it great power and flexibility. This is easily done because most of us have now been indoctrinated with phrases like “to the cloud” and “cloud computing.” It is clearly the modern trend, but what does it really mean? Beyond the veritable wet things that make rain, snow and other storms, what is it really?

For the simple answer, it is best not to get too caught up in the cloud terminology. It is best to realise that software applications, connectivity and storage can exist on a local machine, like a PC or on a server in a network somewhere. Some of the best examples are the potpourri of Web-based applications like email and other points of centralised intelligence like mapping.

The benefit of the cloud is that it is generally connected and hence can be shared by everyone tied to the extended Internet. In order to understand this environment better, we describe the cloud architecture in terms of services.

At the lowest level, we have something called Infrastructure as a Service (IaaS). This is the “nuts and bolts” of the cloud. It includes the network connectivity, physical servers, firewalls, disks and routers.

The next level is known as Platform as a Service (PaaS). This includes all the software which forms contextual communication links and management functions. It also provides the environment in which the top level can exist. The top level is known as Software as a Service (SaaS).

These are the actual applications, be they Web pages, mapping, analytics or others – the place where the ultimate intelligent work gets done, the home of meaningful context. In this way, the device cloud provides the contextual representation of devices using a common language which enables Web-based applications to get real work done.

Of course, this implies that we must have a common vocabulary. This is where the world of Web services comes in. A typical, complicated definition of Web services is a method for integrating Web-based applications using the XML, HTTP, SOAP, WSDL and UDDI open standards over an Internet protocol backbone.

Unfortunately, this really doesn’t tell us what they are. So we rather like to describe them in a much simpler way, namely – leveraging the common language of the Internet to get stuff done! In short, by describing things in a common way, using common verbs to send and receive information (Put or Get), using a methodology that allows for one to many, many to one, by request or subscription. Okay, but how does it really work?

We start with a language that enables communication – you already know it, however, you may not have known what it meant. It is HTTP or Hyper Text Transfer Protocol. This is the language of Internet clients and servers and most importantly the general purpose protocol for applying Internet verbs to nouns. Sounds good right? We learned about nouns and verbs in 2nd grade.

Well it turns out that Internet nouns are things called Universal Resource Locators (URLs). They might look something like “”. Of course, there is a bit more to it because we need to describe little bits of data and big bits of data. In order to do this, methods of encoding information in a flexible way were created.

There are many, but two of the most common are eXtensible Markup Language (XML) and JavaScript Object Notation (JSON). Both are methods for transporting and storing data. Both are self describing which means you generally don’t need a magic decoder ring to understand the context. The order of things is also not important.

Of course, now that we know about nouns, we need some verbs to go along with it. For the verbs we will use something call Representational State Transfer (REST). This means we will use a common set of actions and let the details be handled by the context.

For a protocol like HTTP, we commonly talk about seven different actions or verbs, of which there are four that will do the heavy lifting in the Device Cloud. The seven verbs are: Get, Put, Post, Delete, Head, Trace and Connect. For the sake of this article, don’t worry about Head, Trace and Connect. We really want to focus on the most important four: Get, Put, Post and Delete. So what do they do?

To begin, every time we go to a Web site we do a GET. It is a request to “get” or retrieve a representation of a file or collection. Of course, like many questions, they often lead to more questions so one “get” often leads to another. Get is the verb and the URL plus any other inserted information is the noun.

Next is the PUT. PUT is the opposite of GET and hence is a request to upload or “put” a file or collection into a database. DELETE is the magic eraser. No doubt, if something has been “put” somewhere, we may want to “get” a copy of it, but we most certainly also want to be able to “delete” it.

Finally, we have POST. This is the complicated one. It is best to think of POST as an intermediary step or a relay. Say we want to know an answer to a question, but don’t really know who to ask it. We can’t do a GET because we don’t know what we are asking.

So, we take whatever information we have and package it up into a POST. Once it is “post”ed, so called expert processes will see our post and respond accordingly. We can wait around for the response in real time (synchronously) or we can go away and ask for notification of response (asynchronously).

So now we will apply these pieces to devices and applications. For this, pretend we have a set of temperature sensors connected to different buildings. Each sensor, using the appropriate connection, aggregation and transformation functions sends temperature values into a database in the cloud every hour. In this context, the temperature values are “put” into the cloud.

Next we assume that we have an application which analyses and graphs the various temperatures by time and location. In this context, the application will “get” the values from the database associated with the appropriate time and place nouns. Further, we assume that we only want to keep the data for a month, so every day a separate process does a “delete” on the values that are too old.

Finally, we assume that a user of the application wants the current temperature value in real time, not just to the nearest hour. In this case the application will “post” a request for the current value at a given location and will wait for the request to be processed and an answer returned. We have Web services at work, using simple nouns and verbs.

In summary, we see that successful connection of device information to remote applications is made easy by the appropriate connection, aggregation and transformation functions. The device cloud and the extended internet are then used as the conduit for bridging data to the application. This is all done using a relatively simple collection of internet verbs tied contextually to a set of internet nouns. It doesn’t need to be hard. Just remember to be RESTful and use the POST.