One of the main features of pervasive computing systems is their need to be dynamically reconfigured in order to properly adapt to the continuous changes in their environment conditions (context). An appropriate solution to provide reconfigurability is Aspect-Oriented Software Development, which allows that optional functionalities can be enabled/disabled and services can be replaced with lighter implementations which are less resource consuming. The primary aim of this work is the definition and implementation of an aspect-oriented middleware architecture to dynamically reconfigure pervasive computing systems. Our middleware will provide support for the context-aware, efficient, consistent and homogeneous reconfiguration of middleware and application services. Other requirements of pervasive computing systems such as mobility, fault tolerance and service distribution will also be addressed.
Nowadays pervasive systems have acquired special relevance due to the popularity of smartphones and embedded systems. In these kinds of systems, the context and, consequently, the requirements that services have to satisfy, change continuously. Therefore, context-aware adaptation is needed, which involves enabling, disabling and modifying services. Moreover, adaptation should be as transparent as possible to the services and the applications that use them. Since performing adaptation is a complex task, it should be addressed by a middleware architecture that provides the monitoring and reconfiguration services needed to achieve context-aware adaptation at both the infrastructure and the application services.
Finding solutions to this problem is not easy since we need to face some significant difficulties. For instance, in these kinds of systems we can find devices with very different capabilities with respect to processing, memory and connectivity resources, so applications and middleware should be reconfigured deploying lighter or more complete versions of their services without affecting the global functionality of the system. Furthermore, whenever reconfiguration is performed it is possible that the new deployed configuration is not consistent. However, controlling consistency introduces a significant overhead, so it is necessary to find a balance between reconfiguration flexibility and performance. Finally, the services can be distributed, so many non-functional requirements like security, privacy, fault tolerance or mobility need to be addressed. The main motivation of our work is that although the importance of these requirements in the development of pervasive systems has been identified in the literature, no single existing proposal satisfies them all.
Aspect-Oriented Software Development (AOSD) is an appropriate technology for
this purpose. With AOSD, optional functionalities can be modelled as aspects, which are
dynamically enabled/disabled or even woven/unwoven if the underlying AO platform
supports it [
As has been previously mentioned, reconfiguration is necessary because the
environment and the available resources are continuously changing. Reconfiguration can
be provided for applications, middleware services or both of them. Some work [
In these work, only small changes are performed during reconfiguration, so there
is no need to provide mechanisms to ensure consistency. In some proposals that
provide dynamic reconfiguration (e.g. [
Reconfiguration is a mechanism that provides support for adaptation to changes in the context of the system. Therefore, one of the most relevant services is context monitoring. Most approaches acquire context data in a similar way, and the only significant difference is introduced by aspect-oriented approaches. Concretely, in Janik and Zielinski, context information is provided by sampling devices that are implemented as aspects and can be woven/unwoven as needed. Some kind of context abstraction, like data aggregation or filtering, should be provided. RCSM provides support for past data aggregation introducing the concept of situation, and the proposal by Janik and Zielinski follows a similar approach. On the other hand, SOCAM uses an Ontology Web Language (OWL) and in the work by Paspallis an XML-based language called CQL is used to access context information. None of them is adaptable enough in order to satisfy the necessities of all context-aware applications.
Frequently, the context data sources are remotely instantiated, so the middleware should provide support for accessing remote context. Furthermore, since some kinds of context information (e.g. location) are especially sensitive, the middleware should provide mechanisms to ensure that only authorised entities can access that information. Therefore, two new requirements (privacy and security) arise. All proposals provide support for accessing remote context but none of them address privacy or security.
Access to remote context data could be provided through a distributed context monitoring service. However, it would be desirable that not only context monitoring but every service could benefit from this feature. Distributed services can be remotely instantiated, enabling middleware to run services in devices with more available resources (i.e. computing resources, battery, etc.). In the related work presented in this section, distribution of middleware layer is only provided for context monitoring service.
Although reconfiguration is an important requirement in pervasive computing systems, more requirements have been identified. One common feature in pervasive computing systems is mobility. In mobility situations, the reachability of devices and services changes frequently, and some mechanisms are needed in order to handle these cases. In RCSM, the protocol R-CDP provides support for looking for new sensors dynamically, and SOCAM provides a Service Location service in which context providers are registered. On the other hand, mobile devices are prone to failures, so fault-tolerance mechanisms should be provided too. However, these proposals do not address this requirement.
In this section we have focused on research that provides support for
reconfiguration. It is worth noting that we can find other work such as The Context Toolkit [
With our proposal we provide two main contributions. The first one is a middleware architecture that provides support for a homogeneous reconfiguration of middleware and application services. Second, we propose a service model that covers all the stages of the software development lifecycle, providing support for specifying and developing services that can take advantage of the reconfiguration service.
Context-Monitoring Service
Context Processing IAcquisitionManagement
IContextAcquired Context Acquisition
Application
Service IContextRequest
IReconfigManagement
Dynamic
Reconfiguration Service IContextNotification
IReconfigEvent Aspect Management
Service
Figure 1 shows our high level middleware architecture. In this Figure, the Dynamic Reconfiguration Service (DRS), the Aspect Management Service (AMS) and the Context Monitoring Service (CMS) are explicitly shown because these services are critical parts of our middleware architecture. DRS provides support for services reconfiguration, and takes into account the context information provided by CMS. DRS and CMS provide a well known interface and do not depend on services internal architecture, so every application and middleware service can take advantage of the dynamic reconfiguration and the context monitoring services in a homogeneous way. In our architecture, aspects will be woven and unwoven dynamically by AMS. In this way, new functionalities can be added or removed from services according to previously defined reconfiguration policies.
Figure 2 describes the process of services development and reconfiguration. Development of a service begins with the specification of a features model. This model includes mandatory and optional features of the service, that will be dynamically enabled and disabled based on context data. From the features model and context data a repository of configurations will be defined, which consists of a set of valid and consistent architectures, each one addressing a valid combination of features of the model. At runtime, the DRS will dynamically select the appropriate configuration according to the current context.
Features Model
Config Generation
Context data Configuration Repository Config 1
Config 2
Config N Selected config
Dynamic Reconfiguration
Service Our objective is to define a middleware architecture in which every infrastructure and application service can be reconfigured in a homogeneous way while fulfilling typical requirements of pervasive systems, and we will achieve this objective ensuring that low overhead is introduced.
In the process of services specification, all the steps of software development life
cycle will be followed. We adopt the same principles of the Software Product Lines
(SPL) [
One of our main objectives is that our middleware can be deployed in resource constrained devices. For this reason, we will design and evaluate the most critical parts (in terms of resources consumption) of the system first. Once we are sure that the critical parts of the system are designed in an efficient way, we will define the rest of the services of the architecture. One of these parts is the Aspect Management Service. Since this service provides mechanisms to instrument the communication between components, the design and implementation of other services of the middleware will depend on the design of AMS. Another critical part of the architecture is the Dynamic Reconfiguration Service, so it is necessary to provide mechanims to perform reconfiguration (enabling and disabling features from the service model) from context monitoring data in a very efficient way. Additionally, this service should provide support for defining bindings between context information and reconfiguration triggering. 5
Through the proposed middleware architecture and methodology four contributions are
expected.
1. Homogeneous services reconfiguration. We propose an architecture in which both
application and infrastructure services can be reconfigured in a homogeneous way.
In related work, reconfiguration is frequently limited to application layer and, if
middleware is reconfigurable, it is restricted specifically to some services.
2. Extensible architecture. Since services can be developed independently, the
middleware architecture can be extended with new services as needed. This way, both
functional and non-functional requirements can be fulfilled for any use case.
3. Consistent and efficient reconfiguration mechanism. All the valid configurations of
a service are defined at design time in its features model and associated service
architectures. This way, consistency is guaranteed without introducing additional
overhead. An initial efficiency evaluation of the weaving mechanism has been
performed in [
Currently, we have specified the context monitoring service and have implemented
and evaluated a prototype of the Aspect Management Service, which is one the critical
parts of the system. A first evaluation was presented in [
The next service to be defined in detail is Dynamic Reconfiguration Service, another key part of our middleware architecture. 6
Each time a newservice is introduced into the middleware infrastructure or modified, an evaluation has to be performed in order to ensure that the service works properly and, since we target resource-constrained devices, that it works in an efficient way. To this end, appropriate scenarios will be defined. The results obtained will be compared, when possible, with the results obtained from related work.
First, critical parts of the system will be evaluated, since they affect directly to
the rest of the system. In this way, the first service that has been evaluated is Aspect
Management Service. To this end, we have evaluated AO general-purpose languages
that provide dynamic reconfiguration, such as JBoss AOP; other AO languages (e.g.
Spring AOP) will also be evaluated as part of our future work. However, since these
languages need to address the requirements of every kind of application, our initial
results show that they introduce a high overhead and, consequently, they seem not
suitable for resource-constrained devices. Therefore, we have implemented and evaluated
a prototype of this service that meets the needs of our architecture. In [
Once we have developed the main services of the middleware architecture, some application scenarios will be defined and implemented. In these scenarios, different kinds of devices such as smartphones, laptops and desktop computers will be used, and both application and middleware services will be reconfigured according to context information provided by sensors (e.g. location, temperature), the operating system (e.g. CPU and memory consumption) or the user (e.g. user preferences). These applications will involve requirements such as mobility, distribution and fault tolerance while taking into account the resource-constraints of these kinds of devices.
Acknowledgements This research has been conducted in collaboration with Mo´nica Pinto and Lidia Fuentes from the Languages and Computer Science Department at the University of Ma´laga, which are the PhD Supervisors of the thesis discussed in this paper.