Dynamic reconfiguration of middleware for ... - Semantic Scholar

10 downloads 11898 Views 341KB Size Report
(content/service adaptation, multichannel content delivery, mobility management and so on), ... Computing scenarios that is able to reconfigure both application.
Dynamic Reconfiguration of Middleware for Ubiquitous Computing Antonio Corradi

Enrico Lodolo

Stefano Monti

Samuele Pasini

DEIS, University of Bologna DEIS, University of Bologna DEIS, University of Bologna DEIS, University of Bologna V.le Risorgimento 2, 40136 V.le Risorgimento 2, 40136 V.le Risorgimento 2, 40136 V.le Risorgimento 2, 40136 Bologna, Italy Bologna, Italy Bologna, Italy Bologna, Italy +390512093083 +390512093083 +390512093323 +390512093323

[email protected]

[email protected]

[email protected] [email protected] these scenarios make system reconfiguration and adaptation crucial yet challenging tasks to provide users with a really dynamic support to tailor applications to specific user and environmental conditions.

ABSTRACT Ubiquitous Computing scenarios call for middleware support solutions able to cope with changes in environmental conditions and user requirements. Changes obviously greatly impact on the application logic the middleware is able to carry out (content/service adaptation, multichannel content delivery, mobility management and so on), but also on the non-functional support logic middleware exploits to enforce the application logic itself (e.g., naming, persistence, communication infrastructures). This work proposes a novel middleware for Ubiquitous Computing scenarios that is able to reconfigure both application and non-functional features, in order to cope with increasingly complex and heterogeneous ubiquitous and pervasive landscapes.

Mainstream approaches stem from separation of concerns, decoupling and delegation principles and typically adopt a service-oriented approach to push application logic outside of the middleware support layer and model such logic as a set of small and well-decoupled business units with well-defined interfaces. The middleware layer thus keeps only support features (e.g., service naming, persistence and messaging) and is in charge of conveniently aggregating and coordinating application logic pieces. The inherent modularity of this approach allows, in case of environmental conditions changes, to easily rearrange such compositions by either changing and/or adding/removing business units.

Categories and Subject Descriptors C.2.4 [Computer-Communication systems

Networks]:

Distributed

However, this approach lacks to face a fundamental, and too often neglected, facet of the problem: heterogeneity and dynamism of Ubiquitous and Pervasive scenarios typically have a great impact also on non-functional aspects of middleware platforms. Changes in the environmental conditions (e.g., network conditions and available devices) obviously greatly influence runtime behavior and conditions of non-functional support features. As an example, traditional middleware platforms adopt underlying asynchronous messaging facilities to help coordinate higher level entities of the platform itself; in case of network congestion, it could be necessary to switch from a connection-oriented message transport implementation to a connectionless one, to save bandwidth and to speedup communication, yet renouncing to delivery guarantees.

General Terms Design, Management.

Keywords Ubiquitous computing, pervasive computing, middleware platform, reconfiguration, software components, service-oriented architectures.

1. INTRODUCTION Recent technology advances in wired and wireless network connectivity and increasingly powerful and rich mobile end user devices are more and more making concrete the once only envisioned Ubiquitous and Pervasive computing scenarios. Users are more and more able to exploit services and contents at anytime, anywhere and by means of any device. Furthermore, services and contents much more tailor to fit user needs and characteristics (e.g., device in use) as well as to adapt to environmental conditions (e.g., network connectivity type and status or user location). Heterogeneity and dynamic nature of

In our opinion, a truly viable ubiquity support platform must be able not only to reconfigure its application logic layer, but also to reconfigure its offering of non-functional support layer features, by allowing, for instance, for the coexistence of multiple different alternatives to choose among and to arrange according to the current environmental conditions. We still believe that separation of concerns, decoupling and responsibility delegation principles are key principles in addressing heterogeneity but we strongly claim that the only viable way to achieve fully reconfigurable ubiquity middleware relies on applying the same principles to both application logic and non-functional features of the middleware itself. This paper therefore proposes a novel and fully reconfigurable ubiquity support middleware platform, able to adapt both application logic and non-functional features to changes in user requirements and environment conditions.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ADAMUS’09, July 13–17, 2009, London, United Kingdom. Copyright 2009 ACM 978-1-60558-646-5/09/07...$5.00.

