Dynamic User Task Composition Based on User Preferences

TAA00003

ACM

(Typeset by SPi, Manila, Philippines) 1 of 17

February 15, 2011

7:27

Dynamic User Task Composition Based on User Preferences HAMID MUKHTAR, National University of Sciences and Technology (NUST) DJAMEL BELAÏD and GUY BERNARD, Institut Telecom, Telecom SudParis, CNRS UMR SAMOVAR

As the number of devices in a pervasive environment is increased, the number of components available on the network also grows rapidly. In such cases, it is possible to compose various applications through a combination of different sets of components. Considering the multifaceted problem of having varying device capabilities supporting a different set of protocols, and each device hosting a number of components providing the same functionality, it becomes very difficult to choose a particular device hosting a required component which can be the best-fit for the user. This becomes practically impossible when the required components are distributed across various devices in the networked environment. We propose a solution for dynamic user task composition considering user preferences, device capabilities, and heterogeneity of communication protocols. With our proposed approach, a user task can be instantiated in different environments using a different set of devices and components, depending upon their capabilities and user preferences. We propose mechanisms for modeling device capabilities and user preferences and for modeling the user task as a graph. We then propose algorithms for selection of devices based on user preferences and task requirements. Since the underlying network is also modeled as a graph, we describe an algorithm for mapping of services in the user task on to the components distributed across devices in the pervasive environment. We also give an overview of our initial implementation and some results of our evaluations. Categories and Subject Descriptors: K.8.3 [Computing Milieux]: Personal Computing General Terms: Algorithms, Human Factors Additional Key Words and Phrases: User preferences, device selection, multimedia user tasks, pervasive environments ACM Reference Format: Mukhtar, H., Bela¨ıd, D., and Bernard, G. 2011. Dynamic user task composition based on user preferences. ACM Trans. Auton. Adapt. Syst. 6, 1, Article 4 (February 2011), 17 pages. DOI = 10.1145/1921641.1921645 http://doi.acm.org/10.1145/1921641.1921645

1. INTRODUCTION

Advancements in various hardware, software, and network technologies have introduced the concept of pervasive environments in which a user device can interact with other devices in the user’s vicinity on behalf of the user. Emphasis has been on the automatic selection of services and devices for users in the pervasive environment, with minimal effort or intrusion on the user’s part. In most cases, such an approach considers an abstract user task on the user device which upon execution leads to automatic selection of components across various devices in the environment, according Authors’ addresses: H. Mukhtar, National University of Sciences and Technology, H-12, Islamabad, Pakistan; D. Bela¨ıd (corresponding author) and G. Bernard, Institut Telecom, Telecom SudParis, CNRS UMR SAMOVAR, 9 rue Charles Four¨ıer, 9100 Evry, France; email: [email protected]. Permission to make digital or hard copies part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies show this notice on the first page or initial screen of a display along with the full citation. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works requires prior specific permission and/or a fee. Permission may be requested from Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701, USA, fax +1 (212) 869-0481, or [email protected]. c 2011 ACM 1556-4665/2011/02-ART4 $10.00 DOI 10.1145/1921641.1921645 http://doi.acm.org/10.1145/1921641.1921645

ACM Transactions on Autonomous and Adaptive Systems, Vol. 6, No. 1, Article 4, Publication date: February 2011.

4

TAA00003

4:2

ACM


February 15, 2011

7:27

H. Mukhtar et al.

to the current context. The advantage of such an approach is that the user is free of manual tuning and selection of components and devices. However, such approaches ignore the heterogeneity of devices in terms of their hardware, software, and communications capabilities. It is assumed that components can be instantiated across all the devices uniformly and all devices have a common communication protocol. However, such assumptions fail when we consider diverse communication capabilities (such as Bluetooth, GPRS, WiFi, and IrDA, etc.) available on different devices. Another aspect that is ignored during automatic service composition is the consideration of user preferences. Most of the existing user task composition approaches consider the device’s capabilities from the service’s usage point of view, such as available CPU, memory, and bandwidth, etc. They pay little or no attention toward user preferences for components or devices. For example, two devices having the same services may be regarded as identical due to their resources, but will be viewed differently from user’s point of view due to their interaction style. To illustrate our point, consider a user equipped with a mobile phone. On his device, he has an application that lets him chat with his friends. Depending upon the context in which the user finds himself, the chat application will behave differently. For example, while the user is nomad he can use the mobile phone to start a video-chat session. However, if the user is in a pervasive environment consisting of a number of devices, he may be able to use the functionalities provided by the other devices such as by using a device with larger screen for video-chatting and using the speakers of a PC for enhanced audio. This way the user can take advantage of the hardware and software resources in the environment for dynamically realizing his task for better ergonomics, entertainment, or special needs. Previously, a number of approaches have developed solutions for the previously mentioned problems and various systems have been developed so far [Ben Mokhtar ´ and Campbell 2003; et al. 2007; Fujii and Suda 2009; Kalasapur et al. 2007; Roman Sousa and Garlan 2002]. In these systems, a user task is considered as an abstract description of requirements for hardware and software components which are then sought in the pervasive environments. However, existing systems have not solved several issues that we will be addressing in this article. First, most of the existing systems ignore user preferences; when executing the same user task, different users may have different preferences related to devices and the components on them. Second, existing approaches do not consider device capabilities or network heterogeneity when looking for the components required by the user task in the environment. Third, existing frameworks develop the user task using a description mechanism that is either proprietary or is not based on open standards and they build upon on a particular architectural paradigm. This article proposes a solution for user task composition that considers all these issues. The rest of the article has been organized as follows. In the remaining of this section, we define ad hoc user tasks and declare a few assumptions for user task resolution. In Section 2 we describe some related work and in Section 3 we provide a methodology for user preferences elicitation and their evaluation in a working scenario. Section 4 describes how the user task and the underlying network can be modeled as graphs and how a user task can be described and implemented using Service Component Architecture (SCA) [Open SOA Collaboration 2007]. Section 5 describes our algorithm for mapping of the user task onto the underlying network considering device capabilities, service requirements, and user preferences. In Section 6, we discuss the initial implementation of our system as well as some evaluation results, and Section 7 concludes this article with some future directions.


