A QoS Model for Task-Based Service Composition - MediaTeam Oulu

A QoS Model for Task-Based Service Composition Mikko Perttunen, Marko Jurmu, Jukka Riekki Department of Electrical and Information Engineering and Infotech Oulu University of Oulu , Finland {firstname.lastname}@ee.oulu.fi

Abstract. This paper presents a system, where a model of the user’s tasks is used for automatic service composition in smart spaces. In the system service modeling is decoupled from resource modeling. We present a model for quality of service (QoS) based service composition, integrating it with our resource management scheme. A component acting on behalf of the user composes the service with the aim of maximizing the QoS for the currently active user task. This functionality is decomposed to the description and determination of static and dynamic QoS. The concept of static QoS refers to the degree of match between the requirements of the user’s active task and the qualities and capabilities of a service composition. Dynamic QoS extends static QoS by taking into account the current state and availability of the resources. Keywords: lease, resource, context-aware, mobile computing

1 Introduction and Related Work As its name implies a main element of the field of pervasive and ubiquitous computing [1,2] is that computing is done around us on various devices in the environment. According to this vision the computational resources of our living environments become an inherent part of executing our daily tasks. As a direct result of this progress, we will witness service- and resource rich environments called smart spaces. Due to the difficulty of selecting the best service and the increased usage of these services, the interaction models between users and their surroundings can no longer be based on a single application or a service. In order to alleviate this cognitive load a new paradigm has emerged; In this paradigm, the tasks of users are represented explicitly. Sousa et al. [3] call systems conforming to this paradigm task-aware systems, and Masuoka et al. [4] call them task computing systems. A major challenge in this approach is to effectively bind this representation to the real-world facilities at runtime. Satyanarayanan [1] sees smart spaces as a step towards truly pervasive computing. The usage of these physical spaces with embedded computing infrastructure entails also new problems. Painting the landscape for adapting to variable resource conditions of smart spaces, he asks the following relevant questions: “How will the implementation of a smart space honor resource reservations? What are the most appropriate admission control policies when there are competing requests from

multiple clients? What resources beside wireless network bandwidth is it meaningful and useful for a smart space to reserve? What are the application programming interfaces (APIs) and protocols necessary to negotiate these reservations?” Our work touches most of these questions, although we focus on managing tangible resources such as devices providing input and output interfaces, for example. We think that a smart space should aim to provide the best resources for users’ tasks at anytime to maximize the quality of the user experience, but at the same time to handle conflicting requests from multiple users. The interactions between the users and such intelligent environments are typically ephemeral due to the mobility of the users. The presence of multiple users and the continuing change of users in the space mean that access to the resources of the space should be controlled. This refers to both access control rights for different user groups as well as to conflict resolution for simultaneous requests to a resource. Moreover, resources should be freed as soon as they are not actively used. There has been considerable effort in developing discovery and management architectures and mechanism for services. Service discovery architectures include Jini [5], UPnP [6], and UDDI [7], for example. These however feature only primitive management schemes that appear insufficient for the task-based computing paradigm. An important aspect of service discovery is matchmaking [8], where the system tries to find a matching service description in its service directory by checking the entries against the discovery request. In service discovery systems, time-based leases can be used to maintain the validity of the data in the service directory. That is, the service directory offers a lease for the service provider when it registers a service. If the provider does not renew its entry before the lease period is over, the directory entry is removed. Two different exemplars of discovery systems using such leasing include Jini [5] and the directory facilitator in the JADE agent environment [9]. Mobach et al. utilize leasing to resource management of an agent environment [10]. The target of their system is to support (mobile) agents in finding execution environments which offer suitable resources for the agent. To enable this, representations of the agents’ resource requirements and of the agent execution environments’ capabilities are needed. The resource provider specifies also conditions for the usage of its resources. These conditions are specified in policies. The role of the management system is to choose the agents that are allowed to access the system and to determine the way they are allowed to make use of the resources. The manager does this through evaluating the requirements of an agent against the resource policies. Upon accepting an agent, the manager assigns it a time-based lease for the resources it is allowed to use. It is the role of the agents to renew the leases before they expire. Several languages and knowledge representation systems have been used to describe services [8]. As an example, we consider the OWL-S Semantic Markup for Web Services [11]. A service in that context is described with a profile, a grounding, and a model. Without giving an exhaustive listing of details, the OWL-S service descriptions include name, preconditions, inputs, outputs, effects, and categories. These descriptions are needed to be able to automatically discover and compose services. For example, a service can be composed by using different planning techniques [12,13]. The planning system has to take into account, for instance, the