7

of interaction modalities or application domains (e.g., e-learning [15] or crisis management). Similarly, some general purpose multimodal frameworks [19, 9] have been proposed, but, again, they limit to sets of predefined interaction modes and therefore still lack concrete and widespread adoption.

Section 2 provides background knowledge of ubiquity issues and reconfigurable systems, whereas section 3 describes significant related work in the domain of reconfigurable ubiquitous systems. Section 4 highlights the main principles we followed in the design of our proposal. Section 5 describes the resulting overall architecture, whereas section 6 depicts key choices in designing reconfiguration logic. Section 7 provides relevant implementation details and section 8 provides an example of a reconfiguration case study. Finally, section 9 reports conclusions and illustrates further work our proposal has led to.

2.2

2. BACKGROUND This section describes some background knowledge related to both Ubiquitous computing and reconfigurable systems.

2.1

Reconfigurable systems

System reaction and adaptation to changes is becoming an acknowledged and challenging task, especially for extremely heterogeneous scenarios such as ubiquity-enabled ones. Reflective middleware approaches have historically been the forefront of platform solutions for system reconfiguration. They usually rely on a causally connected self representation model that describes characteristics of the reconfigurable application, and that can be used as a basis to decide how to react and reconfigure. The decision on whether to reconfigure is up to a reflection layer which is able to dynamically inspect current status of the application (not surprisingly, by means of language reflection techniques) [11]. In the last years, the autonomic computing initiative [8] (the term autonomic was first coined by IBM as a metaphor to describe systems that behave as autonomously as human autonomic nervous system) has tackled this issue from a broader point of view, by pinpointing four main reconfiguration properties applications need to face. Selfconfiguration and self-optimization relate to the capability of reacting to changes in order to reconfigure systems that became invalid or no longer optimized. Self-healing and self-protecting systems reactively or proactively take actions to preserve integrity against changes. Some reference models have been proposed to fully or partially address these issues; one of the most appreciated and adopted models is the IBM MAPE-K loop. This model basically identifies five main tasks of autonomic systems: Monitor and Analyze tasks aim at tracking current component status and at extracting information on whether system reconfiguration is necessary; Plan and Execute stages entail the organization and concrete enactment of reconfiguration tasks. Finally, Knowledge task aims at building and runtime updating a consistent model of both current system features and their evolution, in order to provide a sound basis for reconfiguration analysis and planning stages.

Ubiquitous computing

Ubiquity scenarios [20] stress many currently debated research fields, such as mobility support and context awareness, multimodality and multichannel access to contents, variously interconnected and sometimes intermixed. Wireless network connectivity (e.g., 3G mobile networks and WiFi connections) along with more powerful mobile devices (e.g., handheld, smartphones, and tablet PCs) increasingly stress mobility issues. Mobility needs usually relate to three main categories: user, terminal and service mobility [2]. User mobility aims at providing users with a uniform and consistent view of their specific working environment (e.g., user preferences and/or service requirements) while moving across different physical locations. Terminal mobility supports devices willing to move and (re)connect to different networks while remaining reachable and keeping communication sessions consistent. Finally, resource mobility enables resources to migrate throughout network locations and still remain available, independently of their physical location. Content providers are more and more perceiving heterogeneity of end user devices and/or mobility management issues as a key to generate revenues rather than a curse to avoid. Tailoring services and contents to actual user physical location and environmental conditions (e.g., connectivity type or device in use) makes users perceive services and contents as if they were much more personalized. Context-awareness [14] thus refers to the capability of leveraging conditions of the user herself and of her surrounding physical and computational environment to provide more tailored services and contents.

3.

RELATED WORK

