LNCS 4290 - Efficient Semantic Service Discovery in ... · Efﬁcient Semantic Service Discovery in Pervasive Computing Environments 243 The service proﬁle gives a description of

Efficient Semantic Service Discovery in PervasiveComputing Environments

Sonia Ben Mokhtar, Anupam Kaul, Nikolaos Georgantas, and Valerie Issarny

Inria Rocquencourt78153 Le Chesnay, France

{Sonia.Ben Mokhtar, Anupam.Kaul,Nikolaos.Georgantas, Valerie.Issarny}@inria.fr

Abstract. Service-oriented architectures, and notably Web Services, are becom-ing an incontrovertible paradigm for the development of applications in perva-sive computing environments, as they enable publishing and consuming hetero-geneous networked software and hardware resources. Combined with SemanticWeb technologies, in particular ontologies, Web services’ descriptions can be un-ambiguously and automatically interpreted in open pervasive computing environ-ments, where agreement on a single common syntactic standard for identifyingservice semantics cannot be assumed. Nevertheless, efficient matching of seman-tic Web services to effectively automate the discovery and further consumptionof networked resources remains an open issue, which is mainly attributable to thecostly underlying semantic reasoning. After analyzing the cost of ontology-basedsemantic reasoning, which is at the heart of the matching process, we propose asolution towards efficient matching of semantic Web services. We have further in-corporated our solution into a service discovery protocol aimed at open pervasivecomputing environments that integrate heterogeneous wireless network technolo-gies (i.e., ad hoc and infrastructure-based networking). Experimental results showthat our solution enables better response times than of classical syntactic-basedservice discovery protocols.

1 Introduction

The pervasive computing vision is increasingly enabled by the large success of wirelessnetworks and devices. In pervasive computing environments, heterogeneous softwareand hardware resources may be discovered and integrated transparently towards as-sisting the performance of daily tasks. Still, realizing this vision requires middlewaresupport for dynamic and automated discovery and composition of software and hard-ware resources that populate the pervasive computing environment. Service-orientedarchitectures [11], and particularly Web Services1, have proved to be an appropriatearchitectural paradigm offering middleware support for pervasive computing environ-ments. Indeed, Service-Oriented Architecture (SOA) is an architectural style that aimsat the development of highly autonomous, loosely coupled systems that are able to com-municate, compose and evolve in open, dynamic and heterogeneous environments suchas pervasive computing environments [5]. Web Services are then one of the realizations

1 http://www.w3.org/2002/ws/

M. van Steen and M. Henning (Eds.): Middleware 2006, LNCS 4290, pp. 240–259, 2006.c© IFIP International Federation for Information Processing 2006

Efficient Semantic Service Discovery in Pervasive Computing Environments 241

of this architectural style. Using Web Services, each networked resource is abstractedas a service that is described in a declarative manner using the Web Services Descrip-tion Language (WSDL) and is accessible by means of standard protocols such as theSimple Object Access Protocol (SOAP) on top of Internet protocols (HTTP, SMTP).Furthermore, Web Services have already been used in pervasive environments and haveproved to be efficient when deployed on mobile, resource-constrained devices [7].

Abstracting software and hardware resources of the pervasive computing environ-ment as Web services allows having a homogeneous vision of heterogeneous resources.Resources can then be discovered based merely on their WSDL interfaces. However,while using Web Services allows addressing substantially the heterogeneity issue interms of technologies of service implementation, another issue remains, which issyntactic heterogeneity. Indeed, WSDL-based service discovery relies on the syntac-tic conformance of the required interfaces with the provided ones, for which commonunderstanding is hardly achievable in open pervasive computing environments. A solu-tion to this issue can be provided by introducing semantics into the service description.Combined with Semantic Web technologies2, notably ontologies, for the semantic de-scription of the services’ functional and non-functional features, Web services can beautomatically and unambiguously discovered and consumed in open pervasive comput-ing environments. Specifically, ontology-based semantic reasoning enables discoveringnetworked services whose published provided functionalities (or capabilities) matcha required functionality, even if there is no syntactic conformance between them. Anumber of research efforts have been conducted in the area of semantic Web servicespecification, which have led to the development of various semantic service descrip-tion languages, e.g., OWL-S3, WSDL-S4, WSMO5, SWSO6. In this context, we havedeveloped the Amigo-S service description language [2], which is specifically aimed atservices in pervasive computing environments.

Building upon the features of Amigo-S that supports specifying services in rich, openpervasive computing environments, this paper focuses on associated middleware sup-port for effectively enabling the discovery of networked Amigo-S services. Specifically,we introduce a dedicated Service Discovery Protocol (SDP) that enables advertising anddiscovering services in pervasive environments according to the semantics of networkedservices and of sought functionalities. This is to be contrasted with traditional SDPs thatsupport the discovery of services according to syntactic interface descriptions, and thusassume worldwide knowledge and agreement about service interfaces. The key contri-bution of our work then comes not only from introducing an SDP for the discovery ofsemantic Web services in pervasive environments, but also from the fact that our SDPoffers performance that makes it appropriate for use in highly dynamic networked en-vironments populated by resource-constrained, wireless devices. The latter issue is amajor challenge due to the performance and resource costs of ontology-based seman-tic reasoning. This has led us to introduce a solution to lightweight semantic matching

2 http://www.w3.org/2001/sw/3 OWL-S: Semantic Markup for Web Services. http://www.daml.org/services/owl-s4 WSDL-S: http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/5 WSMO: Web Services Modeling Ontology. http://www.wsmo.org/6 SWSO: Semantic Web Service Ontology. http://www.daml.org/services/swsf/1.0/overview/

242 S. Ben Mokhtar et al.

of Web services towards the actual exploitation of semantic Web services in pervasiveenvironments.

