Part 1: Cloud & REST | Part 2: HTML5 WebSockets | Part 3: Physical Mashups
A few weeks ago, I started posting a series about the project we were working on while at MIT: applying the Web of Things patterns and blueprints to the RFID global network (EPC Network). Better late than never, here is the last part of the posts series: Physical Mashups.
Physical Mashups are applications unifying the Web of today and tomorrow’s Web of Things. Tech-savvies, i.e., end-users at ease with new technologies, can create Physical Mashups by composing virtual and physical services. Following the trend of Web 2.0 participatory services and in particular Web mashups, users can create applications mixing real-world devices such as home appliances or sensors with virtual services on the Web.
Thanks to the deployment of the EPC software stack in the cloud and the implementation of a RESTful architecture for RFID, we can now implement Physical Mashup editors for enabling users to flexibly model use-cases of RFID infrastructures. Let us think for instance of an Electronic Article Surveillance system (aka EAS). For this use-case, we design new mashup building-blocks:
These modules were implemented as building-blocks a modified version of the nice Clickscript mashup editor. Reducing interfaces of the EPC Network to Web interfaces enables each building block to be implemented with a small amount of JavaScript code. Using these building-blocks and other basic blocks, we can implement several EAS use-cases within a few clicks. As shown in the figure below, the building-blocks of the RFID mashup editor communicate with several components of the EPC Cloud Infrastructure. First, the RFID-reader block subscribes to the t-pusher HTML5 WebSockets push service using a particular reader ID (e.g., exit-gate). As a consequence, it gets pushed all the RFID events for this reader. The EPCIS block is then used to check whether the pushed RFID number (i.e., EPCs) represent goods that were already sold. To check this, the block uses a RESTful HTTP request on our open-source EPCIS Webadapter.
If it is the case, nothing happens. If it isn’t the case (i.e., the goods were stolen), the Video Camera block is triggered. This components represents a Webcam that can be used to take snapshots through a RESTful API. The URI of the snapshot is then sent to all subscribers of a particular topic (i.e., URI) through t-Pusher. As an example we developed a small mobile Web application with Sencha Touch which subscribes to the topic and loads the corresponding image alongside with the EPC number of the stolen good (see mobile phone in the figure below). Such an application can be used to push information about the theft to all staff members in a store.
Once a mashup has been successfully created and tested locally with Clickscript, it can be exported to our Physical Mashup Engine where is it going to be deployed remotely executed. This illustrates well the benefits of transforming every standard in the EPC Network to offer RESTful Web APIs: development is streamlined to Web development and cross-integration with existing services on the Web (e.g., social networks, visualization tools, could infrastructures, mashups) becomes very straightforward.
The full use-case was tested in a lab deployment at the MIT Auto-ID Labs featuring a standard gate (LLRP) RFID reader and an off-the-shelf Webcam as shown in the figure below. The average observed RTT (round trip time: from the reader, to the Amazon Cloud instance, through the mashup engine and finally to the mobile Web application) was around 1 second. However, it is worth noting that this RTT stronlgy depends on factors such as the available connection bandwidth, the type of instances used on Amazon EC2, the current load of the cloud appliance, etc. Since these factors cannot all be controlled this is a real challenge for IoT / WoT applications in the cloud and we are eager to hear about your real-world experiences in the comments!
For more details about the project, have a look at the published paper or the slides below:
