A Conceptual Framework for Provisioning Context-aware Mobile Cloud Services

Hyun Jung La and Soo Dong Kim Department of Computer Science

Soongsil University 511 Sangdo-Dong, Dongjak-Ku, Seoul, Korea 156-743

hjla@otlab.ssu.ac.kr sdkim777@gmail.com

Abstract— We observe two of the recent trends in information technology. Cloud Computing (CC) is widely accepted as an effective reuse paradigm. Mobile Computing with Mobile Internet Device (MID) such as iPhones and Android devices becomes a convenient alternative to personal computers by integrating mobility, communication, software functionality, and entertainment. Due to the resource limitations of MIDs, cloud services become an ideal alternative to software installed on MIDs. A key feature of MIDs is the capability of sensing users’ contexts such as location, acceleration, longitude, latitude and movement. Hence, it is tempting to configure and provide cloud services for the specific context sensed, such as location-specific Map service. In this paper, we present a framework for enabling context-aware mobile services. The framework enables tasks of capturing context, determining what context-specific adaptation is needed, tailoring candidate services for the context, and running the adapted service. The net result of context-aware services is for consumers to receive better services which fit to the current context of the consumers.

Keywords- Cloud Service, Mobile Internet Device, Context-awareness, Adaptation

I. INTRODUCTION

The motivation behind our research is derived from two trends in IT area; Cloud Computing (CC) and Mobile Computing with Mobile Internet Device (MID). CC is widely accepted in both industry and academia, as an effective reuse paradigm where reusable services are deployed once and shared by many potential consumers. Meanwhile, mobile internet computing is emerging with the advent of yet more powerful MIDs such as smart phones and portable multimedia player.

One downside of MIDs is the limited resource including processor speed, primary and secondary memories and battery life. Hence, large-sized applications could not be deployable on MIDs. A well-matching solution is to deploy reusable services on the service provider side, and to let MIDs access these services over the Internet.

A key feature of MIDs is the capability of sensing users’ contexts such as location, acceleration, longitude, latitude and movement. Hence, it is tempting to configure and provide cloud services for the specific context sensed, such as location-specific Map service. As a motivating example, consider a MID running an application which subscribes several cloud services. As the user moves, its current context

can be changed as shown in Figure 1. The X axis shows different contexts monitored, and the Y axis indicates invoked services for the contexts. Initially, the application invokes Service1 for Context1. As the context is changed to Context2, the application enables to invoke another service to adapt the changed context. This activity is called context-aware service provisioning which is represented with Service Substitution, Service Rerouting, and Interface Adaptation in the figure.

InvokedServices

Context2 ContextnContext1

Timeline

Service1

Service2

…

ServiceSubstitution Interface

Adaptation

ServiceRerouting

InitialBinding

…

Figure 1. Context and Context-aware Provisioning

A key technical challenge is to monitor user contexts and to provision right services for the contexts. Especially, the context of current user’s location finds a number of useful applications [1]. Sometimes, a same service could satisfy the services requirements set by different contexts. Some other times, slightly different services in terms of functionality and QoS could be required for different contexts. A feasible approach to providing different services for the different contexts is to develop services which can be dynamically adapted for the contexts.

Moreover, most works have studied about context-aware system reconfiguration. As service-oriented concepts are getting popular, context-aware service provisioning rather than context-aware system reconfiguration has been in interest.

In this paper, we present a framework for enabling context-aware mobile services. We first discuss how context-awareness affects CC in terms of computing model and overall architecture. And, we derive a hierarchy of service adapters to tailor services to given contexts by using relationship among context, gaps, cause, and adapters. We also present design specification of the related algorithms. For the paper organization, related works are discussed in

2010 IEEE 3rd International Conference on Cloud Computing

978-0-7695-4130-3/10 $26.00 © 2010 IEEE

DOI 10.1109/CLOUD.2010.78

466

section 2, and context-aware CC in section 3. Section 4 presents four types of context-based service adapters, and section 5 present a framework for context-based service provisioning which is based on an agent. Section 6 presents an overall algorithm to adapt services and four specific algorithms of the adapters. We present a case study to show applicability of our framework and adapters in section 7.

II. RELATED WORKS

There are several approaches to present service adaptations or service personalization based on the context information.