The next section provides an overview of semantic Web service technologies, andintroduces Amigo-S and an associated matching relation for semantic Web servicesin pervasive environments. Based on Amigo-S, we present a solution to lightweightsemantic matching of networked services (Section 3). Our solution optimizes ontology-based semantic reasoning, which is at the heart of the matching process. Furthermore,we propose a classification of service advertisements, towards efficient access and re-trieval of services within cooperating service directories deployed on the network. Wehave further integrated our solution in the Ariadne service discovery protocol [12] ex-tending it to S-Ariadne (i.e., Semantic-Ariadne), which is aimed at pervasive computingenvironments, for hybrid wireless networks combining ad hoc and infrastructure-basednetworking (Section 4). Experimental results show that S-Ariadne enables better re-sponse times than of classical service discovery protocols, and is further more scalable(Section 5). Finally, we summarize our contribution and sketch perspectives for ourwork (Section 6).

2 Semantic Web Services for Pervasive Computing

As pointed out in the previous section, semantic Web services can provide an adequatesolution to effective service discovery in open pervasive computing environments. Inthis section, we briefly discuss base technologies supporting the provisioning of se-mantic Web services, and introduce basic elements of our approach for describing andmatching semantic Web services in pervasive environments. We thus discuss semanticWeb services (Section 2.1), the Amigo-S language for the description of pervasive ser-vices (Section 2.2), our definition of a base semantic matching relation (Section 2.3),and a study on the cost of semantic service matching (Section 2.4).

2.1 Semantic Web Services

Ontologies may conveniently be exploited to semantically model Web services. Indeed,while Web services interfaces all have a similar structure, thanks to the WSDL stan-dard, the semantics underlying these interfaces cannot be inferred from their syntacticdescription. Similarly, it cannot be assumed that service providers and consumers willuse worldwide the very same syntactic interface for describing the same service, asthese descriptions are created by different organizations, communities and individualsall over the world. A natural evolution of Web services description has thus been thecombination of the Semantic Web and Web Services paradigms towards the semanticrepresentation of the services functional features, leading to Semantic Web Services. Anumber of research efforts have in particular been undertaken towards the concretiza-tion of this paradigm. In this area, various languages have been proposed to describesemantic Web services, e.g., WSDL-S, OWL-S, WSMO and SWSO.

Among them, OWL-S is the effort directly related to OWL7 (the Ontology WebLanguage), which is a W3C recommendation. A service description in OWL-S is com-posed of three parts : the service profile, the process model and the service grounding.

7 http://www.w3.org/TR/owl-ref/


The service profile gives a description of a service and its provider. It is generally usedfor service publication and discovery. The process model is a representation of the ser-vice conversation, i.e., the interaction protocol between a service and its client that isdescribed as a process. The service grounding specifies the information that is neces-sary for the service invocation, such as the communication protocol, message formatsand addressing information. The OWL-S service grounding is based on WSDL.

2.2 Amigo-S for Pervasive Services

OWL-S and the other languages mentioned above provide adequate solutions for thedescription of semantic Web services. However, these languages are primarily aimed atcharacterizing stationary services deployed on the core Internet and lack key featuresto thoroughly model services to be provisioned in the pervasive computing environ-ment. Such features include characterizing the specifics of the underlying middlewareplatform that vary significantly among networked services. For example, services net-worked in the pervasive home environment illustrate such diversity, as they span thehome automation, consumer electronics, mobile and personal computing applicationdomains, and further require middleware-layer bridging to be interoperable [1,4]. An-other key feature of pervasive services is the need for awareness of context and qualityof service, as these two factors affect decisively the actual user’s experience in perva-sive environments that vary greatly in resource availability and contextual conditions[8,10]. Such specifics of pervasive services has led us to introduce the Amigo-S servicedescription language that meets the requirements of pervasive services.

The key novel features of the Amigo-S language are that it supports heterogeneousservice infrastructures and enables QoS- and context-awareness for service provision-ing. Amigo-S is an ontology formally specified in OWL; it has been developed as partof the effort of the IST Amigo project8. The Amigo-S specification incorporates theOWL-S specification, and extends it by adding new classes and properties. In this way,we reuse established features of OWL-S and provide a new language that can easilybe used by developers already familiar with OWL-S. In the following, we briefly intro-duce only the Amigo-S service profile; a more detailed description of Amigo-S may befound online [2]. In this paper, we mainly exploit the ability of the Amigo-s languagefor specifying service functional features, while other aspects of the language, such asthe description of the services’ underlying middleware, as well as the specification ofQoS and context properties can be exploited like in [1,2].

As discussed above, the OWL-S service profile models a service as both a semanticconcept by specifying the service category and a set of semantic IOPEs. In Amigo-S aswell, a service is described with a service profile. However, we assume that a servicemay offer a number of capabilities, i.e., specific functionalities offered by the service,and we explicitly model such capabilities. OWL-S actually supports multiple profilesfor a service; nevertheless, using a different profile for each capability of a service doesnot allow capabilities to share a set of common attributes, which may globally character-ize the service. In Amigo-S, each such capability is defined as both a semantic conceptand a set of semantic IOPEs. This enables describing richer services supporting severalcapabilities that may be functionally independent or even dependent. For instance a

8 http://www.hitech-projects.com/euprojects/amigo/


complex capability may be composed of simpler capabilities, each one of which is alsoseparately accessible. Further, we explicitly model provided capabilities as capabilitiessupported by a service, and required capabilities as capabilities needed by a service,which will be sought on other networked services. This enables support for any servicecomposition scheme, such as a peer-to-peer scheme or a centrally coordinated scheme.

An example of service profiles as enabled by Amigo-S (restricted to service inputs,outputs and category) is depicted in the upper part of Figure 1. Along with servicedescriptions, the figure includes in its lower part two ontologies representing the con-cepts employed in the service descriptions. The service on the PDA requires a capabilitynamed GetVideoStream, which belongs to the service category VideoServer, takes asinput a title of a VideoResource and provides as output an actual Stream. The serviceon the workstation provides two capabilities, SendDigitalStream and ProvideGame,which share common attributes such as the workstation resources available to them.For the former, service category is DigitalServer, input is DigitalResource and outputis Stream, while for the latter, service category is GameServer, input is GameRe-source and output is Stream. These two capabilities are dependent, as SendDigital-Stream includes ProvideGame, but are separately accessible. Thus, a peer service (inother words, a client) may access the former and have the option to access a video re-source, a sound resource or a game; or access the latter, asking specifically for a game.The peer service on the PDA asking for a video resource should access SendDigital-Stream, which also includes GetVideoStream. Making the right choice is supportedby service matching, which is described in the following two sections.