suitability of outputs of a service as the inputs of another service, and the preconditions and effects of the service execution. A service, as described above, can be as simple as a sensor providing its current reading or as complex as an e-commerce system with a credit card payment mechanism. The smart space services often require physical resources. For example, a large display may be required by a service that displays slides with a high quality. This should be modeled in its service description. Although resource management is an essential topic in smart space research [14,15], not much has been done thus far. Gajos [15] analyses the role of a resource manager in such an environment. His main argument is that the role includes mapping and arbitration; Mapping is the process of finding the most suitable resources given a request. This functionality is also called matchmaking [8], and we designate this role to service discovery. Arbitration means managing possible resource conflicts. Due to users’ mobility and other causes of variable availability of resources, the resources bound for the execution of a task change dynamically. Consequently, smart space software should support fluent resource replacements. Targeting this problem, among other, Sousa et al. [3] suggest space-independent task descriptions. In their system the user can configure abstract structures for their tasks through a graphical user interface. Configurable policies are used to guide the resource selection. Ranganathan [16] reports a task execution system, where users and services can select a task to be executed from among pre-defined tasks. The system executes the task by loading a pre-specified task plan, then discovering and binding the best available resources for the resource placeholders that are represented by variables in the plan. Tripathi et al. [17] present a specification model for context-based collaborative applications. The specification model deals with different activities that encompass different user roles, as well as descriptions of resources required for those activities. Access to resources is controlled through role-based access policies. In the context of our work on resource management [18], we consider smart spaces as execution environments for the users’ tasks. From this point of view the service usage begins with discovering services based on the task description of the user. The next phase is to determine the smart space resources required by the service and checking the availability of those resources. This is followed by acquiring leases for the resources, the actual service usage, and the termination of the service usage. Resource manager controls the availability of resources, the leasing and termination phases as well as the possible lease renewal phase. Access control is handled in the leasing phase. Our resource management solution is based on the concept of leasing. We extended the basic leasing concept by including contextual information other than time into the lease validity criteria. The context-based validation criteria facilitate the resource management. These criteria define the context in which the usage is allowed, including temporal and spatial limitations as well as information regarding the user. Violation of these criteria leads to termination of the lease, and the resource is freed. In this paper we present a model for QoS based service composition, integrating it with our resource management scheme. The main contributions of the paper are the following. Firstly, our concept decouples service modeling from resource modeling. Secondly, it includes a resource leasing process to allow a user with a mobile device to bind smart space resources to his use during task execution. Previous work

typically considers only one user, whereas our resource management concept handles conflicting requests from multiple users. Finally, the concept includes a QoS model for facilitating the selection of best resources for user’s tasks. The rest of this paper is organized as follows: Section 2 presents an example usage scenario. Section 3 presents the system and Section 4 describes the relevant representations. In Section 5 we focus on calculating the static and dynamic QoS along with an example. Section 6 concludes the paper as well as lists some future work.

2 Example Usage Scenario In order to give a tangible example of the kind of situations where the requirements for our system stem from, we present a scenario in this section: While walking towards a cafeteria at an airport, Jim receives a message from his friend asking him to get in touch through a video call. Jim sets video calling as active task. The mobile device starts finding the best resources for the video call. His device finds out that there is a large screen and a web camera nearby, but they are currently in use and available in a maximum of one minute. However, the device also discovers another free web camera just across Jim. According to Jim’s preferences, the mobile chooses to make a reservation for the closest device, since the mobile device has a reasonably sized display as well. The device instructs Jim the route to the web camera. When Jim is at the web camera, the mobile device adapts by dynamically reconstructing Jim’s video calling service to utilize the external video input. The video call is initialized with the incoming video fed to the mobile’s screen, video input to the web camera, and the audio input and output to Jim’s handsfree. Jim is allowed to use the web camera with the following validity criteria: user proximity less than two meters and maximum duration of the lease 10 minutes. After a few minutes, Jim ends the call. Leaving the proximity of the web camera violates the validity criteria of the lease, and it is terminated. The web camera becomes available for other usage.

3 System In this section we give an overview of the system and describe the main components and functionalities of the system. These are derived from the above scenario, generalizing where appropriate. 3.1 Overview Fig. 1 depicts an overview of the system. In the figure, tasks refer to each user having one or more tasks, of which only one is active (currently executed). Each task is described with a task description. In this paper, we consider only atomic tasks,

although in the general case tasks may have more complex structures. Examples of the kind of tasks we consider are ‘programming’, ‘video calling’, and ‘schedule a meeting’. User can explicitly switch the active task among the current tasks. For example, while showing a slide show through a projector in a meeting, switching to reading mails causes the image to be removed from projector, if the task description contains a preference ‘external resource usage not allowed’ When task is switched, the active task is mapped to use the available resources. If this is the first time the task becomes active in the current situation, new leases may be acquired. Leases are userdependent, not task-dependent. That is, if a user switches task, the leased resources not used by the new active task are not given away. The reason for this is that the task may be switched back soon. User has one or more user preferences (e.g. ‘use external display when larger than current display’). User's task descriptions automatically include all user preferences, and may over-write and add new task-specific preferences (e.g. ‘usage of external displays not allowed’). This way the system needs to handle only task descriptions when it discovers and assembles services.