TAA00003

ACM


Dynamic User Task Composition Based on User Preferences

February 15, 2011

7:27

4:3

1.1 Ad Hoc User Task

We consider a user task as an abstract description of services on the user’s device. The description is independent of the particular concrete components and devices that will be used for realizing the user task. The description of a user task can be developed by an application architect, a developer, or even an expert user. In any of these cases, we assume that the end-user has beforehand such an abstract description available on his device. A service in the user task can be implemented by one component or a composition of arbitrary number of components available as network services in the pervasive environment. These components can be implemented in variety of technologies and can communicate with one another using a variety of protocols. The resolution of services into components (or the realization of the user task) is carried out dynamically based on the properties of available network services, devices, network, and user preferences. Thus, the same user task can be instantiated differently in various environments depending upon the capabilities of devices and user preferences. Even if the user task is reused in the same environment having the same set of devices, the selected components and devices may be different if the user specifies some of his preferences differently. Due to this dynamic behavior of the task, a user task is also called as ad hoc user task [Ben Mokhtar et al. 2007]. 1.2 Assumptions and Conditions

In ad hoc pervasive environments, where device participation is dynamic, we do not consider the availability of a central registry or server, but assume that the devices are able to share their capabilities and the available components on them with other devices, using some device and service discovery systems. We also assume that devices share information about other devices with one other, using a link-state-style protocol. The discovery system is available on all the devices, and can be used on top of different communication protocols. Since device communication is protocol dependent, two components on different devices may communicate only if their hosts can use the same protocols; however, a single device may support multiple protocols simultaneously, for example, Bluetooth, WiFi, Infrared, etc. We assume that the components required by a user are already deployed on various devices in the pervasive environment. For each service in the user task, we may find one or more matching components across different devices. Our objective is to resolve services into concrete components considering user preferences, devices’ capabilities, and network heterogeneity. 2. RELATED WORK

The idea of user task composition using a graph-based approach has been treated previously, albeit differently. One of the most recent works, by Fujii and Suda [2009], presents an approach to dynamic service composition that relies on automatic composition of services based on user queries and preferences in a natural language such as “if I am in a meeting do not use a cell phone.” To satisfy the requirement for semantic support, the system comprises three subsystems: Component Service Model with Semantic (CoSMoS), Component Runtime Environment (CoRE), and Semantic Graph-based Service Composition (SeGSeC). CoSMoS integrates the semantic information and functional information into a single semantic graph representation. CoRE provides a unified interface to discover and access components implemented in various component technologies to make them interoperable with CoSMoS components.


TAA00003

ACM


4:4

February 15, 2011

7:27

H. Mukhtar et al.

SeGSeC is a semantic-based service composition mechanism that allows users to request a service using a natural language sentence and it generates the execution path. The major contribution is that this work is semantic based and during the task composition the user context is also considered. However, the set of queries that have been reported to test the system’s functionality is quite limited, indicating that the system is useful only in a few specific scenarios and it needs a lot of add-ons to satisfy additional types of user queries. Another major problem with this approach is that it requires an infrastructure to deliver the deducted service configuration. Our approach of specifying a user task as an assembly of components, conversely, embraces the highly distributed and ad hoc nature of pervasive and ubiquitous computing, and does not depend on computationally intensive deductions. An assembly can be carried on one or more devices when its required components are found. The PICO middleware [Kalasapur et al. 2007] platform approaches the dynamic service composition task by constructing possible compositions based on their semantic and syntactic descriptions. Each service is described by a graph G s representing services and their input/output as well as service attributes such as name, location, cost, and semantic description. All the service graphs G S are combined to create a two-layered aggregation graph G P in a central directory. The first layer of G P is based on semantic description of services and the second layer on syntactic type of its parameters. A task is submitted to the directory for resolution. If there is a direct match, the service is returned, otherwise task components are matched against available basic services and a composition of services is returned. A serious disadvantage of approach is the presence of a centralized directory for services aggregation, which is not always possible in ad hoc pervasive environments. It is also assumed that a single aggregated service graph will always exist in the directory, which is not valid in a heterogeneous environment covering a plethora of service types. User preferences, device capabilities, and protocol heterogeneity are not considered as well. Davidyuk et al. [2008] have presented a graph-based application composition approach based on applying evolutionary and genetic algorithms. Application components required by the user tasks are allocated onto various hosts. The goal is to satisfy the constraints imposed by the platform and application models (both modeled as interconnected graphs) and to optimize the objective function which minimizes the network link bandwidth and the number of hosts used in the component allocation as well as achieving load-balancing among the nodes. The disadvantage of their algorithm is that they are doing dynamic deployment of components, which is not desirable in pervasive environments due to security and privacy reasons. Also, they consider only CPU and memory utilization, and bandwidth consumption for optimization and do not consider other attributes including user preferences and devices’ interoperability. 3. MODELING OF USER PREFERENCES