2.3 Semantic Matching Relation

Based on the Amigo-S service specification, we define a matching relation, i.e., Match(C1, C2), which allows identifying whether capability C1 is equivalent or includes ca-pability C2, i.e., if C1 can substitute C2 in the provisioning of a service capabilitythat is semantically characterized by C2 (see the example of SendDigitalStream andGetVideoStream in Figure 1). The Match relation then constitutes the basis of servicediscovery, as seeking a capability characterized by C amounts to discovering any net-worked service advertising a capability described by N such that Match(N, C) holds.Additionally, the Match relation may conveniently be exploited to group similar capa-bilities of networked services towards efficient service discovery, as further presentedin the next section.

Specifically, the Match relation is defined using the function distance(concept1,concept2), hereafter denoted by d(concept1, concept2), which gives the semantic dis-tance between two concepts, concept1 and concept2, as given in the classified9 ontol-ogy to which the concepts belong. Precisely, if concept1 does not subsume concept2in the ontology to which they belong to, the distance between the two concepts doesnot have a numeric value, i.e., d(concept1, concept2) = NULL. Otherwise, i.e., ifconcept1 subsumes concept2, the distance takes as value the number of levels that sep-arate concept1 from concept2 in the ontology hierarchy.

9 Ontology classification is the result of semantic reasoning on ontology specifications. It al-lows inferring implicit relationships between concepts from the explicit definitions of theseconcepts.


Formally, let the provided capability C1 be defined by the set of expected inputsC1.In and set of offered outputs C1.Out, and the required capability C2 be defined bythe set of offered inputs C2.In and the set of expected outputs C2.Out. Furthermore, letthe capability C1 define a set of provided properties C1.P , and the capability C2 definea set of required properties C2.P , where these properties describe all the informationthat can be required in the user request such as the service category and non-functionalproperties; currently, we only consider the former property. The relation Match is thendefined as:

Match(C1, C2) =∀in′ ∈ C1.In, ∃in ∈ C2.In : d(in, in′) ≥ 0 and∀out′ ∈ C2.Out, ∃out ∈ C1.Out : d(out, out′) ≥ 0 and∀p′ ∈ C2.P, ∃p ∈ C1.P : d(p, p′) ≥ 0

From the above, the relation Match(C1, C2) holds if and only if all the expected inputsof C1 are matched with inputs offered by C2, all the expected outputs of C2 are matchedwith outputs offered by C1, and all the required properties of C2 are matched withproperties provided by C1.

Furthermore, we define the function SemanticDistance(C1, C2), which gives thesemantic distance between the capability C1 and the capability C2:

SemanticDistance(C1, C2) =∑n1

i=1 d(C2.Ini, C1.Ini)+∑n2i=1 d(C1.Outi, C2.Outi)+∑n3i=1 d(C1.pi, C2.pi)

where n1 is the number of inputs expected by C1, n2 is the number of outputs expectedby C2, and n3 is the number of additional properties required by C2. The semantic dis-tance between capabilities corresponds to the sum of the distances between the pairs ofrelated concepts in the advertisement and the request. This allows scoring service adver-tisements with respect to the requested capability with which they are being compared,and selecting the advertisement whose description best fits the user’s requirements. Anexample of matching semantic service capabilities is shown in the middle part of Figure1. In the figure, the requested capability GetVideoStream is matched with the providedcapability SendDigitalStream, using the two underlying ontologies describing digitalresources and servers. The relation Match(SendDigitalStream, GetV ideoStream)holds, and the semantic distance between these capabilities is equal to 3.

2.4 Cost of Semantic Matching

Practically, the semantic matching of service capabilities decomposes in three tasks:

1. Parsing the description of the requested and the provided capabilities;2. Loading and classifying the ontologies used in both the requested and the provided

capabilities using a semantic reasoner; and3. Finding subsumption relationships between inputs, outputs and properties of the

requested and provided capabilities in the classified ontologies.

Implementation and evaluation of semantic matching of service capabilities has beenpresented in the literature, e.g., see [9]. Results show that matching semantic service ca-pabilities is a computation-intensive task with high response times compared to classi-cal syntactic-based service discovery protocols. In particular, results show that the most


Fig. 1. Describing and matching capabilities of pervasive services

expensive phase in the process of matching semantic service capabilities is that of se-mantic reasoning (steps 2 and 3 above). As an illustration, Figure 2 shows an evaluationof the semantic matching of two capabilities using three different semantic reasoners:Racer10, Fact++11 and Pellet12, which are the most popular semantic reasoning tools.The two capabilities have 7 inputs and 3 outputs each. The ontology used for the ex-periment contains 99 OWL classes, i.e., concepts, and 39 properties, i.e., relationshipsbetween the classes. We can notice that for any of the three reasoners, the average timeto match two capabilities is around 4 to 5 seconds, which is much higher than classicalsyntactic-based matching of Web services (e.g., around 160 ms for a UDDI registry[13]). Furthermore, we notice that the time to load and classify ontologies takes from76% to 78% of the total time for matching using any of the three reasoners.

The above results show that matching semantic Web service capabilities is an expen-sive task in terms of response time and resource consumption, which is not acceptablefor a service discovery protocol aimed at pervasive computing environments, whereservice discovery needs to be efficient enough to ensure service availability despite thenetwork’s dynamics, and lightweight enough for use by thin, wireless devices. Thus,in order to enable actual deployment of semantic Web services in pervasive computingenvironments, a number of optimizations have to be introduced in the process of match-