Fig. 1. System overview.

Resources are objects that are used in executing services, and they feature management interfaces decoupled from the services. The rules governing the usage of a resource are defined in its usage policy. The runtime binding of resources to services can be supported by two different conceptual models. The description of the

resource instance may specify the services it supports. Since different instances of the same resource type have different capabilities, the supported services cannot generally be defined in the resource type’s description. Alternatively, service descriptions may specify their resource requirements. We follow the latter approach in our initial design, because it allows, in principle, the resource descriptions to be defined once and be valid forever, while different services utilizing the resource can be added continuously. Another aspect of resource modeling is shared versus exclusive access to a resource. In the special case of shared resources (such as bandwidth), multiple simultaneous services can be supported at runtime. Services are objects to which computational access is possible through an interface. Services utilize resources according to binding rules described above. Service description may contain arbitrarily detailed description of a service. The concept of static QoS refers to the degree of match between the requirements of the user’s active task and the qualities and capabilities of a service composition. Dynamic QoS extends the static QoS by taking into account the current state and availability of the service. The availability of the service depends on the resources it requires. We explain the process of determining QoS in more detail in a following section. 3.2 Components In the following we list the main components of our system. Service assembly (SA) is a component that interprets the task description and composes a customized service composition for it. SA’s goal in the composition process is to maximize the QoS for the currently active task of a user. This maximization takes into account the suitable resources and their future availability estimates, and incorporates the cost of the composition process itself. In this paper, we only concern ourselves with determination of the QoS based on the information relevant to our scenario. The user provides a description of his tasks to the system. This could be done through a task GUI like in the system of Sousa et al. [3], and we do not consider this phase any further in this paper. When SA has the task descriptions and user preferences, it starts building an initial service composition for the task. SA also subscribes the context information that it needs, depending on the current tasks. During service usage various events may trigger an adaptation process. Examples of adaptation triggers are lease termination, context change (e.g. user movement), and task switching. The adaptation process aims to maximize the QoS for the currently active user task. Fig. 2 shows example triggers (the first three messages in the figure) and the key messages exchanged between the components of the system during the adaptation. Please note that the three example triggers in the figure do not represent a sequence of messages, but are to be interpreted as alternatives. Service discovery (SD) stores static descriptions of services and resources and provides matchmaking for service queries. When starting the composition process, SA first builds a query to be sent to SD. The query contains a service composition template (SCT) that specifies the service requirements for the active task. The SCT contains a slot for each required service type, along with possible additional constraints (e.g. maximum allowed distance of a service from the user).

Upon receiving the SCT, SD builds possible service composition candidates (SCC) for the response through matchmaking. Each SCC contains a valid service in each slot of the SCT. After receiving the SCCs, SA ranks them based on their static QoS. The ranking is used in the resource leasing process, described in more detail in section 3.3. Resource manager (RM) maintains the states of the resources in a smart space independently of the services bound to them at a given time. The lease validity criteria and monitoring are initialized by the RM when a resource is leased. The resource manager subscribes the context information relevant to the lease validity criteria from the context manager (CM) and starts monitoring the validity. After a change in the relevant context, the resource manager gets notified and checks the validity criteria. When a validity criterion is broken the lease is terminated and the leaser is notified.

Fig. 2. Adaptation sequence.

3.3 Leasing Process As mentioned above, SA’s goal is to utilize services that maximize the QoS given the user’s current situation and active task. In order to utilize the services, SA needs to

acquire suitable resources for them. Both smart space resources and the mobile terminal’s resources can be utilized. The ranked list of SCCs is used to streamline this process. Each service in a given SCC contains unique identifiers of the resources it requires for execution. The properties (e.g. resolution of a display) of a resource are propagated to the service it is bound to and are used subsequently in the QoS determination. SA acquires the resources from RM through a leasing process, which is illustrated in Fig. 3.

Fig. 3. Resource leasing process from SA’s perspective.

The process begins with determining the set of required resources from all the SCCs returned from RM. Next, SA sends transaction initiation (‘beginTransaction’) message to RM. This message contains the previously determined set of required resources. Subsequently, RM locks the resources in the set for further processing. If this fails due to a simultaneous transaction of another user (‘error’), SA can still lock the free subset of the resources (‘confirmLock’). If this subset is insufficient for every SCC, the transaction ends (‘discardLock’). In the state ‘Dynamic QoS Determination’ SA begins with requesting leases for the resources required by the highest ranked SCC. It can request availability estimates for the set of resources from RM by sending (‘requestEstimates’) message. RM determines an availability estimate for the resources. This estimate contains