User preferences are considered as wishes whose chance of satisfaction should be maximized, but we cannot guarantee the complete fulfillment of user preferences [Alia et al. 2007]. In this section, we will show how they can be used effectively for selection of devices for execution of the user tasks. We mainly consider characteristics of the devices in the pervasive environment. Based on device characteristics, users will specify their preferences of likeness or dislike for a device. In a previous work [Mukhtar et al. 2008a], CC/PP (Composite Capability/Preference Profile) [Kiss 2007] has been extended to introduce various resources and capabilities into the existing model. We assume that device characteristics have been expressed using a similar model. ACM Transactions on Autonomous and Adaptive Systems, Vol. 6, No. 1, Article 4, Publication date: February 2011.

TAA00003

ACM



February 15, 2011

7:27

4:5

Users specify their preferences qualitatively for various device capabilities. These preferences take the form of likings or dislikes; they can also be specified at various levels of relative importance, for example, preference of the form I like Linux more than Windows or I like Windows but I don’t like Linux, etc. Note that these preferences take both the positive (liking) and negative (dislike) form. This is one step ahead of what is usually proposed in literature, where only positive preferences are considered, for example, as in Liu and Issarny [2004]. For modeling of user preferences, we base our approach on CP-nets. 3.1 Specification of User Preferences Using CP-Nets

A CP-net (for Conditional Preference network) [Boutilier et al. 1999] is a model for compactly representing conditional and qualitative preference relations. For representation, CP-nets use directed graphs consisting of set of features V = {X 1 , . . . , X n} represented by nodes, where each node X i is associated with a finite domain D(X i) = {xi1 , . . . , xin}. A feature X i may specify a set of parent features Pa(X i) that can affect the values of X i based on the values assigned to Pa(X i). The relation between a node X i and its parent nodes Pa(X i) is denoted by the arcs that lead from Pa(X i) to X i in the graph. Associated with each variable is its Conditional Preference Table (CPT), which expresses the preferences over the values taken by it. A preference between two outcomes x1 and x2 can be specified by the relation, for example, x1 x2 specifies that x1 is preferred over x2 . To evaluate a CP-net, the graph is traversed in topological order resulting in an induced graph whose nodes and arcs determine the various possible combinations in which the user preferences can be ordered. However, the induced graph specifies the worst and best preferences, respectively, but it does not show any ranking between several intermediate solutions (e.g., see discussion in Boutilier et al. [2003]). This becomes restrictive as it does not imply how important is the value of one feature with respect to another. 3.2 Proposed Extensions to CP-Nets

For a given feature, more than one value may apply and the user may have different preferences for each one of them. In order to capture the notion of more important or less important or even dislike, we propose to use a preference function f eature value → importance level. This function is used to assign different levels of importance to different values of a feature. Users specify their preferences for all of the features in which they are interested. While users specify their preferences qualitatively, we need to map them to specific values so that they can be measured quantitatively [Liu and Issarny 2004]. Table I shows various levels of importance that can be used by the user to specify his likings and dislikes, and their respective mappings. A user’s preference is mapped to a specific real number between the range (−1.0, 1.0). The reason for choosing such values is twofold: first, specifying a range between (−1.0, 1.0) helps in defining a normalized function with respect to user preferences; second, by including negative values, it is possible to eliminate devices with unwanted capabilities, as discussed in Secton 5. Using such values, 1.0 represents a very important capability, −1.0 represents user’s dislike, so much so to avoid using a device with such a capability, and 0.0 representing a don’t-care condition, that is, when user specifies x → dontcare, the value of x is not important for the user. The reason for choosing unequal spaces between various preference levels is to spread the weight space to make the difference more expressive, for example, the distance between somewhat like and like is only 0.2, but between imporant and very ACM Transactions on Autonomous and Adaptive Systems, Vol. 6, No. 1, Article 4, Publication date: February 2011.

TAA00003

ACM


February 15, 2011

4:6

7:27

H. Mukhtar et al. Table I. Values for User Preferences Importance level

Preference value

Very Important Important Like Somewhat Like Don’t Care Dislike Dislike Very Much Avoid

1.0 0.7 0.4 0.2 0.0 −0.5 −0.7 −1.0

Table II. User Preferences for Device Capabilities Variable

Preference value

NetworkAccess

WiFi → Important GPRS → Somewhat Dislike

InputType

VideoInput → Important VoiceInput → Like TextInput → Dislike

ScreenResolution

Optimum()

important, it is 0.3, that is, the difference is more emphasized in the latter case. The importance levels can be used in our extended CP-nets in several ways such as specifying likings and dislikes, specifying indifference, ordering preferences, conditioning preferences, and for specifying resources qualitatively by the user. With these notions, we can specify how critical a feature is for the user. We will now explain how our extended CP-nets can be used for selection of a particular device. Table II shows some of the preferences specified by a user for his selection of a device. There are three attributes for which user has provided his preferences: NetworkAccess, InputType, and ScreenResolution. For the type of NetworkAccess, the user has specified WiFi with an importance level of important while GPRS has been assigned the importance level of somewhat dislike, perhaps due to the access charges incurred when using the latter. For the InputType attribute of a device, the user has specified his preference for video, voice, and text input types. Thus, while not considering the other preferences, the user prefers video input very much as compared to voice input and does not prefer a text input type. Finally, for the ScreenResolution attribute, the user has specified that he prefers the optimum screen size. Eq. (1) defines the Optimum() function which returns the optimum value for the screen attribute of a given device when ranked amongst all the available devices. Optimum(d) =

