Web Services for Smart Objects - Part 3: A real-world web service system for smart objects

The Pachube authentication mechanism is simple. With each HTTP request performed by the client, the client provides a secret key. The server checks the secret key with the pre-registered key for the feed that the client is trying to access. If the key supplied by the client matches the key stored on the server, the server allows the client access to the data.

The key for a particular data feed is created when the feed is created. When creating the feed, the client needs to remember the key that was created as part of the feed since the key is needed for future access to the feed.

The key is sent as part of each HTTP request performed by the client. The key can either be sent as part of the URI or as part of the HTTP headers. Since the authentication key is transmitted in clear text in every HTTP request, it is trivial for third parties to sniff the key as it traverses the network. The sniffed key can later be used not only to gain access to the data, but to delete the entire data feed, including the data history.

To make it harder for third parties to gain unauthorized access to the authorization key, Pachube provides a way to encrypt the data stream using transport layer security through the Secure Sockets Layer (SSL). With SSL, the entire HTTP transaction is protected by encryption so that third parties sniffing on the data cannot read the key or the data transaction.

9.3.6 Triggers
The synchronous API provided by Pachube works well for applications that periodically submit data to Pachube and periodically poll the servers for new data, but it does not allow fully reactive applications. Reactive applications react instantly to incoming data. One example of a reactive application is a burglar alarm that directly alerts the owner when the sensors detect a break-in.

To allow reactive applications, Pachube provides a mechanism called a trigger. A trigger is a small function that clients can upload to the server. Trigger functions are extremely simple and are only able to perform a threshold comparison on a data stream. If the data values in the data stream become greater than or less than the threshold provided in the trigger function, the trigger is executed.

When a trigger is executed, the Pachube server performs an HTTP GET request to a preprogrammed URI. The URI, which is provided by the client when configuring the trigger, points to an application hosted by the user on an external web server. The HTTP request sent by the Pachube server contains information about what feed and data stream caused the trigger to execute, as well as the current data value from the data stream. This permits reactive applications that do not need to poll the Pachube servers for data. After the trigger, the application may use the synchronous Pachube API to retrieve further information about the event that caused the trigger to execute.

Trigger functions can be represented either in XML or in JSON notation. An example trigger is shown in Figure 9.13.

FIGURE 9.13 Pachube trigger function that triggers when the sensor data are greater than 20.0, expressed in JSON format.

This trigger function is programmed to react when the data stream value exceeds 20.0. The "trigger_type" keyword is set to ">" (abbreviation for greater than). The stream ID is 0, the environment ID is 1233, and the user name is "Pachube".

The threshold value is given by the "threshold_value" parameter and is set to 20.0. The "url" field contains the URI that the Pachube server will call when the trigger is executed. The URI must correspond to the RESTful API of the reactive application. The "notified_at" field is updated with the date and time the trigger was last executed. Finally, the "id" parameter contains the identity number of this particular trigger function.

9.4 CONCLUSIONS
Web services provide an established mechanism for exchanging data between disparate systems. They are widely used in general purpose IT systems and the integration benefits of running web services on smart objects are large. With web services for smart objects, smart object systems can be readily integrated in general purpose IT systems such as enterprise resource planning systems and business systems.

Web services can be implemented using the REST principles, which are an architectural model for distributed systems. The REST principles can be efficiently run on top of an HTTP connection, making it simple and compelling for the resource-constrained smart object devices.

Although the performance of web services has been criticized in the context of large-scale server systems, recent studies show that web services can be efficiently implemented on smart objects. Web services can be run over low-power radio networks with good results.

Taken together, the interoperability and integration benefits of web services for smart objects, combined with their low resource requirements and good performance, make them a compelling choice for smart object systems.

References:
83. Fielding R, Gettys J, Mogul J, et al. Hypertext transfer protocol — http/1.1. Internet RFC2616; June 1999.

Printed with permission from Morgan Kauffman, a division of Elsevier. Copyright 2010. "Interconnecting Smart Objects with IP: The Next Internet" by Jean-Philippe Vasseur and Adam Dunkels. For more information about this title and other similar books, please visit www.elsevierdirect.com.

Related links:
Web services for smart objects - Part 1: Overview | Part 2: Performance considerations
Rise of the Embedded Internet
TCP/IP Embedded Internet Applications - The Network Layer, Part 1: The Internet Protocol | Part 2: IPv6, ICMP and UDP | Part 3: The transmission control protocol (TCP)
Back to the basics: Improve TCP/IP performance in memory-constrained embedded apps
Java Essentials for Embedded Networked Devices - Part 1 | Part 2 | Part 3 | Part 4 | Part 5
The basics of adding 802.11n wireless connectivity to your embedded design