information about the current usage, as well as the usage limitations for the requesting user. If the resource is currently in use, the estimate specifies the expected time when the resource becomes available. The response ‘availabilityEstimates’ contains availability information for each resource in the request. After acquiring all estimates for the highest ranked SCC, SA determines the dynamic QoS for it. If the value is high enough, SA leases the resources by sending ‘requestLeases’ message. Note that SA can make this decision because the dynamic QoS of the SCC can only be equal or lower than its static QoS (we describe this in detail in a following section). If the dynamic QoS is not satisfactory, SA starts requesting leases for the next highest ranked SCC. The transaction terminates when SA receives the leases from RM. In case a SCC with a sufficiently high dynamic QoS could not be found, SA can also end the transaction without leasing any resources. The locked resources are freed when the transaction ends.

4 Representations

4.1 Task A comprehensive user model would include the user’s workflows, the required material resources and human resources etc. However, in order to enable rapid prototyping we take a simplified approach. We model the user tasks as independent entities, meaning that there are no dependencies between the tasks. Our task model is based on task templates, similar to those of Sousa et al. [3]. The purpose of the task modeling is to facilitate the user in executing tasks that require multiple services or applications. For the purpose of a following example, an exemplar of a task description in free form text is shown in Fig. 4. The task description lists the required service types and assigns them a name that is unique inside the description. For each service type supplementary capability requirements can be specified. In this case, the description contains an additional constraint stating that the servicing location of each service must be the same. VideoCallTask o Requires VideoInputService ST1 o Resolution 700x500 o Requires AudioInputService ST2 o Requires VideoOutputService ST3 o Resolution 1000x800 o Requires AudioOutputService ST4 o Requires location(ST1) = location (ST2) = location (ST3) = location (ST4)

Fig. 4. Example task description.

4.2 Service and Resource We consider the role of the resource manager to be controlling the usage and availability of the resources in a smart space. A responsibility of the resource manager is also to handle conflicting requests from multiple users. Related to this, the resources have usage policies according to which they can be used. From the point of view of the resource manager, the resource model does not need to include a description of the inputs, outputs, or effects of the usage of the service utilizing the resource. In this respect, the target of resource modeling can be seen as decoupling the service modeling from resource modeling. In this paper, we consider a simplified case, where all the representations only cover the scenario presented in Section 2. Since service discovery also has to deal with descriptions of resources, there should be a common model of resources used by the components. However, there are some differences on the information that each of these components need to know about a resource. The resource model should be able to specify that: • • • • • •

Resource has a unique identifier Resource has a usage policy Resource has current lease(s) and a lease queue Resource specific properties (e.g. resolution) Resource has a type Resource types are organized in a taxonomy

The usage policy defines, for example, a concurrency property. This states whether access to the resource is exclusive or shared. Moreover, lease renewal options, access control properties, and override options (e.g. user from group A may override user from group B) are defined in the usage policy. When the resource usage status is inuse, the resource manager may still create new leases for incoming resource requests. These leases are stored on the resource’s lease queue. Although the previously discussed simplifications to a typical service model can be done, the service discovery and the SA’s QoS determination processes both need a model of the capabilities of the services. As mentioned above, in our model the properties of a resource (e.g. resolution of a display) are propagated to the service. This is done by SD when it builds the SCCs. Thus, our service model includes the following: • • • • •

Service has a unique identifier Service requires resource(s) Service specific properties Service has a type Service types are organized in a taxonomy

The resource requirements of the services specify the type(s) of the required resource(s) and may also specify minimum capability requirements for the resources.

Modeling the dynamic QoS involves describing the availability estimates of resources. This includes both estimating when a resource becomes available and the length of the period the resource would be available for the requesting user. These periods depend on the usage policy of the resource; the policy may state, for example, that a user from group ‘employees’ may use the resource for 15 minutes, or optionally that a user from group ‘employees’ may override a user from group ‘guest’. Dynamic QoS depends also on the location of the resource, so that if the user first needs to move to the resource it lessens the dynamic QoS of the prospective service using the resource. We omit here several factors obviously contributing to QoS, such as the level of ambient noise, presence of other people etc. From the scenario we note the following features affecting the dynamic QoS: • Relative locations of a resource and a user • Current resource status (free, in use); when status is in-use, the leases of the resource’s lease queue • Availability estimate, which depends on the usage policy of the resource 4.3 Lease Leases are negotiated agreements between the mobile client and the resource manager of the smart space, concerning the resources the user needs in performing her task [18]. We argue that leases facilitate management of the resource usage of a smart space in the presence of multiple users, resulting in increased overall quality of service. The basic temporal validity criterion enables the estimation of the future availability of a resource. Because the resource manager can share the estimates with the potential resource consumers, the consumers can consider the availability estimates when determining the dynamic QoS for SCCs. This is clearly not part of the functionality of an archetypal service discovery. Furthermore, examination of the resource’s usage policies and availability status helps the resource manager in conflict management. Leases are dealt with by both the resource manager and the leasers. As mentioned in section 3.2, the lease validity criteria and monitoring are initialized by the resource manager when a resource is leased. The following list contains the requirements for the representation of the leases: • Lease specifies the lease owner • Lease specifies the resource it is for • Lease has a validity context that contains proximity (coordinate or a room-level range) and validity period