Rank(wd) + Rank(hd) 2

(1)

Here wd and hd represent the width and height of the screen of the given device d, respectively. The Rank() function sorts each device according to screen resolution values between the range of 0 and 1. Other types of ranking functions can be used as well [Mukhtar et al. 2009a]. The preferences in Table II can be modeled by a CP-net as shown in Figure 1(a). As it has been a convention, the attributes are represented by one-letter symbols. Although here we assume the preferences have been ordered by the user in this way using some suitable input method, in more complex scenarios this order can be obtained by the conditions and dependencies between the preference variables [Mukhtar et al. 2009a]. ACM Transactions on Autonomous and Adaptive Systems, Vol. 6, No. 1, Article 4, Publication date: February 2011.

TAA00003

ACM


February 15, 2011


7:27

4:7

Fig. 1. User preferences for device selection.

3.3 Specification of User Preferences and Required Capabilities

We assume that user preferences specification already exists on the user device or users specify their preferences explicitly for the given task at the time of its execution with the help of a GUI provided on the device, such as by clicking certain choices, by enabling/disabling certain options, or by specifying a preference value. When a user executes a task, his preferences are retrieved from the preferences repository on the user device and associated with the services in the task. In addition to user preferences, developers may also specify additional capability requirements for services in the user task. For example, a chat service will specify NetworkAccess=Yes and TextInputCapable=Yes as its capability requirements, which specify that a device hosting the chat component must have network access and must have the capabilities to accept user input as text; otherwise this service will be useless for the user. Previously, in Mukhtar et al. [2008a] we have shown how the device capabilities can be used as service requirements by including the capability description in the task definition. The available devices are then evaluated against service requirements and only those devices are considered for selection of components which satisfy the service requirements. As mentioned previously, to interpret CP-nets they are transformed into topological graphs which result in ranked preferences. However, this requires exploring all the possible combinations, which is not useful when the decision maker is interested only in a subset of variables taking possibly few values from the domain set. This also constrains the users to completely specify their preferences for all variables. Contrary to that, we assume that users do not specify their preferences completely. This can happen in two ways: they may specify no preference for a particular variable at all, or they may specify their preferences only for a subset of the values taken by a variable. If a user is not interested in a particular value of a variable, he need not specify it either, and thus we consider such an indifference as a don’t-care condition. To accommodate the extensions in CP-nets, we propose an alternative mechanism which is very efficient for incomplete preference specification. 3.4 The Preference Tree

Referring back to Figure 1(a), we will now describe how it can be evaluated for selection of a device for the user. We use a tree structure called textitPreference Tree, instead of a graph, for exploring the preferences contained in the extended CP-nets ACM Transactions on Autonomous and Adaptive Systems, Vol. 6, No. 1, Article 4, Publication date: February 2011.

TAA00003

ACM


4:8

February 15, 2011

7:27

H. Mukhtar et al.

and their associated CPTs. Instead of searching the tree for all possible values of the variables, we use only the currently available values for the variables. The tree consists of nodes from the CP-net and each node represents only one variable. The arc from a parent node X to a child node Y represents the preference value assigned by the user as they are conditioned in the CP-net and extended CPT. Thus, since each arc represents an importance level, it means that for each parent node, there will be as many arcs (and corresponding children nodes) as there are user preferences for the node variable. For example, for the variable NetworkAcess in Table II, the corresponding node NetworkAccess in the tree contains two children connected to it by arc an labeled by the preference value for the attribute value affected by the device. This preference value is then translated into its equivalent weight based on the mappings in Table I. Figure 1(b) shows a preference tree for created from the CP-net of Figure 1(a). The preference tree has been created for three devices, namely, a Smart-Phone (SP), a LapTop (LT), and a DeskTop (DT). Initially, all the devices have a value of 0, which is noted by the information in the rectangle beside the top node. After evaluating the NetworkAccess node, its children are created based on the values of the NetworkAccess variable in each device. Assuming that only the smart-phone has a GPRS access and the other two devices have a WiFi access, two nodes are created with the edge weights denoting the user preference for that value. The device values are updated corresponding to the edge weights and are shown in the rectangles beside the nodes. This process is then repeated for the remaining two nodes of the CP-net using the order specified by the user. At the bottom of the tree, the aggregated device values are shown. As can be seen, the laptop (LT) has the highest device value and is thus selected for the user. The observant reader may rightfully ask that while the preference tree has been used for selection of the best device according to user preferences, it does not show how it can be used for selection of more than one devices in those cases when the components required by the user task are distributed on several devices. The answer is that the aforementioned example has been constructed with a limited number of preferences and for a very simple case. For a more complex treatment consisting of many devices and relatively large number of attributes, the reader is referred to Mukhtar et al. [2009a]. In one of our previous works, we have also shown that, together with service requirements for device capabilities, user preferences can be used to guide the selection of more than one devices [Mukhtar et al. 2009b]. In that case, each service in the task is assigned a fitness value for each device so that the device with the highest fitness value is selected for the given service. This procedure is repeated for all the services in the user task resulting in possible selection of more than one device for the user task instantiation. The preference tree gives us a ranking of devices based on user preferences. However, we need to evaluate each device for the availability of components required by the user task. If a given required component is available on more than one devices, then device ranking will be used to select the most promising device. To map a user task on components distributed on several devices, and to consider protocol heterogeneity, a sophisticated procedure is needed to ensure proper selection of components that will be able to communicate across different devices. In the next section, we detail this procedure. 4. MODELING OF USER TASK AND NETWORK

