María José Santofimia Romero - Grupo ARCO - Universidad de ...

2.3 Middlewares for Ambient IntelligenceThe essential role played by communications in the Ambient Intelligence paradigms, makes it unavoidableto dedicate a specific section to revising the state of the art in middlewares for AmbientIntelligence. As for the previous section, the revision of the following projects has provided thisthesis with a clear idea of the challenges that remain unsolved and those that have been successfullyaddressed by existing technologies.The first of the revised approaches is the HYDRA 11 project [36]. This project echoes the difficultiesof the middleware frameworks in supporting the communication and exchange of informationof the different off-the-shelf devices. Different devices implement different protocols, architectures,or programming languages. This fact complicates the interaction among different vendor devicesand poses the need for a mechanism that abstract low-level details enabling device interaction. Thisproject is mainly motivated by the need to achieve a middleware framework that works as the abstractionlayer that enables a transparent communication independently of the device. This project hastherefore intended to develop a middleware solution capable of enabling seamless access to differentdevices, bearing in mind at the same time the need to comply with security concerns.The most appealing aspect of the HYDRA middleware is the breakthrough statement they promote,as it is the fact that if device capabilities could be semantically described in such a way thatan intelligent agent could understand and use them, the problem of device interoperability wouldhave been bridged [64]. Since the proposed middleware implements a Service-Oriented Architecture(SOA), achieving interoperability among heterogeneous devices implies that services can be easilycombined, in the sense of composite services, by means of semantic descriptions of the composition.The notion of semantic device proposed by HYDRA is particularly interesting. It is used todescribe the services that a particular application would desire a device to provide. In this sense,HYDRA makes a distinction between a physical device and a semantic device. At some point, thisapproach can be seen as a specific type of service composition, in a sense that the composite serviceis modeled in HYDRA as a semantic device. At the implementation level, programmers just need todeal with the semantic device, which will later on be statically mapped onto physical device services.In order to accomplish such static mapping, knowledge about such services and devices is required.By implementing such an approach, programmers are abstracted from dealing with all the activitiesthat would be involved in the mapping tasks, such as service discovery, access to physical devices,and mapping onto the programmed instance. On the contrary, using the semantic device abstractionrelieves the programmer from having to manually address the involved previous steps.HYDRA has also taken care of easing the process of code generation for the semantic deviceabstractions. This has been achieved by adopting a Model-Driven Approach that, based on a descriptivemodel of the services provided by the semantic device, it automatically generates the codeconcerning the service call. Furthermore, it is also responsible for determining the physical devicethat is implementing the service, and prepare the data to be provided to the services.The only detail that appears to be missing is the capability to automatically generate semantic services,rather than expecting programmers to specify them. In this sense, automating some aspects ofthe implemented model-driven approach, it could be possible to automate the generation of semanticdevices. However, HYDRA does not consider this capability and the semantic device generation canonly be carried out by programmers.The MORE 12 project [45] is devoted to addressing the problem that underlies the way humans11 http://www.hydramiddleware.eu/news.php12 ist-more.org25