A substantial body of work exists in the domain of middleware platforms for Ubiquitous Pervasive support scenarios and some recent proposals try to cope with the non trivial task of system reconfiguration by borrowing ideas from the autonomic computing initiative. However, they typically tend to be extremely vertical, by supporting reconfiguration of specific Ubiquitous scenarios. As an example, [13] and [21] propose context-aware middleware solutions able to cope with reconfiguration driven by context changes but lack to adapt to changes in user requirements and can only reconfigure the application logic layer. [16] extends reconfiguration support to cope with changes in user requirements, but, again, can only reconfigure the application logic. Also part of our previous work [3, 6] proposes a service-oriented reconfigurable and extensible middleware for Ubiquitous and Pervasive computing; however, our proposal too falls short when reconfiguration of nonfunctional layer becomes necessary.

Device heterogeneity also stresses the need for multimodal interfaces and content adaptation: users need to access content or applications by means of different user interfaces and according to their own preferences or device features. Keyboard, handwriting or speech recognition are examples of allowed input modes, whereas text-only documents, images or vocal readings are typical output formats. We refer to multichannel access as the ability of providing the same service or information content via different media channels and platforms. This aspect is becoming important not only to provide users with multiple media access channels but also to promote and extend content accessibility to impaired users [5]. Though compelling requirements for integration of different natural input/output modalities are evident, the currently proposed solutions and frameworks tend to have vertical approaches and focus only on specific and fixed sets

From a different perspective, some interesting works try to propose generic-purpose (not particularly bound to Ubiquitous

8

reconfiguration out (e.g., which pieces of logic need to be substituted or reconfigured). Finally, the reconfiguration enactment engine concretely executes the reconfiguration actions determined by policies.

Pervasive scenarios) fully reconfigurable (so, both at application and at non-functional layer) middleware models by adopting component-based approaches. OpenCOM [7] generic middleware relies on a generic component model with a strong and clear separation of concerns among different layers; however, there is no evidence of concrete deployment and tailoring of such generic model to ubiquitous and pervasive scenarios. [22] proposes a generic component meta-model that tries to support nonfunctional layer reconfiguration, though it specifically targets mobile environments.

4.

4.3

DESIGN PRINCIPLES

Reconfiguration of both the application logic and the nonfunctional aspects of ubiquity support platforms is a challenging task and current state of the art solutions only partially tackle the problem. The main issues in dealing with such problems are the inherent heterogeneity of scenarios and the diversity of environmental conditions and of user requirements. Separation of concerns, decoupling and delegation design approaches have proven to be key principles in designing large heterogeneous distributed middleware platforms. By following these principles we design a fully reconfigurable platform for Ubiquitous Pervasive scenarios.

4.1

Application logic in Ubiquitous Pervasive scenarios typically presents well-marked isolation and loose coupling characteristics [3]; service-oriented computing [12] approaches are extensively adopted to effectively model and capture the essence of pieces of ubiquity-related application/business logic [6] by means of the abstraction of service. The intrinsic modularity of this model allows to easily aggregate and orchestrate services by means of coordination support features. Workflow management systems [1] and enterprise service buses [4] are two of the most preeminent approaches to face such issues. We therefore model the application layer in a service-oriented fashion and let the underlying non-functional support layer provide all of the necessary basic service catalogueing, composition and coordination support features. On the contrary, non-functional support features are typically much more tightly bound to each other and need to interact in a more autonomous way, without intervention of external coordination entities. As an example, a messaging support layer that needs to make dispatched messages persistent, could directly invoke functionalities of the persistence layer. Component-oriented approaches [18] naturally fit this scenario and several proposals have emerged to build generic purpose self-reconfigurable middleware platforms (e.g., [7]). We therefore model the non-functional support layer as a set of generic software components able to interact with each other in an autonomous manner.

Separation of concerns

Our proposal strongly promotes a clear separation of concerns and therefore we partition logic into a layered structure that basically features an application logic layer and a non-functional layer on top of a very minimal kernel layer. Application layer groups all of the ubiquity related logic, hence it provides content generation/retrieval facilities, as well as service/content adaptation and delivery or user interaction facilities. Nonfunctional layer provides basic support facilities the application layer needs to exploit; typical examples include persistence and naming facilities, as well as user/device mobility management or communication facilities. Finally, kernel layer offers basic low level features to enable both application and non-functional layer reconfiguration.