The user task needs to be described in an Architectural Description Language (ADL) and then mapped to the components whose description should also be provided in the same ADL. In Section 4.1, we describe Service Component Architecture (SCA) [Open ACM Transactions on Autonomous and Adaptive Systems, Vol. 6, No. 1, Article 4, Publication date: February 2011.

TAA00003

ACM


February 15, 2011


7:27

4:9

Fig. 2. The VideoChat composite: (a) SCA representation (b) tree representation.

SOA Collaboration 2007] which we have adopted for the description of the user task and components. In Section 4.2, we describe how an application composed in SCA can be modeled as graph and in Section 4.3, we describe the modeling of the underlying network in terms of devices and their interconnection. The mapping of services to the components is discussed in Section 5. 4.1 Service Component Architecture

Service Component Architecture (SCA) provides a programming model for building applications and systems based on a Service-Oriented Architecture (SOA). The main idea behind SCA is to be able to build distributed applications which are technology-, protocol-, and implementation-agnostic. SCA extends and complements prior approaches to implementing services, and builds on open standards such as Web services. The ADL used by SCA is known as Service Component Description Languages (SCDL), which is based on XML. SCA applications are deployed as composites. An SCA composite describes an assembly of components which offer functionality as services and require functionality from other components in the form of references to services. SCA components can be implemented in Java, C++, COBOL, Web Services, or as BPEL processes. Figure 2(a) shows an example video-chat application described in SCA as assembly of components.1 The VideoChat composite, which offers a service, namely VideoChatService, consists of a user-interface component called ChatController that references VideoProcessor and AudioProcessor components for video and audio processing which also refer VideoCapture and Microphone components, respectively. Finally, a reference to the NetworkConnection component is also made for sending the processed contents over the available network access mechanism. The components in the VideoChat composite are defined abstractly, in terms of their service interface, without any implementation. Depending upon the context, the resolution of these abstract services into corresponding concrete components may take place in different ways. For example, they all may be resolved on the same device, or onto three devices 1 Since a component is the basic unit that can be described independently in SCA, unlike services which are associated with components or composites, we represent services in the user task by components which have only interfaces but no implementation. We will call them abstract components and they are representatives of services in the user task.


TAA00003

ACM


4:10

February 15, 2011

7:27

H. Mukhtar et al.

holding the controller, video, and audio components, separately. To ensure that the related components such as AudioProcessor and Microphone components are to be used on the same device (otherwise, it will be useless to have them on separate devices), additional constraints in the form of service colocation can be specified in the user task to ensure they are instantiated on the same device [Mukhtar et al. 2009a]. The matching between services and components can be done using an appropriate matching algorithm. 4.2 Modeling of User Task as Graph

Once we have user task specification in SCA we can use it to compose the task for the user. Let us denote by T the user task specification along with service requirements for device capabilities and user preferences. Specification of service requirements and user preferences was discussed in Section 3.3 and we assume that the runtime has integrated them in the task specification. The purpose is to be able to find the matching components, so that the specification in T is satisfied. In addition, when looking for components, the user preferences and service requirements for device capabilities should also be satisfied. First, we model T as an attributed graph G T = {S, I, U, RT } where S = {S1 , S2 , . . . , Sn} is a set of abstract services in the task and is represented by the nodes in the graph, I ⊆ S × S is the set of edges between nodes and each Ii, j ∈ I represents the communication or dependency interfaces between the services Si and Sj. U is the set of user preferences for the task. RT is the set of capabilities required by all services in RSi ∈ Si. RSi denotes the device capability required by the graph G T , that is, RT = the service Si and is represented by the attributes on the nodes of the graph. Rs can be described using any device specification model like CC/PP. G T is an undirected, connected graph representing a two-way, request/reply communication between the services. Each service Si is deployed independently, unless it is constrained by a colocation dependency as described previously. Services are loosely coupled, that is, communication between services takes place through their exposed interfaces only. We assume that, due to synchronous request/reply paradigm, services are able to maintain the temporal relationship, as specified by their dependencies, and the problem of service sequencing and interleaving is taken care by the underlying infrastructure. Figure 2(b) shows the VideoChat SCA composite of Figure 2(a) as a graph. Each service (abstract SCA component) in the VideoChat user task is represented by a node. Some of the services also have device capability requirements, which are shown below the node. Once we have the user task modeled as abstract graph G T , our aim is to find the components in the environment which implement the services described in the user task as denoted by the nodes in G T . To do this, we need to know the devices in the environment and the components available on them. This can be achieved by modeling the underlying network and network services also as graphs. 4.3 Network Modeling

