An example of applications that can be built with our middleware is participatory sensing applications, that first and foremost must be scalable and support the large number of mobile devices that are able and willing to contribute the measurement data.
The IoTS middleware is an open source middleware that provides traditional discovery, composition and access functionalities. The middleware is extended with knowledge including, but not restricted to, mathematics, physics, features of the real world that might of interest to measure/act on, and about sensors/actuators. As a result, the person responsible to write IoT applications can now easily do so by providing his application logic without being an expert in the sensor/actuator domain.
The IoTS middleware allows sensor/actuator service developers to make these services available, for access, through the registration component. The component is deployed locally on each mobile device (as shown in the figure below) and decides whether or not the service in question should be registered (based on the geographic coverage provided by the service). The decision is computed probabilistically depending on the need for such service. Through this process, the middleware filters out redundant services that do not increase the coverage at their region and can thus better handle the ultra large scale of the IoT. An important requirement for this step to succeed, is for the Registry to be deployed and running (on a server). The Registry is a Web-based component that holds metadata of all registered services.
The IoTS middleware also allows mobile application developers to create thing-based applications to answer any number of queries (requests for sensor data or actuator actions) over any feature of interest in the real world. Similar to above, the Registry should be deployed and running and at least one services at the location of interest must have registered or else no results will be returned. A proxy client, enabling access to smartphones over 3G network, should also be running on each mobile device, otherwise services will not be accessible. Acquiring the measurement data from sensors is done through the access component, deployed locally on mobile devices (as shown in the figure below), and designed to allow easy access to sensors by abstracting all technical heterogeneous details of sensors under a uniform API. In case requested sensor/actuator services are not available, the composition component identifies and executes possible compositions of services that can replace the missing one. Service compositions are defined as mathematical formulas in the ontologies.
Implementation of the CHOReOS IoTS middleware.
The IoTS middleware is written in Java 6, works on personal computers and Android phones. The development of the sensors is done for Android phones. The chosen interaction protocol for the Registry and Access is REST.
Proxy-ing mechanisms have been developed to be able to access smartphones over 3G networks, where mobile operators usually block incoming access requests.