Maamar and his colleagues present an approach of context based web service composition [2]. They first identify three types of contexts, which are user context, webservice context, and resource context, and their relationships. Moreover, to utilize these contexts in personalizing services, they clarify parameters of each context. And, they present how these contexts interact during context-based personalization and develop different types of policies to guarantee that the service can fulfill its functionality correctly. Although they identify types of context in detail, there is room to enhance the way how services are personalized based on these contexts in detail.

Seyler and his colleague present an approach to adapt web service orchestrations based on context information [3]. To do so, they define meta-models for context-aware service composition, which are service composition meta-model,context meta-model, and combined meta-model of two previous meta-models. The third model is to describe context-aware orchestrations of web services and their adaptation to relevant context situations. Based on meta-models, they present deployment-time adaptation and run-time adaptations. Their approach mostly focus on integrating composition meta-model with context meta-model at deployment-time or run-time, rather than presenting an algorithm to personalize services by using the meta-models.

Sheng and his colleagues develop a multi-agent based architecture that aims at providing a distributed, adaptive, and context-aware platform for personalized service provisioning [4]. The architecture realizes three design principles, which are Web Service, Agent, and Publish/Subscribe System, and consists of four layers such as User, Context, Orchestration, and Service Layers. At runtime, client applications allow users to define personalized composite services by using preferences, context agents collect user context, device context, and service context, and orchestration agents generate orchestration of a composite service. It is needed to define concrete types of service personalization and their detailed algorithms.

Sell and his colleague present a way to adapt workflows context-sensitively by introducing a separate layer, adaptation layer [5]. The adaptation layer automatically calculates and semi-automatically executes the necessary workflow adaptations after interacting with a context service to subscribe context changes and an adaptive WfMS to implement the workflow adaptation. For this, they define an

overall architecture and present an adaptation procedure where activity interdependencies and state interdependencies are considered. They present the adaptation procedure conceptually, but it needs to be improved to an implementation level.

Soukkarieh and his colleague present an architecture aiming at adapting content and presentation of services to the user’s context [6]. First, they present an architecture for managing adaptive services, which consists of Context Management Component, Service Management Component,and Adaptation Management Component. Then, they define a method to personalize data representation to the terminal capabilities, network capacities, or user preferences. Also, they consider generating service interface codes automatically. They identify types of adaptations to user’s context, but detailed algorithm for those adaptations needs to be improved.

III. COMPUTING MODEL FOR CONTEXT-AWARE CC In CC, all the cloud services are located on the provider's

side, and consumers look up and invoke the services. Since consumers' mobile devices can sense and monitor their context, the context information can help to invoke cloud services. In context-aware service provisioning, context-specific behavior should be added [7], as shown in Figure 2.

GatheringContext

AnalyzingContext

AdaptingServices

Context

PerformingServices

Situation AdaptedServices

Adapter Decision Rule

Client Application

Service Invocation withUser and Device Context

Cloud Computing with Context Information

Context Profile

Service Results

Adapter Profile

Figure 2. Computing Model of Context-Aware Cloud Services

A main difference between conventional and context-aware methods lies in the process performed by service providers after services gets invoked. Without context information, a searched service is just bound to the consumer. On the other hand, in CC with context information, the context information is accompanied with the service invocation, and analyzed to determine the current situation of the consumer. Then, a most appropriate service is selected at the stage of adapting services, and the service is invoked. While a service is running, its associated context can change and the service needs to be adapted dynamically.

In summary, the context information provides a key clue to adapt service dynamically in terms of service personalization and fault remedy. That is, there are two cases of utilizing context information. First, context is used to personalize a service invoked by a service consumer. Secondly, context is used to dynamically remedy low QoS problems such as faults at service execution time.

467

IV. TYPES OF CONTEXT-BASED SERVICE ADAPTER

According to changes on the context information, services may need to be adapted to tailor them to a consumer or to remedy service faults. Therefore, we derive several types of context-based adapters in this section by analyzing types of gaps, types of causes to the gap, and types of adapters for the given cause.

We consider multi-layered relationships among context-related elements as shown in Figure 3. The figure consists of four layers in deriving context-aware service adapters; Contexts, Gaps, Causes to gaps, and Adapters.

Context

ServiceSubstitutor

DeviceContext

UserPreference

ServiceComponentSubstitutor

ServiceRerouter

SituationalContext

Service–levelUnmatched