10 Racer: http://www.sts.tu-harburg.de/ r.f.moeller/racer/11 Fact++: http://owl.man.ac.uk/factplusplus/12 Pellet: http://www.mindswap.org/2003/pellet/


Fig. 2. Time taken to match a requested and a provided capability

ing semantic service capabilities, particularly, targeting acceptable response times. Thenext section introduces such solutions, building upon recent efforts in the area of effi-cient semantic service matching.

3 Achieving Lightweight Discovery of Semantic Web Services

Lightweight discovery of semantic Web services requires minimizing the overhead dueto semantic reasoning, possibly performing it off-line so that semantic reasoners donot need to be used when advertising and seeking networked services. Specifically,optimization can be introduced at two levels. First, at the semantic reasoning level, byreducing the time spent to infer relationships between concepts in ontologies. Second,at the service discovery level, by classifying directories of services in a way that reducesthe number of semantic matches performed to answer a user request. As discussedbelow (Section 3.1), related optimizations for both ontology-based semantic reasoningand classification of service advertisements have been proposed in the literature [3,13].We then propose an effective solution to the discovery of semantic Web services inpervasive computing environments (Sections 3.2, 3.3).

3.1 Background

In [3], the authors emphasize the need of efficient indexes and search structures for di-rectories. Towards this goal, they propose to numerically encode service descriptionsgiven in OWL-S. This is done by numerically encoding ontology class and propertyhierarchies by intervals. More precisely, each class (resp. property) in a classified hier-archy is associated with an interval. Then, each service description maps to a graphicalrepresentation in the form of a set of rectangles defined by the sets of intervals repre-senting properties combined with the set of intervals representing classes. Furthermore,for efficient service retrieval, the authors base their work on techniques for manag-ing multidimensional data being developed in the database community. More precisely,they use the Generalized Search Tree (GiST) algorithm proposed by Hellerstein in [6]


for creating and maintaining the directory of numeric services. Combining both encod-ing and indexing techniques allows performing efficient service search, in the order ofmilliseconds for trees of 10000 entries. However, insertion within trees of the previoussize is still a heavy process that takes approximately 3 seconds.

In [13], the authors propose an approach to optimize service discovery in a UDDIregistry augmented with OWL-S for the description of semantic Web services. This ap-proach is based on the fact that the publishing phase is not a time critical task. Therefore,the authors propose to exploit this phase to pre-compute and store information aboutthe incoming services. More precisely, a taxonomy that represents the subsumption re-lationships between all the concepts in the ontologies used by services is maintained.Then, each concept C in this taxonomy is annotated with two lists, one to store infor-mation about inputs of services while the other one is used to store information aboutoutputs of services. More precisely, for each concept in the taxonomy, these lists specifyto what degree any request pointing to that concept would match the advertisement. Forexample, for a particular concept C in the taxonomy, the list storing information aboutoutputs is represented as [< Adv1, exact >, < Adv2, subsumes >, ...], where Advi

points to a service advertisement in the repository and exact (resp. subsumes) specifythe degree of match between C and the related concept in the corresponding advertise-ment. A performance evaluation of this approach shows that the publishing phase usingthis algorithm takes around seven times the time taken by UDDI to publish a service,under the assumption that no additional ontologies have to be loaded to the registry. Onthe other hand, the time to process a query is in the order of milliseconds. While theabove increases the time spent for publishing service advertisements, it considerablyreduces the time spent to answer a user request compared to approaches based on on-line reasoning (e.g., see Figure 2). Indeed, the querying phase is reduced to performinglookups in the hierarchical data structure that represents the classified ontology, and toperforming intersections between the lists that store information about the service ad-vertisements. Thus, no on-line reasoning is required to answer a user request. However,the publishing phase still requires semantic reasoning on service descriptions which isan expensive process in terms of consumed resources.

On the other hand, solutions to reduce the number of matches performed to answer auser request are generally based on service classification. OWL-S specification providesthe mean of defining hierarchies of service descriptions called profile hierarchies. Thesehierarchies are similar to the object-oriented inheritance hierarchies. For instance, whena new service profile is defined it may be specified as a subclass of an existing profileclass. This allows the new service to inherit all the properties of all the classes specifiedin its super-hierarchy of classes. While this approach allows the classification of serviceprofiles according to the classes from which they inherit, it does not allow consideringpossible relationships between service profiles that do not have the same common setof properties but that still provide similar functional features. Service classification canalso be based on the service category using existing taxonomies such as NAICS13 orUNSPSC14. However, service categories alone does not give enough information aboutthe service functionality.

13 http://www.census.gov/epcd/www/naics.html14 http://www.unspsc.org/


Using the matching relation defined in the previous section, we propose an efficientsemantic service discovery protocol for pervasive computing environments. Efficiencyis addressed in terms of response time for both the discovery and advertisement of ser-vice capabilities. Towards this goal, we present below a number of optimizations of thesemantic matching process. First, in order to reduce the time to load and classify on-tologies, which is the most costly phase in the discovery process, we propose to encodeclassified ontologies (§ 3.2). Then, in order to reduce the number of semantic matchesperformed in the querying phase we propose to classify capabilities of networked ser-vices into hierarchies (§ 3.3).

3.2 Encoding Concept Hierarchies

In order to avoid semantic reasoning at runtime we propose to encode classified ontolo-gies, represented by hierarchies of concepts, using intervals as described in [3]. Thesehierarchies represent the subsumption relationships between all the concepts in the on-tologies used in the directory. The main idea of the encoding is that any concept in aclassified ontology is associated with an interval. These intervals can be contained inother intervals but are never overlapping. The intervals are defined using a linear inverseexponential function linKinvexpP (x) = 1

pint( xk

) + (x mod k) ∗ 1k ∗ 1

pint( xk

) , where p

and k are two parameters to be fixed. Regarding the scalability of this encoding solu-tion, experiments show that for p=2 and k=5, and a system encoding real numbers as64 bits doubles, the maximum number of entries that we can have on the first level ofthe hierarchy is 1071 and the maximum number of levels that we can have on the firstentries of a level is 462 levels. Figure 3 taken from [3], shows an example of encodinga hierarchy of concepts with intervals.

