Download as a PDF

4.3. Device Driver Extensions
4.3
33
Device Driver Extensions
As mentioned before, Wisspr is reusing the device driver architecture developed in [51]. In
particular the device driver for SunSpots is reused. A device driver works with one class of
devices (e.g. SunSpots). It discovers new devices and interacts with them. The devices, as well
as their sensors and actuators, are presented to the user in a hierarchical form. For example,
the user can retrieve a list of all connected SunSpots by issuing a GET request to the URL
/sunspots/ (different response formats such as HTML, JSON or XML are supported). Then
the user could get information about the capabilities of a device again by sending a GET request
(this time the URL would be /sunspots/sunSpotName). This hierarchy is continued down to
the sensors. A request to the URL /sunspots/sunSpotName/sensors/temperature/ would return information about the temperature sensor, including the last measured temperature value.
In order to make the drivers work well together with Wisspr, a few adaptations had to be
implemented. As described in section 3.4, the messaging module gets the sensor data from
a device driver. Theoretically, it would have been possible to implement this mechanism by
polling the URLs of the sensors regularly. However, this inefficient mechanism was not an
option and therefore a new interface for the communication between the device driver and the
messaging module had to be developed.
4.3.1
RESTful Data Transport
The interface implements a very basic RESTful publish/subscribe mechanism, solely to be
used between device drivers and the messaging bundle of Wisspr. A messaging module wishing
to receive the sensor data of all devices connected to a device driver can issue a HTTP POST
request to the URL http://{deviceDriverHost}/data (the request must include an attribute
callbackURL). Afterwards, the messaging module will receive the sensor data via HTTP POST
requests on the given callback URL. This simple mechanism is far more efficient than the
messaging module polling for updates.
A potential disadvantage of this mechanism is the latency it introduces to the transfer of
sensor data between the driver and the messaging module. In many networks HTTP is however
the only protocol that can be used since ports of other protocols are often blocked by firewalls.
Furthermore, other open and flexible protocols working through the Internet may introduce
delays comparable to HTTP. Nevertheless, other protocols should be considered in the future.
Besides, if the device driver and the messaging module are on the same machine (which will be
often the case), much more efficient mechanisms for data exchange can be used.
4.3.2
OSGi Service Data Transport
The high latency of the RESTful data transport mechanism was the primary reason for us
to adapt the device driver to work as an OSGi bundle and to expose a data service to other
bundles. This allows us to run the messaging module and the device driver together and the
data transfer happens in-memory, therefore is very fast. The interface of the data service is very
simple: it allows another bundle to register a DeviceEventListener which will get notified as
soon as sensor data is available (the interface is shown in listing 4.1).
With these two data notification mechanism we offer the flexibility to run the device driver
and the messaging module on separate machines, yet we also provide a very fast data transfer
mechanism if the two entities are being run in the same OSGi framework instance.