Cause

Srv. Comp. levelUnmatched

Cause

Instance levelUnmatched

Cause

Service InterfaceAdapter

«led by»

Gap onFunctionality

Gap onNon Functionality

«led by»

ServiceContext

MonitoredContext

Gaps

Causesto Gaps

ApplicableAdapters

Gap onInterface«led by»

Interface–levelUnmatched

Cause

Figure 3. Context-Concerned Hierarchy

The top layer of the context-concerned hierarchy is the layer of Monitored Context, which represents the currently monitored context. There are different meta-models of context in services which are presented in representative works [2][4][7][8]. From our survey on them, we define four elements of contexts in Figure 3; Device Context, User Preference, Situational Context and Service Context.Device Context is the environmental settings and configurations of the user’s device. User Preferencespecifies user-specific preference settings, especially those regarding to services selection and invocation. Situational Context is a set of monitored data and information regarding the user’s location, time, and other current settings related to the user. Service Context captures the current status of a service provided such as monitored values of QoS attributes. In context-aware service provisioning, target services should be tailored for the given context, and there often exists a gap between an available service and the service needed for the context.

The second layer in the figure is for Types of Gaps,which specifies three different types of gaps that can occur. To derive types of gaps resulting from context changes, we need to know targets where the gaps occur. As shown in Figure 4, as a user moves with his own MID, the user's context can be also changed from Context1 to Context2.Along with the context change, a service to be bound can be also changed since a former service does not fully match to a new context. Hence, there exist some gaps between Service1 and Service2.

Context2Context1

MID MID

op1

moves

op1

Service1 Service2

bindsNewly binds

Gap occurrence

Cannot invoke!!!

Figure 4. Different Levels of Service Realization

Since a service normally consists of functional and non-functional parts, gaps can occur there. Hence, we derive two kind of gaps; Gap on Functionality and Gap on Non-functionality.

Gap on Functionality is a minor difference between available service and the service demanded for the given context. For example, if a consumer needs a functionality finding a shortest path to get to a destination, the functionality should be specialized / tailored by each type of transportation means such as bus, taxi, or subway. Gap on Non-functionality is a difference between currently measured QoS values and their previous values. This typically occurs when a service consumer travels or the environment of the service platform gets changed.

Accordingly, gap on functionality may result in Gap on Interface. Gap on Interface is a minor difference between the interface of available service and the interface expected / used for the given context. Since a service interface is one of the means to describe service functionality, differences in service functionality may lead to ones in service interface.

The third layer in the figure is for Types of Causes whichspecifies potential causes for the gaps. Causes occur on different levels of cloud service realization, as shown in Figure 5; Service Level, Service Component Level, and Component Instance Level. CaaS service consumers invoke certain services through their own applications, and SaaS service consumers invoke certain services within SaaS.

A service is a self-contained unit through its own interface which is bound to a client application or SaaS, a service component is an implementation for a service, and component instance is an instance of a service component that performs its functionality at runtime. That is, different services have different interfaces, and there can be different service components implementations for the same service interface. Different component instances can be instantiated from a same service component.

SVC1

SVC2

Client applicationor SaaS

…

«class»Comp1

«class»Comp2

«class»Ins1

«class»Ins2

At ServiceLevel

At Service ComponentLevel

At InstanceLevel

Figure 5. Different Levels of Cloud Service Realization

468

According to the given context, context-aware service provisioning can occur on any of these three levels. The third layer in Figure 3 lists four possible causes, which can result in occurrences of the gaps. They are Service-level Unmatched Cause, Service Interface-level Unmatched Cause, Service Component-level Unmatched Cause, and Component Instance-level Unmatched Cause.

The mapping relationships between gaps and causes are context and service-dependent, and so we need to consider these relationships carefully. Since service functionality is determined by its implementation, Gap on Functionalityresults from different service realization, which belongs to Service-level Unmatched Cause and Service Component-level Unmatched Cause. Only if Service-level Unmatched Cause occurs, differences in service interfaces (i.e. Gap on Interface) may happen, which is in turn derived from Service Interface-level Unmatched Cause.

Gap on Non-functionality indicates that certain QoS of cloud services is degraded. Main reasons can be network latency or hardware/middleware faults deploying the service, which is represented with Service Instance-level Unmatched Cause.