Fig. 3. Example of encoding a class hierarchy

Under the assumption that the classified ontologies are encoded and that service ad-vertisements and service requests already contain the codes corresponding to the con-cepts that they involve, semantic service reasoning reduces to a numeric comparison ofcodes. Indeed, to infer whether a concept C1 represented by the interval I1 subsumesanother concept C2 represented by the interval I2, it is sufficient to compare whether I1is included in I2. In order to ensure consistency of codes along with the dynamics andevolution of ontologies, service advertisements and service requests specify the ver-sion of the codes being used. We assume that services periodically check the version ofcodes that they are using and update their codes in the case of ontology evolution.


3.3 Semantic Service Advertisement and Matching

Based on the encoding technique defined in the previous section, we present an algo-rithm for matching a requested capability with a set of capabilities of networked ser-vices. Service capabilities could be added or deleted at any time from the existing setof capabilities. When a request comes, the algorithm tries to find a capability that bestmatches the request minimizing the number of semantic matches performed with capa-bilities of networked services. At a pre-processing phase the algorithm classifies capa-bilities of networked services and constructs directed acyclic graphs (DAGs) of relatedcapabilities. These graphs are indexed according to the ontologies being used in thecapabilities that they contain. The relationship between capabilities that we consider toconstruct a graph is given by the relation Match and the function SemanticDistancedefined in Section 2.3. Specifically, if both Match(C1, C2) and Match(C2, C1) holdand SemanticDistance(C1, C2) = SemanticDistance(C2, C1) = 0, then C1 andC2 will be represented by a single vertex in the graph. For all the other cases whereMatch(C1, C2) holds, C1 and C2 will be represented in the graph by two distinct ver-tices with a directed edge from C1 to C2.

When a new service comes in the network the set of capabilities that it provides areclassified among the existing hierarchies. The algorithm of classifying new capabilitiesin the existing hierarchies is described below.

When a request Req arrives, the algorithm first selects among the existing DAGs,graphs that contain services that are more likely to match the request. This is done us-ing the indexes given to each graph, which correspond to the set of ontologies usedby the capabilities of that graph. When a graph G is selected the algorithm performsa matching between the request and the most generic capabilities of this graph. Thesecapabilities are said to be more generic than other capabilities contained in their sub-hierarchy because they provide a number of outputs that is greater or equal to thenumber of outputs of the other capabilities, and further because their provided out-puts subsume the outputs of other capabilities (e.g., in Figure 1, the capability Send-DigitalStream is more generic than the capability ProvideGame). These capabili-ties correspond to the capabilities represented by vertices of this graph that do nothave predecessors, i.e., the set Roots(G). Similarly, we define Leaves(G) as the setof vertices in the graph G that do not have successors. If Match between Req andall the capabilities of Roots(G) does not hold, the group G is filtered out, and an-other group is selected. Nevertheless, if the matching between the request and a ca-pability C of Roots(G) holds, i.e., Match(C, Req) holds, we evaluate the semanticdistance between C and Req. If the distance is equal to zero, C is selected, other-wise the algorithm tries to find a capability C′ from the successors of C such thatSemanticDistance(C′, Req) = Min(SemanticDistance(Ci, Req)), where Ci is asuccessor of C. The algorithm for answering a user request is presented in more detailslater in this section.

Adding a New Service Advertisement. At a pre-processing phase, a set of DAGgraphs are constructed and maintained. Each time a new service advertisement comesin the network, the graphs have to be updated with the set of capabilities provided bythe new service. The algorithm of classifying the capabilities of a new service within a


set of Graphs G1, G2,..., Gn is given below. For each capability Ci provided by the newservice, the algorithm tries to find a graph Gi in which this capability will be integrated(Steps (1), (2)). A subset of graphs is preselected according to the ontologies beingused by Ci. The algorithm first checks whether Ci can be inserted in the sub-hierarchyof one of the root nodes of G. This is done by verifying if there exists a node Rooti inRoots(Gi) such that Match(Rooti, Ci) holds (step (3)). If Match(Rooti, Ci) holds(step 8), then Ci will have a predecessor in Gi. The next step is to find this node, Ni,among the successors of the node Rooti, such that the Match(Succ(Ni), Ci) fails, andto draw an edge from Ci to Ni. Moreover, Ci could have a successor in Gi. Thus, thealgorithm tries to find among the set Leaves(Gi) if there is a node Leafi such thatMatch(Ci, Leafi)(step (9)). If Match(Ci, Leafi) holds, then Ci will have a succes-sor in Gi. The next step is to find this node, Ni, among the predecessors of Leafi suchthat Match(Ci, P red(Ni)) fails, and to draw an edge from Ci to Ni (step (11)). Onthe other hand, if Match(Rooti, Ci) does not hold (step(4)), Ci will not have a pre-decessor in Gi. Nevertheless, Ci could have a successor in Gi. Thus, the algorithmschecks whether there is a node Leafi in Leaves(Gi) such that Match(Ci, Leafi)holds (steps (5), (6) and (7)). These steps are similar to the aforementioned steps (9),(10) and (11).

input: C1, C2, ..., Cn the set of capabilities of the new service,G1, G2, ..., Gm the set of existing graphs.

output: G′1, G

′2, ..., G

′k the set of graphs after the insertion of the new capabilities.

InsertCapabilities(capabilities)Forall the capabilities Ci in C1, ..., Cn do{ (1)

For all the graphs Gi in G1, ..., Gm that use the same ontologies as Ci

until the insertion of Ci do{ (2)For (Rooti in Roots(Gi)) do{ (3)

If (¬Match(Rooti, Ci)) then{ (4)For (Leafi in Leaves(Gi)) do{ (5)

If (¬Match(Ci, Leafi)) then (6)Fail;

Else{ (7)Test with Predecessors of Leafi

until ¬Match(Ci, P redj(Leafi))Draw an edge from Ci to Predj+1(Leafi)

}}}Else{ (8)

Test with Successors of Rooti

until ¬Match(Succj(Rooti), Ci)Draw an edge from Succj−1(Rooti) to Ci

For (Leafi in Leaves(Gi)) do{ (9)If (¬Match(Ci, Leafi)) then (10)

Fail;Else{ (11)

Test with Predecessors of Leafi

until ¬Match(Ci, P redj(Leafi))Draw an edge from Ci to Predj+1(Leafi)

}}}}}}


