A Template-Based Mechanism for Dynamic Service Composition Based on Context Prediction in Ubicomp Applications Ángel Jiménez Molina, Hyung-Min Koo, In-Young Ko Information and Communications University, 119 Munji-Ro, Yuseong-Gu, Daejeon, Korea {ajimenez, hyungminkoo, iko}@icu.ac.kr Abstract which are usually represented in tasks [18]. In order to satisfy tasks, UCAs need to gather users’ goals and In ubiquitous computing environments, an application context information [11] through embedded devices describes a task that needs to be performed to satisfy a and others. high-level user’s goal. When an application is Context information corresponds to the user’s state executed it is important to understand the context of and his/her space [14]. For instance, physical location, the user and his/her surrounding environment, in order emotional state, physiological state, daily recurrent to dynamically instantiate a task by using available activities, users’ profile, or the room temperature, light services. This task-instantiation process faces the and humidity, network bandwidth, etc. When an UCA problem of complexity in choosing appropriate is executed, it is important to understand and interpret services for a task. In order to improve the the context information, and based on it, execute performance of dynamically choosing and binding adequate services to satisfy high-level users’ tasks. services, in this paper we propose a template-based Services that meet tasks may come from multiple mechanism to dynamically select and compose services heterogeneous computing resources, which are usually according to the context information predicted in connected by the means of a middleware infrastructure. advance. This mechanism ensures continuous service This infrastructure dynamically instantiates tasks into provision, service conflict prediction and resolution, available services, which need to be conveniently and dynamic reconfiguration of services. To make use configured, initialized and composed [1], [4], [17], of predicted context, our mechanism provides the [15]. following capabilities: (1) task-based context The task-instantiation process must occurs with the prediction, (2) template-based task execution and (3) minimum delay from the UCA identifies the task until pattern-based service composition. We developed a its satisfaction. In this sense, our work strives to task-oriented architecture to support these capabilities. incorporate proactivity into the UCA. In a proactive Our dynamic service composition mechanism system, the state at time t depends on the current, past contributes to improve the reusability, flexibility and and predicted future states [12]. As was explained dynamism of ubiquitous computing applications. before, the state of the user and his/her space corresponds to the context information. Thus, our idea Keywords: Ubiquitous computing, context prediction, context is to provide to the UCA not only with the current awareness, task-oriented computing, architecture-driven context information, but also with predicted context [cf. systems. 12]. In order to enable the UCA to proactively deliver services, this predicted context need to be of high-level. 1. Introduction In Ubicomp, high-level context is represented in tasks. A proactive as well as a reactive task-instantiation Ubiquitous computing (ubicomp) is a forward state process faces the problem of complexity in selecting of distributed systems (DS) and mobile computing appropriate services for a task. This complexity can be (MC). Some of the supporting technologies (embedded reduced by improving the performance of dynamically devices, components services, communications selecting and binding services. In this sense, we capabilities and others) in ubicomp correspond to those propose a template-based mechanism to dynamically in DS and MC (Satyanarayanan, 2001) [13]. The select and compose services according to the context difference is that ubicomp is user-centric. That is, such information predicted in advance. This mechanism ubicomp applications (UCAs) must satisfy users’ goals, ensures continuous service provision, service conflict International Workshop on Intelligent Web Based Tools (IWBT-07) in conjunction with 19th IEEE ICTAI-07 1 prediction and resolution, and dynamic reconfiguration the environment and UCA context, which is captured of services. Our dynamic service composition for suitable sensors. mechanism provides three major capabilities: (1) task- According to [12], one of the most important based context prediction –making use of the work of constraints in future context is that its capture and Mayrhofer et al. [12]-, (2) template-based task prediction have to be during run-time, in order to execution and (3) pattern-based service composition. ensure that running applications do not stop and The organization of those capabilities results in a task- continuously provide services to the user. On the other oriented architecture. hand, the system also might provide prediction of the Our solution contributes to improve the reusability, available resources, such as network bandwidth or flexibility and dynamism of UCAs. In fact, templates memory space [18]. Unfortunately, usually there are and patterns can be reused for others UCAs, which can not enough log data for analyzing it offline, such as in be made by composing patterns. That is, patterns can knowledge discovery in databases approach. Therefore, be composed dynamically to meet dynamically- our approach is based on providing future context changed user’s tasks. Current ubicomp frameworks do prediction during run-time. not provide such template and patterns reusability. An architecture for context prediction has been The rest of the paper is organized as follow. In introduced in the work of Mayrhofer et al., which can section 2 we introduce the related work in ubicomp and be implemented making use of specific type of sensors, context prediction. Section 3 provides a brief classification algorithms and forecast techniques. In explanation of task-oriented applications execution and order to achieve their goals, the authors propose the use the design of our task-oriented architecture. Section 4 of classification algorithms, which can determine which provides the dynamic template-based service action is the closest to the current situation in order to composition mechanism. In Section 5 we describe a proactively prepare a future task execution. sample scenario for our service composition      mechanism. In section 6 we evaluate our mechanism.        Finally, we draw a conclusion and explain future work         in section 7.                2. Related Work                  Ubicomp is an active research issue. In fact, several          abstract frameworks have been proposed to develop  UCAs that use context information. However, in In short, in order to forecast context to improve the relation to our work, can be mentioned those that use task plan generation and deliver proactive services to historical data. In that category we can find examples the user during run-time, it is possible to process and like CASS [7], CoBra [6], Context Toolkit [2], classify gathered raw sensor data of a current state, CORTEX [4], Gaia [8], SOCAM [9], etc. However, enabling the prediction of future context based on this none of them provide a proactive way of selecting and historical data. binding services. The Aura project [18] has works related to computing resource prediction during run- 2.1 Context Prediction Model time. The goal of this prediction is to maximize users’ utility allocating resources to UCAs based on an This section introduces the context prediction instantaneous evaluation of configuration. However model to be used as part of our dynamic template- this work does not consider high level context based service composition mechanism. As was stated in prediction, which corresponds to the task desired by the the second section, this model is based on the work of user, inferred from the user’s state and his/her space. Mayrhofer et al. in [12]; however, in this paper is There exist some works related with predicting provided our own interpretation of the model. high-level context from user behavior, which, for The first definition for the context prediction model instance, have been addresses by Mayrhofer et al. in corresponds to “internal context” of the UCA at time t, [12]. In fact, in this work, user behavior in several which is established, based on the sensor data. Internal domains can be gathered and analyzed in order to context depends on the current context, the last context predict future user context from historical data, and the input value at time t-1. The model output at delivering proactive services to the user. This time t depends on this internal context and on predicted prediction depends on the current and future state of future contexts. Future contexts are predicted International Workshop on Intelligent Web Based Tools (IWBT-07) in conjunction with 19th IEEE ICTAI-07 2 recursively making use of suitable algorithms, such as the future classes in s, based on time t, which is the clustering, neural networks, time series techniques, etc. predicted context. [12]. The complete process considers the following steps: 3. Tasks-Oriented Architecture  Sensor data acquisition: raw sensor data gathered Task-driven computing enables the UCA to access at time t, defines a sensor vector s in the sensor explicit computing tasks and task context, automatic space S, with (s1 x s2 x …..x sL)t  S1 x S2 x …..x service configuration and composition, manage SL, which dimension is adjusted to the nature of computing resources constraints and dynamic services. the sensor measurement (brightness, audio, In this sense, the benefits to users are that they can temperature, etc.) accomplish high-level tasks with transparency of low- level configuration activities (manual configuration of  Feature extraction: the sensor vector s is single devices such as desktop computers, laptops, transformed into the feature space F, contracting or PDAs, or manual transference of users; state among expanding it in order to better interpretation and those devices, or mapping of their tasks by themselves) computation management. S  F. The new vector In this paper, a task is defined as a set of actions f in F is called feature vector, with (f1 x f2 x …..x organized in a sequential or parallel way. An action is a fn)t  F1 x F2 x …..x Fn . For instance the sensor high-level function defined according to the user’s vector can be scaled to the interval [0,1]. perspective. In this sense, a task attempts to formally and explicitly represent high-level user’s goals, such as  Classification: the context predictor finds out preparing a presentation, taking a rest, editing a common patterns in the feature space, defining document in the airport, meeting scheduling, etc. clusters. In this sense, the feature vector in F is In real world, users require to move from one to assigned to one cluster c, or multiple clusters with another task or to continue performing a specific one. different degree of membership, in the space C, In short, it is task transition and task continuity with (c1 x c2 x …..x cm)t  C1 x C2 x …..x Cm. The respectively. In fact, given an interruption of a task, the classes {ci} constitute the detected context in the system has to be able to realize when the user attempts space C. to retake it, providing continuity in the same or another space. In addition, task transition is verified when users  Labeling: in this step each class is assigned to require to change from one to another task. predetermined strings in N that denote descriptive The organization of these actions constitutes a task names. These descriptive names are defined plan, which involves a generation effort to the UCA according to the current space features. In this that can be reduced. In fact, making use of high-level sense, C1 x C2 x …..x Cm  N. A context label nt  predicted context, can be determined a future action of N describes the current context at time t. other task, that switch with the current action in a given task. Actually, can be determined several different Sensor Data 1 tasks that match with the current action. Therefore, in Sensor C1 ! Taskt order to reduce the efforts to generate the task plan, Data 2 ! Exercising there exists the need of a mechanism to decide between C2 Sensor the set of predicted future tasks. However, it is not in Data 3 the focus of this paper. ! Taskt + " As is noted in this paper, there is a benefit utilizing Cm ! Taking a rest the capability of context prediction in order to Sensor dynamically compose services in advance. In addition, Data n this goal is pursued through two more capabilities ! Feature extraction ! Classification ! Labeling ! Prediction provided by this paper: template-based task execution and pattern-based service composition. These Fig. 1 Context Prediction Model capabilities are organized in a task-based architecture. The fundamental definitions provided in this paper  Predicition: It is defined the future class vector (c1 to design the task-oriented architecture are: application x c2 x …..x cm)s = p((c1 x c2 x …..x cm)t , t, s), whit template and service composition pattern. In fact: (s > t) and p an iterative process. The results are i. Application template: a determined and International Workshop on Intelligent Web Based Tools (IWBT-07) in conjunction with 19th IEEE ICTAI-07 3 descriptive way to organize actions in a suitable information, it is stored current and historical raw sequence (sequential or parallel) sensor data. A deep description of the context base repository can be done through an ontology description ii. Service composition pattern: a configuration or model, but it is not in the scope of this paper. The set of high-level abstract services or functions that application template broker gets the predicted task are to perform actions. from the application template repository. The reconfiguration manager contains the service In order to provide the required task-based composition pattern broker, which gets the service architecture, let’s consider the following overall composition patterns from the service composition structure composed of its core elements. Main elements pattern repository. of our architecture are as follow (see figure 2): The requesting of services is done by the service discovery, which interacts with the service repository. i. Context Manager: it receives low-level raw sensor There are several protocols that can be used in our data and performs high-level task context task-based architecture to accomplish the service prediction, making use of the context predictor discovery process, such as UPnP, Jini, Salutation, element. In addition, given the predicted task, an Service Location Protocol, Group-based Service application template is selected from the Discovery, etc. In all these protocols, service providers repository through the application template broker. make an advertisement of their services description and attributes, following broadcast, unicast or multicast ii. Reconfiguration Manager: it deploys service strategies. For instance, in Jini each service provider composition patterns and makes a consolidated finds out a lookup service to inform its service object service composition pattern (for service conflict and service attribute. Then, a client requests a service prediction and resolution) downloading the mobile code of the service object. This service object is used by the client to invoke the iii. Service Composition Pattern Broker: it searches actual service from the service provider [19]. In this appropriate service composition patterns to example the lookup service is like a directory support actions in application template. repository that in ubicomp environments is usually distributed. iv. Distributed repositories: they store application templates and service composition patterns in distributed environment. In addition, it provides a way to search appropriate application templates and service composition patterns from distributed repositories. v. Application Composition Tool: this tool supports developers for developing, registering into the repositories and simulating application templates and service composition patterns. The context manager acts given a current task. Indeed, its components are the context predictor and the application template broker. The context predictor Fig. 2 Overall Task-Oriented Architecture. is in charge of determining proactively the next task to be executed, based on the raw sensor data gathered by the devices, and the historical information keeps into 4. Dynamic Template-Based Service the context base repository. The context base Composition Mechanism repository holds high-level and low-level information. Regarding to high-level information are the tasks, In this section, we describe our proposed service actions and required quality attributes of them. This composition mechanism, to improve the performance information must be determined in advance and is part of dynamically selecting and binding available services of design work. Indeed, this repository stores the according to the context information predicted in history of switched tasks. Regarding to low-level advance, reducing the complexity of this process. This International Workshop on Intelligent Web Based Tools (IWBT-07) in conjunction with 19th IEEE ICTAI-07 4 mechanism makes use of our introduced application  For each action, the service composition pattern template and service composition pattern definitions. broker must search service composition patterns The mechanism has as input low-level raw sensor into the service composition pattern repository. data that generate the current task context (state).  Given the service composition pattern, the service Consequently, it predicts during run-time the context discovery requests actual services from the service determining next tasks that have to be performed, repository or other distributed repositories. The enabling to UCA proactively configure, initialize and searching trials into the service repository are compose accessible services in advance. In this sense, delimited by the required functionality contained proactivity ensures that the task-instantiation process is in each given service composition pattern. verified with the minimum delay from the UCA identifies the task until the delivery of services to the  The actual services are bounded and executed to user. perform the service composition pattern, and As is shown in the figure 3, the mechanism consequently perform task actions. introduced in this paper, begins with high-level user’s goals represented in tasks. Given a task, the mechanism considers a medium-level represented in actions. For each action are selected a set of service composition patterns, and finally several actual services to satisfy the user’s goal and execute the task. Therefore, our dynamic template-based service composition mechanism considers applying the following steps:  The context predictor receives low-level raw sensor data gathered from physical sensors. Indeed the context predictor selects historical raw sensor data and high-level information from the context base repository.  The context predictor makes use of the task Fig. 3 Dynamic Template-Based Service Composition context prediction model introduced in the section Mechanism. two and forecast the next tasks. Our proposed mechanism can be described in  Given the predicted task 1 , the context predictor pseudocode as depicted in figure 4. communicates the task features to the application template broker, element that is in charge of gather in advance an adequate predetermined task from 5. Sample Scenario the application template repository. In advance means before the task is actually required to be In this section, we describe a simple scenario of executed by the UCA. using the service composition mechanism. This scenario shows how the UCA makes use of predicted  Once selected the adequate task that match well context to compose in advance the services that are with the predicted one’s features, the application required for a future task. The involved tasks are: template broker gets the set of actions that “exercising” task and “taking a rest” task in a home conform the task and that will be necessary to map space. We assume that there is one user at home, and to service composition patterns. that user’s hobby is exercising. i. John comes to home from his job. ii. John changes his suit to training cloths, and then context manager finds out that John wants to             exercise and select the “exercising” task.                     iii. The application template for exercising is selected           and prepared for execution.               iv. John goes to the area where the exercising International Workshop on Intelligent Web Based Tools (IWBT-07) in conjunction with 19th IEEE ICTAI-07 5 machines are. Application templates and service composition v. The application template for exercising is activated patterns are described making use of ACME by the reconfiguration manager. architecture description language, as preliminary depicted in figure 6. vi. Actions (e.g. “making the room cooler”, “making the exercising machines available”) and services (e.g. “open the windows”, “turn on the running 6. Evaluation machine”) are executed. Main feature of our mechanism includes the high- vii. During the exercising, the context manager level abstract representation of actual services into collects sensor data (e.g. temperature of John’s service composition patterns, which reduces the body and the room, passed time of exercising, necessary searching trials into the set of primitive burnt calories of user). services. Therefore, this mechanism reduces the viii. The context manager predicts that the user will complexity of selecting suitable services for a task, and take a rest after exercising and select “taking a improves the required process. As this abstract rest” task. Then the application template for representation is linked with the user’s goals through “taking a rest” is selected. the reusable application templates, which are not present in other popular ubicomp frameworks such as ix. When John finishes his exercises, the application Aura [18], it inherits the required functionality from a template for taking a rest is activated and actions high-level user’s perspective. Therefore, our task- (e.g. “making room darker”, “making room quiet”) oriented architecture and template-based mechanism and services (e.g. “make lights darker”, “make AV constitute a topological optimization to enable the devices quiet”) are executed (See figure 5) dynamic service composition process to reduce its inherent complexity. The Following features are implied from our dynamic template-based service //Given a current task Gather_Sensor_Data () { composition: s := sensor_vector; } Gather_context_repository_information () hi := historical_information; i. High-level abstract service composition: services } Context_prediction (s, hi) { can be composed based on user-perspectives, Feature_extraction () { rather than system-perspectives. f := feature vector; } Classification (f) { ii. Dynamic reconfiguration of services: services ci := classi; //Detected user context and their composition can be dynamically } Labeling (ci) { reconfigurable based on changes of available nt := contextt; //Predefined context names services and environment conditions. } Prediction (nt); iii. Continuous Service Provision: predicted context } Get_task_application_template_repository enables the UCA to prepare the execution of tasks (predicted_task); //Application template broker Get_actions (task); //Application template broker in advance. It reduces interruptions to service For each actioni { provision, which is performed without a hitch. Get_service_composition_patterns_repository (actioni); //Service composition pattern broker For each service_composition_patternsj { Get_actual_services (service_composition_patternsj); //Service discovery } } Execute_actual_services (actual_servicek) Fig. 4 Pseudocode of the Dynamic Template-Based Service Composition Mechanism. Fig. 5 Taking a Rest Task. International Workshop on Intelligent Web Based Tools (IWBT-07) in conjunction with 19th IEEE ICTAI-07 6 iv. Service conflict prediction and resolution: In fact, UCAs can be made by composing patterns, conflicts can be detected and resolved by using and patterns can be used for many UCAs, rather than high-level abstraction mechanism, before considering composition of actual services. executions of actual services. It enables the UCA Also our solution contributes with an improvement to improve the use of its limited resources. of dynamism. Patterns can be composed dynamically to We are currently working in the implementation of meet dynamically-changed user’s goals and to deal a prototype of our task-oriented architecture to perform with dynamically-changed space conditions, based on experiments in our test-bed [20]. We will evaluate the context information. Patterns provide units for dynamic performance of our service composition mechanism reconfiguration of UCAs during run-time, rather than through two specific metrics: number of service reconfiguration of real services. In addition, our task- provision interruptions and the required searching trials oriented architecture can provide user-perspective of actual services in long term execution. By the means services by using high-level patterns and services, of the first metric, it is possible to perform a binary rather than system-perspectives. In this sense, there is a evaluation of the service provision continuity. The separation of users’ concern from actual services. second metric is a way to evaluate the reduction of Our future work considers the performance complexity in searching suitable services to execute a evaluation of the proposed service composition given task, and in switching them. mechanism through two specific metrics: number of service provision interruptions and the required searching trials of actual services in long term 7. Conclusion execution. We are currently working on the problem of service In this paper we provide a task-oriented architecture conflict prediction and resolution in an abstract level. and a template-based mechanism for dynamic service For instance, the application template “making the composition in UCAs based on the predicted context. room quiet” will require the service composition We have introduced two key definitions considered in pattern “making windows closed”. However, an our architecture and mechanism: application template application template such “making the room cooler”, and service composition pattern. By the means of the will require the service composition pattern “making template-based mechanism, the UCA makes a windows opened”. In this sense the conflict should be coordinated transition in advance between different predicted and resolved through some mechanism, such tasks based on predicted tasks, reducing the complexity as providing alternative services, working with of the service composition. priorities of services or performing negotiations between services. Our solution contributes providing an improvement An interesting future work is related with executing of UCAs’ reusability. In fact, an application template an off line context prediction. In this case it will be constitutes a reusable structure for a specific task, and necessary to design a way to detect common patterns the service composition patterns can be reused for into tasks. These patterns can be deduced from the other UCAs. In addition, there is an improvement of historical data making use of clustering algorithms that flexibility that can be incorporated during design time. create groups of related information. Patterns can be System making_the_room_quiet ={ Component Making_AV_Devices_quiet= { used in the future for a better reaction of UCAs. Also Component AV_Services = { patterns can be stored in a new repository accessible ports send; operations{AV_service.setVolmueLevel(2);} properties {rdfsource : string = http://as.icu.ac.kr/services#av_services}} from the context manager. Offline context prediction Connector AudioRequest = { Role { request; response } } Attachments { ….. would require incorporating into the context prediction } } model, an additional steps such logging of the tasks Component Making_cleaning_devices_off ={ operations{cleaningDevices.turnOff()} sequences into the repository. properties {patternSource : string = http://as.icu.ac.kr/patterns#making_doors_cloased} } Component Making_doors_closed ={ Acknowledgments. This research is supported by the operations{doors.close()} properties {patternSource : string = “http://as.icu.ac.kr/patterns#making_doors_cloased”} ubiquitous computing and network (UCN) project, the } Ministry of Information and Communication (MIC) Component Making_windows_closed ={ operations{windows.close()} properties {patternSource : string = “http://as.icu.ac.kr/patterns#making_windows_closed”} 21st Century Frontier R&D Program in Korea. The } authors would also like to thank Gonzalo Huerta } Canepa for his comments on the draft. Fig. 6 An example of Service Composition Patterns Description Written in ACME International Workshop on Intelligent Web Based Tools (IWBT-07) in conjunction with 19th IEEE ICTAI-07 7 8. References California, Irvine. Special Issue of Human Computer Interaction. Volume 16, 2001. [1] A. Dey, S. Salber, M. Futakawa, G. Abowd. “An [12] R Mayrhofer, H Radi, A Ferscha . “Recognizing and Architecture to Support Context-Aware Applications”. GVU Predicting Context by Learning from User Behavior“. Technical Report GIT-GVU-99-23, 1999. Institute for Pervasive Computing, Johannes Kepler Universitat Linz; Proceedings of The International [2] A. Dey. “Understanding and Using Context”. Personal Conference On Advances in Mobile Multimedia, Volume and Ubiquitous Computing, Vol 5, No 1, pp 4-7, 2001. 171; September 2003. [3] Baldauf M., Dustdar S., Rosenberg F. “A Survey on [13] Satyanarayanan, M. “Pervasive computing: vision and Context-Aware Systems”. International Journal of Ad Hoc challenges“. Carnegie Mellon Univ., Pittsburgh, PA; and Ubiquitous Computing, 2004. Personal Communications, IEEE, Volume 8; Aug 2001. [4] Biegel G, Cahill V. “A Framework for Developing [14] Schilit B, Adams N, Want R. “Context-Aware Mobile, Context-Aware Applications”. Trinity College Computing Applications”. Procsof IEEE Workshop on Dublin. In Proceedings of the 2nd IEEE Conference on Mobile Computing Systems and Applications. 1994. Pages Pervasive Computing and Communication, 2004. 85-90. [5] Bradbury, J.; Cordy, J.; Dingel, J.; Wemelinger, M. “A [15] Shang-Wen Cheng; Garlan, D; Schmerl, Sousa J; Survey of Self Management in Dynamic Software Spitznagel, B; Steenkiste, P; Ningning Hu. “Software Architecture Specifications”. Proc. Of the International Architecture-Based Adaptation for Pervasive Systems”. Workshop on Self-Managed Systems (WOSS’04), Newport Trends in Network and Pervasive Computing - ARCS 2002 : Beach, California, USA, October/November 2004. International Conference on Architecture of Computing Systems, Karlsruhe, Germany, April 8-12, 2002. Proceedings [6] Chen, H. “An Intelligent Broker Architecture for Pervasive Context-Aware Systems”. PhD thesis, University [16] Tae Seung Ha; Ji Hong Jung; Sung Yong Oh. “Method of Maryland, Baltimore County, 2004. to Analyze User Behavior in Home Environment”. Graduate School of Techno Design, Interaction Design Lab; Personal [7] Fahy P; Clarke, S. “CASS a Middleware for Mobile and Ubiquitous Computing, Springer-Verlag London, Context-Aware Applications”. In Workshop on Context Volume 10, numbers 2-3; April 2006. Awareness, MobiSys, 2004. [17] Yu-Sik Park; In-Young Ko; Sooyong Park. “A Task- [8] Gaia Project. University of Illinois at Urbana-Champaign. based Approach to Generate Optimal Software-Architecture At gaia.cs.uiuc.edu for Intelligent Service Robots”. Information and Communications University, Sogang University, Republic of [9] Gu, T; Pung, H; Zhang, D. “A Middleware for Building Korea, 2007. Context-Aware Mobile Services”. In Proceedings of IEEE Vehicular Technology Conference (VTC 2004), Milan, Italy, [18] Z. Wang and D. Garlan. Task-Driven Computing. 2004. Technical Report CMU-CS-00-154, School of Computer Science, Carnegie Mellon University, May 2000. [10] Hnetynka, P.; Plasil, F. “Dynamic Reconfiguration and Access to Services in Hierarchical Component Models”. [19] Jini Network Technology. Department of Software Engineering, Faculty of http://www.jini.org/wiki/Main_Page Mathematics and Physics, Charles University, Czech Republic. Proceedings of CBSE, 2006. [20] Group-aware Ubiquitous Computing Middleware System. Information and Communications University. [11] Moran T, Dourish P. “Introduction to Context-Aware http://as.icu.ac.kr/index.html Computing”. IBM Almaden Research Center, University of International Workshop on Intelligent Web Based Tools (IWBT-07) in conjunction with 19th IEEE ICTAI-07 8