A cause should be removed or remedied by some adapters, which are shown in the fourth layer in Figure 3. We define four kinds of adapters, for the four cause types; Service Substitutor, Service Interface Adapter, Service Component Substitutor, and Service Rerouter. Service Substitutor is to bind different services for the required functionality. Service Interface Adapter is to modify the service interface for a service to be invoked. Different functionality leads specifying different interfaces since an interface explains what the functionality of the service is. Service Component Substitutor is to invoke one of the service components which implement same interface. Service Rerouter is to change location of the component instances to be invoked.

These adapters are the specialized forms of the generic adapter, Adapter, which will be illustrated in Figure 6, and one of the adapters is invoked according to types of gaps resulted from the given context.

V. CONTEXT-AWARE PROVISIONING ARCHITECTURE

Based on the computing model, we define the architecture of a context-aware service provisioning framework. As shown in Figure 6, the architecture consists of three layers; User Layer, Agent Layer, and Service Layer.Each layer has components, and their related dataset.

User layer consists of multiple MIDs, and client applications are deployed on MIDs. Agent Layer plays a role of adapting services by using context information including user preferences. The layer contains three types of components; Context Collector, Adapter Determiner, and Adapter. Context Collector is to gather all the context information from end users or devices. Using the context information, Adapter Determiner is to analyze context information, look up candidate services, choose the most appropriate context-aware service adapter, and invoke an adapted service. (generic) Adapter is to make a service personalized to a service consumer and is specialized to

more specific forms which will be covered in the following section. Service Layer deploys multiple services such as CaaS and SaaS.

User Layer

Agent Layer

Service Layer

ServiceRegistry

AdapterRegistry

ContextRegistry

UserContextRegistry

ContextCollector

AdapterDeterminer

«generic»

Adapter

«service»Service

Component

«service»BusinessProcess

«service»Service

Component

«service»BusinessProcess

«service»CaaS

«service»SaaS

ClientApplicationClient

Application«MID»

ClientApplication

Service invocation& Context Information Service Results

Service ResultsAdaptedService

Invocation

• Device Context• User Preference

•Situational Context

Figure 6. Context-Aware Provisioning Architecture

When it comes to allocating these layers to client and provider sides, we identify three kinds of the configurations as shown in Figure 7. A main difference among the configurations is the location of Agent Layer. The first and second configurations are where Agent Layer is located on the client and provider side respectively, while the last configuration is where Agent Layer is distributed to client and provider side by considering functionality distribution.

AgentContextCollector

AdapterDeterminer

«generic»Adapter

Network

MID

«service»CaaS

«service»SaaS

«service»CaaS

«service»SaaS

«service»CaaS

«service»SaaS

<Agent on Client Side>

Agent

Network

MID

«service»CaaS

«service»SaaS

«service»CaaS

«service»SaaS

«service»CaaS

«service»SaaS

<Agents on Both Sides>

Agent

AdapterDeterminer

«generic»Adapter

ContextCollector

AgentContextCollector

AdapterDeterminer

«generic»Adapter

Network

MID

«service»CaaS

«service»SaaS

«service»CaaS

«service»SaaS

«service»CaaS

«service»SaaS

<Agent on Provider Side>

Figure 7. Three Possible Configurations

At runtime, when a service consumer invokes services with user and device context information, Context Collectorgathers additional context information related to a service and its runtime environment. Then, Adapter Determiner is to discover several candidate services meeting functionalities required by the consumer, to check whether context-based adaption is needed or not, and to determine the most appropriate form of adapter. Finally, the adapted service is invoked and returns the results to the service consumer.

A. Algorithm for Context Collector To support effective collecting context information,

Context Collector is designed with two ways: using pullingpattern and using pushing pattern.

With pulling pattern, Context Collector sends out messages for monitoring purposes to MIDs on certain time

469

intervals. With pushing pattern, a Context Collector implements publish-and-subscribe pattern to register itself to MIDs and to get notified from MIDs whenever context changes. Acquiring context information using pushing is more efficient than pulling, but it requires the active collaboration of MIDs, i.e. MID should actively inform the listener with new context information.

B. Algorithm for Adapter Determiner As discussed in IV, there are several kinds of applicable