Fig. 4. Example of inserting a capability in a DAG

Figure 4 shows an example of inserting a capability, newC, in a DAG of capabilities, G.The first step (left part of the figure) is to match newC with capabilities from Roots(G)to find out whether newC will have a predecessor in G. Indeed, Match(C1, newC)holds, which means that one of the successors of C1 will be linked with newC, i.e.,C3. The next step (right part of the figure) is then to find out whether newC will havea successor in G. This is done by matching the capabilities in Leaves(G) with newC.Indeed, Match(newC, C7) holds, which means that newC will be linked with one ofthe predecessors of C7, i.e., C5.

Answering User Requests. When a user request that contains a set of required capa-bilities comes, the algorithm below finds out a set of capabilities of networked servicesthat best match the ones required by the user. More precisely, for each capability Ci

in the user request the algorithm tries to find a graph that may contain capabilities thatmatch Ci (steps (1) and (2)). A graph Gi is selected if it is indexed with the ontolo-gies used in the request and if there exist a node Rooti in the set Roots(Gi) such thatMatch(Rooti, Ci) holds (step 3). In this case, a node that has the minimal semanticdistance with Ci is selected from the successors of Rooti (step 5).

inputs: a set of capabilities required in the service description C1, C2, ..., Cn

a set of graphs G1, G2, ..., Gm

outputs: a set of capabilities of networked services that match the capabilities given as input

MatchService(requested service)For all the capabilities Ci required in the service description do{ (1)

For all the graphs Gi in G1, ..., Gm that use the same ontologies as Ci

until Ci is matched do{ (2)For all Rootj in Roots(Gi) do { (3)

If (¬Match(Rooti, Ci)) then (4)Try with the next node in Root(Gi)

Else (5)Return Succ(Rooti) from the successors of Rooti such thatSemanticDistance(Succ(Rooti), Ci) is minimal

}}}

An example of matching a requested capability with capabilities of networked servicesis given in Figure 5. In this figure, the requested capability NewC uses the ontology


Fig. 5. Example of matching a user’s requested capability

O1 in its specification. This allows to filter out the DAG2 as it is indexed with only theontology O3. The next step is to match NewC with capabilities from Roots(DAG1)and Roots(DAG3), i.e., the capabilities C1 and C4. If the matching fails with one ofthese capabilities, we can infer that no capability will match newC in the correspondinggraph.

The benefits of using this solution to match user’s required capabilities with capa-bilities of networked services is to reduce the number of semantic matches performedto answer a query. Indeed, it is sufficient to perform a semantic match with a subset ofthe capabilities of networked services rather than performing a semantic match with allthe capabilities hosted by a directory of services. Furthermore, using the encoding ofclassified ontologies allows to reduce the semantic reasoning to a numeric comparisonof codes.

4 S-ARIADNE Service Discovery Protocol

Towards the deployment of our solution in pervasive computing environments, we buildupon the Ariadne middleware15, which introduces a semi-distributed service discoveryprotocol for mobile ad hoc networks (MANETs) [12]. According to the design pre-sented in [12], our discovery protocol, which we call S-Ariadne, relies on a backbone ofdirectories constituting a virtual network. Directories are dynamically deployed, eachdirectory performing service discovery in its vicinity. Then, service discovery in theglobal network is based on collaboration among deployed directories.

More precisely, S-Ariadne decomposes into a local and a global discovery process.The local discovery process is performed by each directory. Each directory is then re-sponsible for:

(i) caching the Amigo-S descriptions of the services available in its vicinity, and classi-fying the capabilities provided by these services according to the grouping schemediscussed in Section 3.3, and

(ii) periodically advertising the presence of registered services to the vicinity.

15 http://www-rocq.inria.fr/arles/download/ariadne/


When a directory receives a service request, specified as an Amigo-S service, it seekscapabilities of the cached services that semantically match the requested service asdiscussed in section 3.3.

To deal with the dynamics of pervasive networks, directories are dynamically andhomogeneously deployed in the network using an on the fly election process. Specifi-cally, if for a given period of time, a node does not receive any directory advertisement,the node initiates the election of a directory. The election process is done by broad-casting an election message in the network up to a given number of hops. Then, nodescan either accept or refuse to act as a directory, depending on a number of parameterssuch as network coverage, mobility and remaining/available resources. This mechanismallows electing directories with the best physical properties and distributing them effi-ciently since an election process is launched in the less covered areas. A node actingas a directory then periodically advertises its presence in its vicinity (i.e., up to a givennumber of hops).

The global service discovery process is based on collaboration among elected di-rectories. However, the efficiency of the discovery process in terms of response timeand generated traffic requires to query directories that are the most likely to cache ser-vice advertisements that do match the requested service. Towards this goal, we usedirectory categorization as introduced in [12], which gives a compact overview of thedirectory content. More precisely, we use Bloom filters for summarizing the contentof a directory. The main idea is to compute a vector v of m bits, which correspondsto a Bloom filter. For any capability C, its semantic description relies on a set of on-tologies O(C) = {O1, O2, ..., On} to which belong the concepts describing its in-puts, outputs and properties. Then, for each capability C provided by a networkedservice, and stored in a directory, the capability description in terms of used ontolo-gies is hashed with k independent hash functions. Each ontology is considered in termsof its URI. The bits of the vector v whose positions are given by the results of the khash functions are set to 1, i.e., the bits at position h1(O(C)), h2(O(C)), ..., hk(O(C))are set to 1. In order to determine whether a directory possibly caches a requestedcapability Req using the directory’s Bloom filter, we check whether the bit positionsh1(O(Req)), h2(O(Req)), ..., hk(O(Req)) in the vector are all set to 1. If there is a bitthat is not set to 1, the directory will not contain the required capability. Nevertheless,if all the bits are set to 1, the directory is likely to contain the required capability, anda concrete local service discovery is performed in that directory. The probability of afalse positive depends on the parameters k that is the number of hash functions and mthat is the size of the Bloom filter. These values can be chosen so that the probability offalse positive is minimized.

