Automated context-driven composition of pervasive services to alleviate non-functional concerns Davy Preuveneers Yolande Berbers Department of Computer Science Department of Computer Science Katholieke Universiteit Leuven Katholieke Universiteit Leuven Celestijnenlaan 200A, B-3001 Leuven, Belgium Celestijnenlaan 200A, B-3001 Leuven, Belgium Email: davy.preuveneers@cs.kuleuven.ac.be Email: yolande.berbers@cs.kuleuven.ac.be Telephone: (+32) (0)16 327853 Telephone: (+32) (0)16 327636 Fax: (+32) (0)16 327996 Fax: (+32) (0)16 327996 Abstract— Service-oriented computing is a new emerging com- to a broad range of systems, ranging from personal hand- puting paradigm that changes the way applications are designed, helds and smart phones to larger set-top boxes. The second implemented and consumed in a ubiquitous computing environ- requirement is that applications and services need to be less ment. In such environments computing is pushed away from the traditional desktop to small embedded and networked computing dependent on user-intervention and prevent users from being devices around us. However, developing mobile and pervasive overwhelmed with intrusive human computer interactions. services for a broad range of systems with different capabilities Therefore, service-oriented architectures must be able to gather and limitations while ensuring its users a minimum quality of information about the user and his physical and digital envi- service is a daunting task. ronment to autonomously adapt the behavior of the provided The core contribution of this paper is a context-driven com- position infrastructure to create an instantiation of a pervasive services according to the current context of the user and the service customized to the preferences of the user and to the capa- device he is interacting with. It are these two gaps that our bilities of his device. We implement services as a composition of infrastructure is trying to fill in. components. This enables us to compose a service implementation To alleviate the first concern we employ a component-based targeted at a specific device while still being able to adapt it at software engineering methodology [3] for building services run-time to respond to changing working conditions. to be consumed within ubiquitous computing environments. Component-based software engineering is being recognized I. I NTRODUCTION as an important approach for software upgrade and dynamic The third wave of computing is slowly appearing: ubiq- reconfiguration in dependable resource-constrained and em- uitous computing. This new computing paradigm promises bedded devices. As such, services are a collection of inter- an augmented reality that changes the way people interact connected computational building blocks that offer a certain with computers. It promises continuous human computer functionality to a network of devices with varying capabilities. interaction with small embedded and networked computing The second concern with respect to customization of services systems around us that provide 24/7 access to information and is tackled by context-driven composition of components and computational capabilities, and envisions pushing computing using context-awareness, including user preferences, to in- away from the traditional desktop system [1]. crease the non-intrusiveness of pervasive services. The overall When Weiser introduced the area of ubiquitous comput- objective is to achieve automatic composition of customized ing [2] in 1991, he put forth a vision of a deployment of pervasive services using components as building blocks by us- devices at varying scales, ranging from hand-held personal ing contextual information [4] for dealing with the variability digital assistants to larger shared devices providing the neces- of pervasive computing devices and user personalization. sary infrastructure support. He also envisioned a new paradigm In section II we discuss several non-functional concerns of interaction using natural interfaces such as speech, video with respect to services being targeted at ubiquitous comput- and sensor inputs, instead of traditional keyboard and mouse, ing environments and how a component-based development to facilitate communication between humans and computers. methodology can be of help for designing and deploying per- This new way of interaction with computational devices vasive services. Section III discusses how context, including introduces two important non-functional requirements with user preferences and resource availability among other infor- respect to the development of pervasive services. The first mation, and components are formally specified in OWL to sup- requirement is that services should not be developed from port automated service composition for optimal deployment scratch to provide an optimal implementation for each device on a specific device. The core ideas of automated context- with different capabilities and limitations. As such, the design driven composition of components into services are directly and the deployment process of services should offer the illustrated in section IV and build upon previous work on software engineer the necessary flexibility to target services context modeling [4], pervasive service specification [5] and context management support [6]. In section V we evaluate our composition infrastructure. Section VI provides an overview of related work. We end with conclusions and future work in section VII. II. N ON - FUNCTIONAL CONCERNS OF PERVASIVE SERVICES Pervasive services offer a certain functionality to nearby customers and are accessed in an anytime-anywhere fashion, while being deployed on all kinds of devices. The aspects of user mobility, personalization and context-awareness may activate service adaptation and migration to other devices with different characteristics. In this section we review several non-functional concerns with respect to ensuring that all the requirements of the delivery and provision of the service to be consumed in a mobile and pervasive setting are met. These concerns have an impact on the design and the de- ployment of services and often define deployment constraints that take the capabilities and limitations of a device into account as well as any user requirements or preferences with respect to the service. A. Resource-awareness In the ubiquitous computing setting, available services will approach the user on detection of his presence, while the user wants to have the best deals. However, this multi-user and multi-computer interaction causes a competition of resources on shared devices. Therefore, resource-awareness about the Fig. 1. A simple component-based application maximum availability and current usage of processing power, memory, network bandwidth, battery lifetime, etc., is a pre- requisite to guarantee a minimum quality of service. and semantics of the interfaces of a component remain the Due to the black box nature of components, a component’s same [9]. Other components may require state transfer first. functional properties (interfaces and task description) as well D. A simple component-based application as its non-functional properties (resource requirements and Our pervasive service design methodology makes use of the adaptation policies) [7] can be specified more easily to better SEESCOA component methodology [10] which is targeted at support resource-awareness. software development for embedded systems. This implies that B. Mobility a pervasive service incorporates components and connectors User mobility is a corner stone of the society of tomorrow. to fulfill its functional aspects. Components provide the func- Due to possible wireless network disruptions, a user may wish tional building blocks of a service and use Component Ports to download and run a service locally. If, on the other hand, the as communication gateways to other components. Connectors downloaded service does not run within the currently available serve as the message channel between these ports. Commu- resources of the device, the user may wish to run the service nication between component ports is managed by sending on a remote more powerful device in the vicinity of the user asynchronous Messages. Contracts [7] define restrictions or or to relocate (parts of) an already running service. In both requirements on two or more components or ports, for ex- cases the mobile setting of the user triggers service migration ample, to limit or guarantee memory availability or to define to other devices. timing constraints. Composite Components are prefabricated The encapsulation of the implementation of components and compositions of component instances and act to the outside their message-based interaction make it easy to relocate a com- as regular components. Their component ports are exported ponent for distributed execution of the service by instantiating internal component ports. the component elsewhere [8] and rerouting the messages. The example in Figure 1 shows how three components, Number Generator, Switch and Control Relay, are C. Adaptation composed into a new composite component Pausible In the face of highly dynamic environments, heterogeneous Number Generator. The number generator repeatedly devices and their changing context, services will need to adapt provides random numbers with a user-defined frequency. If to changing working conditions. the Switch component is enabled, then the numbers are For stateless components, a component can be replaced shown on a screen by the Number Display component. with a similar component at runtime as long as the syntax The random number generator interacts with the Scheduler component to get notified of when to send out a new number. The user is able to interact with the application by using the Interactive Shell component. It provides a prompt to 1 send messages to the application, for example, to pause and later continue the random number generation by (de)activating the switch. These messages are intercepted by the Control Relay component, which forwards the messages to the right component. The Timing contract specifies timing constraints for sending messages from the number generator to the switch to ensure that messages are delivered on time, and is only shown here for demonstration purposes. III. I NTEGRATING CONTEXT- AWARENESS INTO 1 COMPONENT- BASED PERVASIVE SERVICES The example in Figure 1 is an extension of an even smaller application that does not include the switch and control relay. In the latter case, the user is not able to pause the random number generation. The core of our contribution is that pervasive services are modeled by specifying all components, including the optional components and that these components are instan- tiated by selecting an appropriate implementation or bypassed depending on the current context of the device or any user requirements. The functional specification of components and 1 runtime support for their non-functional concerns in com- ponent systems allow the programmer to design services in terms of components and focus on program logic instead of deployment dependencies. With proper middleware support, the programmer does not need to implement resource moni- toring, decision making or adaptation of services to respond to changing working conditions. Two prerequisites for context-aware composition of per- ... vasive services are an explicit model for specifying context and middleware that is able to gather and interpret this Fig. 2. A meta-model specification of a component in OWL contextual information. In the Context Toolkit [11], context is modeled as a set of key-value pairs. The more structured approaches for modeling context that have been proposed and syntax of a service and its service ports, and hence in the past use RDF [12], UAProf and CC/PP [13], and of how the service can be interfaced, so that other CSCP [14]. Ontologies, which allow the definition of more components or services can discover and use the service. complex context models, have been used in several context This information is expressed in OWL-s [19]. This port modeling approaches [15], [16], [17]. is used to gather information about resource requirements We have designed a context ontology [4] in OWL based on and adaptation policies. the concepts of User, Platform, Service and Environment. This • Service Control Interface: The Service Control Interface ontology is specifically targeted at context-driven adaptation is a standard dedicated interface for controlling a service. of mobile services [18]. This context ontology is used in our It allows the service to be (re)started, updated, relocated, context management system which is discussed in [6]. The stopped and uninstalled. By making this an obligatory context management system, which in itself is also component- interface, no knowledge about the other service ports is based, provides all the necessary information for context-based required for basic service management. This port is used composition and adaptation of pervasive services. Pervasive to alleviate the adaptation concern. services in our methodology are more than just a collection of • Context Interface: The Context Interface is responsible components with specific responsibilities. In [5] we provide for the sending and receiving of the context information a more detailed specification of pervasive services. In short, available at run-time when the service is active. Among pervasive services act as normal composite components but other things, it allows the service to be notified of new with the following extra dedicated ports: resources, and to inform other services or devices about • Service Information Interface: the Service Information resources currently in use by this service. Interface provides a static description of the semantics By modeling services as components, all aspects of composing Fig. 4. Internet Gateway Service and Communication Service types as concepts in another OWL file. This concept ontology is necessary as messages are not restricted to primitive data types, such as strings and integers, but can also include 1048576 objects of any kind of which the inheritance properties can be modeled in the concept ontology as well. The component and concept ontology allow us to make sure that alternative implementations of the same blueprint match syntactically and Fig. 3. Minimum memory requirement as ServiceParameter in OWL-s semantically and that connected component ports exchange messages that are understood by both parties. Context-awareness comes into play during the evaluation components into a services apply to services is well, which of the non-functional properties of services and components. means that services can be combined to form a new service. The service and each component separately can specify min- The automated composition of our infrastructure requires imum resource requirements, such as the minimum avail- that all components are fully specified. We therefore created ability of memory, processing power or network bandwidth. a component ontology in OWL which serves as a meta-model These resource requirements are specified by extending the of all the concepts of the SEESCOA methodology, speci- serviceParameter concept in OWL-s of which an exam- fying components, ports, messages, parameters, connectors, ple is given in bold in Figure 3. In this example, a minimum contracts, etc. as an OWL Class, ObjectProperty or Datatype- memory requirement for the service is specified, but it could Property with cardinality restrictions where appropriate. See have been any contextual requirement with respect to concepts Figure 2 for a partial meta-model specification of a compo- in our context ontology [4]. For example, user preferences in nent in OWL 1 . It allows the software engineer to validate a certain context with respect to a service could be taken into component descriptions by using a regular OWL validator [20] account to increase the non-intrusiveness of the service. so that for automated composition the infrastructure can rely on correctly specified components. As components are self- Our context-driven composition infrastructure instantiates a contained and perhaps independently developed, we have to pervasive service by connecting a selection of components make sure that messages sent out by one component port are such that all requirements hold. In the next section, we will well understood by the other component port on the receiving describe an example of a service with several optional com- part of the connector. We therefore also declare all message ponents that can be activated when possible. These optional 1 The complete OWL meta-model specification of a component can components require extra resources, and we therefore specify be found at http://www.cs.kuleuven.ac.be/˜davy/owl-s/ triggers to model QoS requirements and to define adaptation Component.owl policies. IV. C ONTEXT- DRIVEN COMPOSITION OF PERVASIVE SERVICES The core ideas of how our infrastructure supports automated context-driven composition of pervasive services are discussed in this section. The concepts of taking into account the 1 capabilities and limitations of a device, resource awareness and user preferences in a specific context are illustrated by means of an example. We also provide an outline of our algorithm to discuss the steps taken to deploy a customized pervasive &xsd;#int service and mention implementation details. Consider the following scenario in a ubiquitous and mobile computing environment where two friends, Jack and Jill, are having a conversation over the Internet: “Jack is heading off to work and using public transport. He is using his advanced smartphone and a shared Internet gateway service on the train. Bandwidth is equally shared by 1 all passengers currently logged on to the Internet gateway service. Jill is at home using her laptop with broadband Internet connection and has no resource limitations. &concepts;#VideoFrame on their device is able to communicate using text messaging, speech and video, sorted by increasing bandwidth require- ments. The speech and video quality (high, medium and low) depends on the compression, the frame rate and the frame size being used. These parameters are chosen dynamically depending on the available bandwidth and processing power on the smartphone or are defined as user preferences in a ... certain context.” A. The component-based model of the communication service Fig. 5. Instantiation of the OWL component meta-model for a video frame rate filter component See Figure 4 for a simplified overview of both services. We will now focus on the Communication Service for which a composition will be auto-instantiated depending on the current B. Resource requirements for deployment context of the user and the communication device. The service has the following components: The minimum resource requirements for the service, as • Audio Encoder and Decoder: Adaptable and optional shown in bold in Figure 3, specify what is needed to have a components for (de-)compressing the audio stream with text-based conversation. This kind of communication requires high, medium or low quality encoding. the least bandwidth and processing power. If more resources • Video Filter: Optional components for reducing the video are available, audio and video-based communication can be frame rate or changing the frame size. See Figure 5 enabled as well. Information about available resources is pro- for an instantiation of the OWL component meta-model. vided by our context management system [6]. In this example, The component name and port names are in bold for the limiting factors are the processing capabilities of the smart clarification purposes. phone and the available bandwidth for each passenger. An • Video Encoder and Decoder: Adaptable and optional overview of all resource requirements is given in Table I. components for (de-)compressing the video stream with The total bandwidth requirements for video streaming depend high, medium or low quality encoding. on the quality options and the use of other video filters. The • Controller: (de-)multiplexes text, speech and video, and processing power requirements are only an estimate as a real sends/receives the combined data stream. device may have hardware support for multimedia applica- The audio and video components in this service model are tions. Our prototype is implemented in the Java language and optional, and can be activated when enough resources are makes use of other pure Java libraries. Therefore, the system available. These components can have several implementations requirements are a lot higher to process audio and video on using different encoding schemes. Both parties would have to demand in real-time. agree which encoding schemes can be used on the two com- munication devices. However, in this example one party, Jill, C. User preferences in a certain context has no resource restrictions and can instantiate any component A user may have a preference stating that during office hours she likes. the high quality option for video encoding should be used. TABLE I N ON - FUNCTIONAL REQUIREMENTS AND RESTRICTIONS OF THE COMMUNICATION SERVICE . Component Optional User Preference Processing power Bandwidth Text-based Messenger false - ≈ 50 MIPS > 0 bps Audio Encoder/Decoder true High Quality ≈ 200 MIPS 64 kbps Medium Quality 32 kbps Low Quality 8 kbps Video Encoder/Decoder true High Quality ≈ 800 MIPS 10:1 Reduction Medium Quality 20:1 Reduction Low Quality 30:1 Reduction Frame Resizer true - ≈ 100 MIPS 4:1 Reduction Frame Rate Filter true - ≈ 50 MIPS 2:1 Reduction 3) Service requirements Check any I/O requirements of the service with the I/O support of the device. Check if the minimal resource requirements can be fulfilled. If deploying is not possible, then stop or propose to run the service on another device in the neighborhood or relocate already running services. 4) User preferences Check for all preferences if the con- text of application is fulfilled and if these preferences can be enforced given the available resources. Checking if the context applies, may require some reasoning steps, for example, to determine that geographical coordinates Fig. 6. User preference with respect to video encoding of a GPS system point to a location known as our office. 5) Component selection Given the available resources, See Figure 6, the preference property and value as well as the eliminate all optional components which resource re- time and location conditions are marked in bold. Using this quirements are too demanding. For each obligatory contextual information, an appropriate service is instantiated component, retrieve the resource requirements for all of that takes any user preferences and the current available its implementations. resources and the limitations and capabilities of the device into 6) Constraint solving Given the above resource constraints account. For example, before deploying the communication of the device and the requirements for the obligatory service on a PDA or smart phone, we check if the hardware components and user preferences, solve the set of equa- has the necessary support for video communication as, for tions to find a minimal composition of component in- example, not all devices have a camera on-board. stances. Cut down on the user preferences if no solution is found. D. Outline of the context-driven service composition proce- 7) Adaptation policy Check which optional components dure can be enabled for the preliminary minimal service The goal of our context-driven composition infrastructure instantiation from the previous step. Given the available is an automated instantiation of a service targeted at the resources, these optional components can be enabled capabilities of a specific device that takes into account any immediately, when enough resources are available or user preferences in a specific context. The whole algorithm when the context changes and other user preferences is entirely based on the processing of OWL and OWL-s are to be applied. specifications and consists of the following steps. For the multimedia components of the communication ser- 1) Hardware Process the hardware description of the de- vice, we made use of the IBM Mpeg4 Java toolkit [21] vice to discover resource specifications, such as max- and for the OWL parsing and reasoning the Jena2 frame- imum available memory, processing power, network work [22] is used. The necessary infrastructure support for bandwidth, etc., as well as support for user input and instantiating a customized service based on the service model output, such as microphone, camera, speaker, keyboard, was developed on top of Draco [23], an extensible runtime display, sensors, etc. This is part of the context specifi- system for components designed to be run on embedded cation of a device and is largely static information. devices. It acts as a component container that instantiates 2) Resource awareness Request the current available re- components and manages all connections between compo- sources from the context management system. This is nents. It has runtime support for non-functional concerns, such also part of the current context, but mostly dynamic as component distribution, live updates, contract monitoring information achieved by monitoring the system. and resource management. This runtime environment with extensions provides a unique test platform for validating the need to be considered to guarantee interoperability. The proposed service concepts in a ubiquitous computing context. authors are working on providing support for adaptational behavior, as already supported in our infrastructure using V. E VALUATION composite components. The authors also acknowledge the The case study has shown that for varying hardware and interference between functional and non-functional aspects resource descriptions the implemented infrastructure is able to and between different non-functional concerns. Additionally, compose and instantiate a service while also taking the user our infrastructure supports automated component selection and preferences into account. Another advantage is that composing composition using a context-driven approach. the service targeted at a specific device can also be carried out Efstratiou et al. [29] propose an architecture with support on a more powerful device when composing the service, for for context-aware service adaptation. The authors describe the example, on a personal hand-held would take too long. architectural requirements for adaptation control and coordi- Something that is currently not implemented is multi-party nation for mobile applications. The adaptation mechanisms to negotiation of which components to instantiate as there can respond to, for example, a change in resource availability, are be dependencies between component deployments on different less flexible than ours as the authors define operational modes devices. In the above example, there is no use in instantiating of an application together with a contextual trigger that would a video encoding component on one device if the other party make the application switch to that mode. This coarse-grained is not able to process or show the video stream. adaptation mechanism allows them to use very simple XML The two non-functional concerns with respect to resource- descriptions of a service and operation mode. Our approach awareness and user-preferences in a certain context are easily does not require the software engineer to define all possible managed using a component-based methodology if all aspects instantiations of a service. Our composition infrastructures are fully specified. These aspects are specified by hand in takes care of finding an appropriate composition, which OWL using the Protégé [24] tool. We acknowledge that this additionally supports taking user preferences into account. is not a user friendly way to declare user preferences. Our infrastructure allows operation modes that the software However, not all non-functional aspects can be solved that developer originally may have not yet foreseen. easily using a component-based software engineering method- Lin et al. [30] propose a goal description language for ology. For cross-cutting concerns, such as security or logging, automatic composition of semantic web services. The authors an aspect-oriented software development approach (AOSD) acknowledge that it is hard to adapt to users’ requirements can prove to be more useful. Security concerns, for example, in current web service compositions, and propose a goal relate to the connection between components and may impose description language based on the OWL ontology description restrictions on how to customize and adapt pervasive services, language to describe the goals that need to be achieved, such as restricting the relocation of parts of a service to another relationships within goals, constraints for achieving the goals, device to avoid interception of sensitive messages sent over and a way to detect any inconsistencies in the specified goals. a network. The disadvantage of using AOSD techniques is However, this language for automatic composition is targeted that depending on the tools applied, such as AspectJ [25], at web services and does not consider the non-functional the technology can be quite invasive while modifying the requirements of pervasive services as mentioned in a previous component in such a way that other non-functional concerns, section. such as resource requirements, are no longer guaranteed to be correct. VII. C ONCLUSION AND FUTURE WORK We have developed infrastructure support for automated VI. R ELATED WORK context-driven composition of components into pervasive ser- Two very well-known component models are OMG’s vices, while taking into account non-functional concerns such CORBA Component Model (CCM) [26] and Sun’s Enterprise as the capabilities and limitations of a device on which it will JavaBeans (EJB) [27]. However, both only provide limited be deployed, resource availability and user preferences in a support for non-functional concerns, such as persistency, trans- specific context. It lets the software engineer focus on the actions and access control. Neither of them provide support for application logic of smaller building blocks, while optimal dynamic selection of component instantiations. deployment of a service on a specific device and adaptation The COMQUAD component model [28] provides support support for responding to changing working conditions is for non-functional aspects and describes them orthogonally managed by our supporting infrastructure. to the application structure using descriptors. These non- First, we have identified several non-functional concerns functional aspects are woven into the application using an with respect to pervasive services and then discussed how a AOSD approach based on the non-functional properties of component-based methodology can alleviate these concerns. components. Additionally, the COMQUAD component model We formalized the component methodology by creating a has extensions to provide support for stream-based commu- meta-model of all software aspects of components to allow au- nication. However, selecting components based on functional tomated processing of the functional and non-functional prop- properties is not the goal of the authors. In our composition erties of components and services. We discussed how context- infrastructure, both functional and non-functional properties awareness can be used for composition of component-based services using our previous work on context modeling [4], [12] Korpipää, P., et al., “Managing context information in mobile devices,” specification of pervasive services [5] and context management IEEE Pervasive Computing, Mobile and Ubiquitous Systems, vol. 2, no. 3, pp. 42–51, July-September 2003. support [6]. We illustrated the core ideas of our infrastructure [13] Indulska, J., et al., “Experiences in using cc/pp in context-aware sys- support by means of an example, and gave an outline of all tems,” in LNCS 2893: Proceedings of 4th IFIP WG 6.1 International the steps in the procedure to achieve a customized service. Conference on Distributed Applications and Interoperable Systems (DAIS2003), ser. Lecture Notes in Computer Science (LNCS), J.-B. We evaluated our work and can conclude that for targeting Stefani, I. Dameure, and D. Hagimont, Eds., vol. 2893. Paris/France: a specific platform and incorporating user preferences, our Springer Verlag, November 2003, pp. 224–235. automated context-driven composition infrastructure is able [14] S. Buchholz, T. Hamann, and G. Hubsch, “Comprehensive structured context profiles (cscp): Design and experiences,” in Proceedings to provide the necessary support for these non-functional of the Second IEEE Annual Conference on Pervasive Computing concerns typical for pervasive services. and Communications Workshops, March 2004. [Online]. Available: However, more work should be carried out to provide sup- citeseer.ist.psu.edu/690057.html [15] Strang. T., et al., “CoOL: A Context Ontology Language to enable port for cross-cutting non-functional concerns, such as secu- Contextual Interoperability,” in LNCS 2893: Proceedings of 4th IFIP rity. Security requirements cannot be derived from component WG 6.1 International Conference on Distributed Applications and descriptions as is the case for resource requirements. Future Interoperable Systems (DAIS2003), ser. Lecture Notes in Computer Science (LNCS), J.-B. Stefani, I. Dameure, and D. Hagimont, Eds., vol. work in the short term will focus on how to integrate multi- 2893. Paris/France: Springer Verlag, November 2003, pp. 236–247. party negotiation for selecting and instantiating components in [Online]. Available: http://www.kn.op.dlr.de/∼strang/paper/dais2003 the presence of dependencies between component deployments [16] Gu, T., et al., “An ontology-based context model in intelligent envi- ronments,” In Proceedings of Communication Networks and Distributed on different devices. Systems Modeling and Simulation Conference, San Diego, California, USA, January 2004. R EFERENCES [17] H. Chen, T. Finin, and A. Joshi, “An ontology for context-aware [1] M. Weiser, “The world is not a desktop,” Interactions, pp. 7–8, Jan. pervasive computing environments,” Special Issue on Ontologies for 1994. Distributed Systems, Knowledge Engineering Review, 2003. [2] M. Weiser, “The Computer for the Twenty-First Century,” Scientific [18] DistriNet (K.U.Leuven), EDM (LUC), ELIS-PARIS (UGent), PROG American, pp. 99–104, Sept. 1991. (VUB) and SSEL (VUB), “CoDAMoS: Context Driven Adaptation of [3] C. Szyperski, Component Software: Beyond Object-Oriented Program- Mobile Services,” http://www.cs.kuleuven.ac.be/cwis/research/distrinet/ ming, 2nd edition. Addison-Wesley and ACM Press, 2002. projects/CoDAMoS/. [4] D. Preuveneers, J. Van den Bergh, D. Wagelaar, A. Georges, P. Rigole, [19] The OWL Services Coalition, “OWL-S: Semantic Markup for Web Ser- T. Clerckx, Y. Berbers, K. Coninx, V. Jonckers, and K. De Bosschere, vices, Release 1.1,” http://www.daml.org/services/owl-s/1.1/index.html, “Towards an extensible context ontology for Ambient Intelligence,” in November 2004. Proceedings of the Second European Symposium on Ambient Intelli- [20] BBN Technologies, “vOWLidator, version 20040716,” gence. Springer-Verlag, November 2004. http://projects.semwebcentral.org/projects/vowlidator/, 2004. [5] D. Preuveneers and Y. Berbers, “Semantic and syntactic modeling [21] IBM alphaWorks, “IBM Toolkit for MPEG-4,” of component-based services for context-aware pervasive systems us- http://www.alphaworks.ibm.com/tech/tk4mpeg4. ing OWL-s,” in Proceedings of 1st International Workshop on Man- [22] HP Labs, “Jena 2 - A Semantic Web Framework,” http://www.hpl.hp. aging Context Information in Mobile and Pervasive Environments com/semweb/jena2.htm, 2004. (MCMP2005) (to appear), Ayia Napa, Cyprus, May 2005. [23] Y. Vandewoude, “Draco: An adaptive runtime environment for compo- [6] D. Preuveneers and Y. Berbers, “Adaptive context management using nents ,” http://www.cs.kuleuven.ac.be/˜yvesv/Draco/index.html. a component-based approach,” in LNCS 3543: Proceedings of 5th IFIP [24] Stanford Medical Informatics, “The Protégé Ontology Editor and International Conference on Distributed Applications and Interoperable Knowledge Acauisition System,” http://protege.stanford.edu/, 2005. Systems (DAIS2005) (to appear), ser. Lecture Notes in Computer Science [25] The AspectJ project, “aspectj - crosscutting objects for better modular- (LNCS), L. Merakos, N. Alonistioti, and L. Kutvonen, Eds., vol. 3543. ity,” http://www.eclipse.org/aspectj/, 2005. Athens, Greece: Springer, June 2005, pp. 14–26. [26] Object Management Group, “CORBA Component Model, v3.0,” [7] A. Wils, J. Gorinsek, S. Van Baelen, Y. Berbers, and K. De http://www.omg.org/cgi-bin/apps/doc?formal/02-06-65.pdf, 2005. Vlaminck, “Flexible Component Contracts for Local Resource [27] Sun Microsystems, “The Enterprise JavaBeans 2.1 specification,” Awareness,” in ECOOP 2003 Workshop on resource aware computing, http://java.sun.com/products/ejb/docs.html, 2005. C. Bryce and G. Czajkowski, Eds., July 2003. [Online]. Available: [28] S. Göbel, C. Pohl, S. Röttger, and S. Zschaler, “The COMQUAD http://www.cs.kuleuven.ac.be/∼andrew/stuff/ecoop2003.pdf component model: enabling dynamic selection of implementations by [8] P. Rigole, Y. Berbers, and T. Holvoet, “Mobile adaptive tasks guided by weaving non-functional aspects,” in AOSD ’04: Proceedings of the resource contracts,” in the 2nd Workshop on Middleware for Pervasive 3rd international conference on Aspect-oriented software development. and Ad-Hoc Computing, Toronto, Ontario, Canada, October 2004, pp. New York, NY, USA: ACM Press, 2004, pp. 74–82. 117–120. [29] C. Efstratiou, K. Cheverst, N. Davies, and A. Friday, “An architecture [9] Y. Vandewoude and Y. Berbers, “Run-time evolution for embedded for the effective support of adaptive context-aware applications,” component-oriented systems,” in Proceedings of the International Con- in Proceedings of 2nd International Conference in Mobile Data ference on Software Maintenance, B. Werner, Ed. Canada: IEEE Management (MDM‘01), vol. Lecture Notes in Computer Science Computer Society, October 2002, pp. 242–245. Volume 1987. Hong Kong: Springer, January 2001, pp. 15–26. [10] D. Urting, S. Van Baelen, T. Holvoet, and Y. Berbers, “Embedded [Online]. Available: citeseer.ist.psu.edu/efstratiou01architecture.html software development: Components and contracts,” in Proceedings of the [30] M. Lin, H. Guo, and J. Yin, “Goal description language for semantic IASTED International Conference Parallel and Distributed Computing web service automatic composition.” in SAINT, 2005, pp. 190–196. and Systems, 2001, pp. 685–690. [11] A. K. Dey, D. Salber, and G. D. Abowd, “A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications,” Human-Computer Interaction (HCI) Journal, vol. 16, no. 2-4, pp. 97–166, 2001.