5 Calculating Static and Dynamic QoS The similarity between the requirements of the SCT and the qualities and capabilities of a service composition candidate (SCC) determine the static QoS. Thus, the method

and the accuracy of determining the degree of match depend on the representation of both of those elements. This is conceptually similar to service matchmaking. Naumenko et al. review several representations for service matchmaking and their respective distance measures in [8]. In the following sections we describe our initial approach to QoS modeling and determination, mainly serving here the purpose of illustrating the overall functionality of the system. 5.1 Static QoS – A Case In this section we present a concrete, but simplified example on determining static QoS. Fig. 5 shows a floor plan with several computational resources. In the figure all the rooms represent public spaces. Similar to the scenario described in section 2, the user is in the corridor between rooms seven and eight of the smart space and wishes to make a video call. In the following examples we base our location and distance models on room granularity, so that each room is related to its opposite and adjacent rooms with ‘connectedTo’-relations. As exemplars of distance measures based on this model, the distance from Cor7-8 to Room5 is two units and the distance from Cor7-8 to Room8 is one unit. Several location models for ubiquitous computing are reviewed in [19].

Fig. 5. Floor plan of a smart space with computational resources.

The order of presenting the following example is based on Fig. 1, where the basic relations between a task, service, and resources are shown. The task description for the example is shown in Fig. 4 and example user preferences are listed in Fig. 6. The first two preferences define that the user of the mobile device allows using, for example, displays and video cameras from the smart space. Example resources of the mobile terminal are shown in Fig. 7. The audio input and output on the mobile device could be routed to a hands-free, making the execution of the example video call task with external display and a web camera more natural. Based on the above task requirements, user preferences, and resources of the mobile terminal the SA on the mobile terminal creates a service composition template (SCT), which is sent as the query to SD. An example service composition template is

shown in Fig. 8. The first four bullets specify the required services. The last two lines, the servicing location and the proximity requirements, are derived from the task description (Fig. 4) and user preferences (Fig. 6), correspondingly.

User preferences: o Allow usage of external VideoInputDevices o Allow usage of external VideoOutputDevices o Maximum service distance 2 rooms o Maximum service waiting time 3min

Fig. 6. Example user preferences.

Resources in the mobile terminal: o AudioInputResource RM1 o AudioOutputResource RM2 o VideoOutputResource RM3 o Resolution 300x200

Fig. 7. Example mobile terminal resources.

SCT: o Required VideoInputService SQ1 o Resolution 700x500 o Optional VideoOutputService SQ2 o Resolution 1000x800 o Optional AudioInputService SQ3 o Optional AudioOutputService SQ4 o Required location(SQ1) = location(SQ2) o Required proximity 2 rooms

Fig. 8. Example service composition template.

In our design SA can specify some fields in the SCT as optional, so that if smart space does not contain the necessary resources to support a service type in the template, SD can leave it empty. To create additional SCCs the SA can fill these empty slots with services that can be provided with the resources of the mobile device. The optional services in Fig. 8 are those that can be provided by utilizing the resources of the mobile terminal and required services are those that should be found from the environment. When SD processes the SCT, it binds the matching resources to the queried services to produce all possible SCCs. The matchmaking is based on matching the types of the required resources of SCT’s services, specified in their service descriptions, to the types of the resources in the directory. As a simple example, an

‘AudioOutputService’ requires a resource of type speakers or headphones. Furthermore, SD guarantees that the produced SCCs satisfy possible co-location and proximity requirements of the SCT. If the required services of the SCT have ‘minimum capability requirements’ (e.g. minimum resolution) for the resources, those are checked by SD in the matchmaking process. In the example case, we omit such requirements. Fig. 9 shows an example response to the above SCT. In candidate A, a Web camera and a display would be utilized from the environment, whereas in candidate B, only a Web camera would be used as a smart space resource. Note that we have listed the resolution as a property of, for instance, the video input service. Naturally, this is derived from the physical resource and in an actual representation some kind of pointer to the respective property of the resource could be used instead. To shorten the example we do not include a listing of SD’s service directory. As described above, SA builds more candidates considering also the resources on the mobile terminal.

SCC-A o VideoInputService S1 o Resolution 300x200 o Location Room5 o Requires resource R3 o VideoOutputService S2 o Resolution 800x600 o Location Room5 o Requires resource R4 o AudioInputService NIL o AudioOutputService NIL SCC-B o VideoInputService S3 o Resolution 400x300 o Location Room8 o Requires resource R5 o VideoOutputService NIL o AudioInputService NIL o AudioOutputService NIL

Fig. 9. Service composition candidates in query response.

For the purpose of the following example, we define an initial model of the static QoS determination. We model the static QoS of a service composition candidate (SCC) with the following equation:

QoSSscc = ∑ WTi, u SimTi(Pi, scc, Pi, q) ,

(1)

i