4.2

Decoupling

Ubiquitous Pervasive scenarios are inherently extremely dynamic, heterogeneous and ever-growing. To manage the increasing demand of novel features, both the application and the nonfunctional support layer must obey two major requirements. First, they need to promote strong decoupling of business logic into small, manageable and well-defined pieces; second, they need to be dynamically extensible by either plugging in novel features (pieces of business logic) and/or by replacing/reconfiguring existing ones. These principles however need to cope with the inherently different nature of application logic pieces and nonfunctional logic ones.

Delegation

To tame the complexity of reconfiguring both application and non-functional layer we propose to delegate reconfiguration responsibility: application layer reconfiguration is essentially a non-functional feature and as a consequence should reside at the non-functional layer; similarly, reconfiguration of the nonfunctional layer is the lowest level facility our platform provides and therefore resides at the kernel layer. By following MAPE-K model fundamental ideas, we identify the following main elements of the reconfiguration process.

5.

ARCHITECTURE

By following the principles sketched in section 4, we propose the architecture represented in Figure 2.

Figure 1: Reconfiguration tasks As can be seen in Figure 1, basically each reconfiguration layer features a monitoring engine whose aim is to keep track of current status of elements of the (monitored) layer above. The policy engine determines both whether reconfiguration needs to take place (by basing on current monitoring results) and how to carry

Figure 2: Architecture

9

In our proposal, services provide both syntactic and semantic descriptors, to help determine whether they can collaborate, and the service catalogue provides convenient features to query for currently available services by both syntactical and semantic parameters. Workflow-based service coordination strategies have proven to be extremely powerful and manageable; as a consequence, the composition enactment engine relies on a worflow management system that is able to aggregate, coordinate and execute flows of services, from simple sequences to more complex workflows that feature conditional execution, branches, loops and so on. As far as workflow management system concretely handles service invocation and management, it can easily be used also to monitor and track service status; typical examples of monitored properties involve both single-service and overall workflow characteristics such as average execution time or execution counters.

The application layer concerns services that model typical ubiquity-related application logic; common examples are content retrieving (e.g., news and RSS feed readers, or HTML scrapers), content adaptation (e.g., audio/video transcoding modules, and vocal synthesizers) or content delivery services (e.g., media streaming servers, SMS gateways, DVB-T carousel servers, and HTTP servers). Novel services can be plugged in by need at any time, in a dynamic fashion, to realize novel ubiquity scenarios. In order to build complex scenarios on top of such basic building blocks, services need to be aggregated, executed, and managed; since these are inherently non-functional features, we model them as full-fledged non-functional layer components. Reconfiguration of the application layer is therefore completely targeted by the non-functional layer and, since components of the non-functional layer themselves can be substituted and/or reconfigured as well, our system is able to easily change, substitute or implement different application reconfiguration strategies if in need.

The service composition engine carries out the crucial task of arranging services into workflows according to user needs, available services and environmental conditions. It relies on a set of composition rules that determine whether it is possible and, in case, how to translate user requirements into concrete workflows of currently available services. Such composition rules can constrain both semantic and syntactical features of services; for instance, to enforce correct sequences of services, each one operating on the result of the previous one, a rule may constrain the output format of a service to be the same as the input one of the following service. Similar composition rules can be used to trigger service or workflow reconfigurations when environmental conditions or user requirements change.

The non-functional layer features a heterogeneous set of support facilities; we describe the most relevant ones in the following. A service catalogue provides support to easily add/remove new services to the platform as well as to query for existing ones by allowing for different search criteria. By basing on services currently available in the catalogue, the service composition engine is able to compose sets of services into value-added aggregates that realize user requirements. Along with concrete service compositions, the composition engine is able to provide the service policy engine with suitable policies to determine whether and how services or compositions need to be reconfigured. Composition enactment engine is in charge of executing service compositions. Similarly, to react to environmental or user requirements changes, a service monitoring engine observes both services and service compositions, in order to detect anomalies. The service policy engine is then in charge of determining whether reconfigurations need to take place by analyzing policies that were provided by the composition engine at composition build time. In addition, the non-functional support layer encompasses components that model other typical and more generic non-functional features; asynchronous messaging, user profiling support, and information persistence layer are common examples of such features.