adapters. Hence, we need to determine right adapter to provide context-aware services to MID users. In this section, we present an algorithm used to determine the right adapter for the given context, shown in List 1. The overall flow of the algorithm is consistent with the flow of the computing model in section 3.1, and this algorithm is executed by Adapter Determiner illustrated in Figure 6.

Assume that service registry is enhanced to be able to manage information when services can be invoked in terms of types of context [9].

LIST 1. ALGORITHM TO CHOOSE CONTEXT-AWARE ADAPTER

Algorithm adapt(Service aService, ContextType aContext) { // ‘aService’ is the currently provisioning service. // ‘aContext’ is the monitored context.

// Step 1. Determine the type of gap for aContext. 1. GapType gap determineGap (aService, a Context); // Step 2. Determine the cause for the identified gap. 2. CauseType cause determineCause (gap); // Step 3. Save the current states of service invocation. 3. States savedState = getCurrentState(aContext, currentMessage );

// Step 4. Determine & invoke the right adapter. 4. switch cause.getLevel { 5. case ‘Service’: invoke “Service Substitutor”;6. case ‘Interface’: invoke “Service Interface Adapter”;7. case ‘Service Component’: invoke “Service Component

Substitutor”;8. case ‘Component Instance’: invoke “Service Rerouter”;9. }

// Step 5. Restore the state if adaptation fails. 10. IF (result of adaptation fails) 11. restoreState (savedState); 12. }End of Algorithm

Step 1 is to analyze types of gaps occurring in the given context. As discussed earlier, targets of analyzing gap occurrence are between previous and current contexts or services to be bound in each context. Hence, we figure out types of gaps by comparing services in previous and current contexts.

For this, we first identify what contexts are changed by considering all kinds of contexts such as Device Context,User Preferences, Situational Context, and Service Context.Then, according to the changes on the context, Adapter

Determiner checks whether the service functionality depends on the context changes or not. For example, Translation Service delivers different translated languages based on the user’s location and nationality. Hence, it is concluded that this service depends on the context changes. Therefore, by analyzing dependency on the context, we can figure out the types of gaps. When it comes to the types of gaps, we observe that;

Gap on Functionality occurs when the service delivered to MID user has different functionalities according to the user’s current context, like an example of Translation Service.Otherwise, the gap can be concluded as Gap on Non-Functionality.

Then, we check whether Gap on Interface occurs or not by analyzing the provided services.

Step 2 is to determine types of causes for the identified gap. Since there is m to n relationship between gaps and causes as illustrated in Figure 3, this step is not straightforward. Hence, we should consider different cases to decide the correct cause as followings;

Observation #1) If Gap on Functionality and Gap on Interface are detected at the same time, the cause may occur in service-level since different services provide different functionality through different interfaces. Therefore, the cause for this case can be Service-Level Unmatched Cause.Observation #2) If only Gap on Interface is detected, the cause may occur only in interface-level. That is, the cause can be Interface-level Unmatched Cause.Observation #3) If only Gap on Functionality is detected, the cause may occur in service component-level. Observation #4) If only Gap on Non-Functionality is detected, all the causes except can be derived. In this case, we need to consider other factors such as checking available components or available instances.

Step 3 is to save current states of the incoming message (i.e. input values directly entered by a service consumer) and its related target elements. This step is needed to transfer the current states of invoked service to another service to be adapted.

Step 4 is to determine and invoke the most appropriate adapter for the causes. Since the relationship between a cause and an adapter is defined as 1 to 1, an adapter is quite straightforwardly decided.

Step 5 is to restore the original state when adaptation fails. Since there is a chance to partially commit state changes during adaptation, a roll back mechanism is needed.

VI. DETAILED VIEWS OF ADAPTERS FOR SERVICE PROVISIONING

Based on the hierarchy of service adapters for context-awareness, we take a close look at each type of service adapter in terms of its algorithm in this section.

470

A. Design of ‘Service Substitutor’ Functionality: This adapter is to bind different services

for the functionality for the current context. According to contexts, different services can be bound for a functionality required by consumers. For example, a consumer A wants to find the shortest path to get to a specific destination at a bus stop or a subway station. According to the location (i.e. context), a service for finding shortest path of buses or subways may be invoked, which is realized as different services called BusPathFinder and SubwayPathFinder. This adapter is used to choose one of these services according to the given context.

Algorithm: The most essential task is to discover a service interface to be bound from service registry.

