Keywords

Resource type: :

Software

Permanent URL: :

http://dx.doi.org/10.5281/zenodo.50701

1 Introduction and Motivation

The World Wide Web Consortium (W3C) has standardized the Linked Data (LD) management on the Web with the Linked Data Platform (LDP) specification [8]. Unfortunately, this effort leaves out the so-called Web of Things (WoT) where HTTP is replaced by simpler protocols, e.g., CoAP (Constrained Application Protocol) [12], suitable for resource-constrained scenarios. CoAP adopts a loosely coupled client/server model, based on stateless operations on resources [2] identified by URIs (Uniform Resource Identifiers). Clients access them via asynchronous request/response interactions through HTTP-derived methods mapping the Read, Create, Update and Delete operations of data management. Section 3.12 of Linked Data Platform Use Cases and Requirements [1] reports on a possible one-to-one translation of HTTP primitives toward CoAP, nevertheless the proposed solution appears quite limited. The given mapping [3] only considers basic HTTP interactions: options, head and patch methods are not allowed and various MIME content-format types are missing.

Main motivation of this resource is to enable the extension of the Linked Data Platform standard to Web of Things contexts. A specific variant of the HTTP-CoAP mapping is proposed, preserving LDP features and capabilities: the envisioned HTTP-CoAP proxy makes objects networks first-class Linked Data providers on the Web. Novel features are also giving added value to the strongest peculiarities of CoAP with respect to HTTP, e.g., resource discovery via CoRE Link Format. The proposed solution is released as open source. Performance tests evidence LDP-CoAP supports all types of LDP resources keeping computational performances comparable with other frameworks. Results of the W3C LDP conformance test suite show the proposal does not completely cover LDP specification yet.

2 Coping with Lightweight Linked Data Platform

