CASD: Management of a Context-Aware Service Directory - CiteSeerX

CASD: Management of a Context-Aware Service Directory Christos Doulkeridis Dept. of Informatics, AUEB Athens, Greece [email protected]

Michalis Vazirgiannis Dept. of Informatics, AUEB Athens, Greece [email protected]

May 3, 2008 Abstract Traditional web service discovery is strongly related to the use of service directories. Especially in the case of mobile web services, where both service requestors and providers are mobile, the dynamics impose the need for directory-based discovery. Context plays an eminent role with mobility, as a filtering mechanism that enhances service discovery through the selection of the most appropriate service. However, current service directory specifications do not focus on mobility of services or context-awareness. In this paper, we propose CASD, a context-aware service directory, envisioned as a context-based index for services on top of any traditional service directory, and design algorithms for construction, search, update and merge of such directories. Furthermore, we describe the architecture of our system for context-aware service discovery, we present a prototype implementation and discuss the experimental results as well as the overall evaluation. The contribution of this work is the proposal for a novel, enhanced representation model for a context-aware service directory.

1

Introduction and Motivation

Recent advances in mobile and wireless computing allow small, portable mobile devices to act not only as requestors of data (clients), but as data providers (servers) as well, or even having a hybrid role of both client and server (often called servent). As a result, a wealth of data and information is available by autonomous, mobile data sources, which demands novel techniques and algorithms for efficient management. Mobility of data introduces several restrictions, when compared to traditional stationary data management, regarding the hosting device capabilities (energy consumption, limited storage space, low processing capacity, discontinuous connectivity). Furthermore, the heterogeneous nature of 1

semi-structured or completely unstructured data residing on miscellaneous devices requires uniform access methods to enable data sharing. We address context-awareness in such a dynamic and heterogeneous environment. We assume a data-centric and service-oriented [32] approach, in order to deal with some of the aforementioned challenges. Access to data is enabled through web service calls, providing a standard, well-defined interface that tackles heterogeneity issues and problems [33]. In this way, data management related tasks, like searching and querying data, evolve to web service management, like service discovery, invocation and composition. In this paper, the term service refers to web services as defined by the W3C 1 . On the other hand, despite the latest technological advances, handheld devices still have restricted capabilities that hinder the design of straightforward communication protocols and prevent the management of data or services in an easy way. Moreover, mobile users usually prefer using mobile services: a) from nearby locations, b) that return fresh data 2 , c) provided by trusted users, and d) returning results that can be displayed on the requesting device. In other words, several parameters such as location, time, user identity and profile, device capabilities, that involve both the requesting user as well as the service provider, can influence the efficiency of the search for the most suitable service. These parameters constitute the notion of context and highlight the need for context management to support the efficient deployment of applications that strongly depend on mobility of users and data sources. Context plays the role of a filtering mechanism, allowing only transmission of relevant data and services back to the device, thus saving bandwidth and reducing query processing cost. Web service architectures rely on the use of service directories for discovering services [43]. However, when the entities involved (providers and requestors) are static, there exist alternative means of communication, such as direct connection or through an FTP server or even a Web site. The need for directory-based support is more evident in the case of dynamic environments characterized by service mobility and, subsequently, frequent changes of the service status. Thus, the role of a service directory is crucial, since enables 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, etc. This motivates the need for enhanced service directories that enable the provision of more sophisticated service discovery mechanisms. 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 1

W3C, Web Services Architecture. W3C Working Group Note 11 February 2004. http://www.w3. org/TR/2004/NOTE-ws-arch-20040211/, 2004. 2 Freshness is related to the temporal dimension and implies that newly created shared data and resources (images, files, etc) are more popular than outdated ones

2

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 implications and disadvantages of this discovery process materialize through this scenario. First, the data volume sent to the device is extremely large, when compared to its small storage space. Then, the precision of the search is 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 an enhanced service directory that supports context-based filtering of services, would facilitate service discovery and increase its precision. In this paper, we present the complete results of our work, namely a proposal for a context-aware service directory (CASD), envisioned as a context-based index for services on top of any traditional service registry. Each service category is associated with a set of relevant contextual dimensions, which are assigned with values, for each service, that define the service context. An intrinsic feature of our approach is that the adopted representation model is generic, therefore independence from the actual registry implementation is achieved. We also design algorithms for construction, search, update and merge of directories. Furthermore, we present our prototype implementation and discuss the experimental results as well as the overall evaluation. Due to the intrinsic property of CASD, namely that it sits above anykind of registry, we consider CASD as a middleware for serviceoriented applications running on heterogeneous mobile devices, which can provide support for context-awareness to new applications and facilitate their development. The main contribution of our work is the introduction of context-awareness in service directories, to facilitate more efficient and accurate service discovery. Technically we: 1. propose a novel representation model for a context-aware service directory to enhance service discovery, particularly useful in mobile environments 2. present a prototype implementation of the proposed service directory, as well as an experimental evaluation of its performance This paper is a revised and substantially extended version of earlier work [11, 12, 13], where we presented searching, merging of CASDs and the overall architecture. We now extend this work by formally defining the data model, justifying its appropriateness and how to integrate with existing standards, we present update operations on CASD, and we present our complete experimental study. In particular, the contents of Sections 3, 4.3 are entirely new, while Sections 4.1, 5, 6 are either extended or substantially revised. The rest of this paper is organized as follows: in Section 2 we review the related work regarding a) enhanced service directories, b) context-aware service discovery, and c) 3

distributed and mobile service discovery. In Section 3, we discuss in a motivating manner the need for context in mobile service discovery. The context-aware service directory management is presented in Section 4 with algorithms for construction, search, update and merge of directories. Section 5 describes the overall system architecture and the prototype implementation and Section 6 presents the experimental results and the overall evaluation. Finally, in Section 7 we conclude the paper and sketch future research directions.

2

Related Work

In this Section, we present the research initiatives that are considered relevant to our work. We distinguish the following research directions: 1) Enhanced Service Directories, 2) Context-Aware Service Discovery, and 3) Distributed and Mobile Service Discovery. For a recent survey on context modeling, see [40].

2.1

Enhanced Service Directories

