Updating a Context-Aware Service Directory for ∗ M-Services Christos Doulkeridis
Michalis Vazirgiannis
Database Systems Laboratory Athens University of Economics & Business 10434 Athens, Greece
Database Systems Laboratory Athens University of Economics & Business 10434 Athens, Greece
[email protected]
[email protected]
ABSTRACT Several interesting research directions materialize through the convergence of mobile computing and service-oriented computing. As mobile devices keep getting smaller, cheaper and more sophisticated, their use is becoming a commodity. We envision future scenarios that involve mobile devices acting not only as requestors, but as providers of data as well. In order to hide the heterogeneous nature of web data, service-oriented architectures are adopted. Nevertheless, existing service discovery mechanisms usually focus on exact or semantic matching of static attributes, thus ignoring contextual parameters. We argue that context for mobile web services plays an important role in service discovery by increasing the precision and effectiveness of the search. We explain our notion of context regarding web services, describe query evaluation and updates in a context-aware service directory, and show how the management of device profiles is exploited. Our prototype is fully implemented, as part of the MobiShare architecture, thus proving the feasibility of our approach as well as demonstrating its advantages. Keywords: Context-awareness, Mobile Services, Mobile Computing, Service Directory, Service Discovery.
1.
INTRODUCTION & MOTIVATION
Mobile services have emerged by the convergence of mobile and service-oriented computing as a novel category of pervasive computing [15]. While the usage of mobile devices keeps getting part of our daily life more and more, the capabilities of the same devices are enhanced, thus moving away from the client application perspective and towards scenarios of small, ad-hoc mobile service providers [6]. In this respect, mobile devices can provide access to their data through mobile services, thus hiding the heterogeneous nature of data ∗Work partially supported by EU IST project DBGlobe (IST-2001-32645) under the FET Proactive Initiative on Global Computing for the co-operation of autonomous and mobile entities in dynamic environments
scattered around the world, while providing a common, universally accepted, machine-understandable way to exchange information [20]. These technological advances introduce a paradigm shift from traditional desktop applications to new mobile applications, which are characterized by dynamic changes of the actors’ environment, still restricted (though enhanced) device capabilities, limitations in the availability of bandwidth and sudden disconnections from the network infrastructure. Several challenges [9, 16] arise in this novel computing environment, such as information retrieval, query processing, indexing and caching, all inherently dependent on issues like managing service directories, performing service discovery and service composition. The majority of web service architectures use service directories, which facilitate service discovery based on parameters. In the case of dynamic architectures, the role of a service directory is crucial, since it is responsible for enabling the discovery of available services by taking into account several parameters such as: location of the service, hosting device capabilities, type of the returned results. Obviously a context-aware service directory [5] would facilitate service discovery and increase its precision. So far, discovery mechanisms focus either on exact matching based on service attributes or on semantic service discovery (more ambitious approaches). We argue that using the context of devices and services will make the existing methods more efficient. Throughout this paper, a use-case scenario will be adopted to demonstrate the usefulness of our approach. Consider the case of a tourist, Chris, who carries a mobile device with limited capabilities to access world-wide spread information from practically anyplace, while visiting Athens during the Olympic Games. On arrival at the airport, the tourist wants to collect electronic hotel brochures to choose the best accommodation, according to his interests. Thus, Chris initiates a search for web services that provide hotel information, by entering a couple of keywords, such as: hotel, accommodation. After some seconds the result of the search is depicted on the small screen of the device. This comprises a long list of web services and their short descriptions, that return information about accommodation facilities. At first, as Chris traverses through the services, he finds hotels located in other countries. Having found a web service that actually concerns the area around his current location, he invokes it, only to see that it returns a pdf brochure that his
device cannot display. Finally, when he finds a web service that returns results that can be displayed, he is disappointed to see that the hotel is very expensive. Several serious implications and disadvantages of this discovery process materialize through this scenario. First, the data volume sent to the device is extremely large, especially when compared to its small storage space. Then, the precision of the search is very small, since it ignores various important factors that affect the user’s request. Moreover, the whole process is time-consuming and annoying for the user, who downloads information that while relevant, cannot be processed by his device. Obviously, a context-aware approach would increase the precision of the search, and decrease both the amount of exchanged data and the time spent by the user to find what he seeks. The contribution of our work consists of: • motivating the importance of context for web service discovery, especially in mobile environments • increasing the efficiency and quality of the service discovery procedure • introducing update algorithms and a query formulation mechanism for a context-aware service directory • combining device profiles with contextual features of web services to improve the service discovery process
1.1
Organization of this Paper
The rest of this paper is organized as follows: section 2 discusses the notion of context concerning web services and reveals its importance during service discovery. Section 3 deals with querying a context-aware service directory and shows how the precision of the search is increased, when context is taken into account. Section 4 presents basic algorithms for updating the context-aware service directory, while section 5 shows how the management of device profiles can assist in mobile service discovery. In section 6, we present the preliminary experiments we have performed. The related work is covered in section 7 and finally section 8 concludes the paper and explores future research directions.
2.
CONTEXT FOR MOBILE SERVICES
Existing service discovery approaches are based on service directories [21, 22], which provide primitive searching facilities. Initially, service discovery was performed by exact matching of attributes describing services, but this approach was proven restrictive, since it ignored the semantics concerning the search [8]. Later, semantic service discovery approaches [13, 20] provided more flexible means for discovering services. We believe that context-based service discovery is a complementary approach that adds value to existing approaches, by increasing the precision of the retrieval. In mobile scenarios, the volume of environmental data collected by moving objects creates a lot of implicit information. Handling this amount of data with respect to contextawareness is the solution to many challenges of mobile computing. Mobile services are also directly dependent on the
contextual circumstances. Especially when context is combined with other useful information such as user preferences and requestor device capabilities, it offers unique retrieval results by filtering out irrelevant or unsuitable services. Context is used in many areas of computer science such as in information retrieval [2]. In order to exploit context, we must first define the notion of context for mobile service discovery. Having presented a review of context definitions [4], Dey defines context (regarding handheld and ubiquitous computing) [4] as: any information that can be used to characterize the situation of an entity, where an entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves. According to our definition, context in service discovery for mobile computing is the implicit information related to the requesting user that can affect the usefulness of the returned services. Some profound dimensions of context can be: location, time and time constraints, device features, user profiles, etc. The following issues arise from mobility in service discovery with respect to context, namely capturing, representing, processing and its exploitation: • Context sensing mechanisms regarding mobile services can automatically capture available information, when possible. As an example, consider the case of a file sharing service. By means of a simple traversal of the shared directories’ contents, the type of the documents could be obtained, in order to establish the type of results of the service. • Context representation in mobile computing environments has been studied by numerous research groups so far [3]. Several approaches [3] have been presented, with the most prevailing: tagged encoding, key-value pairs, object-oriented and rule-based. As for context representation for web services, a few researchers have recently turned their attention towards this direction [5, 10, 11, 14]. • Context processing is directly dependent on its representation. In this sense, rule-based representations seem to be advantageous, since they inherently support logic processing. However, other approaches are powerful enough to educe refined results based on raw contextual data. • Context exploitation is exhibited by numerous contextaware applications in mobile computing that usually focus on improving service discovery [5, 10, 11, 14], adaptation of content [12], providing personalization of services, assisting human-computer interaction [17], etc. However, these issues are still application-specific and a research challenge would be to provide a generic framework to facilitate context information collection, aggregation, processing and reasoning from heterogeneous context sources. Furthermore, little work has been presented so far regarding context for mobile services.
2.1
Data Model
In our approach, we focus on representation of context for web services and we choose a context representation formalism adopted from previous work on context-dependent representations [19]: context is represented by a set of dimensions that take one or more discrete values or range over a specific domain. Combining different dimensions of context that specify the conditions under which a service exists, results in a graph that represents a specific service category within the service directory. A set of such service categories form the service directory. Note that each service category may contain different contextual dimensions, based on the type of services it includes. Obviously, the combination of different dimensions within a service category results in more costly updates, but improves greatly searching for services based on contextual information.
of service identifiers. Intuitively, the proposed context-aware service directory can be thought of as an index on a traditional table in a relational database, in the sense that it provides context-based retrieval of services stored in the directory. Image Retrieval Services &1 [location=Acropolis] [location=Plaka] &2
&6
We can make some interesting observations based on the description of the graph. First, the graph is mainly constructed by successive context edges that point either to multidimensional nodes or to atomic nodes representing the actual services. There are practically no entity edges (except from those defining service categories) and the only context nodes that exist in the structure are those that represent the available services in the directory. Moreover, the morphology of the graph is similar to a tree, with the only difference that there can exist leaves, which belong to different subtrees (i.e. service nodes pointed by more than one edge, being valid for different contexts). Based on these observations, we find that the graph presents several similarities with multiple way (m-way) search trees [5]. Note that the approach is: • generic, in the sense that it is oblivious of the actual model of the service directory • complementary to existing efforts of standardizing service directories (UDDI, ebXML). In particular, integration of the proposed context-aware service directory with existing implementations, like UDDI or ebXML, by software vendors is easy and straightforward. Since the use of context does not follow a mediator approach, as an external layer on top of the directory, integration with existing directories and registries is accomplished by means
[time=09:00]
[time=14:00] [time=09:00] [time=12:00] [time=07:00]
&8
&7
[image=jpg]
[image=jpg][image=jpg] [image=mpg]
&5
&4
&3 [time=09:00] [time=10:00]
&9
&10
&11
[time=10:00]
[time=14:00] [time=12:00]
&12
&13
&14
&15
[image=mpg] [image=bmp] [image=mpg] [image=bmp] [image=mpg] [image=jpg][image=jpg] [image=jpg] [image=jpg] [image=mpg]
&19 &16 &18 &23 &24 &17 &20 &21 &25 &26 &27 &28 &29 &22 [user=Michalis] [user=Joan] [user=Michalis] [user=Stratis] [user=Chris] [user=Nikos] [user=Makis][user=Niki] [user=Chris] [user=Sue] [user=Chris] [user=John] [user=Maria] [user=Niki] [user=Kostas] #2
The graph (see fig. 1) comprises two kinds of nodes (following the notation of [19]): rectangular nodes, called multidimensional nodes, represent multidimensional entities that present different facets under different contexts, whereas circular nodes, representing entities, are called atomic or context nodes, depending on whether they are leaves of the graph or not. Atomic nodes are able to hold some kind of data and in our approach they represent web services. In our approach, only atomic nodes exist, no context nodes. There are also two kinds of edges: context and entity edges. Context edges are represented by thick lines and they define the contexts (represented by labels called explicit contexts) under which the services hold. Entity edges are plain edges that represent relations between entities, and in this approach they are used to define the service category.
[location=Filopappou] [location=Thiseio]
#1 #3
#5
#41
#40
#42
#1
#5 #43 #1
#45
#44
#46
#13
#17
#14
#6
#18
#15
#7
#44 #8
#40
#12 #11
#13 #9 #19
#16 #19
#10
Figure 1: A snapshot of (part of ) a context-aware service directory that contains image retrieval services, using the following dimensions of context: location, time, type of image, user identity.
3.
QUERYING A CONTEXT-AWARE SERVICE DIRECTORY
In this section, we describe the formulation of queries issued against the service directory and we explore how query evaluation is performed. In previous work [5], we have introduced a context-aware service directory as a mechanism to facilitate service discovery based on contextual parameters. Furthermore, we have discussed in detail how service discovery is performed based on context. In mobile and dynamic environments where users move frequently, it is important to provide for initiating ad-hoc search queries. A simple and convenient way is to support keywordbased search queries. This approach enables the user to express (to the best of his knowledge) what he seeks. In order to present context-dependent results to the user, a separate query capturing his current context should be attached to the user-defined query. Definition 1: Let Qusr be a user-defined, keyword-based query and Qcxt be a context-based query with respect to Qusr . A query Q is a pair (Qusr , Qcxt ), such that Q evaluates to the intersection of Qusr and Qcxt : Q =< Qusr , Qcxt > Example 1: Consider our user Chris issuing a request for available hotels in the area near his current location. A possible user input could be: Qusr = (hotel, accommodation) At the same time, his current context is retrieved and attached to the query: Qcxt = (location=Athens, rt=(html,pdf), price=medium) The result of the search would be a filtered set of web ser-
vices that offer information about hotels, with respect to the contextual parameters provided. Note that the contextual query is formulated automatically, without directly prompting the user to provide information about his context, thus reducing user distraction [15] and annoyance. An interesting issue is about the building blocks of the contextual query. The contextual query consists of a set of queries related to various dimensions of context. Identifying specific dimensions is an application-specific matter that involves the customization of this approach according to the domain of appliance.
atomic node, this node represents a service that is in accordance with the search criteria, and it will be included in the search results. The algorithm ensures that only the atomic nodes, which should be returned, will be examined.
4.
In this section we present some basic update algorithms for the directory structure. Note that construction and search algorithms have been presented in [5]. Assuming a fixed set of contextual dimensions, we focus on update operations regarding (sets of) services and context values. We focus here on three cases that cover the update operations on the directory:
Definition 2: A contextual query Qcxt is a set of queries, each related to a dimension of context: Qcxt =< QL , QT , QU , QD , ... > where some illustrative queries are: QL is a location-based query, QT is a temporal query, QU is a user-oriented query and QD is a device-specific query. The contextual query is issued against the context-aware service directory to match those web services that comply to the requirements imposed by the query. Consider the graph of figure 1, which represents a context-aware service directory and more specifically, the service category of image retrieval services. Image retrieval services are differentiated according to relevant dimensions of context, in particular: location, time, type of image, and user identity. In our scenario, Chris wants to visit picturesque locations in Athens and share his images with other tourists near him. He publishes a service on his mobile device that makes available images of type jpg. As he walks, the service is made available at 10:00 in Acropolis and at 12:00 near Plaka (the oldest section of Athens and arguably the nicest neighborhood in central Athens). Now, consider another tourist who also visits Acropolis shortly after 10:00 and wants to find pictures of Acropolis to store in her PDA. She enters the keywords: Qusr = (photos,Acropolis) to initiate a search for suitable services and at the same time a contextual query is formulated: Qcxt = (location=Acropolis,time=10:05,image=(jpg,gif)) that captures her location, the current time and the representation capabilities of her device. The evaluation of Qcxt on the service directory focuses on the left subtree of the graph (for location Acropolis) and returns service with id: 1, which belongs to Chris, and ignores service with ids: 2 and 3 that return mpg files. As you can see, even for a simple example, the precision of the search is increased and the results are refined in terms of the relevant context. A breadth first search algorithm is introduced in [5] to traverse the graph and spot the services that match the search criteria. The algorithm starts its execution from the root of the graph, and examines all edges that depart from the root. For each of these edges, its explicit context is compared to the context specifier, which determines the context of the search, and if their intersection [19] is equal to the empty context [-] [19], then the subgraph pointed by this edge is ignored. Alternatively, the node (pointed by the edge) is kept for further processing. When the algorithm finds an
UPDATING A CONTEXT-AWARE SERVICE DIRECTORY
• Insert a new service in the directory. • Update the context of a service. Intuitively, to change the context of a service, one has to alter the values of the contextual dimensions. • Merging directories. This refers to merging of graphs representing the directories.
4.1
Insert a New Service
Whenever a new device is registered, its published services must be added to the service directory. Given the context of each new service, an algorithm adds the service in the directory.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Algorithm: InsertNewService Input: Root, servID, k, [d1 = v1 , d2 = v2 , ..dk = vk ] Output: Root Edge e boolean bFoundEdge = true Node newNode, n = Root for i = 1 to k if (e = ExistsEdge(n, di , vi )) then n = e.ToNode() continue else bFoundEdge = false break endif endfor if (not bFoundEdge) then for j = i to k CreateNode(newNode) DrawEdge(n, newNode, dj , vj ) n = newNode endfor endif AddService(servID, n) return Root
Figure 2: Algorithm for insertion of a new service in the directory. The following functions are used by the algorithms. ExistsEdge(n, d, v): verifies the existence of an edge labelled [d = v] that starts from node with identifier n. If the edge exists, it is returned otherwise null is returned.
CreateNode(n): creates a multidimensional (rectangular) node with identifier n in the service directory. DrawEdge(nFrom, nTo, d, v): creates an edge from node: nF rom to node nT o labelled [d = v]. AddService(servID, n): adds a new service with identifier servID in the directory, under node n. FindAncestorAtLevel(i, servID): returns the identifier of the node at depth i (from the root) that is an ancestor of servID. DeleteService(servID): Deletes the service with identifier servID from the directory. Consider a directory with n services under k dimensions of context, namely: d1 , d2 , ..dk . A new service with identifier servID and context: [d1 = v1 , d2 = v2 , ..dk = vk ] is inserted in the directory. The algorithm in figure 2 implements this procedure. The intuition of the algorithm is that a breadth-first search is performed as long as there exist edges with labels that contain the context value of the new service (lines 4-12). When no edge is found, the rest of the contextual path of the service is constructed (lines 14-18), by successive nodes and edges. Finally, a path of context [d1 = v1 , d2 = v2 , ..dk = vk ] is constructed, starting from the root and leading to the new service.
4.2
Update the Context of a Service
In a mobile environment, frequent changes are expected to take place. This is also the case for the context of mobile services. Mobility affects several contextual dimensions and their values, and this motivates the introduction of an algorithm that updates the contextual values of a service. Consider again a directory with n services for the k dimensions of context, namely: d1 , d2 , ..dk . The context of a service changes from: [di = wi , ..dk = wk ] to: [di = vi , ..dk = vk ]. The algorithm in figure 3 implements this functionality.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Algorithm: UpdateServiceContext Input: Root, servID, i, k, [di = vi , ..dk = vk ] Output: Root Edge e boolean bFoundEdge = true Node n, newNode n = FindAncestorAtLevel(i, servid ) for j = i to k if (e = ExistsEdge(n, dj , vj )) then n = e.ToNode() continue else bFoundEdge = false break endif endfor if (not bFoundEdge) then for r = j to k CreateNode(newNode) DrawEdge(n, newNode, dr , vr ) n = newNode endfor endif DeleteService(servID) AddService(servID, n) return Root
Figure 3: Algorithm for updating the context of a service in the directory.
super-peer. This highlights the need for merging directories in mobile, peer-to-peer environments. Let us consider the case of updating a directory DA by merging with another directory DB . Without restriction of generality, let us assume that one of the directories, say DA , contains a superset of the dimensions of the other. Moreover, by means of the restructuring procedure [5], it is always possible to transform the dimension hierarchies of the directories in the form: DA = d1 , .., dj , .., dk and DB = dj , .., dk
At first, the algorithm locates the ancestor node (n) of the service at level i (line 4). The following steps (lines 5-20) resemble the algorithm InsertNewService, using node n as root. At the end, service servID is deleted (line 21) from its initial position and inserted (line 22) at the position defined by its new context. For example consider the directory depicted in figure 4. The context of the grey-colored service 9 changes from: [di = vi3 , dj = vj 5 ] to: [di = vi2 , dj = vj 5 ]. In this case, the function FindAncestorAtLevel() returns node with id 1. Notice that the edge 3 → 9 is a new edge added by the algorithm.
&1 [di = vi1 ]
&2
&4 [dj = vj5 ] [d j = vj4 ]
[dj = vj2 ] [d j = vj3]
[dj = vj5 ]
#1
Merging Directories
In order for a mobile, ad-hoc system to be scalable, a major issue is to move from centralized architectures to distributed solutions. The management of distributed context-aware service directories is a step towards this direction, particularly for peer-to-peer systems that dynamically reconfigure their organization by replacing a number of peers with a
[di = vi3 ]
&3 [dj = vj1 ]
#2
4.3
[di = vi2]
#9 #3
#x
&y
#5
#7
#6
#8
#4
#9
: Service : Graph node
Update service #9 to hold under [di = vi2 , dj = vj5 ]
Figure 4: Update the context for service 9 from [di = vi3 , dj = vj 5 ] to [di = vi2 , dj = vj 5 ].
Figure 5 describes the procedure of merging two directories. Our algorithm finds in directory DA the node RA with context [d1 = v1 , ..dj−1 = vj−1 ] (line 3). Then, for each service that exists in DB , its context is retrieved (line 8) and subsequently the algorithm InsertNewService is executed (line 9) in order to insert the service in DA . In figure 6 two service directories are depicted, namely DA and DB . Services in DA and DB are defined by 3 and 2 dimensions of context respectively. The updated directory DA contains two kind of nodes: white nodes that used to belong to DA in its initial form, and grey-colored nodes that used to belong to DB . The figure gives an intuition of the notion of merging two context-aware directories. Algorithm: MergeDirectories Input: Root1, k, Root2, j, [d1 = v1 , ..dj−1 = vj−1 ] Output: Root1 Node n Context cxt // for example: [d1 = v1 , d2 = v2 , ..] Find RA ∈DA for context [d1 = v1 , ..dj−1 = vj−1 ] n = RA // for every service in DB execute the // algorithm InsertNewService for DA for each servID ∈DB Find the context (cxt) of service servID InsertNewService(n, servID, k-j+1, cxt) endfor return Root1
1 2 3 4 5 6 7 8 9 10 11
Figure 5: Algorithm for merging directories. Directory A (DA )
Directory B (DB ) &1
[d i = vi1 ]
[di = vi2 ]
’complete’ or ’dense’ graph, i.e. m edges starting from every node. In [5], we have discussed the similarity of the graph structure with multiple way (m-way) search trees. Furthermore, the number of nodes for a complete tree of height h and fan-out m is: Nm (h) = 1 + m + m2 + .. + mk = O(mk ) and the mean value of the number of node accesses for a successful context-based search for exactly one service is [5]: E = m/2 ∗ k + 1 = O(mk) With respect to these results, the mean value of the number of node accesses for InsertNewService is: Eins = m/2 ∗ k = O(mk) and for MergeDirectories of directories DA and DB : Emer = nB ∗ (C + Eins ) = nB ∗ C + nB ∗ mA /2 ∗ kA = O(nB (C + mA kA )) where C is a function of mB and kB , concerning the cost of finding the context of a service in DB . Note that the UpdateServiceContext algorithm is of the same class complexity with InsertNewService.
5.
MANAGING DEVICE PROFILES
Mobile devices usually have restricted capabilities in processing, storing and representing data. This fact should be considered during service discovery, since it is useless to locate services providing data in unsuitable formats. Therefore there must exist some provision for serving requests with respect to the requestor’s capabilities. In this sense, a useful and extendable representation for device profiles is the CC/PP specification [23], which is adopted in our implementation, so as to manipulate device characteristics. A CC/PP profile is a description of device capabilities and user preferences that can be used to guide the adaptation of content presented to that device.
[d i = vi4 ]
[di = vi3 ]
&20 &2
&3
[dj = vj1 ] [d = v ] j j2
&6
&7
&4 [d j = vj3 ]
[dj = vj1 ]
&8
[dj = vj2 ] &22
&23
&5
[dj = vj4 ] [d j = vj5 ]
&9
&10
[d j = vj2 ]
&11
[dj = vj1 ]
[dj = vj3 ] [dj = vj2 ]
&21
&22
[d j = vj5 ] [dj = vj3 ] &12
New PMO Arrival
&13
[dk = vk1 ] [dk = vk1] [dk = vk1 ] [d k = vk1 ] [dk = vk1] [dk = vk2] [dk = vk2] [dk = vk2] [dk = vk3 ] [dk = vk1] [dk = vk2 ] [dk = vk1] [d k = vk3 ]
[d k = vk1 ]
#2
#4
#3
#5
#41
#40
#42
#43
#44
#6
#8
#10
#45
#7
#9
#11
#46 #x
&y
#13
#12
: Service : Graph node
#14 #15
#16
#17
&23
[d k = vk2 ] [dk = vk1 ]
[dk = vk1]
Repository API
Database
[d k = vk3 ] #41
#43
#42
PMO moved to another cell
Device Controller
#18
Retrieve Information
#44 #45 #46
#19
CC/PP Profiles Registration Logon Logoff
CC/PP Profiles
Update DA by attaching DB under [di = vi2 ]
Figure 6: Merge directory DA with directory DB for context [di = vi2 ]. Notice that merging directories is a very important feature that enables distributed approaches. Moreover merging can be computed off line and does not affect the performance of the basic search operations conducted on the directory. This is also in compliance with the UDDI synchronization mechanism; there can exist replicas of the same directory, distributed in different locations, that are updated at the end of the day.
4.4
REQUEST/UPDATE
REPLY #40
#1
SQL Server 2000
Complexity Analysis
Consider a service directory that contains n services, and k contextual dimensions. Assume that each dimension can take up to m distinct values. Further on, let us assume a
Laptop computer
PDA
Pocket organizer
Figure 7: Architecture of module responsible for managing profiles of mobile devices. In MobiShare [20], a fully implemented system for sharing semantic and context-aware services and data from mobile sources, we have a module responsible for handling device profiles of mobile devices that consists of the following components (see figure 7): • A Device Repository, which keeps metadata for the mobile objects, in the form of XML documents. These documents describe the capabilities and the special characteristics of the devices.
• A Repository API that provides access to the metadata describing the mobile devices. 14 12 Time (sec)
• A Device Controller, responsible for recording every device that enters the premises of the cell. This module updates the Device Repository whenever a new device registers in the cell, as well as whenever some of the parameters describing the device profile change.
Performance of MergeDirectories for k=4 dimensions
10
m=4
8 6
m=5 m=6
4
m=7
2
Using specific parts of the device profile enables formulating the device query QD . Consider again our tourist searching for attractions and monuments in the near area. He sends a request for web services that provide access to web pages with tourist information. As he issues the keyword-based query, the device profile (see an excerpt, below) is processed and the following device-specific query is built: QD = (htmlVersionsSupported=(2.0,3.2)) Now, the result of the search is a filtered set of web pages, excluding those that do not conform to the supported html versions. For example, web pages published using html 4.0 will be excluded from the results.
0 100 200 300 400 500 600 700 800 900 1000 Number of Services (n)
Figure 8: Time required for merging 2 directories for: k=4 dimensions of context, m=4-7 values per dimension, and n=100-1000 services.
Performance of MergeDirectories for m=7 values per dimension
2.0 3.2
Time (sec)
100 80
k=4
60
k=5 k=6
40 k=7 20 0 100
200
300
400
500
600
700
800
900
1000
Number of Services (n)
6.
EXPERIMENTS
In this section, we present some experimental results concerning the performance of the algorithm: MergeDirectories. We focus on merging, because it is more interesting than the other algorithms, which are of straightforward complexity. All algorithms are implemented in Java and our experiments are performed in main memory on a Pentium IV with 256MB RAM. Given two graphs representing two service directories, we measure the time required for merging the directories for a specified context. An intuition of form of the directories DA , DB used in our experiments is depicted in figure 6. DA contains all contextual dimensions of DB , plus one extra dimension, which is placed directly under the root. For example, when we measure the time for k = 5 dimensions, m = 7 values per dimension and n = 500 services, this corresponds to directories: DA with k = 5 dimensions, m = 7, n = 500 and DB with k = 4 dimensions, m = 7, n = 500 (different services from the ones in DA ). The result of the experiment is the updated DA with k = 5 dimensions, m = 7, n = 1000 services. Figure 8 shows how increasing the number of values per dimension affects the time required to merge two directories, for k = 4 dimensions and for various numbers of services. Figure 9 shows that the performance of the algorithm degrades as the number of contextual dimensions increases. According to our scenarios of use, typical values for k range from 2 to 7 and m ranges from 4 to 10. However, we intend to continue our experiments towards exploring the scalability of the algorithm for larger numbers of k, m and n.
7.
RELATED WORK
Current standardization efforts regarding service directories like UDDI [21] and ebXML [22] present certain limitations.
Figure 9: Time required for merging 2 directories for: k=4-7 dimensions of context, m=7 values per dimension, and n=100-1000 services.
For instance, in [8], the authors achieve service categorization based on their WSDL descriptions, which proves restrictive, when trying to address issues like mobility of services, semantic discovery and context-awareness. Therefore, research initiatives have tried either to enhance the functionality of service directories [1, 8, 18] or to identify new research challenges [7]. The WASP project [14] extends the functionality of UDDI by introducing UDDI+, an attempt to improve the existing service discovery mechanisms regarding semantic and contextual features. However, this approach is technologyspecific, depending on previous work concerning UDDI [21] and DAML-S [13], whereas our approach is an external and independent model that enables context-based indexing within any service directory. While we both stress the importance of the context of a service and focus on improving the performance of service discovery based on contextual parameters, Pokraev et al. [14] provide support for exact and inexact service matching based on their types, capabilities and models, through the use of a context ontology. We expect to deal with inexact matching in our future work. The CB-SeC framework [10] attempts to enable more sophisticated discovery and composition of services, by combining agent-oriented and context-aware computing. Its notion of context is similar to our approach, but the representation is
different. Modelling the contextual information is achieved by means of a recursive function, whereas our approach is more data-centric and focuses on providing a context-based index for service discovery. Lee et Helal [11] also recognize the limitations of existing service discovery approaches and try to exploit context-aware information in this respect. Moreover, they also argue in favor of providing support for context-awareness by means of service registries. The authors introduce the notion of context attributes, as part of the service description, which allow dynamic evaluation of contextual parameters to enhance service discovery.
8.
CONCLUSIONS & FUTURE WORK
In this paper, we showed the importance of context in mobile service discovery and we described an approach that increases the efficiency and quality of service discovery. We motivated the use of a context-aware service directory, we examined how querying is performed, we presented some basic update algorithms for manipulating the directory and we discussed part of our implementation concerning the management of device profiles. Furthermore, we presented some interesting experimental results. Our future work will focus on the synchronization of contextaware service directories in decentralized, peer-to-peer environments and we will explore novel aspects (dimensions) of context. Another interesting research direction concerns the support of inexact matching in the service discovery process, with respect to context. We also intend to deal with user profiles and their representation, that we only mentioned shortly here.
9.
REFERENCES
[1] R. Akkiraju, R. Goodwin, P. Doshi, S. Roeder. A Method for Semantically Enhancing the Service Discovery Capabilities of UDDI. In Proceedings of IJCAI-2003 Workshop on Information Integration on the Web (IIWeb-03), Acapulco, Mexico, August, 2003.
Conference on Wireless Communication Networks, (WCNC), New Orleans, Louisiana, March, 2003. [7] B. Hofreiter, C. Huemer, W. Klas. ebXML Status, Research Issues, and Obstacles. In 12th Int. Workshop on Research Issues on Data Engineering (RIDE02), San Jose, California, February, 2002. [8] M. Jeckle, B. Zengler. Active UDDI - an Extension to UDDI for Dynamic and Fault-Tolerant Service Invocation. citeseer.nj.nec.com/552374.html, 2002. [9] C.S. Jensen. Research Challenges in Location- Enabled M-Services. In the Proceedings of the 3rd International Conference on Mobile Data Management, Singapore, January, 2002. [10] S. KouadriM., B. Hirsbrunner. Towards a Context Based Service Composition Framework. In the Proc. of the 1st Int. Conference in Web Services (ICWS’03), Las Vegas, Nevada, USA, June, 2003. [11] C. Lee, S. Helal. Context Attributes: An Approach to Enable Context-awareness for Service Discovery. In the Proceedings of the 2003 Symposium on Applications and the Internet (SAINT’03), Orlando, FL, USA, January, 2003. [12] W.Y. Lum, F.C.M. Lau. A Context-aware Decision Engine for Content Adaptation. IEEE Pervasive Computing, 2002. [13] M. Paolucci, T. Kawamura, T.R. Payne, K.P. Sycara. Semantic Matching of Web Services Capabilities. In the Proceedings of the 1st International Semantic Web Conference on The Semantic Web, Sardinia, Italy, June, 2002. [14] S. Pokraev, J. Koolwaaij, M. Wibbels. Extending UDDI with Context-Aware Features Based on Semantic Service Descriptions. In the Proceedings of the 1st International Conference on Web Services (ICWS’03), Las Vegas, Nevada, USA, June, 2003.
[2] P.J. Brown, G.J.F. Jones. Context-aware Retrieval: Exploring a New Environment for Information Retrieval and Information Filtering. Personal and Ubiquitous Computing, 5, 4, pp253-263, 2001.
[15] M. Satyanarayanan. Pervasive Computing: Vision and Challenges. IEEE Personal Communications, August 2001.
[3] G. Chen, D. Kotz. A Survey of Context-Aware Mobile Computing Research. Dartmouth Computer Science Technical Report TR2000-381.
[16] M. Satyanarayanan. Challenges in Implementing a Context-Aware System. IEEE Pervasive Computing (Context-Aware Computing), July-September 2002.
[4] A.K. Dey, G.D. Abowd. Towards a Better Understaning Context and Context-Awareness. In the Workshop on The What, Who, Where, When, and How of Context-Awareness, The Hague, The Netherlands, April, 2000.
[17] A. Schmidt. Implicit Human Computer Interaction Through Context. Personal Technologies Vol.4(2&3), pp191-199, June, 2000.
[5] C. Doulkeridis, E. Valavanis, M. Vazirgiannis. Towards a Context-Aware Service Directory. In the Proceedings of the 4th VLDB Workshop on Technologies on E-Services (TES’03), Berlin, Germany, September, 2003. [6] S. Helal, N. Desai, C. Lee, V. Verna. Konark - A Service Discovery and Delivery Protocol for Ad-hoc Networks. In the Proceedings of the 3rd IEEE
[18] A. ShaikhAli, O.F. Rana, R. Al-Ali, D.W. Walker. UDDIe: An Extended Registry for Web Services. In the 2003 Symposium on Applications and the Internet Workshops (SAINT-w03). [19] Y. Stavrakas and M. Gergatsoulis. Multidimensional Semistructured Data: Representing Context-dependent Information on the Web. In Proc. of the 14th Int. Conf. on Advanced Information Systems Engineering (CAISE’02), Toronto, Canada, May 2002.
[20] E. Valavanis, C. Ververidis, M. Vazirgiannis, G. C. Polyzos, K. Norvag. MobiShare: Sharing Context-Dependent Data and Services from Mobile Sources. In the Proceedings 2003 IEEE/WIC International Conference on Web Intelligence (WI’03), Halifax, Canada, October 13-17, 2003. [21] UDDI The UDDI Technical White Paper. http://www.uddi.org [22] ebXML http://www.ebxml.org [23] Composite Capabilities/Preference Profiles (CC/PP) http://www.w3.org/Mobile/CCPP/