6.2

Finally, the kernel layer provides coordination facilities to help reconfigure the non-functional layer. The component monitoring engine monitors current state of non-functional components (e.g., by monitoring QoS parameters such as responsiveness, average load and so on) whereas the component policy engine determines when and which components need to be reconfigured in case environmental or user conditions/requirements change. Finally, the component reconfiguration engine is in charge of concretely enacting component (re-)configuration.

6.

RECONFIGURATION DETAILS

Furthermore, since non-functional components execute autonomously with no external management or coordination (contrarily to the service-oriented approach where a centralized workflow management system is responsible for invoking services), the monitoring task becomes a really compelling and non-trivial issue to implement. In typical naïve approaches, each component implements its own monitoring logic, with quite obvious limitations to portability and modularity. Monitoring can be seen as a typical concern that cross-cuts several different

The intrinsically diverse nature of entities at the application and non-functional layers (services and components) requires to handle reconfiguration issues in different ways.

6.1

Non-functional layer reconfiguration

Component-oriented models inherently promote autonomous and spontaneous cooperation and interoperability among components. To realize this, components willing to cooperate need to bind to each other (essentially, to know how to communicate) in more or less decoupled ways (e.g., by direct reference, or by referencing component interfaces). This can however become a burden when reconfiguration needs to take place: suppose a component needs to be substituted by another one, in this case references to the old component become invalid and need to be substituted for each collaborating component. The Inversion of Control principle (and its most widespread implementation, the Dependency Injection technique) is a novel approach that delegates component binding and resolution to the execution environment where components live. Components willing to interact need only to declare interfaces they depend on and it is up to the component container to decide and transparently “inject” (into declaring components) the component that currently best implements the required interface. Thus, our component reconfiguration engine heavily relies on dependency injection primitives to easily reconfigure component references.

Application layer reconfiguration

Since the application layer reconfiguration task is carried out by facilities at the non-functional layer, different service coordination and reconfiguration strategies can be implemented.

10

Each time a news get published, its plain-text version is then made available to other workflows by means of the asynchronous messaging support component. Each user interested in receiving a phone call owns an instance of the phone call generation workflow running within our platform whereas users interested in an SMS message have an associated SMS delivery workflow instance. The phone call generation workflow translates plain-text news into MP3 content by means of a voice synthesizer, and then initiates the phone call by means of a PSTN gateway. Similarly, the SMS delivery service splits plain-text content in trunks of 160 characters and then sends them as SMS messages.

components, as well as other low-lever features such as security or transaction management. More recent approaches to component-oriented computing solve the issue of modeling and reusing cross-cutting concerns by means of Aspect-oriented Programming (AoP) techniques. Aspects are pieces of business logic that implement a certain cross-cutting concern and are defined outside of any specific component. The aspect management layer allows to programmatically and declaratively “decorate” component activities with as many aspects as needed, and it is in charge of concretely executing them when needed, typically before and/or after component activities themselves. This approach again fosters clear separation of concerns and decoupling principles. Our component monitoring engine thus heavily relies on AoP techniques to dynamically add or remove monitoring logic to managed components; typical examples of monitored features involve for instance method execution average time, persistence layer access statistics and so on. Aspects can be easily shared and reused across non-functional support components and can be automatically re-registered in case of component substitution or reconfiguration.

7.

Figure 3: Case study As users keep getting registered, hence adding novel workflows, the platform experiences serious performance loss. The component monitoring engine detects the messaging component is becoming a bottleneck and message delivery times are increasing. As a consequence, the component reconfiguration engine substitutes the current costless JMS-based component implementation with a costly but outperforming RTI DDS implementation that can better guarantee near real-time messaging delivery. Similarly, the service monitoring engine detects the voice synthesizer is producing MP3 files at an increasingly lower pace: the service composition engine reconfigures phone call generation workflow by substituting the synthesizer service with a lower quality one that produces MP3 contents at a consistently lower bitrate but in a shorter time.