Current standardization efforts regarding service directories like UDDI [41] and ebXML [16] present certain limitations. For instance, in [21], 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, 21, 37] or to identify new research challenges [19]. An interesting recent survey of service registries proposed in the bibliography can be found in [15]. Constantinescu et al [8] propose an enhanced service directory that supports indexing of services. In this sense, their work is the most similar to our approach. The authors allow partial matching of services and user-defined ranking functions for decreasing directory response times. As in our case, the importance of indexing within the service directory is recognized, however our main focus is on context representation for services and on contextbased service retrieval. Moreover our approach also focuses on mobility of services. The WASP project [34] 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 technology-specific, depending on previous work concerning UDDI [41] and DAML-S [31], 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. [34] provide support for exact and inexact service matching based on their types, capabilities and models, through the use of a context ontology. Similar work is the one in [3], where the authors enumerate partial matching degrees. We expect to extend our approach towards ontology-based matching in our future work. In [2], the authors propose a context-aware component registry for mobile environments. In their approach, they attempt to combine semantic service descriptions with dynamic 4

context information.

2.2

Context-Aware Service Discovery

One direction of related research exploits agent technology to assist context-aware discovery. Maamar et al [27] present an approach for Web service composition based on the use of agents and context. Their context model (I/W/C-Contexts) is service-centric and comprises three types of context: a) I-context refers to a Web service instance context b) W-context is the Web service context that is defined by means of I-contexts and c) Ccontext is the context of the composite service and is defined by the respective W-contexts. The CB-SeC framework [30] 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 [24] 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. In contrast, our work does not rely on extensions of the service description, rather it is an external mechanism that can be deployed on top of any service registry, to facilitate context-based service retrieval regardless of the service description protocol used. Chen and Kotz [7] propose an extension to attribute-based names for handling contextual information. They use a similar model to our approach and they leave matching based on inequalities for future work. A restriction of this approach is that all attributes must be present for a query to match a context. Moreover their work is not applicable in ad-hoc environments. Robinson and Indulska [35] provide a context-sensitive extension to the Superstring protocol, which is particularly suitable for ad-hoc environments. While the query language supported can be more expressive, this approach is not directly comparable to our approach, as it is designed for specific application scenarios and at the very least its applicability to web service discovery is questionable. In [9], the authors propose an approach for context-aware service discovery based on service attributes. Context is modeled by means of dynamic service attributes. The main focus is on handling dynamic information to support service selection and discovery. In [23], the authors consider client-side context to identify the properties or the situation of the client’s environment. Web services exploit this contextual information, encoded in SOAP messages, in order to adapt to the current context. An extension of WSDL to support context-aware features in the service description is presented in [29]. Our approach does not rely on extensions of existing standards, therefore it is considered more technologically agnostic.

5

2.3

Distributed and Mobile Service Discovery

Distributed service discovery approaches (for instance JXTA [22]) are also relevant to mobile service discovery (and consequently to our approach). Furthermore, distribution of service registries is considered in our work [14, 42]. Compared to [28], our registries rely on a wired infrastructure, communicate and inter-operate directly, in order to support discovery of services hosted by mobile devices that communicate in a wireless way. In fact, we have used the JXTA framework in recent work [14], in order to study mobile service discovery in a distributed architecture of context-aware service directories.

2.4

Remarks

From the aforementioned discussion, we state that the contribution of this work is the introduction of a novel hierarchical representation model for context-awareness, which can be placed on top of any traditional web service directory. The underlying structure is inherently designed for representing contextual information [38], which makes it more suitable and extendable for the purpose proposed. CASD is novel and different than existing web service discovery mechanisms, as it resembles a context-based index that is neutral to the actual service registry. Compared to actual service directories (like UDDI or ebXML), CASD enhances their functionality by introducing context-awareness, without compromising existing formats (such as WSDL).

3

Context in Mobile Service Discovery

Existing service discovery approaches are based on service directories (like UDDI or ebXML), which provide primitive searching facilities. Initially, service discovery was performed by exact matching of predetermined attributes or parameters that belong to the service description, but this approach was proven restrictive, since it ignored the semantics concerning the search [21]. Later, semantic service discovery approaches [31, 42] provided more flexible means for discovering services. The main building block for introducing semantics in service discovery is the use of ontologies. We claim that context-based service discovery is a complementary approach that adds value to existing approaches, by increasing the precision of service retrieval. In mobile scenarios, the volume of environmental data (user’s current situation, surrounding conditions, etc.) collected by moving objects creates a lot of implicit information. Handling this amount of data with respect to context-awareness 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 [4]. In order to exploit context, we must first define the notion of context for mobile service

6

discovery. Having presented a review of context definitions [10], Dey and Abowd define context (regarding handheld and ubiquitous computing) [10] 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 both to the requesting user and service provider that can affect the usefulness of the returned results. In our approach, two kinds of context are identified, namely service context and user context. Service context can be the location of the service, its version, the providers identity, the type of the returned results, (possibly) its cost of use, as well as any other parameter that is considered important, with respect to the potential application. On the other hand, each user is characterized by a user context that defines her current situation. This includes several parameters like location, time, temporal constraints, as well as device capabilities and user preferences. During service discovery user context is matched against service context in order to retrieve relevant services with respect to context-awareness. Context is very important in mobile service discovery, since it can play the role of a filtering mechanism returning only the subset of retrieved services that conform to the user’s current context. Mobility raises several research issues/challenges in service discovery with respect to context, namely capturing, representing, processing and exploiting context: • Context sensing mechanisms regarding mobile services can automatically capture available information. 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 is 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. Several approaches [6] have been presented, with the most prevailing being the following approaches: tagged encoding, key-value pairs, object-oriented and rule-based. In a more recent survey [40], the value of ontologybased modeling is highlighted and this approach is deemed most promising. However, its applicability to distributed and mobile environments is still open for research. As for context representation for web services, a few researchers have recently turned their attention towards this direction [8, 12, 30, 24, 27, 34]. • Context processing [23] 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 context-aware applications in mobile computing that usually focus on improving service discovery [11, 12, 30, 24, 34], adaptation of content [25], providing personalization of services [26], assisting humancomputer interaction [36], etc. 7

However, these issues are still application-specific and a grand research challenge would be to provide a generic framework, envisioned as middleware, to facilitate context information collection, aggregation, processing and reasoning from heterogeneous contextual sources. While there exist middleware solutions [18] for context-aware systems, we stress here that these are not necessarily directly suited and applicable to mobile web services. Towards this goal, we propose in the sequel a generic representation model for context management over any web service directory.

4

Context-Aware Service Directory

4.1

Data Model