where the summation index i runs through all the matching properties of the query and the SCC, Ti is the type of the property Pi, WTi, u is a user-specific or default weight for the type Ti , SimTi is a similarity function for the property type Ti , Pi,scc

is a property value in the SCC, and Pi,q is a corresponding property value in the SCT. Each similarity function returns a normalized value in [0,1]. Thus, (1) models the static QoS in terms of a specific similarity function and a weight for each property type. As a simplification the property values, that is, the properties of the services are compared pairwise and independently of the services they belong to. Note also that in (1) index i runs through only the matching property value pairs and does not assign a penalty for mismatching, or missing properties and values. A more comprehensive method might also determine a total similarity value for each service, then combining these values. Moreover, we would like to note that considering the ontological relations of the service types as well as the types and values of their properties could benefit the similarity calculation [20], especially if generic similarity functions based on the ontological relations could be utilized. Note that in our example, we define a specific similarity function for each property type. With potentially hundreds of property types, this implies too much overhead. We are aware of the difficulties that may arise when determining values for the weights and selecting the most descriptive similarity functions for real life applications. However, we believe that machine learning techniques may help in finding reasonable values for some of the weights. As mentioned before, we consider that the user is currently in the corridor between rooms seven and eight of Fig. 5. Next we show an example procedure for calculating the similarity between the SCT and the each SCC. For the purpose of this example, the resolutions in the task description are interpreted here as optimum resolutions (were there other kind of resolution properties in our example, this property could be named ‘optimumResolution’). This means that both larger and smaller resolutions are handled as worse than an exact match with a service. Thus, similarity of the resolution properties is calculated with equation Simres (R1, R2) = (

Min(x1, x2) Min(y1, y2) + )/2 , Max(x1, x2) Max(y1, y2)

(2)

where R1 and R2 are the values of the resolution properties, x1, x2, y1, y2 are the respective horizontal and vertical resolutions of R1 and R2, and the division by two normalizes the similarity to [0,1]. For locations, we use the similarity function d Simloc(L1, L2) = Exp(- ), d ∈[0,10], d ∈ Ν , 5

where L1 and L2 are the locations, d is the distance between L1 and L2, and parameters of the distance function are positive integers in [0,10]. As the weight the resolution property for both video input and video output we use 0.7 and for location property we use weight 1. The following similarity values relating to candidate A were calculated using and the values from Fig. 9 and Fig. 10: • Sim(SQ1.resolution, SCC-A.S1.resolution) ≈ 0.41, • Sim(SQ2.resolution, SCC-A.S2.resolution) ≈ 0.78, and • Sim(Q1.location, SCC-A.R3.location) ≈ 0.67.

(3) the for the (2)

Substituting the above similarity values and weights to (1), we get a total similarity value •

QoSSA = 0.7x0.41+0.7x0.78+1x0.67 ≈ 1.50.

Similarly, for candidate B combined with RM3 from mobile terminal, we get ≈ 1.42. Thus, with these weights and similarity functions SA would first try to lease the resources from Room5 for the user. As implied before, it is ultimately a challenge to determine such weights and similarity functions that reflect the preferences and intuitions of the user. 5.2 Dynamic QoS – A Case In this section we first introduce the concept of dynamic QoS and then continue the example from the previous section by calculating dynamic QoS values for the same SCCs. We model the determination of the dynamic QoS of a SCC as a function of static QoS of the SCC and availability of the resources the SCC requires. Thus, the determination of the dynamic QoS takes the current state of the resources into account through equation

QoSDscc = Aw ⋅ QoSSscc ,

(4)

where Aw is the availability weight determined through examining the availability of each resource R the SCC requires. Hence, before the QoSDscc can be determined, the availability of each resource must be determined or estimated. The availability of a resource depends on the current state of the resource (free, in-use), the usage policy of the resource, and the user groups the requesting user and the possible current user belong to (e.g. employee, administrator). Thus, the availability weight of a resource R is

AW, R = detavail(STR, PR, QR, GCU, GRU) ,

(5)

where STR is the current state of the resource, including the lease information in case the resource is currently in use, PR is the usage policy of the resource, QR is a vector that contains the lease information for users that are currently on the queue of this resource (including user groups the respective users belongs to), and GCU and GRU are vectors that contain the user groups the possible current user (when STR equals inuse) and the requesting user, respectively, belong to. Returning to the example of the previous section, we now specify some simplifications and then calculate the availability weight of the resources in SCC-A. For that, we define that the resources in SCC-A, that is, R3 and R4 are currently in use (STR = in-use) and have a usage policy that does not allow breaking a valid lease due to differing access right levels. Thus, we do not need to consider the user groups in availability estimation. Moreover, all resources in this example are exclusive, that is, only one user can use them at a time. For this example, we select that the lease period of R3 and R4 will end in 1 minute and that there are no users queuing for those resources. The resource R5 of SCC-B is currently free. With these simplifications and