The underlying network is represented by a graph G N = {D, L}, where D = {D1, D2, . . . , D m} is the set of devices available in the environment at the time of user task composition and L ⊆ D× D is the set of links such that each L i, j denotes the connection between devices D i and D j. A device is modeled by D = {C, R D , G C } where C = {C1 , C2 , . . . , Cn} is the set of components installed on the device, R D is a set of properties characterizing the capabilities or the resource available on the device, and G C = {G C1 , G C2 , . . . , G Cn } is a set ACM Transactions on Autonomous and Adaptive Systems, Vol. 6, No. 1, Article 4, Publication date: February 2011.

TAA00003

ACM



February 15, 2011

7:27

4:11

of graphs, where each G Ci represents concrete compositions of components, already deployed on the device. Each G Ci represents either a single component in C exported as a network service, or a composition of various components Cu, Cv , ...Cz ∈ C that is exported as a network service. Thus the implementation of an abstract service will be provided either by a single component Ci or a set of components represented by G Ci . The next section describes how the user task can be resolved into available components by mapping the user task graph on the network graph. 4.3.1 Considering Environment Heterogeneity. One important aspect of modeling the network as a graph is to consider the heterogeneity of communication protocols in the underlying network. In the graph G N , two devices are connected to each other only if they can speak the same protocol, otherwise there is no edge between them in the graph. This is an important consideration, as not all devices will be using the same protocols, for example, a device using only Bluetooth cannot communicate with a device using only WiFi. If, on the other hand, a pair of devices can communicate using more than one protocol simultaneously, we model their communication by a single edge. The exact protocol used for communication will be dependent on the component’s configuration and is taken care of by the runtime. 5. USER TASK RESOLUTION

An abstract user task is resolved into components only at the time of execution of the task. This requires matching of abstract services with components on the devices, which is carried out after evaluating several aspects: services’ functional interfaces, service requirements for device capabilities, heterogeneity of communication protocols, and user preferences. These aspects cannot be met simultaneously; rather they need to be evaluated one by one, in order. For this purpose, we have proposed a three-phase protocol to resolve a task into components [Mukhtar et al. 2008b]. To carry out this process, we assume that a Task Composer is present on the device where the user task is initiated. 5.1 Task Resolution Using Three-Phase Protocol

In this section, we explain how a user task is resolved into components based on user preferences, using the example video-chat application described previously. Figure 3 shows the three layers of service composition used by our task composition algorithm for the same VideoChat user task graph of Figure 2(b). The Task Composer first determines the abstract services S, their interfaces I, and the capability requirements RT of all the services, from the user task specification T. These are used to create a graph representation G T of the user task. The User Task layer in Figure 3 shows such a graph. To create the network graph G N , the Task Composer forwards G T to the Service Discovery system and uses the three-phase task composition protocol as follows. 5.1.1 Phase I - Device Elimination. The Service Discovery system interrogates the environment for available devices and queries them for their capabilities. Each device sends back its capabilities R D to the requesting device. For each device D i, the Task Composer compares R Di with the abstract resource requirements RT of the task and the user preferences U for the task. Any device which does not meet the required device capabilities or user preferences is eliminated from the graph (shown by the shaded circles in the Network layer of Figure 3). This results in a reduced graph to be matched. 5.1.2 Phase II - Graph Aggregation. The Service Discovery sends the abstract services in G T to the selected devices. Each device sends back a description of those ACM Transactions on Autonomous and Adaptive Systems, Vol. 6, No. 1, Article 4, Publication date: February 2011.

TAA00003

ACM

(Typeset by SPi, Manila, Philippines) 12 of 17 February 15, 2011

4:12

7:27

H. Mukhtar et al.

Algorithm 1. ComposeTask(G T , G N ) 1: G T = {S, I, U, RT }, G C = {Q, Y, R} 2: sort G T and G C by node label 3: while S = ∅ and C = ∅ do 4: let s1 be the first element of S 5: let c1 be the first element of C 6: if α1 (s1 ) = α2 (c1 ) then 7: μ(s1 ) := c1 8: S := S − {s1 } 9: end if 10: C := C − {c1 } 11: end while 12: sort I and Y by node label 13: while I = ∅ and Y = ∅ do 14: let (s1 , s2 ) and (c1 , c2 ) be the first element of I and Y 15: if μ(s1 ) = c1 and μ(s2 ) = c2 and 16: β1 (s1 , s2 ) = β2 (c1 , c2 ) then 17: I := I − (s1 , s2 ) 18: end if 19: Y := Y − (c1 , c2 ) 20: end while 21: match := (S = ∅ and I = ∅) 22: return (μ, match)

Fig. 3. Task resolution at three different layers.

components which match with at least one of the abstract services S in G T . The Task Composer then combines the various components, obtained from all devices, into a single component graph G C = {Q, Y, R}, where Q is the set of components obtained from all the partial graphs, R = R Di and each R Di is associated with the component ACM Transactions on Autonomous and Adaptive Systems, Vol. 6, No. 1, Article 4, Publication date: February 2011.

TAA00003

ACM

(Typeset by SPi, Manila, Philippines) 13 of 17 February 15, 2011


7:27

4:13

C j ∈ D i, 1 ≤ j ≤ Cn. As we will see later, associating device capabilitiesto its components will be useful when matching services with components. Y = {F P}, where F is the set of functional interfaces between components and pi ∈ P is the network-level protocol used between two components when they use functional interface fi ∈ F. The Component layer in Figure 3 shows an example component graph. 5.1.3 Phase III - Matching G T and G C . The Task Composer can now match G T with G C to determine the final set of components and their composition, as required by the user task. The goal is to find a subgraph H of G C such that there is a one-toone correspondence between H and G T . The final graph obtained, H, represents the concrete user task graph that is sent to an execution engine which executes the task by invoking the appropriate network services. 5.2 Graph to Subgraph Matching