LIST 2. ALGORITHM OF ‘SERVICE SUBSTITUTOR’

Algorithm susbtituteService (savedState) {

// Task 1. Define required functionality for the given context 1. Description func defineFunctionality (savedState.func,

currentContext)

// Task 2. Search service interface for required functionality 2. ServiceInterface interface lookupService (func);

// Task 3. Perform adapting service interface. 3. Invoke ‘Service Interface Adapter’ 4. }END of Algorithm

The method substituteService( ) in List 2 is invoked from the line #5 in the algorithm for deciding an adapter in List 1.

Task 1 is to define required functionality that is tailored to the given context. Typically, this adapter is invoked when the functionality tightly depends on contexts. Therefore, we first identify functionality adapted for the context. This information should be stored in advance.

Task 2 is to search a service interface such as WSDL for the required functionality from service registry.

Task 3 is to adapt interface by invoking Service Interface Adapter since there is a gap between an interface expected by a consumer and one provided by the chosen service. This step is necessarily required since different services are invoked in this adapter.

B. Design of ‘Service Interface Adapter’ Functionality: This adapter is to resolve the interface

incompatibility between callers and callees. According to contexts, it is possible to invoke different services with different interfaces for the required functionality. For example, a consumer subscribes a service for searching historical site. According to the country where the consumeris located, different service components which have different interface but realize same functionality can be invoked. In this case, there exists incompatibility between an interface expected by a service consumer and one actually provided service. As service components cannot be

modified due to black-box nature, resolving the mismatches between caller and callee should be done outside of the service component.

Algorithm: For this adapter, we should identify incompatibility of the service interfaces and decide methods to adapt the interface incompatibility as given in List 3.

LIST 3. ALGORITHM OF ‘SERVICE INTERFACE ADAPTER’

Algorithm adaptServiceInterface (savedState) {

// Task 1. Find mismatched parts. 1. MismatchSet mismatches compare(Interface(Caller),

Interface(Callee))

// Task 2. Apply mapping rules to mismatched parts. 2. FOR (all mismatches in MismatchSet) { 3. Rule rulesForMapping searchMappingRule (mismatchType);4. IF (rulesForMapping != null) { 5. applyRule (mismatchType, rulesForMapping,

caller, callee) 6. } 7. }

// Task 3. Invoke a service with adapted interface 8. invoke savedState.invokedServiceName with resolved interface 9. }End of Algorithm

Task 1 is to find parts where interface mismatches occur by comparing Inteface(Caller) with Interface(Callee). Interface(x) consists of three parts; OpName for operation name, ParameterList for a sequence of data types of input parameters, and ReturnType for the type of return value. In line #1, mismatches specifies pairs of mismatches with the following four type of mismatches.

