In ubiquitous computing environments, an application describes a task that needs to be performed to satisfy a high-level user's goal. When an application is executed it is important to understand the context of the user and his/her surrounding environment, in order to dynamically instantiate a task by using available services. This task-instantiation process faces the problem of complexity in choosing appropriate services for a task. In order to improve the performance of dynamically choosing and binding services, in this paper we propose a template-based mechanism to dynamically select and compose services according to the context information predicted in advance. This mechanism ensures continuous service provision, service conflict prediction and resolution, and dynamic reconfiguration of services. To make use of predicted context, our mechanism provides the following capabilities: (1) task-based context prediction, (2) template-based task execution and (3) pattern-based service composition. We developed a task-oriented architecture to support these capabilities. Our dynamic service composition mechanism contributes to improve the reusability, flexibility and dynamism of ubiquitous computing applications.
Ubiquitous computing (ubicomp) is a forward state
of distributed systems (DS) and mobile computing
(MC). Some of the supporting technologies (embedded
devices, components services, communications
capabilities and others) in ubicomp correspond to those
in DS and MC (Satyanarayanan, 2001) [13]. The
difference is that ubicomp is user-centric. That is, such
ubicomp applications (UCAs) must satisfy users’ goals,
which are usually represented in tasks [
Context information corresponds to the user’s state
and his/her space [
The task-instantiation process must occurs with the minimum delay from the UCA identifies the task until its satisfaction. In this sense, our work strives to incorporate proactivity into the UCA. In a proactive system, the state at time t depends on the current, past and predicted future states [12]. As was explained before, the state of the user and his/her space corresponds to the context information. Thus, our idea is to provide to the UCA not only with the current context information, but also with predicted context [cf. 12]. In order to enable the UCA to proactively deliver services, this predicted context need to be of high-level. In Ubicomp, high-level context is represented in tasks.
A proactive as well as a reactive task-instantiation process faces the problem of complexity in selecting appropriate services for a task. This complexity can be reduced by improving the performance of dynamically selecting and binding services. In this sense, we propose a template-based mechanism to dynamically select and compose services according to the context information predicted in advance. This mechanism ensures continuous service provision, service conflict prediction and resolution, and dynamic reconfiguration of services. Our dynamic service composition mechanism provides three major capabilities: (1) taskbased context prediction –making use of the work of Mayrhofer et al. [12]-, (2) template-based task execution and (3) pattern-based service composition. The organization of those capabilities results in a taskoriented architecture.
Our solution contributes to improve the reusability, flexibility and dynamism of UCAs. In fact, templates and patterns can be reused for others UCAs, which can be made by composing patterns. That is, patterns can be composed dynamically to meet dynamicallychanged user’s tasks. Current ubicomp frameworks do not provide such template and patterns reusability.
The rest of the paper is organized as follow. In section 2 we introduce the related work in ubicomp and context prediction. Section 3 provides a brief explanation of task-oriented applications execution and the design of our task-oriented architecture. Section 4 provides the dynamic template-based service composition mechanism. In Section 5 we describe a 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.
Ubicomp is an active research issue. In fact, several
abstract frameworks have been proposed to develop
UCAs that use context information. However, in
relation to our work, can be mentioned those that use
historical data. In that category we can find examples
like CASS [
There exist some works related with predicting high-level context from user behavior, which, for instance, have been addresses by Mayrhofer et al. in [12]. In fact, in this work, user behavior in several domains can be gathered and analyzed in order to predict future user context from historical data, delivering proactive services to the user. This prediction depends on the current and future state of the environment and UCA context, which is captured for suitable sensors.
According to [12], one of the most important
constraints in future context is that its capture and
prediction have to be during run-time, in order to
ensure that running applications do not stop and
continuously provide services to the user. On the other
hand, the system also might provide prediction of the
available resources, such as network bandwidth or
memory space [
An architecture for context prediction has been introduced in the work of Mayrhofer et al., which can be implemented making use of specific type of sensors, classification algorithms and forecast techniques. In order to achieve their goals, the authors propose the use of classification algorithms, which can determine which action is the closest to the current situation in order to proactively prepare a future task execution.
In short, in order to forecast context to improve the task plan generation and deliver proactive services to the user during run-time, it is possible to process and classify gathered raw sensor data of a current state, enabling the prediction of future context based on this historical data.
This section introduces the context prediction model to be used as part of our dynamic templatebased service composition mechanism. As was stated in the second section, this model is based on the work of Mayrhofer et al. in [12]; however, in this paper is provided our own interpretation of the model.
The first definition for the context prediction model
corresponds to “internal context” of the UCA at time t,
which is established, based on the sensor data. Internal
context depends on the current context, the last context
and the input value at time t-1. The model output at
time t depends on this internal context and on predicted
future contexts. Future contexts are predicted
recursively making use of suitable algorithms, such as
clustering, neural networks, time series techniques, etc.
[12]. The complete process considers the following
steps:
Sensor data acquisition: raw sensor data gathered
at time t, defines a sensor vector s in the sensor
space S, with (s1 x s2 x …..x sL)t S1 x S2 x …..x
SL, which dimension is adjusted to the nature of
the sensor measurement (brightness, audio,
temperature, etc.)
Feature extraction: the sensor vector s is
transformed into the feature space F, contracting or
expanding it in order to better interpretation and
computation management. S F. The new vector
f in F is called feature vector, with (f1 x f2 x …..x
fn)t F1 x F2 x …..x Fn . For instance the sensor
vector can be scaled to the interval [
! Feature extraction ! Classification ! Labeling ! Prediction Predicition: It is defined the future class vector (c1 x c2 x …..x cm)s = p((c1 x c2 x …..x cm)t , t, s), whit (s > t) and p an iterative process. The results are Sensor Data 1 Sensor Data 2 Sensor Data 3 Sensor Data n
C1 C2 Cm ! Exercising ! Taking a rest ! Taskt ! Taskt+ " the future classes in s, based on time t, which is the predicted context.
Task-driven computing enables the UCA to access explicit computing tasks and task context, automatic service configuration and composition, manage computing resources constraints and dynamic services. In this sense, the benefits to users are that they can accomplish high-level tasks with transparency of lowlevel configuration activities (manual configuration of single devices such as desktop computers, laptops, PDAs, or manual transference of users; state among those devices, or mapping of their tasks by themselves)
In this paper, a task is defined as a set of actions organized in a sequential or parallel way. An action is a high-level function defined according to the user’s perspective. In this sense, a task attempts to formally and explicitly represent high-level user’s goals, such as preparing a presentation, taking a rest, editing a document in the airport, meeting scheduling, etc.
In real world, users require to move from one to another task or to continue performing a specific one. In short, it is task transition and task continuity respectively. In fact, given an interruption of a task, the system has to be able to realize when the user attempts to retake it, providing continuity in the same or another space. In addition, task transition is verified when users require to change from one to another task.
The organization of these actions constitutes a task plan, which involves a generation effort to the UCA that can be reduced. In fact, making use of high-level predicted context, can be determined a future action of other task, that switch with the current action in a given task. Actually, can be determined several different tasks that match with the current action. Therefore, in order to reduce the efforts to generate the task plan, there exists the need of a mechanism to decide between the set of predicted future tasks. However, it is not in the focus of this paper.
As is noted in this paper, there is a benefit utilizing the capability of context prediction in order to dynamically compose services in advance. In addition, this goal is pursued through two more capabilities provided by this paper: template-based task execution and pattern-based service composition. These capabilities are organized in a task-based architecture.
The fundamental definitions provided in this paper to design the task-oriented architecture are: application template and service composition pattern. In fact: i. Application template: a determined and descriptive way to organize actions in a suitable sequence (sequential or parallel) ii. Service composition pattern: a configuration or set of high-level abstract services or functions that are to perform actions.
In order to provide the required task-based architecture, let’s consider the following overall structure composed of its core elements. Main elements of our architecture are as follow (see figure 2): i. Context Manager: it receives low-level raw sensor data and performs high-level task context prediction, making use of the context predictor element. In addition, given the predicted task, an application template is selected from the repository through the application template broker. ii. Reconfiguration Manager: it deploys service composition patterns and makes a consolidated service composition pattern (for service conflict prediction and resolution) iii. Service Composition Pattern Broker: it searches appropriate service composition patterns to support actions in application template. 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 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 the context base repository. The context base repository holds high-level and low-level information. Regarding to high-level information are the tasks, actions and required quality attributes of them. This information must be determined in advance and is part of design work. Indeed, this repository stores the history of switched tasks. Regarding to low-level information, it is stored current and historical raw sensor data. A deep description of the context base repository can be done through an ontology description model, but it is not in the scope of this paper. The application template broker gets the predicted task from the application template repository.
The reconfiguration manager contains the service composition pattern broker, which gets the service composition patterns from the service composition pattern repository.
The requesting of services is done by the service
discovery, which interacts with the service repository.
There are several protocols that can be used in our
task-based architecture to accomplish the service
discovery process, such as UPnP, Jini, Salutation,
Service Location Protocol, Group-based Service
Discovery, etc. In all these protocols, service providers
make an advertisement of their services description and
attributes, following broadcast, unicast or multicast
strategies. For instance, in Jini each service provider
finds out a lookup service to inform its service object
and service attribute. Then, a client requests a service
downloading the mobile code of the service object.
This service object is used by the client to invoke the
actual service from the service provider [
In this section, we describe our proposed service composition mechanism, to improve the performance of dynamically selecting and binding available services according to the context information predicted in advance, reducing the complexity of this process. This mechanism makes use of our introduced application template and service composition pattern definitions.
The mechanism has as input low-level raw sensor data that generate the current task context (state). Consequently, it predicts during run-time the context determining next tasks that have to be performed, enabling to UCA proactively configure, initialize and compose accessible services in advance. In this sense, proactivity ensures that the task-instantiation process is verified with the minimum delay from the UCA identifies the task until the delivery of services to the user.
As is shown in the figure 3, the mechanism 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 context prediction model introduced in the section two and forecast the next tasks. Given the predicted task 1 , the context predictor communicates the task features to the application template broker, element that is in charge of gather in advance an adequate predetermined task from the application template repository. In advance means before the task is actually required to be executed by the UCA. Once selected the adequate task that match well with the predicted one’s features, the application template broker gets the set of actions that conform the task and that will be necessary to map to service composition patterns. For each action, the service composition pattern broker must search service composition patterns into the service composition pattern repository. Given the service composition pattern, the service discovery requests actual services from the service repository or other distributed repositories. The searching trials into the service repository are delimited by the required functionality contained in each given service composition pattern. The actual services are bounded and executed to perform the service composition pattern, and consequently perform task actions.
In this section, we describe a simple scenario of using the service composition mechanism. This scenario shows how the UCA makes use of predicted context to compose in advance the services that are required for a future task. The involved tasks are: “exercising” task and “taking a rest” task in a home space. We assume that there is one user at home, and 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 machines are. v. The application template for exercising is activated by the reconfiguration manager. vi. Actions (e.g. “making the room cooler”, “making the exercising machines available”) and services (e.g. “open the windows”, “turn on the running machine”) are executed. vii. During the exercising, the context manager collects sensor data (e.g. temperature of John’s body and the room, passed time of exercising, burnt calories of user). viii. The context manager predicts that the user will take a rest after exercising and select “taking a rest” task. Then the application template for “taking a rest” is selected. ix. When John finishes his exercises, the application template for taking a rest is activated and actions (e.g. “making room darker”, “making room quiet”) and services (e.g. “make lights darker”, “make AV devices quiet”) are executed (See figure 5) //Given a current task Gather_Sensor_Data () {
s := sensor_vector; } Gather_context_repository_information ()
hi := historical_information; } Context_prediction (s, hi) {
Feature_extraction () {
f := feature vector; } Classification (f) {
ci := classi; //Detected user context } Labeling (ci) { nt := contextt; //Predefined context names }
Prediction (nt); } Get_task_application_template_repository (predicted_task); //Application template broker Get_actions (task); //Application template broker For each actioni {
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)
Application templates and service composition patterns are described making use of ACME architecture description language, as preliminary depicted in figure 6.
Main feature of our mechanism includes the
highlevel abstract representation of actual services into
service composition patterns, which reduces the
necessary searching trials into the set of primitive
services. Therefore, this mechanism reduces the
complexity of selecting suitable services for a task, and
improves the required process. As this abstract
representation is linked with the user’s goals through
the reusable application templates, which are not
present in other popular ubicomp frameworks such as
Aura [
We are currently working in the implementation of
a prototype of our task-oriented architecture to perform
experiments in our test-bed [
In this paper we provide a task-oriented architecture and a template-based mechanism for dynamic service composition in UCAs based on the predicted context. We have introduced two key definitions considered in our architecture and mechanism: application template and service composition pattern. By the means of the template-based mechanism, the UCA makes a coordinated transition in advance between different tasks based on predicted tasks, reducing the complexity of the service composition.
Our solution contributes providing an improvement of UCAs’ reusability. In fact, an application template constitutes a reusable structure for a specific task, and the service composition patterns can be reused for other UCAs. In addition, there is an improvement of flexibility that can be incorporated during design time. } } System making_the_room_quiet ={ Component Making_AV_Devices_quiet= {
Component AV_Services = { ports send; operations{AV_service.setVolmueLevel(2);} properties {rdfsource : string = http://as.icu.ac.kr/services#av_services}}
Connector AudioRequest = { Role { request; response } } }Attachments { ….. } Component Making_cleaning_devices_off ={ operations{cleaningDevices.turnOff()} properties {patternSource : string = http://as.icu.ac.kr/patterns#making_doors_cloased} } Component Making_doors_closed ={ operations{doors.close()} properties {patternSource : string = “http://as.icu.ac.kr/patterns#making_doors_cloased”} } Component Making_windows_closed ={ operations{windows.close()} properties {patternSource : string = “http://as.icu.ac.kr/patterns#making_windows_closed”}
In fact, UCAs can be made by composing patterns, and patterns can be used for many UCAs, rather than considering composition of actual services.
Also our solution contributes with an improvement of dynamism. Patterns can be composed dynamically to meet dynamically-changed user’s goals and to deal with dynamically-changed space conditions, based on context information. Patterns provide units for dynamic reconfiguration of UCAs during run-time, rather than reconfiguration of real services. In addition, our taskoriented architecture can provide user-perspective services by using high-level patterns and services, rather than system-perspectives. In this sense, there is a separation of users’ concern from actual services.
Our future work considers the performance evaluation of the proposed service composition mechanism through two specific metrics: number of service provision interruptions and the required searching trials of actual services in long term execution.
We are currently working on the problem of service conflict prediction and resolution in an abstract level. For instance, the application template “making the room quiet” will require the service composition pattern “making windows closed”. However, an application template such “making the room cooler”, will require the service composition pattern “making windows opened”. In this sense the conflict should be predicted and resolved through some mechanism, such as providing alternative services, working with priorities of services or performing negotiations between services.
An interesting future work is related with executing an off line context prediction. In this case it will be necessary to design a way to detect common patterns into tasks. These patterns can be deduced from the historical data making use of clustering algorithms that create groups of related information. Patterns can be used in the future for a better reaction of UCAs. Also patterns can be stored in a new repository accessible from the context manager. Offline context prediction would require incorporating into the context prediction model, an additional steps such logging of the tasks sequences into the repository.
Acknowledgments. This research is supported by the ubiquitous computing and network (UCN) project, the Ministry of Information and Communication (MIC) 21st Century Frontier R&D Program in Korea. The authors would also like to thank Gonzalo Huerta Canepa for his comments on the draft.
[12] R Mayrhofer, H Radi, A Ferscha . “Recognizing and Predicting Context by Learning from User Behavior“. Institute for Pervasive Computing, Johannes Kepler Universitat Linz; Proceedings of The International Conference On Advances in Mobile Multimedia, Volume 171; September 2003.