The graph (G C ) to subgraph (G T ) matching is known as subgraph isomorphism in graph theory. The problem of subgraph isomorphism detection is known to be NPcomplete [Garey and Johnson]. However, by imposing certain conditions on the properties of the graphs, it is possible to derive algorithms that have a polynomially bounded complexity. One efficient algorithm for subgraph isomorphism, proposed recently by Valiente [2007] assumes that each node, in the graphs to be matched, has unique labels. Thus matching is done by their labels. A modified version of the algorithm is shown in Algorithm 1 and it works as follows. The task graph G T and the component graph G C are represented as shown previously. The unique node labels are used to identify each service and component in G T and G C , respectively. In G T , each label consists of the service interface, while in G C it consists of a combination of component interface, devices’ capabilities, and the network protocol associated with the interface. This uniquely identifies each component in G C . The α and β are node labeling and edge labeling functions in the graphs, while μ is an assignment function which assigns a component to a service when they match. α matches functional interfaces, while β ensures protocol compatibility between different components. 6. IMPLEMENTATION AND EVALUATION

We have implemented a prototype of our user task composition system in Java. The interaction between various system entities has been shown in Figure 4. Due to system modularity, the number of architectural components is more than what was described in the previous section. Although our architecture is not centralized and parts of the composition process take place on different devices, we have shown here a centralized view of the architecture from the user’s point of view. We are currently working on incorporating our implementation into the open-source Newton project2 which defines a SCA component model on top of the OSGi service model. 6.1 Evaluation

We have evaluated several aspects of our prototype implementation. However, since there is no existing system which considers user preferences for the task composition as we do here, we cannot compare our results with other approaches. Thus, we present here only a few results to demonstrate the efficiency and performance of our implementation. 2 http://newton.codecauldron.org


TAA00003

4:14

ACM


February 15, 2011

7:27

H. Mukhtar et al.

Fig. 4. Sequence of actions used by our architectural entities for task composition.

Since the number and types of devices in pervasive environments can be dynamic as well as the number of components on them, we cannot determine a particular scenario for evaluation of our experiments. Thus, we begin our experiments with a few assumptions. First, the number of services in the user task, the number of devices in the environment, and the number of components on these devices cannot be very large. Normally, a user task may not contain more than a few components. Similarly, the number of simultaneous devices available to a user in a pervasive environment may not be very large in most cases. Also, the number of components on different devices may be different and there will be no correlation between the components on these devices. Thus, we assume a random distribution of components on upto 10 devices. Based on these assumptions, we run the following experiments. These experiments have been run on a DELL Latitude D810 laptop with 1.7 GHz Intel processor and 1GB of RAM. All times were recorded as average of 10 runs of simulations. 6.1.1 Complexity of the User Task. One aspect of the evaluation was to see the scalability of our approach in terms of the services in the user task. In the first experiment, we wanted to evaluate the time required to compose the user task with varying number of services. Figure 5 shows the resulting graph for a user task when it contains from 1 to 15 different services. This includes the time to parse the user task (described as SCA composite), to create the abstract user task graph, network graph, and aggregate graph, as well as matching of the abstract and aggregate graphs. As it can be seen, the variation between the times required to compose the tasks does not vary much in all the cases. The reason is that for all the cases, since the number of devices and components is the same, the time required to create the aggregate graph does not change very much. Hence, we can conclude that increasing the number of services does not have significant effect on the performance of the composition process. It will mainly depend on the type and number of devices and the components available on them. ACM Transactions on Autonomous and Adaptive Systems, Vol. 6, No. 1, Article 4, Publication date: February 2011.

TAA00003

ACM



February 15, 2011

7:27

4:15

Fig. 5. Time required to compose a user task with varying number of abstract services in the task.

6.1.2 Size of the Aggregate Graph. Figure 6 explains how, by adding service requirements and user preferences, the complexity of the aggregate graph can be reduced. These experiments have been run on the same setup as explained before but the composition process is carried out for three different cases. In first case, an aggregate graph was created for the user task without considering the user preferences and service requirements. In second case, only service requirements were considered and in the last case both user preferences and service requirements were considered. Since the number of components in the aggregate graph increases exponentially with respect to the number of services in the abstract graph, the graph has been drawn to log scale on the y-axis. It can be seen that even for 10 services in the abstract graph, there are 10 times more number of solutions when considering only service requirements compared to considering both service requirements and user preferences simultaneously. Similarly, there are 1000 times less number of solutions in the aggregate graph when considering service requirements as compared to the case when they are not considered. We can conclude that by incorporating service requirements and user preferences in the user task, the size of the aggregate graph can be reduced. This is possible because additional factors are included during graph aggregation which further constrains the nodes and edges in the graph, resulting in a reduced aggregate graph. 7. CONCLUSIONS AND FUTURE WORK

