=Paper=
{{Paper
|id=Vol-302/paper-2
|storemode=property
|title=A Template-Based Mechanism for Dynamic Service Composition Based on Context
|pdfUrl=https://ceur-ws.org/Vol-302/paper1.pdf
|volume=Vol-302
}}
==A Template-Based Mechanism for Dynamic Service Composition Based on Context==
https://ceur-ws.org/Vol-302/paper1.pdf
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