The LDP W3C Recommendation provides standard rules for accessing and managing Linked Data on the Web LDP servers. Basically, it defines seven types of LDP Resources as well as patterns of HTTP methods and headers for CRUD (Create, Read, Update, Delete) operationsFootnote 1. W3C LDP implementations web page (http://www.w3.org/wiki/LDP_Implementations) lists several software tools: Table 1 reports the most relevant ones along with main properties and supported resource types, in order of release date. All solutions are based on the HTTP protocol, with no current support for WoT standards such as CoAP.

Table 1. Current LDP implementations
Full size table
Table 2. HTTP-CoAP mapping of preference headers
Full size table

The W3C suggests explicit use cases [1] aiming to integrate LDP in resource-constrained devices and networks with specific reference to CoAP [12], a compact protocol conceived for machine-to-machine (M2M) communication. Some CoAP options are derived from HTTP header fields (e.g., content type, headers and proxy support), while some other ones have no counterpart in HTTP. So an HTTP-CoAP mapping is needed to exploit all LDP features with CoAP. An early mapping proposal was defined in [3], but it only worked with basic HTTP interactions. The HTTP-CoAP mapping for LDP envisioned in [7] and outlined here, enables a direct CoAP-to-CoAP interaction. HTTP methods mapping is applied for each CoAP method (if present). HEAD and OPTIONS, undefined in CoAP, are mapped to existing GET and PUT methods, by adding the new Core Link Format attribute ldp. There is full backward compatibility with the standard protocol, while extending the basic CoAP functionalities. W.r.t. the early proposal [7], additional features have been also defined to support: (i) PATCH method; (ii) RDF Patch format [10] along with application/rdf-patch content-format media type; (iii) LDP Prefer headers of request/reply messages (Table 2).

LDP-CoAP mapping was implemented in a Java-based framework providing the basic components required to publish Linked Data on the WoT according to LDP-CoAP specification. It consists of several modules, as shown in Fig. 1a.

Fig. 1.
figure 1

LDP-CoAP framework architecture

Full size image

ldp-coap-core: includes the implementation of all LDP-CoAP resources and a basic LDP-CoAP server handling CoAP-based communication and RDF data management. The main Java package coap.ldp was partitioned in the following sub-packages each providing a specific functionality.

– coap.ldp.server: the reference CoAPLDPServer implementation. It extends the CoAPServer provided by californium-core-ldp module (described below) and exposes methods to create and manage LDP resources. The package also includes the CoAPLDPTestSuiteServer, used for experiments described in Sect. 3.

– coap.ldp.resources: according to the LDP resource hierarchy [8], several Java classes were developed extending the CoAPLDPResource base class providing common methods and attributes. For each resource class, a specific data handler can be implemented to retrieve whatever kind of data (e.g., observation from a sensor) and update the RDF repository with user-defined periodicity. Handlers can be defined starting from the LDPDataHandler abstract class. In this way, developers can build specific applications implementing the whole business logic and data management procedures within the handleData method of the handler, without any other modification of the source code. CoAPLDPResourceManager implements read-write operations on the RDF data storage exploiting an OpenRDF Sesame (http://rdf4j.org) in-memory RDF repository.

– coap.ldp.handler: two simple handlers were defined as usage examples to expose real-time system CPU load and RAM usage ratio as LDPRDFResource. Data are collected through the operating system interfaces of Java 7 (or later).

– coap.ldp.exception: a CoAPLDPException class was defined to catch errors due to incorrect usage of LDP methods, headers or attributes. Its subclasses represent typical problems (e.g., content format or precondition failed).

– rdf.vocabulary: contains RDF ontologies mapped as Java classes to simplify creation and querying of RDF triple. As an example, SSN-XG ontology [4] was mapped through the Sesame Vocabulary Builder (http://github.com/tkurz/sesame-vocab-builder) tool and included here.

The following libraries are required to correctly compile ldp-coap-core: JSON-java (http://github.com/stleary/JSON-java) to format data in JSON; jsonld-java (http://github.com/jsonld-java) to support the json-ld specification [6]; Apache Marmotta RDF Patch Util (http://marmotta.apache.org/sesame.html) to update RDF statements of a Sesame repository according to the rdf-patch [10] format.

californium-core-ldp: a modified version of the Californium CoAP framework [5], extended to support LDP features. Main modifications include: (i) novel content-format media types added to MediaTypeRegistry class; (ii) additional response codes introduced within CoAP main class.

ldp-coap-proxy: a modified version of californium-proxy implementing the mapping rules defined before and translating LDP-HTTP request to the corresponding LDP-CoAP ones. As shown in Fig. 1b, LDP-CoAP mapping procedures take advantage of the classes in this module. In particular, ProxyHttpServer is responsible for processing a request –coming from a generic HTTP client– through its HttpStack member class where the mapping occurs. HttpStack transforms an HTTP request into a compatible LDP-CoAP one and for each CoAP request it starts two threads, CoapRequestWorker and CoapResponseWorker, synchronized according to the producer-consumer pattern. The CoapRequestWorker thread produces the LDP-CoAP translated request for the ProxyHttpServer class instance which forwards that request to the proper LDP-CoAP server. The CoapResponseWorker is responsible for consuming and translating the LDP-CoAP response coming from the ProxyHttpServer into the HTTP response which is returned to the client.

In addition to the basic framework, the following two packages were developed to build LDP-CoAP applications on embedded and resource-constrained devices.

ldp-coap-raspberry: ldp-coap-core was tested on a Raspberry Pi (http://www.raspberrypi.org) board. W.r.t. other LDP implementations, LDP-CoAP is very lightweight and simple to run on low-resource environments like Raspberry Pi, having a minimum number of dependencies and low system requirements in terms of memory and processing capabilites. As a reference example, two handlers were implemented to publish CPU temperature and free RAM as LDP resources. Data are retrieved using the Pi4J (http://pi4j.com) library.

ldp-coap-android: a simple project exploiting ldp-coap-core on Android devices. It runs unmodified on all platforms supporting modules compiled with Java SE runtime environment, version 7 or later, so it can be directly used as a library also by Android applications. Android OS provides a uniform interface (the Android sensor framework, http://developer.android.com/guide/topics/sensors/sensors_overview.html) to access sensor data. Therefore, a single handler (named GenericSensorHandler) was implemented to manage both hardware and software-based device sensors. The project includes a basic activity starting a LDP-CoAP server exposing data from interface sensors modeled as LDP resources. Source code is available on [9], including Javadoc documentation; quick usage examples are on the project website http://sisinflab.poliba.it/swottools/ldp-coap. All modules were developed as Eclipse (http://eclipse.org) projects using Apache Maven (http://maven.apache.org) to manage dependencies. Only ldp-coap-android is a project for Android Studio (http://developer.android.com/tools/studio/index.html), the Google official IDE for app development. In this case, all dependencies can be defined through a Gradle (http://gradle.org) configuration file.

A few validation examples are reported here, in order to clarify the proposal. Full examples are on the LDP-CoAP project website.

Ex. 1 – Basic HTTP GET request on an LDP resource. HTTP-CoAP mapping is shown in Fig. 2. As described in [7], a single CoAP GET request cannot produce all the needed headers. So the original HTTP request (Fig. 2a) is translated to three LDP-CoAP packets: a GET message (Fig. 2d), a CoAP discovery message (Fig. 2c), and an OPTIONS message (Fig. 2b). In particular, since Allow, Accept-Post and Accept-Patch response headers are not defined in CoAP, their values are set in the LDP-CoAP OPTIONS response body in JSON syntax and then mapped to the corresponding HTTP headers. As per the CoRE Link Format specification [11], the CoAP discovery request maps the HTTP Link header with the resource type (rt) retrieved via the /.well-known/core reserved resource path.

Fig. 2.
figure 2

HTTP-CoAP mapping for an LDP GET request/response

Full size image

Ex. 2 – Create a new LDP resource through an HTTP POST request. In this case, the HTTP request (Fig. 3a) is translated to a single CoAP POST message, as in Fig. 3b (see [7] for details).

Fig. 3.
figure 3

HTTP-CoAP mapping for an LDP POST request/response

Full size image

3 Experiments

The W3C LDP Test Suite (http://w3c.github.io/ldp-testsuite/) is used to evaluate the functionality of the proposed framework and to compare it with existing solutions. The suite consists of 236 tests which query an LDP server by means of HTTP messages; only for LDP-CoAP requests were sent to the server through an LDP-CoAP proxy as in Fig. 1a. Obtained results are grouped by supported LDP resources (RDF Sources, Non-RDF Sources and Basic, Direct, Indirect Containers – see [8] for definitions) and compliance levels (MUST, SHOULD, MAY). For each resource/level pair, Table 3 compares the score of LDP-CoAP with the highest value obtained by other LDP tools. Full LDP-CoAP results are on the project website. Overall, LDP-CoAP presents good scores, when considering 17 manual tests were skipped in this first experimental campaign and only automated ones were executed.

Table 3. Comparison of implementation conformance tests
Full size table

In addition to LDP-CoAP 7 tools were evaluated: Virtuoso, LDP.js, Apache Marmotta, LDP4j, RWW.IO, Fedora4 and Eclipse Lyo. They were selected according to the features listed in Table 1: current status, completeness, open license, last update and supported resources (in particular RDF Source and Basic Container). Gold was tested and discarded due to the limited compatibility with LDP specification. Only supported resources were taken into account to retrieve processing time. Each test was repeated three times on the same PC and (only for tests passed by all tools) the average value was reported in Fig. 4. Fedora4 and LDP-CoAP support all LDP resources. Eclipse Lyo and LDP4j manage four resources groups, whereas remaining frameworks only operate on RDF Sources and Basic Containers. LDP-CoAP has good processing times, as results are comparable with the other implementations even while involving the HTTP-CoAP proxy. Only for non-RDF Source tests performance is slightly worse.

Fig. 4.
figure 4

Comparison of processing time for tested LDP implementations

Full size image

To evaluate the feasibility of exploiting LDP in mobile and pervasive computing scenarios, LDP-CoAP performance was tested on three different Java-compatible platforms: a PCFootnote 2, an Android smartphone (LG Google E960 Nexus 4, specifications at http://www.lg.com/us/cell-phones/lg-LGE960-nexus-4) and a Raspberry Pi 1 Model B+ board (http://www.raspberrypi.org/products/model-b-plus/) All requests were originated from a PC client running both the LDP Test Suite and the LDP HTTP-CoAP proxy, connected through a local IEEE 802.11 network to one of the three LDP-CoAP servers for each test. The overall processing time, shown in Fig. 5, is defined as the time elapsed from sending the request until receiving a response by the client, including communication and HTTP-CoAP message translation times. Values on Android are roughly 3 times higher than on PC, whereas performance on Raspberry are an order of magnitude higher with respect to PC. However, average response times are under 1 second both on Android and Raspberry (except for LDP-NR responses on Raspberry). Memory usage was also measured every 2 s during the execution of the test suite for the three platforms. Memory allocation peak of the LDP-CoAP server was about 44.7 MB on PC, 18.3 MB on Android and 7.4 MB on Raspberry. Stricter memory constraints on smartphones and embedded devices imposes to have as much free memory as possible at any time. Consequently, on these platforms Java virtual machines perform more frequent and aggressive garbage collection (see Fig. 6). The garbage collector was invoked many times, corresponding to the falling edges in the chart. This behavior reduces memory usage, but on the other hand it causes the processing time gap found on the different platforms.

Fig. 5.
figure 5

Device time comparison

Full size image
Fig. 6.
figure 6

Memory use on Raspberry Pi

Full size image

4 Future Directions

This paper presented an LDP-CoAP mapping and framework for managing Linked Data in the Web of Things. Performance tests evidence LDP-CoAP supports all types of LDP resources and its computational performances are comparable with those of other frameworks. Future revisions will extend compliance as much as possible; progress will be measured through test suite adopted here. Planned developments also include: evolving the forks of Californium core and proxy modules to merge them with the original codebase eventually; adding the capability to manage RDF resources on persistent storage in addition to in-memory ones; porting LDP-CoAP server to more languages (e.g., C/C++, Python, Go) and computing platforms (e.g., Arduino).