With the ubiquity of computing devices and with the increased communication capabilities offered by these devices using wide range of protocols, it is now possible to compose a user task across various devices present in the pervasive environment. In such cases, the components required by the abstract user task are distributed across different devices and the selection of a component on a particular device is done at the time of execution of the task. In this article, we have proposed an approach for dynamic user task composition which has several novel aspects as compared to existing approaches: (1) we consider device capabilities as an essential aspect before selection of devices for components, thus taking care of differences between devices from service usage point of view and only select that device on which a particular service can be ACM Transactions on Autonomous and Adaptive Systems, Vol. 6, No. 1, Article 4, Publication date: February 2011.

TAA00003

ACM


4:16

Fig. 6. Comparison of task composition solutions: requirements.

February 15, 2011

7:27

H. Mukhtar et al.

when considering user preferences and service

instantiated, based on its requirements; (2) the heterogeneity of protocols for device communication is also considered; and (3) the selection of devices and components is influenced in majority by user preferences. We have discussed the implementation and a few results showing the evaluation of our approach. However, the prototype framework will be merged with the opensource Newton platform for provisioning of services required by the user task. Once implemented completely, our framework will also be capable of dynamic adaptation of user task, in case better devices appear or one of the existing devices disappears. This will also lead to the continuity of user session from one device to another. REFERENCES A LIA , M., W OLD E IDE , V. S., PASPALLIS, N., E LIASSEN, F., H ALLSTEINSEN, S. O., AND PAPADOPOULOS, G. A. 2007. A utility-based adaptivity model for mobile applications. In Proceedings of the 21st International Conference on Advanced Information Networking and Applications Workshops (AINAW’07). Vol. 2. IEEE Computer Society, 556–563. Los Alamitos, CA. B EN M OKHTAR , S., G EORGANTAS, N., AND I SSARNY, V. 2007. Cocoa: Conversation-Based service composition in pervasive computing environments with qos support. J. Syst. Softw. 80, 12, 1941–1955. B OUTILIER , C., B RAFMAN, R., H OOS, H., AND P OOLE , D. 1999. Reasoning with conditional ceteris paribus preference statements. In Proceedings of the 15th Annual Conference on Uncertainty in Artificial Intelligence. Morgan Kaufmann, 71–80. B OUTILIER , C., B RAFMAN, R., D OMSHLAK , C., H OOS, H., AND P OOLE , D. 2003. CP-Nets: A tool for representing and reasoning with conditional Ceteris Paribus preference statements. J. Artif. Intell. Res. 21, 1. D AVIDYUK , O., S ELEK , I., D URAN, J. I., AND R IEKKI , J. 2008. Algorithms for composing pervasive applications. Int. J. Softw. Engin. Appl. 2, 2, 71–94. F UJII , K. AND S UDA , T. 2009. Semantics-Based context-aware dynamic service composition. ACM Trans. Auton. Adapt. Syst. 4, 2, 1–31.


TAA00003

ACM



February 15, 2011

7:27

4:17

G AREY, M. R. AND J OHNSON, D. S. 1979. Computers and Intractability: A Guide to the Theory of NP-Completeness. Freeman Co. K ALASAPUR , S., K UMAR , M., AND S HIRAZI , B. 2007. Dynamic service composition in pervasive computing. IEEE Trans. Parall. Distrib. Syst. 18, 7, 907–918. K ISS, C. 2007. Composite capability/preference profiles (cc/pp): Structure and vocabularies 2.0. w3c working draft. 30 April. http://www.w3.org/TR/CCPP-struct-vocab2/. L IU, J. AND I SSARNY, V. 2004. QoS-Aware service location in mobile ad hoc networks. In Proceedings of the IEEE International Conference on Mobile Data Management. 224–235. M UKHTAR , H., B ELA Ï D, D., AND B ERNARD, G. 2008a. A model for resource specification in mobile services. In Proceedings of the 3rd International Workshop on Services Integration in Pervasive Environments (SIPE’08). ACM, New York, 37–42. M UKHTAR , H., B ELA Ï D, D., AND B ERNARD, G. 2008b. User preferences-based service selection for ad hoc task composition in pervasive environments. In Proceedings of the Workshop on Service Discovery and Composition in Ubiquitous and Pervasive Environments. M UKHTAR , H., B ELA Ï D, D., AND B ERNARD, G. 2009a. Quantitative model for user preferences based on qualitative specifications. In Proceedings of the IEEE International Conference on Pervasive Services (ICPS’09). M UKHTAR , H., B ELA Ï D, D., AND B ERNARD, G. 2009b. User preferences-based automatic device selection for multimedia user tasks in pervasive environments. In Proceedings of the 5th International Conference on Networking and Services (ICNS’09). 43–48. O PEN SOA C OLLABORATION. 2007. Service component architecture (sca): Sca assembly model v1.00 specifications. http://www.osoa.org/. ´ , M. AND C AMPBELL , R. H. 2003. A middleware-based application framework for active space R OM AN applications. In Proceedings of the ACM/IFIP/USENIX International Conference on Middleware (Middleware’03). Springer, 433–454. S OUSA , J. P. AND G ARLAN, D. 2002. Aura: An architectural framework for user mobility in ubiquitous computing environments. In Proceedings of the IFIP 17th World Computer Congress - TC2 Stream/3rd IEEE/IFIP Conference on Software Architecture. Kluwer, 29–43. VALIENTE , G. 2007. Efficient algorithms on trees and graphs with unique node labels. In Applied Graph Theory in Computer Vision and Pattern Recognition, 137–149. Received June 2009; revised March 2010; accepted July 2010
