Enabling Flexible and Continuous Capability Invocation in Mobile Prosumer Environments
Mobile prosumer environments require the communication with heterogeneous devices during the execution of mobile services. These environments integrate sensors, actuators and smart devices, whose availability continuously changes. The aim of this paper is to design a reference architecture for implementing a model for continuous service execution and access to capabilities, i.e., the functionalities provided by these devices. The defined architecture follows a set of software engineering
... s and includes some communication paradigms to cope with the heterogeneity of sensors, actuators, controllers and other devices in the environment. In addition, we stress the importance of the flexibility in capability invocation by allowing the communication middleware to select the access technology and change the communication paradigm when dealing with smart devices, and by describing and evaluating two algorithms for resource access management. Introduction Uniform access to resources and devices is one of the most discussed topics in ubiquitous computing related work. This is demonstrated by the large amount of work on communication middleware available today [1, 2] . Continuous service execution requires addressing device interoperability problems, due to the wide heterogeneous nature of existing devices. The most common interoperability issues are related either to technology and access protocols or the format of the exchanged data, that is, the set of rules that must be taken into account to interpret the data once obtained. This work deals with the first category, which includes interoperability issues related to communication paradigms. Communication paradigms are often bounded to the employed protocol but sometimes they are decoupled. Connection-oriented, synchronous or asynchronous, message-based or service-based communications are considered in this category. This paper contributes to solve some of the issues related to communication middleware, regarding flexible and continuous service executions. For this, we describe the design and validation of a middleware solution for continuous capability access whilst service execution is taking place in ubiquitous environments. The main contribution of the paper is the definition of the communication middleware's architecture and its integration with other interdependent subsystems. Also, an implementation of this resource access middleware is proposed that integrates a set of access technologies and communication paradigms, which are commonly used and requested by available capabilities. The presented middleware contributions are based on the work done in the mIO! project, which aims at the provision and consumption of prosumer services in a mobile environment. The term prosumer  (as an acronym formed by the fusion of the words producer and consumer) is applied to those users that are at the same time consumers and producers of services or contents. In our view, these users, placed in the center of device-rich environments, uses their smartphone to design, compose and configure new services with the help of creation tools. In mobile prosumer environments, the generated services use the available functionalities offered by surrounding devices and nearby elements. The middleware will try to guarantee that the service execution is maintained even though the used elements may change or disappear. Mobile prosumer environments establish some requirements that determine the design of the proposed architecture. Focusing on non-expert users, a high level of abstraction is required in order to enable users to create their own services in an easy way. Besides, the architecture needs to adapt to changes in the availability of resources and services, as well as to provide a communication infrastructure for uniform resource access. For further information about the prosumer concept and the mIO! architecture the reader is referred to our previous work  . Based on the requirements of the mobile prosumer environment, the service must present a logical structure defined by different layers, described in the next Section. Section 3 analyses the communication paradigms currently used in communication middleware. Section 4 describes the overall architecture, which has been designed using various design patterns in order to meet the requirements imposed by the ubiquitous environment and the studied communication paradigms. Sections 5 and 6 describe the integration between the resolution and capability invocation processes while Sections 7 and 8 make a contribution to the communication with smart devices and the problem of resource and connection management Sensors 2012, 12 8932 respectively. Finally, the paper concludes with a validation of the designed system, related work and some conclusions of the proposed solution. Service Logical Model The provision of a higher level of abstraction for prosumer users leads to the following concepts: Service, as a unit supplied and consumed by the prosumer, Component, which represents a basic and functional unit used by a service, and Capability, which is the implementation of the functionality defined by a component and provided by some element (hardware or software). It is also necessary to introduce the concept of Orchestration, which manages the interaction between the different components of a service, Resolution, which manages the association of capabilities to components and, finally, Invocation, which provides a uniform access to the infrastructure capabilities. A service can be defined in many ways, depending on the state of the life cycle in which the service is. We define the logical structure of a service by different levels: the service level, the component level and the capability level. To illustrate these concepts we present the example of a simple prosumer service, called Sport Tracker, which aims to access the location information of a user and to represent it on a map along with information about his heartbeat. This service consists of three components: a Map provider, a Location provider and a Pulse provider. These abstract services provide an interface that must be implemented so that the composed service can be executed. For example, the Location component needs to be resolved into a GPS device or a GPS capability (e.g., offered by a mobile phone) in order to obtain the information about the user's location. Figure 1 shows the proposed service logical model, adapted to this simple example service.