In our approach, we focus on representation of context for web services and we choose a representation formalism adopted from previous work on context-dependent representations [38], applicable in various fields, for instance representing histories of semi-structured databases [39]. 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 (or the constraints) of a service, results in a graph that represents a specific service category within the service directory. A set of such service categories (CASD graphs) eventually 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 greatly improves searching for services based on contextual information. In the sequel, we formally define the CASD graph. CASD Graph Definition: A CASD graph is a directed edge-labeled graph CASD = (V, E, e, r), where: 1. The set of nodes V consists of multidimensional and atomic nodes, V = Vmld ∪ Va . 2. The set of edges E consists of context edges and one entity edge, E = Ecxt ∪ e, with e defining the service category. 3. r ∈ V is the root, with the property that there exists a path from r to every other node in V . The graph (see Figure 1) comprises two kinds of nodes (following the notation of [38], namely the MOEM model): 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 8

that represent relations between entities, and in this approach they are only used to define the service category. Information Services Video Sharing Services Image Retrieval Services &1 [location=Athens]

[location=Thessaloniki] [location=Rhodes]

[location=Patras]

&5

&2 [type=mpg]

&3 [type=wmv]

&6

&4

[type=mpg]

[type=wmv]

&8

&7

[band=high] [band=high] [band=low] [band=medium]

&9

#23

#2

#1

#4

#6

#8

#3

#21

#5

#7

#9

&11

&12

[band=high]

[band=medium] [band=low] [band=high]

[band=high]

#10 #22

#20

[type=mpg]

[type=wmv]

&10

[band=low]

[band=high]

#1

[type=mpg]

#11

#13

#15

#18

#12

#14

#16

#19

#17

Figure 1: A snapshot of (part of) a context-aware service directory that contains video sharing services, using the following dimensions of context: location, type of video file, bandwidth availability. In the following, we make some interesting observations based on the properties of the CASD graph, which highlight its differences from MOEM graphs. 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. Obviously, other multidimensional indexing schemes can be employed (for a survey see [17]). Our choice of the MOEM model is explained due to its rich expressiveness, in particular regarding semi-structured data, such as service descriptions. Moreover it is a simple model that meets the case requirements and it does not require complex maintenance algorithms. We stress here that we mainly focus on providing a representation model that supports rich expressiveness and direct support for semi-structured data representation, instead of adopting a more efficient, yet with restricted expressiveness, index for data. Note that the approach is: 1) generic, in the sense that it is oblivious of the actual model of the service directory, and 2) complementary to existing standards or specifications of 9

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Algorithm: Search Algorithm Input: Root, searchContext Output: SelNodes List nodeList, edgeList Root.setVisited(true) nodeList.add(Root) while (nodeList.size() > 0) Node n = nodeList.getNext() if (n.isAtomic()) then SelNodes.add(n) continue endif listEdges = n.getEdges() while (edgeList.size() > 0) Edge e = edgeList.getNext() if ((e.getExpContext() ∩ searchContext 6= [−]) && (e.ToNode().isVisited()==false)) then e.ToNode().setVisited(true) nodeList.add(e.ToNode()) endif edgeList.remove(e) wend wend return SelNodes Figure 2: Search Algorithm.

service directories (UDDI, ebXML). In particular, integration of the proposed context-aware service directory with existing registry implementations, like UDDI or ebXML, by software vendors is easy and straightforward. Since service context is incorporated within the directory, instead of being handled at application level, integration with existing directories and registries is accomplished by means 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.

4.2

Searching and Construction

Having explained the role of the MOEM graph as a model for representing a service directory, it is important to elucidate the service discovery mechanism. We introduce a breadth first search algorithm to traverse the graph and to spot the services that match the search criteria. This algorithm takes as input the identifier of the root and a context specifier, 10

location band Athens high Athens low Patras low ... ...

type mpg mpg,wmv wmv ...

Service #1 #2 #3 ...

Table 1: State Table. which is a syntactic construct representing the context of the search. An example of a context specifier is: [location = Acropolis, time = 09 : 00, image = jpg]. This is a essentially a conjunctive query. Notice that our approach also supports disjunctive contextual queries in the form of q = q1 ∨ q2 , which can be decomposed into conjunctive queries q1 and q2 , then processed separately, and finally use a filtering step to remove duplicates from the result set. Intuitively, we note that there is a path starting from the root to the source, for every service that belongs to the result set of the search. This path should only consist of context edges with explicit contexts consistent with the context specifier representing the search criteria. The algorithm (see Figure 2) 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 ∩ [38] is equal to the empty context [−] (line 13) [38], then the subgraph pointed by this edge is ignored. Alternatively, the node (pointed by the edge) is kept for further processing (line 16). When the algorithm finds an atomic node, this node represents a service that is in accordance with the search criteria, and it will be included in the search results (line 7). The algorithm ensures that only the atomic nodes, which should be returned, will be examined. For example, consider the query: ”find all video sharing services provided in Patras”, which is issued at the service directory depicted in the left graph of Figure 3. The context specifier representing the query is: [location = P atras]. It is easy to understand that applying the search algorithm on the graph, returns service #3. Note that the subgraph with node &2 as its root, is completely excluded from the search, since it holds under the context [location = Athens], thus not conforming to [location = P atras]. We argue that the same graph can be represented by numerous equivalent graphs, by simply changing the hierarchy of the dimensions that define context. We will show that the time required to perform a search depends on the morphology of the graph that represents the service directory. Assume that context is defined for video sharing services by means of the following dimensions: location, type and band. We summarize the contextual information in a table, called State Table. We will construct a CASD graph that represents the information held in the State Table, with the help of a simple construction algorithm (see Figure 4). Let us choose 11

Video Sharing Services

Video Sharing Services

&1

&1

[location=Athens]

&3

&2 [band=high]

&4

[band=low]

&5

#2

[type=wmv] &3

&2 [band=high]

[band=low] &6

[type=mpg] [type in {mpg,wmv}] [type=wmv] #1

[type=mpg]

[location=Patras]

&4

&5

[location=Athens]

#3

#1

[band=low]

[band=low] &6

[location=Patras] [location=Athens]

[location=Athens] #3 #2

Figure 3: Two equivalent graphs holding contextual information.

1 2 3 4 5 6 7

Algorithm: Construction Algorithm Input: State Table (ST) Output: MOEM Graph (G) representing the service directory for each service in ST begin create all possible paths to the service draw the produced paths on G (if a subpath of a path already exists, extend it to point to the specific service) end return G Figure 4: Construction Algorithm.

the dimensions with respect to their order on the State Table, i.e. at first dimension location, then band, and finally type. Consider the root (&1) of the graph depicted on the left of Figure 3. In order to apply the algorithm on the State Table, we start with service #1, and we create and then draw the path that defines the service context, namely: [location = Athens, band = high, type = mpg]. Similarly, for services #2 and #3 we create the corresponding paths. The graph that is constructed by these paths is depicted on the left of Figure 3. Let us now try to construct an equivalent graph. This graph is depicted on the right of Figure 3 and is constructed by selecting the dimensions in a different order. At first, we choose dimension type, then band, and finally location. Search performance is improved when the queries concern dimensions that are closer to the root. In many cases we can optimize service search by restructuring the directory. However, in any case, notice that the correctness of the result is guaranteed, only the retrieval will be slower. The dimensions that appear more frequently in the queries are placed