definitions, the availability of a resource R depends only on the current state of the resource, STR. For the example, we chose to model the waiting time dependency linearly. So calculating the availability weight AW,R of a resource becomes

AW, R = -

1 texp + 1, texp ∈[0, WTmax] , WT max

(6)

where the WTmax is the value of the user preference ‘maximum service wait time’ of the requesting user (c.f. Fig. 7), and texp is the duration from the current time till expiration of resource R’s current lease. (Note that if there was a queue of leases for the resource, sum of the lease lengths should be determined). The final availability weight AW is got by

AW = Min( AW, R) ,

(7)

where AW,R is a vector containing the calculated availability weights for each resource required by the SCC. Using (6) the availability weights for the resources in SCC-A become AW,R3=2/3, AW,R4=2/3 , and for SCC-B AW,R5=1. Selecting the minimum availability weight for SCC-A and SCC-B and substituting these and the static QoS values calculated in the previous section into (4) gives QoSDA=1, and QoSDB=1.42. Thus, in this example the SCC-B would provide the best dynamic QoS for the user. Consequently, SA would lease resource R5 from Room8 and utilize service composition candidate B. As mentioned above, (1) does not assign a penalty for mismatches. If such penalties would be included, the static QoS of SCC-B could be significantly worse and the SCC-A might be selected instead. Furthermore, determining the best similarity functions and weights presents a considerable challenge.

6 Discussion and Future Work In this paper, we presented a system supporting task-based service composition in smart spaces. The composition process is driven by two-tiered QoS model, and integrates with our existing resource management scheme. A major target of our system is to decouple the service modeling from resource modeling. We achieve this target by assigning the responsibility of matchmaking service composition templates with services to service discovery, determination of static and dynamic QoS to service assembly, and management of the resource usage and availability to the resource manager. In this paper, we have shown how these components interact to maximize the QoS for the active user task. In the work of Gajos et al. [15] arbitration means managing possible resource conflicts. We think this is the main responsibility of a resource manager. However, this part of our work differs in two major ways from that of Gajos et al. First, they mainly consider a smart space with one user and their arbitration phase tries to find a global resource utility maximum. This may result in taking away resources from a consumer for the benefit of another. Their system would require a special mechanism

to handle conflicting resource requests from multiple users. Second, we use leases to guarantee a certain resource for the user until the lease validity criteria is broken. Our subjective opinion is that the resources guaranteed to a user should not be taken away in arbitration. Furthermore, we describe a special component, service assembly, which handles the conflicting resource demands of different tasks of a single user. Thus, the resource manager in our work does not have to deal with those conflicts. We defined that leases are negotiated agreements between the mobile client and the resource manager of the smart space, concerning the resources the user needs in performing her task. The main motivation for having a resource manager in a smart space is that it can locally manage the resource usage of the users in the space. If resources were allocated in a decentralized way by using, for example, a contract net protocol [21], the contracts would be done directly between a resource provider and a resource consumer. Thus, there would not be a straightforward possibility for controlling the resource allocation. On the other hand, it could be argued that when the current state of a resource is managed by the resource itself (or a service wrapping the resource), the fault tolerance of the system is higher. Moreover, a design solution residing between the centralized-decentralized distribution continuum could prove to be the best one. Future work is needed in several directions. First, data should be collected to develop a more realistic QoS determination model and to find out the kind of user preferences that are needed in practical use, as well as the best similarity functions. In case of screens, the resolution could be leased in more fine-grained way, focusing on the screen real-estate instead of the resource itself. This functionality naturally raises privacy issues. Second, we are in the process of developing the first realization of the system. We see the agent paradigm as a promising basis for the development of ubiquitous computing systems. Several context-aware systems have used agent programming [22-25]. Clearly, to support interactions between the heterogeneous resources of the infrastructure and their clients, common protocols and content languages are required. Thus, we think that the support for interoperability provided by the FIPA standards [26] is a good base for provisioning infrastructural services. To test, and hopefully validate, the feasibility of our approach we are currently designing the components of our system as JADE [9] agents. JADE is a FIPA compliant agent system developed in Java. JADE provides implementations for FIPA protocols that can be easily used to realize several of the interactions between our system components. For example, the subscribe interaction protocol (IP) can be used between SA and CM as well as between the RM and the CM, and the request-IP by SA to request the SD to query its service directory. We plan to utilize the SL content language [26] through the support provided by JADE. In particular, we are developing a frame based ontology for the resource management scenario in section 2 with the help of JADE Protégé plug-in called BeanGenerator. Acknowledgments. This work was funded by the National Technology Agency of Finland. The authors would like to thank all the personnel in the Capnet program, and the participating companies. The first author would also like to thank the Finnish Graduate School in Electronics, Telecommunications and Automation (GETA) as well as the Nokia Foundation.