IMPLEMENTATION

The Spring framework [17] is becoming more and more largely adopted as a full-fledged component model that natively support Aspect-oriented Programming and Dependency Injection principles. As a consequence, we implemented the component reconfiguration engine and all of the other kernel components by exploiting this framework facilities. However, current implementation of the Spring dependency injection container does not natively support dynamic component addition or removal; as a consequence, we had to adopt the Spring Dynamic Modules extension, that targets this issue by integrating Spring with OSGI framework features for dynamic service load/unload. Components of the non-functional support layer are realized as full-fledged Spring components; specifically, the service coordination engine builds on the widespread workflow engine management tool JBoss JBPM [10]. Finally, the application layer supports virtually any kind of service, from traditional Web Services to J2EE EJB components; current services are hosted on the open-source JBoss J2EE application server.

8.

We are currently exploring other highly distributed and computation-intensive scenarios where the (currently centralized) workflow execution engine itself becomes a bottleneck, due to increasing costs of remote service invocations. To target these scenarios, we are realizing an alternative, fully decentralized workflow execution engine based on Mobile Agents techniques. Preliminary experimental results showed that in largely distributed deployments this alternative implementation is able to reduce overall workflow execution times of one order of magnitude.

CASE STUDY

We implemented a number of different heterogeneous real-usage scenarios that mix different kinds of services and we extensively stressed our platform to assess the viability and extensibility of the proposed approach. This section describes a small and relevant (to the extent of this paper) portion of a larger deployment of our platform in a typical ubiquitous pervasive scenario where mobile users require notification of traffic news related to a certain urban area each time news get published on a specific traffic portal. Some users prefer getting notified by a phone call with a synthesized voice reading news contents whereas others prefer an SMS message be sent to their mobile phone. As depicted in Figure 3, our platform arranges three different kinds of service workflows, each one realizing a specific portion of the overall scenario.

9.

CONCLUSIONS

Ubiquitous Pervasive scenarios stress heterogeneity and require middleware support platforms to be able to dynamically react to face such ever-changing scenarios. Current middleware solutions tend to provide reconfiguration support only for the application logic and lack non-functional adaptation support, thus poorly tailoring to environmental condition changes. This paper has presented a novel approach to reconfiguration of both application and non-functional features for Ubiquitous middleware that relies on a clear and neat separation of concerns, and is inspired by delegation and decoupling design principles. The proposed solution has been successfully deployed on a number of different scenarios, ranging from content adaptation for multimedia streams to multimodal support for mobile users equipped with a wide variety of different devices.

The first workflow features two services: the first one monitors the specific traffic portal to detect news publishing, whereas the second one extracts plain-text news content from the HTML page.

11

[10] JBoss JBPM. http://www.jboss.org/jbossjbpm

Current and ongoing work aims at integrating and extending novel non-functional features, specially related to system scalability and reliability. In fact, we are developing a highly scalable persistence layer based on in-memory database technologies and we are investigating how well our platform is able to dynamically switch between older (less scalable but yet more robust, by now) and newer component. Finally, we are currently investigating automated policy conflict resolution engines to tame conflicts in runtime enactment of policies.

[11] Kon, F., Costa, F., Blair, G., and Campbell, R. H. 2002. The case for reflective middleware. Commun. ACM 45, 6 (Jun. 2002), 33-38. DOI= http://doi.acm.org/10.1145/508448.508470 [12] Papazoglou, M. P. and Georgakopoulos, D. 2003. Introduction. Commun. ACM 46, 10 (Oct. 2003), 24-28. DOI= http://doi.acm.org/10.1145/944217.944233 [13] Preuveneers, D., Berbers, Y. 2005 Adaptive Context Management Using a Component-Based Approach. Lecture Notes in Computer Science, 3543/2005 (May 2005), 14-26. DOI=10.1007/11498094_2