12

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 ))==true) then n = e.ToNode() continue else bFoundEdge = false break endif endfor if (bFoundEdge==false) then for j = i to k CreateNode(newNode) DrawEdge(n, newNode, dj , vj ) n = newNode endfor endif AddService(servID, n) return Root

Figure 5: Algorithm for insertion of a new service in the directory. higher in the hierarchy, so that larger portions of the hierarchy are pruned faster. This is achieved by monitoring the query workload and maintaining statistics for the queried dimensions. If the frequency of occurrence for one or more dimension surpasses a certain threshold, then the directory must be restructured. Restructuring the directory improves performance due to a reduction of the number of nodes and edges examined by the algorithm. For example, consider the query: ”find all video sharing services that return videos of type mpg”, which is issued against each of the graphs depicted in Figure 3. When the search algorithm is applied to the left graph, all nodes will be processed and services #1 and #2 will be retrieved. The same algorithm applied on the right graph would only traverse the left sub-tree to retrieve the same services. Obviously, in the second case, the performance of the search is improved, and the gain is significant even in the case of graphs of relatively small size.

13

4.3

Updating

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 covering the directory update operations: 1. Insert a new service in the directory. 2. Update the context of a service. Intuitively, to change the context of a service, one has to alter the values of the contextual dimensions. 3. Merging directories. This refers to merging of graphs representing the directories. 4.3.1

New Service Insertion

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. 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. The function returns the edge, if it exists, otherwise null. 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 5 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 context path [d1 = v1 , d2 = v2 , ..dk = vk ] is constructed, starting from the root and leading to the new service. 4.3.2

Service Context Update

In a mobile environment, frequent changes are expected to take place affecting thus the relevant context. Mobility affects several contextual dimensions and their values, and this motivates the introduction of an algorithm that updates the contextual values of a service.