References 1. Satyanarayanan,M., (2001) “Pervasive computing: vision and challenges”, IEEE Pers. Commun., Vol. 8, 4, pp. 10-17. 2. Roman,M., Hess,C., Cerqueira,R., Ranganathan,A., Campbell,R.H. & Nahrstedt,K., (2002) “A middleware infrastructure for active spaces.”, Pervasive Computing, IEEE, Vol. 1, 4, pp. 74-83. 3. Sousa,J.P., Poladian,V., Garlan,D., Schmerl,B. & Shaw,M., (2006) “Task-based adaptation for ubiquitous computing”, Systems, Man and Cybernetics, Part C, IEEE Transactions on, Vol. 36, 3, pp. 328-340. 4. Masuoka,R., Parsia,B. & Labrou,Y., (2003) “Task Computing - The Semantic Web Meets Pervasive Computing”, Proc. of 2nd International Semantic Web Conference (ISWC2003), Sanibel Island, Florida, USA, pp. 866-881. 5. Jini Network Technology. (1/9 2007) URL: http://www.sun.com/software/jini/. 6. The UPnP Forum. URL: http://www.upnp.org/. 7. Universal Description, Discovery and Integration (UDDI). (1/9 2007) URL: http://www.uddi.org/. 8. Naumenko, N., Nikitin, S., & Terziyan, V., (2006) “Service matching in agent systems”, Appl.Intell., Vol. V25, 2, pp. 223-237. 9. Java Agent DEvelopment Framework (JADE). URL: http://jade.tilab.com/. 10. Mobach,D.G.A., Overeinder,B.J., Marin,O. & Brazier,F.M.T., (2005) “Lease-based Decentralized Resource Management in Open Multi-Agent Systems”, Proceedings of the 18th International FLAIRS Conference, May, pp. 339-344. 11. Martin,D., Burstein M. & Hobbs J., et al., (1/9 2007) “OWL-S: Semantic Markup for Web Services”, URL: http://www.w3.org/Submission/OWL-S/. 12. Dustdar,S. & Schreiner,W., (2005) “A survey on web services composition”, Int. J. of Web and Grid Services, Vol. 1, 1, pp. 1-30. 13. J. Peer, “Web Service Composition as AI Planning - a Survey”, Univ. of St.Gallen., March 22, 2005. 14. Hellenschmidt,M., (2006) “Some Issues on Requirements for Pervasive Software Infrastructures”, Proceedings of the 1st International Workshop on Requirements and Solutions for Pervasive Software Infrastructures (RSPSI 2006), May 7, 2006, Dublin, Ireland, pp. 549-552. 15. Gajos, K., Weisman, L., and Shrobe, H., (2003) “Design Principles for Resource Management Systems for Intelligent Spaces”, Lecture Notes in Computer Science Vol. 2614: 198-215. 16. Ranganathan A., (2005) “A Task Execution Framework for Autonomic Ubiquitous Computing”, Ph.D. diss., University of Illinois at Urbana-Champaign. Ph.D. Urbana, Illinois, USA. 17. Tripathi,A.R., Kulkarni,D. & Ahmed,T., (2005) “A specification model for context-based collaborative applications”, Pervasive and Mobile Computing, Vol. 1, 1, pp. 21-42. 18. Jurmu,M., Perttunen,M. & Riekki,J., (2007) “Lease-based resource management in smart spaces”, Proceeding of Workshops of the 5th Annual IEEE International Conference on Pervasive Computing and Communications, White Plains, NY, USA, pp. 622-625. 19. Becker,C. & Dürr,F., (2005) “On location models for ubiquitous computing. Personal Ubiquitous Comput”, Vol. 9, 1, pp. 20-31. 20. Li,L. & Horrocks,I., (2003) “A software framework for matchmaking based on semantic web technology”, Proceedings of the Twelfth International World Wide Web Conference (WWW'2003), pp. 331-339.

21. Smith,R.G., (1980) “The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver”, IEEE Transactions on Computers, Vol. C-29, 12, pp. 11041113. 22. Chen,H., Finin,T., Anupam,J., Kagal,L., Perich,F. & Dipanjan,C., (2004) “Intelligent agents meet the semantic Web in smart spaces”, Internet Computing, Vol. 8, 6, pp. 69-79. 23. Riekki,J., Huhtinen,J., Ala-Siuru,P., Alahuhta,P., Kaartinen,J. & Roning,J., (2003) “Genie of the net, an agent platform for managing services on behalf of the user”, Comput.Commun., Vol. 26, 11, pp. 1188-1198. 24. Gandon,F.L. & Sadeh,N.M., (2004) “Semantic web technologies to reconcile privacy and context awareness”, J.Web Sem., Vol. 1, 3, pp. 241-260. 25. Soldatos,J., Pandis,I., Stamatis,K., Polymenakos,L. & Crowley,J.L., (2007) “Agent based middleware infrastructure for autonomous context-aware ubiquitous computing services”, Computer Communications, Vol. 30, 3, pp. 577-591. 26. The Foundation of Intelligent Physical Agents (FIPA). URL: http://www.fipa.org/.