10. REFERENCES [1] Alonso, G., Casati, F., Kuno, H., Machiraju V., Enterprise application integration, in: Web Services: Concepts, Architectures and Applications, Springer-Verlag, 2003, ISBN 3540440089.

[14] Schilit, B.; Adams, N.; Want, R., "Context-aware computing applications," Mobile Computing Systems and Applications, 1994. Proceedings., Workshop on , pp.85-90, Dec. 1994.

[2] Bellavista, P., Corradi, A., Montanari, R., and Stefanelli, C. 2003. Dynamic Binding in Mobile Applications: A Middleware Approach. IEEE Internet Computing 7, 2 (Mar. 2003), 34-42. DOI= http://dx.doi.org/10.1109/MIC.2003.1189187.

[15] Shih, T.K., Wang, T., Chang, C., Kao, T., Hamilton, D. 2007. Ubiquitous eLearning With Multimodal Multimedia Devices. IEEE Transactions on Multimedia, Vol. 9, No. 3, Apr. 2007.

[3] Boari, M., Lodolo, E., Monti, S., and Pasini, S. 2008. Middleware for automatic dynamic reconfiguration of context-driven services. Microprocess. Microsyst. 32, 3 (May. 2008), 145-158. DOI= http://dx.doi.org/10.1016/j.micpro.2007.08.001.

[16] Sousa, J.P.; Poladian, V.; Garlan, D.; Schmerl, B.; Shaw, M., Task-based adaptation for ubiquitous computing. Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEE Transactions on , vol.36, no.3, pp.328-340, May 2006. [17] Spring framework. http://www.springsource.org/

[4] Chapell, D. Enterprise Service Bus. O'Reilly, 2004. ISBN 0596006756, 9780596006754

[18] Szyperski, C.: Component Software: beyond Object Oriented Programming, New York: ACM Press/ Addison Wesley 1998.

[5] Commission of the European Communities, eEurope 2005: An information society for all, Available at: http://ec.europa.eu/information_society/eeurope/2002/news_l ibrary/documents/eeurope2005/eeurope2005_en.pdf Bruxelles, Belgium, May 2002.

[19] W3 Consortium, W3C Multimodal Interaction Framework, W3C Note, http://www.w3.org/TR/mmiframework, 2003. [20] Weiser, M. 1999. The computer for the 21st century. SIGMOBILE Mob. Comput. Commun. Rev. 3, 3 (Jul. 1999), 3-11. DOI= http://doi.acm.org/10.1145/329124.329126.

[6] Corradi, A.; Lodolo, E.; Monti, S.; Pasini, S., A user-centric composition model for the Internet of Services. Computers and Communications, 2008. ISCC 2008. IEEE Symposium on ; pp.110-117, 6-9 Jul. 2008.

[21] Yau, S. S., Karim, F., Wang, Y., Wang, B., and Gupta, S. K. 2002. Reconfigurable Context-Sensitive Middleware for Pervasive Computing. IEEE Pervasive Computing 1, 3 (Jul. 2002), 33-40. DOI= http://dx.doi.org/10.1109/MPRV.2002.1037720

[7] Coulson, G., Blair, G., Grace, P., Taiani, F., Joolia, A., Lee, K., Ueyama, J., and Sivaharan, T. 2008. A generic component model for building systems software. ACM Trans. Comput. Syst. 26, 1 (Feb. 2008), 1-42.

[22] Zachariadis, S. and Mascolo, C. 2006. The SATIN Component System-A Metamodel for Engineering Adaptable Mobile Systems. IEEE Trans. Softw. Eng. 32, 11 (Nov. 2006), 910-927. DOI= http://dx.doi.org/10.1109/TSE.2006.115

[8] Huebscher, M. C. and McCann, J. A. 2008. A survey of autonomic computing—degrees, models, and applications. ACM Comput. Surv. 40, 3 (Aug. 2008), 1-28. DOI=http://doi.acm.org/10.1145/1380584.1380585 [9] International Business Machines Corporation, “Why IBM? – Leadership in Multimodal”, http://www306.ibm.com/software/pervasive/multimodal, 2006.

12