14

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 ))==true) then n = e.ToNode() continue else bFoundEdge = false break endif endfor if (bFoundEdge==false) 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 6: Algorithm for updating the context of a service in the directory. Consider again a directory with n services and k contextual dimensions, namely: d1 , d2 , ..dk . Assume the context of a service changes from: [di = wi , ..dk = wk ] to: [di = vi , ..dk = vk ]. The algorithm in Figure 6 implements the service context update. 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 7. The context of the grey-colored service 9 changes from: [di = vi3 , dj = vj5 ] to: [di = vi2 , dj = vj5 ]. In this case, the function FindAncestorAtLevel() returns node with id &1. Notice that the edge 3 → 9, with context [dj = vj5 , is a new edge added by the algorithm.

15

&1 [di = vi1 ]

&2

[di = vi2 ]

[d i = vi3 ]

&3

&4

[d j = vj1 ]

[dj = vj5] [dj = vj4 ]

[d j = vj2 ] [dj = vj3]

[dj = vj5 ]

#1

#2

#9 #3

#x

&y

#5

#7

#6

#8

#4

#9

: Service : Graph node

Update service #9 to hold under [di = vi2 , dj = vj5 ]

Figure 7: Update the context for service 9 from [di = vi3 , dj = vj5 ] to [di = vi2 , dj = vj5 ].

4.4

Merging Directories

Scalability is a key issue in mobile systems, especially when involved in ad-hoc networks. Then 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 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 loss of generality, let us assume that DA ’s dimensions are a superset of DB ’s. Moreover, by means of the restructuring procedure (see 4.2), it is always possible to transform the dimension hierarchies of the directories in the form: DA = d1 , .., dj , .., dk and DB = dj , .., dk Figure 8 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 in DB , its context is retrieved (line 8) and subsequently the algorithm InsertNewService is invoked (line 9) to insert the service in DA . In Figure 9 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. 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 16

Algorithm: MergeDirectories Input: Root1, k, Root2, j, [d1 = v1 , ..dj−1 = vj−1 ] Output: Root1 1 Node n 2 Context cxt // for example: [d1 = v1 , d2 = v2 , ..] 3 Find RA ∈ DA for context [d1 = v1 , ..dj−1 = vj−1 ] 4 n = RA 5 // for every service in DB execute the 6 // algorithm InsertNewService for DA 7 for each servID ∈ DB 8 Find the context (cxt) of service servID 9 InsertNewService(n, servID, k-j+1, cxt) 10 endfor 11 return Root1 Figure 8: Algorithm for merging directories. of the basic search operations conducted on the directory. This is also in compliance with the UDDI synchronization mechanism, which provides for replicas of the same directory, distributed in different locations, that are updated at the end of the day.

4.5

Complexity Analysis

Consider a service directory that contains n services, and k dimensions (defining the context). Assume that each dimension can take up to m distinct values. Further on, let us assume a ’complete’ graph, i.e. m edges starting from every node, which is the worst-case scenario both in terms of space and time complexity. If we think of the graph as a tree, then its height is: h=k+1 since k is the number of dimensions and each level corresponds to context edges describing one dimension. The fan-out of the tree is equal to the number of values m that a dimension can take, so: fo = m which is the number of edges starting from a node. The number of nodes for a complete tree of height h and fan-out m is: P Nm (h) = mi , i = 0..k therefore the related complexity is: O(mk ). The mean value of the number of node accesses for a successful search (for exactly one service, i.e. node) is: E = m2 × k + 1 = O(mk) m since 2 is the mean value of outcoming edges for each node, in order to find the edge that matches the search criteria, and the search is performed in k levels. When searching for all services that hold under a specific context: 17

Directory A (DA )

Directory B (DB ) &1

[d i = vi1 ]

[d i = vi2 ]

[d i = vi4 ]

[d i = vi3 ]

&20 &2

&3

[dj = vj1 ] [d = v ] j j2

&6

&7

[d j = vj1 ]

&8

&4 [dj = vj3 ]

[dj = vj2 ] &22

&23

&5

[dj = vj4 ] [dj = vj5 ]

&9

&10

[d j = vj2 ]

[d j = vj5 ] [dj = vj3 ]

&11

&12

[dj = vj1 ]

[dj = vj3 ] [dj = vj2 ]

&21

&22

&13

[dk = vk1] [d k = vk1] [d = v ] [d = v ] [dk = vk1] [dk = vk1 ] k k2 k k1 [d k = vk2] [dk = vk2] [dk = vk3] [dk = vk1 ] [dk = vk2] [dk = vk1] [dk = vk3 ]

[dk = vk1 ]

[d k = vk2 ] [dk = vk1] #40

#1

#2

#4

#3

#5

#41

#40

#42

#43

#44

#6

#8

#10

#45

#7

#9

#11

#46 #x

&y

#13

#12

: Service

#14 #15

#16

#17

&23 [d k = vk1 ]

[dk = vk3 ] #41

#43

#42

#18

#44 #45 #46

#19

Update DA by attaching DB under [di = vi2 ]

: Graph node

Figure 9: Merge directory DA with directory DB for context [di = vi2 ]. E = m2 × k + ni = O(mk + ni ) with ni ≤ n representing the number of services under this context. Generally: P ni = n, i = 1..mk and if a uniform distribution is presumed, then: ni = mnk . With respect to these results, the average node accesses for InsertNewService is: Eins = m2 × k = O(mk) and for MergeDirectories of directories DA and DB : Emer = nB × (C + Eins ) = nB × C + nB × m2A × 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

System Architecture and Implementation

In order to realize context-aware service provision in a mobile environment, there is a need for introducing context within the core of the service discovery process. As already mentioned, we consider a context-aware service directory, i.e., a service directory enhanced with contextual descriptions, as the cornerstone of an architecture for mobile service discovery. In this section, we present the overall architecture for context-aware service discovery and discuss in detail its design and the prototype implementation.

18

Exchanged Messages Module Communication

Returned Services Contextual service request

ServiceRegistry

Context-Aware Service Directory

UDDI

ebXML

Device Profile Repository

Other registry

User Profile Repository

Semantic Discovery Module

User Query

Mobile user

JAXR Service request based on service category

Keywords

Figure 10: Overall system architecture for context-aware service discovery

5.1

Context Management

Context within a service directory, in a sense, resembles an index, like the ones used in traditional relational databases. Intuitively, parallels can be drawn between service retrieval based on contextual attributes and tuple selection based on a table’s indexed column. In this sense, a context-based index enables service discovery within a service directory based on contextual attributes. This is an alternative and complementary approach to standard searching mechanisms provided by directory specifications, for example search by organization or by service category. In Figure 10, the overall system architecture for context-aware service discovery is depicted. In a typical web service architecture, a variety of service registries (UDDI, ebXML, other variant) is generally available for publishing web services. Access to this information is provided by means of a standard interface, namely JAXR [20]. JAXR abstracts the particular underlying service registry and allows transparent access to service descriptions. Similarly to JAXR, the context-aware service directory plays the role of an interface to all aforementioned registries - using functions provided by JAXR (e.g. findServices, that returns all services in the Registry Server that belong to a specified category given as parameter)- but additionally supports service retrieval based on a contextual query. However, a context-aware service directory must be updated, whenever a change of a service’s context occurs. We have studied such updates in [13]. Device capabilities and user preferences are important features, integral parts of user’s context. In order to manage this information a set of repositories is maintained, namely a device repository and a user profile repository. • User Profile Repository: During user registration in the system, a user may submit his/her preferences to form the corresponding user profile. This can be updated later, 19

based on user’s behavior, for example using the invoked web services or the history of use. User preferences provide a personalization mechanism, which can be seen as part of the overall context, and enable service discovery in a way that matches best the explicit or implicit user requirements. • Device Profile Repository: Since a user may have access to the system using more than one device, during each log on, the mobile device’s profile is sent to the device repository. Notice that uploading the device profile usually takes place once at registration time, and then at subsequent times, changes of the device characteristics will be detected, and only the modified part of the profile will be sent to the repository, thus saving valuable bandwidth. Taking into account device profiles avoids retrieval of services with device requirements that do not match the current device’s capabilities.

5.2

Service Discovery

In our application scenarios, mobile users issue service requests (or queries) for mobile or stationary web services, using handheld devices. Due to mobility of both requestors and providers, the surrounding environment is exceptionally dynamic and volatile. Service discovery plays an eminent role in enabling intercommunication of mobile users as well as data sharing. In the following, we describe the service discovery process in the context of our architecture. Mobile users are rarely aware of available web services that fulfill their current needs. Therefore, enhanced service discovery mechanisms are required, besides traditional search by category or organization (the latter is actually useless in mobile environments). Our system allows users to issue keyword-based requests for services, so that a user can describe to the best of his knowledge his needs. This strongly resembles web search, where users search for documents based on a set of submitted keywords. A semantic discovery module is responsible for determining the service categories that are related to the user’s request, based on the use of a domain ontology. For example, if the keywords were ”University Master Programs”, then after the semantic analysis the service category would be Educational Services. However, semantic service discovery is out of the scope of this work, so the interested reader may refer to [42] for a more detailed view of our approach. 5.2.1

Query Evaluation

A typical request for services must be contextually enhanced to return results that match the user’s current context. Thus, a separate query (henceforth referred to as Qcxt ) capturing the user’s current context is attached to the user-defined keyword-based query Qusr , in order to present context-dependent results to the user. Definition 1: Let Qusr be a user-defined, keyword-based query and Qcxt be a contextbased query with respect to Qusr . A query Q is a pair (Qusr , Qcxt ), such that Q evaluates to the intersection of Qusr and Qcxt : 20

Q =< Qusr , Qcxt > 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 following steps describe the query evaluation process: 1. Qusr is semantically analyzed and submitted to the service registry through the JAXR interface (see Figure 10). This query retrieves all services that potentially fulfill the user’s needs. 2. Then, all services belonging to the specified category, that are stored in the various registries, are retrieved and sent to the context-aware service directory. At the same time: 1. Qcxt is formulated using the device profile and the user profile repositories. Additional contextual information is contained in Qcxt , such as the user’s location and the time of the request. 2. The contextual query is sent to the context-aware service directory and filters the set of services. This is practically a join operator between the two sets of services: a) those that semantically match the request, and b) those that match the context of the search. The resulting subset of services, namely those that match the user’s context, along with short descriptions, is sent back to the user. Summarizing, Qcxt acts as a filter on Qusr ’s results, thus, a significantly smaller set of services that both meet the user’s needs and his/her context is returned to the user.

5.3

Implementation Status

As described in Section 5, the system has a server-side and a client-side part. The serverside part implements the context-aware service directory, while the client-side part provides the user interface. In this section we will present an overall description of the system’s implementation and of the tools that were used to implement the system. In the server-side part we used: • UDDI (Universal Description, Discovery and Integration): UDDI is an XML registry that provides standard mechanisms for organizations to describe and publish their services, discover other businesses that offer desired services, and integrate with them. UDDI provides two types of service discovery a) by organization and b) by 21