If operation names are not identical, mismatches is on (OpNamecallee, OpNamecallee, OpNameMismatch ). If the types of input parameters are not identical, mismatches is on ((DataTypecaller, Declaration#), (DataTypecallee, Declaration#),InputParamTypeMismatch). Declaration# is the order of declaring the input parameter. If the return types are not compatible, mismatches is on (DatTypecallee, DataTypecaller, ReturnTypeMismatch).If the sequences of parameters are not identical, mismatches is on (ParameterListcaller,ParameterListcallee, InputParamSeqMismatch).

Task 2 is to apply appropriate mapping rules for resolving the mismatches. The rulesForMapping is a set of predefined rules for resolving mismatches and is defined by using mappings. For each type of mismatches, rulesForMapping is retrieved in line #3 and the rule is applied to the mismatch in line #5. With rulesForMapping,incompatible interfaces are resolved and the callee’s operation is invoked with the modified caller’s operation.

Then, task 3 is to invoke the service with an adapted interface.

471

C. Design of ‘Service Component Substitutor’ Functionality: This adapter is to replace a service

component with a compatible service component adapted to the given context. A number of service components which conform to the same service specification can be deployed in a service grid. In this situation, a substitutable service component can be located and can replace the original component. For example, a consumer wants a Translation Service which translates foreign languages to user’s mother language. Let us assume that a provider implements different components for Translation Service which realize the same interface but are tailored to the country where a consumer locates. According to user’s current location, different service components for Translation Service are invoked for the service invocation.

This adapter is the most common and is called as dynamic service composition [3][4][5] which most works consider as a way to adapt service to the context.

Algorithm: The most essential task is to find candidate service components and to validate their compatibility for both functionality and interface as given in List 4.

LIST 4. ALGORITHM OF ‘SERVICE COMPONENT SUBSTITUTOR’

Algorithm substituteServiceComponent (savedState) {

// Task 1. Find a substitutable component. 1. CompatibleComponentList SetOfCompatibleComs

SearchCompatibleComponents (getFunctionality(savedState.invokedServiceName), getInterface(savedState.invokedServiceName))

2. IF (SetOfCompatibleComs == empty) 3. Notify failure due to unavailability. 4. ELSE5. CompSubstituted com = Component with Highest QoS

in SetOfCompatibleComs

// Task 2. Invoke a service with adapted interface. 6. invoke CompSubstituted with savedState. 7. }End of Algorithm

Task 1 is to find a substitutable component. Candidate services are discovered from the service registry with the getFunctionality (SRVinvoked) and getInterface (SRVinvoked)which is the functional description and interface description of the original service component respectively [10]. From this, we can get the candidate (i.e. SetOfCompatibleComs)which has compatible functionality and interface of SRVinvoked (line #1). When considering compatibility in a service interface, input parameters and return type should be evaluated. Compatibility in input parameters is evaluated by considering how much the sequence of input parameters is identical and how much compatible the data types of input parameters are, and compatibility in the return type is determined by how much compatible the data type of return value are.

If SetOfCompatibleComs is not null, the most compatible service component, com, is selected by

calculating QoS of the service components in SetOfCompatibleComs (line #4). It is not trivial to calculate QoS of the service components quantitatively, but can be estimated by these guidelines;

Compare types of quality attributes. If the value of a quality attribute is greater than its expected value, set the value to 1. If the value of a quality attribute is lower than its expected value, apply a calculation; (actualValue/expectedValue * 100).

Task 2 is to invoke the determined service component, com, with saved state.

D. Design of ‘Service Rerouter’ Functionality: This adapter is to modify the location of

a service component which gets invoked, and to reroute the invocation to the new location. Rerouting is a task of intercepting incoming service invocation messages and sending them to other service components which are compatible. When a pool of instances from a component type is maintained, it becomes feasible to reroute the invocation.

Algorithm: A key task is to check availability of substitutable instances of the service component as given in List 5.

LIST 5. ALGORITHM OF ‘SERVICE REROUTER’

Algorithm rerouteServiceInstance (savedState) {

// Task 1. Search available instances for the component 1. InstanceList availableInstances searchInstances (name of the

component)

// Task 2. Get endpoint information of the instance. 2. IF (availableInstances.size != 0) { 3. Endpoint locationOfEndpoint searchLocation

(availableInstances) 4. }

// Task 3. Invoke a new instance with saved state. 5. Invoke new instance of locationOfEndpoint with savedState. 6. }End of Algorithm

Task 1 is to find available instances of the service component. In general, a component middleware maintains pools of component instances. By looking up the pool, available instances are retrieved as in line #1.

Task 2 is to get endpoint information of the instance (line #2), and task 3 is to invoke the new instance with saved state information.

VII. CASE STUDY

We conduct a case study of applying the proposed framework on the domain of Travel Assistant for users with a MID, which can provide the current location information of the user. John as a service consumer wants to search

472

hotels for two nights by using Travel Assistant mobile service, which uses location information and gather current offerings from the eligible hotels. The service finds a list of hotels of which offerings well match to John’s preferences stored in User Preference Profile. The context here consists of current location and user preference, and it is compared to current offerings of the premises.

We now consider two specific situations of adapting services for the context. One case is searching hotels with no user preference, and the other case is searching hotels with a user preference which specifies single room, free Internet, and a fitness center facility. The two cases resulted in using different services as shown in Figure 8.

searchHotelServicewhose interface is searchHotel (String place)advancedSearchHotelServicewhose interface is advancedSearchHotel(String place, String roomtType, String offerings)

«requiredFunctionality»searchHotel

«originalService»searchHotelService

[if user preferences are defined]

[If user preferences are not defined]

«adaptedService»advancedSearchHotelService

«bound»

«bound»

Figure 8. Scenario for Subsituting Services

Now, let us trace the sequence of the algorithm in List 1. In step 1, the gap type becomes Gap on Functionality and then Gap on Interface by considering John’s preference and available services. That’s why a functionality specification expected by service consumer (i.e. advancedSearchHotel)and service functionality specification (i.e. searchHotel)have gaps on interface and functionality. In step 2, the cause type becomes Service-level Unmatched Cause since the two gaps are applied to the Observation #1 discussed in section 5.1. Accordingly, Service Substitutor adapter is selected in step 4. Then, according to the algorithm in List 2, this adapter first searches required functionality for preferences from the profile, and discovers service interfaces which match the required functionality (i.e. advancedSearchHotelService) in task 1 and 2. Hence, this adapter replaces the original service to advancedSearchHotelService at runtime. The net result of applying this algorithm is to be able to provide the right service of searching hotels for John’s personal context.

VIII. CONCLUSION

With the advent of various mobile internet devices such as smart phones and portable multimedia player, we observe a potential happy marriage between CC and MID, which is to providing services for MIDs. That’s why problems resulting from resource limitation of MID can be resolved by deploying functionalities on the provider side in the form of service. In enabling mobile services, there is a technical issue to resolve; monitoring user contexts and provisioning services for the monitored contexts.

In this paper, we presented a conceptual framework for enabling context-aware mobile services by dynamically adapting the service to the given contexts. We first presented how context-awareness affects CC in terms of computing model and overall architecture. And, we identified three types of gaps resulting from context changes; Gap on Functionality, Gap on Interface, and Gap on Non-Functionality. Based on the gaps, we derived four causes by considering different levels of service realizations. Then, we derived hierarchy of the service adapters including Service Substitutor, Service Interface Adapter, Service Component Substitutor, and Service Rerouter. Then, we present an algorithm for each context-based adapter. By using context-sensitive service adapters, we hope that service consumers can be provided with right services seamlessly regardless of changing their contexts.

ACKNOWLEDGMENT

This research was supported by the National IT Industry Promotion Agency (NIPA) under the program of Software Engineering Technologies Development.

REFERENCES

[1] Abowd, G.D., Dey, A.K., Brown, P.J., Davies, N., Smith, M., and Steggles, P., “Towards a Better Understanding of Context and Context-Awareness,” In Proceedings of the 1st International Symposium on Handheld and Ubiquitous Computing, Lecture Notes in Computer Science 1707, pp. 304-307, 1999.

[2] Maamar, Z., Mostefaoui, S.K., and Mahmoud, Q.H., “Context for Personalized Web Services,” In Proceedings of the 28th Hawaii International Conference on System Sciences (HICSS 2005), pp. 66-73, 2005.

[3] Seyler, F. and Taconet, C., “Context Adaptation of Web Service Orchestrations,” In Proceedings of the 16th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 2007), pp. 351-356, 2007.

[4] Sheng, Q.Z., Benatallah, B., and Maamar, Z., “User-Centric Services Provisioning in Wireless Environments,” Communications of the ACM, Vol. 51, No. 11, pp. 130-135, 2008.

[5] Sell, C. and Springer, T., “Context-Sensitive Adaptation of Workflows,” In Proceedings of the doctoral symposium for ESEC/FSE on Doctoral symposium, pp. 1-4, 2009.

[6] Soukkarieh, B. and Sèdes, F. “Dynamic Service Adaptation to the User’s Context,” In Proceedings of 2009 Fourth International Conference on Internet and Web Applications and Services (ICIW 2009), pp. 223-228, 2009.

[7] Yang, S.J.H, Lan, B.C.W., and Chung, J.Y., “A New Approach for Context Aware SOA,” In Proceedings of the 2005 IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE 2005), pp. 438-443, 2005.

[8] Choi, O.J. and Yoon, Y.I., “A Meta Data Model of Context Information for Dynamic Service Adaptation,” In Proceedings of 2007 International Conference on Multimedia and Ubiquitous Engineering (MUE 2007), pp. 108-113, 2007.

[9] Chen, I. Y.L, Yang, S.J.H, and Zhang, J., “Ubiquitous Provision of Context Aware Web Service,” In Proceedings of the 2006 IEEE International Conference on Services Computing (SCC 2006), pp. 60-68, 2006.

[10] Agarwal, S. and Studer, R., “Automatic Matchmaking of Web Services,” In Proceedings of IEEE International Conference on Web Services (ICWS 2006), pp. 45-54, 2006.

473