The cooperation between directories is performed by exchanging the Bloom filtersthat give an overview of the directories content. The exchange of Bloom filters is donewhen new directories are elected and reactively, i.e., requested by another directory,when the percentage of false positives reaches a given threshold.

According to the deployment policy, each mobile node is associated to at least onedirectory. When the mobile node seeks a service characterized by a set of required capa-bilities, it sends a query message to the directory that is responsible of its network area(i.e., in its vicinity). The directory performs for each required capability a local service


Fig. 6. S-Ariadne

discovery, as described in Section 3.3. If the required capabilities are not stored locally,the directory forwards the request to a subset of directories that are likely to cache ca-pabilities that match the request. The directories to which the request is forwarded areselected according to their Bloom filters and additional parameters such as remainingbattery lifetime and the distance between the respective directories.

Figure 6 provides an overview of the S-Ariadne architecture. In the figure, threenodes have been elected to act as directories. When a service request is issued, the di-rectory node that is in the vicinity of the service requester, i.e., Directory A, receives theservice request (Step(1)). The directory performs a local service discovery to find capa-bilities that semantically match the capabilities of the requested service (Step (2)). Ser-vice advertisements providing these capabilities are returned to the requester. If somecapabilities have not been found locally, another request is sent to remote directoriesthat are likely to store relevant capabilities according to their summarized description,i.e., Boom filters (Step (3)). These directories perform a local service discovery (Step(4)), and return the corresponding service advertisements (Step (5)), which are sent tothe requester (Step(6)).

5 Prototype Implementation and Evaluation

We have implemented a prototype of our solution to efficient matching of semanticservice capabilities as part of the Ariadne service discovery protocol extending it toS-Ariadne. We have evaluated the impact of introducing semantic service matching inAriadne, which originally uses basic WSDL-based syntactic matching of Web servicesfor the local service discovery. We have performed our evaluations on a Toshiba Satel-lite notebook with a 1.6 GHz Intel Centrino processor and 512 MB of RAM. In all theexperiments that we performed, we increased the number of services from 1 to 100.The service descriptions are using 22 different ontologies, and each service descriptioncontains a single provided capability. Figure 7 shows the results of our first experiment,which evaluates the time to create graphs of services in an empty directory. A scenario


for this experiment would be realized when a directory leaves the network and whenanother one is elected and has to host the set of service descriptions available in itsvicinity. Figure 7 shows three measurements: (1) the time to parse the service descrip-tions; (2) the time to classify the service capabilities into graphs; and (3) the total time,i.e., time to parse and create the graphs. From this figure, we can notice that the time tocreate the graphs is negligible compared to the time to parse service descriptions, i.e.,XML parsing time, which is mandatory due to the use of Web services and SemanticWeb technologies.

The results given by the second experiment that we performed are depicted inFigure 8. This experiment shows the time to insert a new capability in a directory. Thisfigure shows 3 measurements: (1) the time to parse the new service description; (2) thetime to insert a capability in a directory; and (3) the total time, i.e., the time to parse andinsert the new service description. Results show that the to time to classify a capabilityin a set of existing graphs is negligible compared to XML parsing time of the service de-scription. We also notice that this time is nearly constant. This is due to the fact that thenumber of semantic matches performed in the directory in order to insert a capabilitydepends neither on the total number of services on the directory nor on the number ofgraphs. The time to insert a capability depends on the number of capabilities containedin the graph in which the capability will be inserted. This is due to the fact that graphsare indexed using the ontologies that are being used in the capabilities’ descriptions,which allows pre-selecting a subset of graphs that are likely to be appropriate for theinsertion of the new capability. Thus, only a few number of semantic matches are per-formed in order to insert a capability in a directory. The results of the third experiment

0

50

100

150

200

250

300

350

400

0 20 40 60 80 100

Tim

e (m

s)

No. of Services

Time to parse servicesTime to create graphs

Total time

Fig. 7. Time to create graphs

0

20

40

60

80

100

120

140

160

0 20 40 60 80 100

Tim

e (m

s)

No. of Services

Time to insert a service in the graphs Time to parse the service request

Total Time

Fig. 8. Time to publish a service advertisement

that we performed are depicted in Figure 9. In this experiment, we evaluate the time tomatch a service request with services hosted by a directory. Furthermore, we comparethe time to match a request in a directory where capabilities are classified into a set ofgraphs, with the time to match a request in a directory without classification. Results aregiven without the XML parsing time of the request description. In this figure, we cannotice that without classification the average overhead for matching is around 50% ofthe time to match when the capabilities are pre-classified. Moreover, we can notice that


0

1

2

3

4

5

0 20 40 60 80 100

Tim

e (m

s)

No. of Services

Time for optimized matchingTime for non optimized matching

Fig. 9. Time to match a service request

0

50

100

150

200

250

300

350

400

0 20 40 60 80 100

Tim

e (m

s)

No. of Services

AriadneS-Ariadne

Fig. 10. Ariadne vs S-Ariadne

the time to match a request in the classified directory is almost constant, which is due tothe graphs indexing and the directory structuring. We can also notice that the responsetime to match a required capability, excluding XML parsing time, is in the order of fewmilliseconds.