category. We have used version 2 of the Universal Description, Discovery and Integration project implemented in the Registry Server’s release of Java Web Services Developer Pack (JWSDP v.1.4). The Registry Server is a service registry where organizations and services are stored and implements both types of service discovery provided by UDDI. • JAXR (Java API for XML Registries): JAXR provides a standard Java API for performing registry operations over a diverse set of registries. It also provides a unified information model for describing registry contents. So regardless of the registry provider used, all programs deal with the same information model. JAXR provides also the Registry Browser Tool. This tool connects to a Registry Server and enables operations such as: – insert/delete services or organizations from the Registry Server – discover organizations in the Registry Server • Programming environment: To develop the various modules of our system we used J2EE 1.4 and Apache Tomcat 1.4 for JWSDP (Java Web Services Developer Pack) as web and application server. The systems client-side part consists of three basic modules: 1. The system administrator’s interface: This is a web interface, where the administrator can delete an organization and all its services or bulk insert organizations from a text file with a certain format (this option extends the Registry Servers insertion, where only one organization or service can be inserted at a time). 2. The client’s (user) web interface: Gives the user two options, either search by organization or by service category. The user also has to fill his contextual parameters manually. This is a simple prototype that we developed for querying the contextaware service directory and it is not used by users, since in our approach context is transparently managed without requiring user intervention. Both the administrator’s and client’s web interfaces are implemented using JSP and Servlet technology. 3. The user’s mobile interface (m-interface): The system purpose is to improve the search results for mobile users; this is why we developed one more user interface, this time for a mobile device. This interface has been developed using the J2ME technology. The communication between the user’s mobile device and our system is implemented using the IEEE 802.11 protocol. In our system implementation we have adopted a useful and extendable representation for device profiles, namely the CC/PP specification [5], 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. We use device profiles (a subset of context) mainly as a filtering mechanism that guides the search, in 22

SQL Server 2000 New PMO Arrival REQUEST/UPDATE

Repository API

Database

PMO moved to another cell

Device Controller

REPLY Retrieve Information

CC/PP Profiles Registration Logon Logoff

Laptop computer

CC/PP Profiles

PDA

Pocket organizer

Figure 11: Architecture of module responsible for managing profiles of mobile devices, also called PMO (Primary Mobile Object). order to return only services that are within the device capabilities, with respect to processing, display, etc. We have implemented a CC/PP repository on top of SQLServer2000, through the construction of stored procedures that enable storing CC/PP files (which are XML-based) to a relational database, as well as subsequent querying based on the device identifier. In Figure 11, we use the following components: 1) 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. 2) A Repository API that provides access to the metadata describing the mobile devices. 3) 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. Regarding user profiles, we adopt a simple model based on hierarchical representation of user preferences. For example, this can be a hierarchy of interests and sub-interests combined with some weights that range from 0 to 1, such that the weight at the root of the hierarchy adds up to 1. The user can submit his profile at registration time and also update it later. This enables only basic personalized service discovery, i.e. practically attribute-based matching. However user preferences are more dynamic, more diverse and therefore should be modeled in more flexible way. It is our intention to extend this module in the future by integrating more sophisticated representation means for user profiles that can express user preferences in a better way.

6

Experimental Results

In this section, we present the experimental study and the overall evaluation conducted on the proposed service directory. We deal with: 1) the time required to find all services that match a specified context, 2) the time required to merge context-aware service directories, 3) the processing time overhead of a service registry, due to the management of contextual 23

Performance of Searching 1600 1400 Time (msec)

1200

600 400

1000

k=3, m=4 k=3, m=6 k=4, m=4 k=4, m=6

Returned Services

k=3, n=400 k=4, n=400

800 Time (msec)

200

Performance of Searching

1000

800 600 400

200

150

k=3,m=4 k=3,m=6 k=4,m=4 k=4,m=6

100

50

200 0 4

6

8

0 200

Number of distinct values (m)

400

600

Number of services (n)

800

0 200

400 600 Total Number of Services

800

Figure 12: Time required for service retrieval for various numbers of distinct values (m) (left), and for various numbers of services (n) (middle). On the right the number of returned services is shown. information, 4) the decrease in the size of data transmitted back to the requesting device, when context is taken into account, and 5)the increase of search quality. All algorithms are implemented in Java and our experiments are performed in main memory on a Pentium IV commodity PC.

6.1

Service Retrieval

We have performed a series of experiments concerning service lookup with respect to contextual information. Given a graph (of varying size) representing the service directory, we measured the time required to find all services that match the specified context. Figure 12(left) shows the search time for a CASD with 400 services for different number of distinct values (m) per contextual dimension. The middle part of the same Figure depicts the results produced from CASDs containing different number of services for different values of k and m. In the right part of the same figure, the number of returned services is shown, corresponding to the different setups of k, m and n.

6.2

Merging Directories

Here we present some experimental results concerning the performance of the algorithm MergeDirectories. Given two graphs representing two service directories, we measure the time required for merging the directories for a specified context. An intuition of the form of the directories DA , DB used in our experiments is depicted in figure 9. 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, m = 7, n = 500 (different services from those in DA ). The result of the experiment is the updated DA with k = 5 dimensions, m = 7, n = 1000 services. The left part of Figure 13 shows how increasing the number of values per dimension affects the time required to merge two directories, for k = 4 dimensions and for various 24

Performance of MergeDirectories for m=7 values per dimension

Performance of MergeDirectories for k=4 dimensions

100 12 Time (msec)

Time (msec)

m=4 m=5 m=6 m=7

14

k=4 k=5 k=6 k=7

80 60 40

10 8 6 4

20 2 0

0 0

200

400

600

800

1000

Number of Services (n)

0

200

400

600

800

1000

Number of Services (n)

Figure 13: Performance of MergeDirectories.

numbers of services. The right chart shows how 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.

6.3

Overhead in Registry’s Processing Time

In the rest of this section, we present the experimental results when the CASD is used with a registry server, whereas the aforementioned results where produced by studying only a stand-alone CASD. Our experimental setup consists of two evaluation scenarios. We created 250 (scenario 1) and 1000 (scenario 2) web service descriptions and inserted them into the registry server. The first three columns of Table 2 show the service distribution in 10 service categories. The latter three columns show the query selectivity for 10 random contextual queries that we used in our experiments (the same queries are used in Figure 14). Note that the total number of different contexts is 100 in both scenarios (in other words there exist 100 different paths in the CASD, or 3 contextual dimensions, each having 4 or 5 distinct values). For instance, category 1 is Accommodation and Food Services with 25 and 105 services in each scenario, and the contextual query 1 is: [device = palmtop, os = winCE, location = F rance] which matches a total of 2 and 4 services (that belong to this category) respectively. Then, we measure the extra burden imposed by context management, in terms of processing times for serving requests for services. Our initial evaluation results show that the use of context within the service directory increases processing time during searching only by 14 % (scenario 1) and 2, 5 % (scenario 2) on average (see Figure 14), while this improves when the number of services increases. It is clear that CASD processing times are small (less than half a second) and increase slightly with the number of services. Of course processing times of registry server and CASD are not directly comparable for several reasons, i.e. the number of retrieved services is not equal and CASD is implemented in main memory, however the setup simulates a realistic situation where only a small subset of services within a particular service category is expected to match the context of the query. The results show that the processing overhead 25

Scenario 1 Scenario 2 250 1000 25 105 20 100 25 100 20 100 20 70 25 100 20 100 25 125 20 100 20 105

Total services Category 1 Category 2 Category 3 Category 4 Category 5 Category 6 Category 7 Category 8 Category 9 Category 10

Scenario 1 Scenario 2 Contexts 100 100 Query 1 2 4 Query 2 4 6 Query 3 1 3 Query 4 3 7 Query 5 1 2 Query 6 3 4 Query 7 4 6 Query 8 4 10 Query 9 1 2 Query 10 2 5

Table 2: Experimental setup parameters: The first 3 columns show the service distribution in 10 service categories within the service directory, while the last 3 columns show the query selectivity for each of the 10 queries used in our two evaluation scenarios. imposed by context management can be tolerated, compared to a registry’s response times.

6.4

Size of Transmitted Data

25

0.9 Registry Server, 250 services Registry Server, 1000 services

CASD Processing Time (sec)

Registry Server Processing Time (sec)

We also calculate the associated cost of transmitting service descriptions with and without context management. Given an average size of retrieved service description: SDavg bytes, the amount of transmitted data is SDavg multiplied by the number of matched services. Searching by service category without taking context into account results in all services in the category, while context filters out those services that do not conform to the user’s current situation. The average amount of transmitted bytes is reduced by a factor of 8, 8 in scenario 1 and

20 15 10 5 0

CASD, 250 services CASD, 1000 services

0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0

1

2

3

4

5 6 Queries

7

8

9

10

1

2

3

4

5 6 Queries

7

8

9

10

Figure 14: Processing time for service registry (left) and CASD (right) for the 10 distinct queries of Table 2.

26

20, 5 in scenario 2, due to the increased query selectivity when context is taken into account.

6.5

Search Quality

Regarding search quality, it is rather self-evident that using contextual information improves the results of searches. Especially the precision of search is increased, since the returned results do not contain services that are considered useless, as they do not match the user’s context. Precision is defined as the proportion of retrieved services that are relevant. We consider as relevant those services that conform both semantically and contextually to the user’s request. In other words, relevant services are those that belong to the appropriate service category and at the same time return results that can be processed by the mobile device; these are the services that are really useful to the requesting user. Context-aware service discovery achieves to reduce the number of retrieved services, by returning only the subset of potentially relevant services that conforms to the context of the request. In the example of scenario 1, a typical search for Accommodation and Food Services would return all 25 services in this service category, while the context-based search would only return the 2 services that actually conform to the context of the request. Concluding, the extra cost by managing context is considered minimal, when compared to the achieved increase in precision and the reduced number of bytes transmitted to the requestor. Updating and searching the CASD has a low cost in principal. Even when the number of contextual dimensions increases, these operations exhibit relatively good performance. Actually, the only drawback of the approach is the CASD construction cost, especially for high dimensional contextual spaces, but a) this cost occurs only once and b) the number of dimensions refers to those within each service category and not all dimensions over all categories, so it is normally bounded. After all, service directories usually receive many search requests and relatively few updates, and this approach deals effectively with search requests.

7

Conclusions and Future Work

In this paper, we propose the use of a novel context-aware service directory (CASD) to support context management for web and/or mobile services. The directory resembles a context-based index of services and can be used on top of any available service registry. We designed algorithms for construction, search, update and merge of directories. Furthermore, we presented our prototype implementation and discussed the experimental results. The main contribution of our work is the introduction of context-awareness in service directories, to facilitate more efficient and accurate service discovery. Due to the intrinsic property of CASD, namely that it sits above anykind of registry, we consider CASD as a middleware for service-oriented applications running on heterogeneous mobile devices, which can provide support for context-awareness to new applications and facilitate their development.

27

Regarding future research directions, we intend to focus mainly in extending the contextaware service directory by means of contextual ontologies, in order to enable semantically enriched contextual requests for services, without the restriction of predefined contextual types or values.

References [1] R. Akkiraju, R. Goodwin, P. Doshi, and 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), August 2003. [2] R. Belotti, C. Decurtins, M.C. Norrie, and E. Python. A Context-aware Component Registry for Ubiquitous and Mobile Applications. In Proceedings of Workshop on Ubiquitous Mobile Information and Collaboration Systems (UMICS’05), 2005. [3] T. Broens, S. Pokraev, M. van Sinderen, J. Koolwaaij and P. Dockhorn Costa. ContextAware, Ontology-Based Service Discovery. Ambient Intelligence, Lecture Notes in Computer Science, vol.3295, Springer, 2004. [4] P.J. Brown and G.J.F. Jones. Context-aware Retrieval: Exploring a New Environment for Information Retrieval and Information Filtering. Personal and Ubiquitous Computing, 5(4):253–263, 2001. [5] Composite Capabilities/Preference Profiles (CC/PP), http://www.w3.org/Mobile/CCPP/. [6] G. Chen and D. Kotz. A Survey of Context-aware Mobile Computing Research. Dartmouth Computer Science Technical Report TR2000-381, 2000. [7] G. Chen and D. Kotz. Context-Sensitive Resource Discovery. In Proceedings of the First IEEE International Conference on Pervasive Computing and Communications, pages 243, 2003. [8] I. Constantinescu, W. Binder, and B. Faltings. An Extensible Directory Enabling Efficient Semantic Web Service Integration. In Proceedings of the 3rd International Semantic Web Conference, pages 605–619, 2004. [9] S. Cuddy, M. Katchabaw, and H. Luftiyya. Context-aware Service Selection Based on Dynamic and Static Service Attributes. In Proceedings of IEEE International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob’05), 2005. [10] A.K. Dey and G.D. Abowd. Towards a Better Understaning Context and Context-awareness. In Proceedings of the Workshop on The What, Who, Where, When, and How of ContextAwareness, April 2000. [11] C. Doulkeridis, N. Loutas, and M. Vazirgiannis. A System Architecture for Context-Aware Service Discovery. In Proceedings of the International Workshop on Context for Web Services (CWS’05) (Held in conjunction with the 5th International and Interdisciplinary Conference on Modeling and Using Context), July 2005.