The last experiment that we performed is a comparison of the response time given bythe classical syntactic-based matching performed by Ariadne and the optimized seman-tic matching performed by S-Ariadne. The results are given in Figure 10. This figureshows that the response time given by Ariadne is increasing with the number of ser-vices available in the directory, while S-Ariadne has an almost stable response time,which is due to the following reasons: (1) using S-Ariadne, the services are parsedonce at the publishing phase and their capabilities are classified, which avoids match-ing a request with all the services of the directory; (2) due to the numeric encodingof classified ontologies, the semantic matching performed by S-Ariadne reduces to anumeric comparison of codes, while using Ariadne the matching is performed by syn-tactically comparing the WSDL descriptions. We can conclude that, using S-Ariadne,semantic matching, which allows to leverage the openness of pervasive computing en-vironments, can be performed more efficiently than classical syntactic matching. Fur-thermore, thanks to the indexing and classification of service capabilities, S-Ariadne ismore scalable than Ariadne.

6 Conclusion

The pervasive computing vision implies that everywhere around us the environment ispopulated with networked software and hardware resources that can be discovered andintegrated towards the realization of our daily tasks. Towards the realization of this vi-sion, middleware support for the efficient dynamic discovery of software and hardwareresources of the pervasive computing environment is a key requirement. Such middle-ware support has to deal with the heterogeneity of the networked resources. This canbe partially addressed using service-oriented architectures, and particularly the Webservices paradigm. Indeed, Web services enable having a homogeneous vision and ac-cess to the heterogeneous networked resources of the environments. Nevertheless, Web


services discovery and interaction commonly relies on the syntactic conformance ofservice interfaces, for which common understanding is hardly achievable in open en-vironments. The Semantic Web paradigm allows to overcome this limitation by intro-ducing semantic specification of service functional and non-functional features, whichenables semantic reasoning on Web services capabilities.

Building on semantic Web services, our approach to dynamic service discovery inpervasive computing environments relies on the Amigo-S language for the semanticspecification of pervasive services, and introduces an efficient matching relation of ser-vice capabilities, which we have integrated in S-Ariadne extending Ariadne, a semi-distributed discovery protocol adapted to pervasive computing environments. Our solu-tion optimizes the costly ontology-based semantic reasoning on one hand, and the num-ber of semantic matches to be performed to answer a user request on the other hand. Theoptimization of the semantic reasoning is based on the encoding of classified concepthierarchies, which allows to reduce the semantic reasoning to a numeric comparisonof codes, while the optimization of the matching process is based on the classificationof service capabilities into hierarchies of related capabilities. Our results show that S-Ariadne provide better response time for the semantic matching of service capabilitiesthan Ariadne, its syntactic ancestor, for the basic syntactic service matching. Further-more, thanks to the indexing and the structuring of service directories, S-Ariadne ismore scalable than a classical service directory.

Acknowledgments

This research is partially supported by the European IST AMIGO project16 (EU-IST-004182).

References

1. Yerom-David Bromberg and Valerie Issarny. Indiss: Interoperable discovery system for net-worked services. In Proceedings of ACM/IFIP/USENIX 6th International Middleware Con-ference (Middleware’05), 2005.

2. Amigo Consortium. Amigo middleware core: Prototype implementation and documentation.Project Deliverable D3.2, 2006.

3. Ion Constantinescu and Boi Faltings. Efficient matchmaking and directory services. InProceedings of the IEEE International Conference on Web Intelligence (WI’03), 2003.

4. N. Georgantas, S. Ben Mokhtar, Y.-D. Bromberg, V. Issarny, J. Kalaoja, A. Grodolle J. Kan-tarovitch, and R. Mevissen. The amigo service architecture for the open networked homeenvironment. In Proceedings of 5th Working IEEE/IFIP Conference on Software Architec-ture (WICSA’05), 2005.

5. Nikolaos Georgantas, Sonia Ben Mokhtar, Ferda Tartanoglu, and Valerie Issarny. Architect-ing Dependable Systems III, chapter Semantic-aware Services for the Mobile ComputingEnvironment. Springer Verlag, 2005.

6. Joseph M. Hellerstein, Jeffrey F. Naughton, and Avi Pfeffer. Generalized search trees fordatabase systems. In Proceedings of the 21st International Conference of Very Large DataBases, VLDB’95, 1995.

16 http://www.hitech-projects.com/euprojects/amigo/


7. Valerie Issarny, Daniele Sacchetti, Ferda Tartanoglu, Francoise Sailhan, Rafik Chibout,Nicole Levy, and Angel Talamona. Developing ambient intelligence systems: A solutionbased on web services. Journal of Automated Software Engineering, 2004.

8. Sonia Ben Mokhtar, Damien Fournier, Nikolaos Georgantas, and Valerie Issarny. Context-aware service composition in pervasive computing environments. In Proceedings of the 2ndInternational Workshop on Rapid Integration of Software Engineering Techniques (RISE’05),2005.

9. Sonia Ben Mokhtar, Anupam Kaul, Nikolaos Georgantas, and Valerie Issarny. Towards effi-cient matching of semantic web service capabilities. In Proceedings of the workshop of WebServices Modeling and Testing (WS-MATE’06), 2006.

10. Sonia Ben Mokhtar, Jinshan Liu, Nikolaos Georgantas, and Valerie Issarny. Qos-aware dy-namic service composition in ambient intelligence environments. In Proceedings of the 20thIEEE/ACM International Conference on Automated Software Engineering (ASE’05), 2005.

11. Mike P. Papazoglou. Service -oriented computing: Concepts, characteristics and directions.In Proceedings of the Fourth International Conference on Web Information Systems Engi-neering(WISE ’03), 2003.

12. Francoise Sailhan and Valerie Issarny. Scalable service discovery for MANET. In Proceed-ings of the 3rd IEEE International Conference on Pervasive Computing and Communications(PerCom’05), 2005.

13. Naveen Srinivasan, Massimo Paolucci, and Katia Sycara. Adding owl-s to uddi, implemen-tation and throughput. In Proceedings of the Workshop on Semantic Web Service and WebProcess Composition, 2004.

Documents

LNCS 4290 - Efficient Semantic Service Discovery in ... · Efﬁcient Semantic Service Discovery in Pervasive Computing Environments 243 The service proﬁle gives a description of