28

[12] C. Doulkeridis, E. Valavanis, and M. Vazirgiannis. Towards a Context-aware Service Directory. In Proceedings of the 4th VLDB Workshop on Technologies on E-Services (TES’03), pages 54–65, September 2003. [13] C. Doulkeridis and M. Vazirgiannis. Querying and Updating a Context-aware Service Directory in Mobile Environments. In Proceedings of the 2004 IEEE/WIC/ACM Web Intelligence Conference (WI’04), pages 562–565, September 2004. [14] C. Doulkeridis, V. Zafeiris, and M. Vazirgiannis. The Role of Caching and ContextAwareness in P2P Service Discovery. In Proceedings of the 6th International Conference on Mobile Data Management (MDM’05), May 2005. [15] S. Dustdar and M. Treiber. A View Based Analysis on Web Service Registries. Distributed and Parallel Databases, 2005. [16] ebXML, http://www.ebxml.org/. [17] Volker Gaede and Oliver G¨ unther. Multidimensional Access Methods. ACM Computing Surveys, 30(2):170–231, 1998. [18] K. Henricksen, J. Indulska, T. McFadden and S. Balasubramaniam. Middleware for Distributed Context-Aware System. In International Symposium on Distributed Objects and Applications (DOA), 2005. [19] B. Hofreiter, C. Huemer, and W. Klas. ebXML Status, Research Issues, and Obstacles. In Proceedings of the 12th International Workshop on Research Issues on Data Engineering (RIDE’02), February 2002. [20] JAVA API for XML Registries (JAXR), http://java.sun.com/webservices/jaxr/. [21] M. Jeckle and B. Zengler. Active UDDI - an Extension to UDDI for Dynamic and Faulttolerant Service Invocation. In Proceedings of Web, Web-Services, and Database Systems, 2002. [22] Project JXTA: A technology overview. http://www.jxta.org/. [23] M. Keidl and A. Kemper. Towards Context-Aware Adaptable Web Services. In Proceedings of 13th International World Wide Web Conference (WWW’04), 2004. [24] C. Lee and S. Helal. Context Attributes: An Approach to Enable Context-awareness for Service Discovery. In Proceedings of the 2003 Symposium on Applications and the Internet (SAINT’03), January 2003. [25] W.Y. Lum and F.C.M. Lau. A Context-aware Decision Engine for Content Adaptation. IEEE Pervasive Computing, 1(3):41–49, 2002. [26] Z. Maamar, S. K. Mostefaoui, and Q. H. Mahmoud. Context for Personalized Web Services. In Proceedings of the 38th Hawaii International Conference on System Sciences (HICSS’05), 2005.

29

[27] Z. Maamar, S. K. Mostefaoui, and H. Yahyaoui. Toward an Agent-Based and ContextOriented Approach for Web Services Composition. IEEE Transactions on Knowledge and Data Engineering, 17(5):686–697, 2005. [28] Z. Maamar, H. Yahyaoui, Q. H. Mahmoud, and F. Akhter. Dynamic Management of UDDI Registries in a Wireless Environment of Web Services. In Proceedings of the 2nd International Conference on Wired/Wireless Internet Communications (WWIC’04), pages 284–294, 2004. [29] S.K. Mostefaoui, H. Gassert, and B. Hirsbrunner. Context Meets Web Services: Enhancing WSDL with Context-Aware Features. In Proceedings of 19th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA’04), 2004. [30] S.K. Mostefaoui and B. Hirsbrunner. Towards a Context Based Service Composition Framework. In Proceedings of the 1st International Conference in Web Services (ICWS’03), June 2003. [31] M. Paolucci, T. Kawamura, T.R. Payne, and K.P. Sycara. Semantic Matching of Web Services Capabilities. In Proceedings of the 1st International Semantic Web Conference on The Semantic Web, June 2002. [32] M.P. Papazoglou and D. Georgakopoulos. Service-oriented Computing. Communications of the ACM, 46(10):25–28, 2003. [33] E. Pitoura, S. Abiteboul, D. Pfoser, G. Samaras, and M. Vazirgiannis. DBGlobe: a Serviceoriented P2P System for Global Computing. SIGMOD Record, 32(1):77–82, 2003. [34] S. Pokraev, J. Koolwaaij, and M. Wibbels. Extending UDDI with Context-aware Features Based on Semantic Service Descriptions. In Proceedings of the 1st International Conference on Web Services (ICWS’03), June 2003. [35] R. Robinson and J. Indulska. A Context-Sensitive Service Discovery Protocol for Mobile Computing Environments. In Proceedings of the 4th International Conference on Mobile Business, 2005. [36] A. Schmidt. Implicit Human Computer Interaction Through Context. Personal Technologies, 4(2&3):191–199, 2000. [37] A. ShaikhAli, O.F. Rana, R. Al-Ali, and D.W. Walker. UDDIe: An Extended Registry for Web Services. In Symposium on Applications and the Internet Workshops (SAINT-w03), 2003. [38] Y. Stavrakas and M. Gergatsoulis. Multidimensional Semistructured Data: Representing context-dependent information on the web. In Proceedings of the 14th International Conference on Advanced Information Systems Engineering (CAISE’02), May 2002. [39] Y. Stavrakas, M. Gergatsoulis, C. Doulkeridis, and V. Zafeiris. Representing and Querying Histories of Semistructured Databases Using Multidimensional OEM. Information Systems, 29(6):461–482, 2004.

30

[40] T. Strang and C. Linnhoff-Popien. A Context Modeling Survey. In Ubicomp 2004 Workshop on Advanced Context Modelling, Reasoning and Management, September 2004. [41] The UDDI specification version 3.0, http://www.uddi.org/. [42] E. Valavanis, C. Ververidis, M. Vazirgiannis, G.C. Polyzos, and K. Norvag. Mobishare: Sharing Context-dependent Data and Services from Mobile Sources. In Proceedings of IEEE/WIC International Conference on Web Intelligence (WI’03), October 2003. [43] Web Services Conceptual Architecture (WSCA 1.0), IBM Software Group.

31