DISCOVERING SEMANTIC WEB SERVICES

IN FEDERATED DIRECTORIES

Michael Schumacher

University of Applied Sciences Western Switzerland, Institute of Business Information Systems, CH-3960 Sierre, Switzerland

Tim van Pelt, Ion Constantinescu, Alexandre de Oliveira e Sousa and Boi Faltings

Artiﬁcial Intelligence Lab, Ecole Polytechnique F

erale de Lausanne (EPFL), CH-1015 Lausanne, Switzerland

Keywords:

Semantic web services, distributed directories, intelligent agents, coordination, eHealth.

Abstract:

This paper presents a ﬂexible federated directory system called WSDir, which allows registration and dis-

covery of semantic web services. Our directory system is used in a context where ubiquitous ehealth services

should be ﬂexibly coordinated and pervasively provided to the mobile user by intelligent agents in dynamically

changing environments. The system has been modeled, designed and implemented as a backbone directory

system to be searched by an infrastructure made up by such kind of agents coordinating web services. The sys-

tem is modeled as a federation: directory services form its atomic units, and the federation emerges from the

registration of directory services in other directory services. Directories are virtual clusters of service entries

stored in one or more directory services. To create the topology, policies are deﬁned on all possible operations

to be called on directories. For instance, they allow for routed registration and selective access to directories.

1 INTRODUCTION

UDDI has become the de-facto standard to provide

a general framework to describe and discover ser-

vices and Web service providers. More speciﬁcally,

WSDL descriptions of web services can be mapped

to UDDI data structures, allowing to ﬁnd web service

descriptions using the standard UDDI query interface.

Within the academic world, a number of approaches

exist that try to build semantically enhanced discovery

components on top of UDDI. (Kawamura et al., 2003)

augments the standard UDDI registry APIs with se-

mantic annotations. (Verma et al., 2004) uses a set of

distributed UDDI registries as a storage layer, where

each registry is mapped to a speciﬁc domain based on

a registry ontology.

This paper presents a new federated directory (or

registry) system called WSDir

, which allows regis-

tration and discovery of OWL-S semantic web ser-

vices (Martin et al., 2004). Our directory system is

used in the CASCOM platform

where ehealth ser-

This work has been supported in part by the Euro-

pean Commission under the project grant FP6-IST-511632-

CASCOM.

http://www.ist-cascom.org

vices should be ﬂexibly coordinated and pervasively

provided to the mobile user by intelligent agents in

dynamically changing environments. We modeled,

designed and implemented WSDir as a backbone di-

rectory system to be searched by an infrastructure

made up by such kind of agents coordinating web

services. This agent infrastructure therefore is de-

ployed on mobile users: it queries our directory sys-

tem for OWL-S service descriptions, composes them

to achieve a target higher functionality and executes

them. WSDir is currently being used in the trials of

an ehealth emergency application.

We followed speciﬁc requirements for designing

WSDir: i) it should have itself a Web service interface

to be universally invoked; ii) it should be distributed;

iii) the construction of the network should induce

minimal overhead and should be scalable; also, the

network should be robust to changes in topology and

the number of interactions with the system; iv) the di-

rectory should allow a great number of services to be

registered, and this in a very dynamic way, including

lease times.

These requirements lead us to model WSDir as a

federation: directory services form its atomic units,

and the federation emerges from the registration of

283

Schumacher M., van Pelt T., Constantinescu I., de Oliveira e Sousa A. and Faltings B. (2007).

DISCOVERING SEMANTIC WEB SERVICES IN FEDERATED DIRECTORIES.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - SAIC, pages 283-286

DOI: 10.5220/0002362902830286

 SciTePress

directory services in other directory services. Direc-

tories are virtual clusters of service entries stored in

one or more directory services. To create the topol-

ogy, policies are deﬁned on all possible operations to

be called on directories. For instance, they allow for

routed registration and selective access to directories.

The paper is organized as follows. In Sec. 2, we

explain the service entries stored in WSDir. Sec-

tions 3 to 6 explain the concepts and architecture of

WSDir. In Sec. 7, we give a concrete network ar-

chitecture example based on WSDir. Finally, Sec. 8

concludes the paper.

2 SERVICE ENTRIES

We describe services using OWL-S (Martin et al.,

2004). Internally, the directory system stores then

service entries in the FIPA SL0 description language.

The internal representation contains a subset of the

information provided in the original service descrip-

tion, to be used to ﬁnd matching services. In addition,

the original OWL-S description is stored in a separate

slot. This ﬁeld is used to retrieve the original descrip-

tion, e.g., to retrieve the grounding(s) of a service at

service execution.

In the following, we present the information that a

service entry in WSDir contains:

ServiceCategories: entry in some ontology or taxon-

omy of services.

ServiceProﬁleURIs: set of proﬁle URIs that point to

an externally stored, but (web-)retrievable service

proﬁle.

ServiceProcessURI: process URI deﬁned in the ser-

vice description (can be empty).

ServiceGroundings: set of full-text service ground-

ings (can be empty).

OWLSServiceDescription: original OWL-S service

description as a full-text entry.

3 DIRECTORIES

A directory comprises a set of service entries which

are managed by a collection of one or more directory

services. All service entries, including directory ser-

vice entries, are registered at a directory service as

belonging to a speciﬁc directory. Such, directory ser-

vices can form an arbitrary organisational structure

(peer-to-peer, hierarchy etc.). Speciﬁcally, a direc-

tory can contain other directories, and a directory is

supported by one or more directory services.

.(dot)

Body

Directory

Directory service

name

Directory service entry

Figure 1: Visual recapitulation of directory system con-

cepts.

The above is used to characterize directories by

two different types of interactions:

• Client-Directory interactions: in which clients

registering, deregistering, and querying the direc-

tory interact with directory services supporting

the directory.

• Director-Directory interactions: in which direc-

tory services supporting the directories interact

with one another to perform the internal manage-

ment of the directory (e.g. federated queries).

4 DIRECTORY SERVICES

Directory services provide a Web service interface to

a repository that holds service entries. The service

entries in this store are all registered as belonging

to a certain directory. The directory service forms

the atomic unit of the directory federation. It allows

clients to register, deregister, modify and search reg-

istrations in its repository. These registrations include

service descriptions of services offered by clients as

well as proﬁles of other directory service. By reg-

istering directory services in other directory service

stores, the system becomes federated.

Figure 1 visually summarizes the relationship be-

tween service entries, directories and directory ser-

vices. The directory service holds regular service en-

tries and a directory service entry belonging to a Hos-

pitals directory as well as entries belonging to an In-

surers directory. Both directories are contained in the

Body directory, which in turn is contained in the all-

encompassing ”.” directory.

ICEIS 2007 - International Conference on Enterprise Information Systems

284

5 DIRECTORY OPERATIONS

The directory is able to handle ﬁve types of opera-

tions:

Registration: The register operation enables a client

to register a service description entry into a di-

rectory for a time period given by a lease-time.

The directory-service can return a redirect mes-

sage pointing to another directory where the client

could try to register its object.

Deregistration: The deregister operation de-

registers a service that previously has been

registered identiﬁed.

Modiﬁcation: The modify operation allows modify-

ing a registered service.

Search: The search operation looks in the directory

for services that match a template. The request

can possibly be forwarded to supporting directo-

ries, depending on the implemented search policy

at the directory. As the internal service descrip-

tions are expressed as SL0 expressions, the struc-

tured element used in the operation is also an SL0

expression. Search-constraints can be speciﬁed in

order to restrain the search:

• a max-time speciﬁes a deadline by which the

constrained search should return the results.

• a max-depth speciﬁes the maximum depth of

propagation of the search to federated directo-

ries.

• a max-results element speciﬁes the maximum

number of results to be returned.

Get Proﬁle The get-proﬁle requests meta-

information on a directory service such as its

name and the policies governing the operations.

6 POLICIES

Directory services employ directory policies to regu-

late the operation of directories. Policies are deﬁned

per directory service in the directory service proﬁle

and determine the behaviour of a speciﬁc directory.

Two types of policies can be distinguished:

• Pro-active policies are typically used for internal

management of the directories.

• Reactive policies assign a behaviour to combina-

tions of directories and operations; they are exe-

cuted whenever a bound operation is called and

deﬁned as a triple: (directory name, operation,

policy).

get-profile

. (dot)

Body

Hospitals

Insurers

Directory

Service

modify

deregister

Directory Service policies

(directory, operation, policy)

Hospitals : search : secauth

Body : register : child

Body : search : policy-3

* (default) : register : policy-4

Figure 2: Example use of policies.

From the consequent application of policies, the

network topology emerges. Policies can for exam-

ple deﬁne how much entries can be registered per di-

rectory, which directories can be searched by which

clients, and which types of services will be accepted.

Each directory service can deﬁne its own policies or

use one of the pre-deﬁned policies. The only require-

ment on the part of a policy is that it can be executed.

A straightforward example of a pre-deﬁned policy is

the child/sibling policy: this policy forwards all oper-

ations to both the known children as well as its known

siblings.

Figure 2 shows an example of the reactive poli-

cies that are assigned to the various directories this

directory service supports. In the illustration, when

a client calls the search operation on the ”Hospitals”

directory, a policy called ”secauth” will be applied.

Such a policy could for example require the client to

authenticate itself before it is allowed to query the di-

rectory.

7 AN EXAMPLE OF A NETWORK

ARCHITECTURE

WSDir allows to setup ﬂexible distributed directory

systems, especially thanks to the mechanism of poli-

cies. We present here a speciﬁc application of WS-

Dir to build a network of directory services which are

modelled as a virtual tree with multiple roots.

The nodes of the tree are made up by the individ-

ual directory services. This hierarchical structure with

multiple entry points effectuates:

• No replication or data is cached within the direc-

tory;

• Directory services will forward queries to other

directory services;

• Query messages are checked for duplication;

DISCOVERING SEMANTIC WEB SERVICES IN FEDERATED DIRECTORIES

285

Hidden

Body-1 Body-2

Top-1

Top-2

Body-5 Body-6

Domain-1

Body-4Body-3

Service entry

Network directory

Domain directory

Directory service

Body-7

Figure 3: Network Topology.

• Identical results may be returned by one or more

directory services for a single query.

Figure 3 illustrates our network topology. We dis-

tinguish two types of directories: network directories

and domain directories. Network directories are a re-

served set of directories that are used for the construc-

tion of the network. Among them, we can distinguish

three different network directories:

• Hidden network directory forms the root of the

federation by registering the top-level nodes of the

network.

• Top network directory is visible to the network

as being one of the roots of the federation multi-

rooted tree.

• Body network directory is used for regular di-

rectory services that form the body of the multi-

rooted tree.

Domain directories emerge from the registrations

of service descriptions at the directory services that

make up the directory system. By deﬁnition, domain

directories are contained in the ”Body Members” di-

rectory.

At boot time, the directory makes use of a pre-

deﬁned network conﬁguration to create a network

topology. The conﬁguration speciﬁes management

and data relations between members of the network.

In a typical setting, the node at the highest level will

be hidden to all nodes not belonging to the ”Top

Members” directory.

To construct the network topology, WSDir em-

ploys a set of pre-deﬁned pro-active policies. For in-

stance, a speciﬁc policy would make search requests

directed at a directory service be forwarded to its reg-

istered children and its known siblings.

8 CONCLUSION

WSDir has been tested thoroughly in a real distributed

setting spread over different countries. The system

has proven to be scalable and very stable. It is be-

ing used as backbone in a use case scenario in health

emergency management. Future work could espe-

cially enhance security.

We currently employ standard security mecha-

nisms for accessing the directory services. In particu-

lar, if a directory service requires protecting messag-

ing from overhearing or if it would require privacy

sensible data as parameters, the access to this web

service will be based on HTTPS. In cases where no

HTTPS is available, e.g., in most MIDP 2.0 imple-

mentations, we could couple WSDir with Guarantor

agents (Bianchi et al., 2005) spread in the architec-

ture in order to provide a secure tunnelling between

secure ACL messages and HTTPS.

Another improvement could deﬁne security mea-

sures directly within the directory system by deﬁning

speciﬁc policies. A policy can be employed to restrict

the right to perform a certain operation on a directory

to only those clients that can provide the right creden-

tials.

REFERENCES

Bianchi, R., Fontana, A., and Bergenti, F. (2005). A real-

world approach to secure and trusted negotiation in

mass. In AAMAS ’05: Proceedings of the fourth inter-

national joint conference on Autonomous agents and

multiagent systems, pages 1163–1164, New York, NY,

USA. ACM Press.

Kawamura, T., Blasio, J.-A. D., Hasegawa, T., Paolucci, M.,

and Sycara, K. P. (2003). Preliminary report of public

experiment of semantic service matchmaker with uddi

business registry. In ICSOC, pages 208–224.

Martin, D., Paolucci, M., McIlraith, S., Burstein, M., Mc-

Dermott, D., McGuinness, D., Parsia, B., Payne, T.,

Sabou, M., Solanki, M., Srinivasan, N., and Sycara,

K. (2004). Bringing semantics to web services: The

owl-s approach. In Proceedings of the First Interna-

tional Workshop on Semantic Web Services and Web

Process Composition (SWSWPC 2004).

Verma, K., Sivashanmugam, K., Sheth, A., Patil, A., Ound-

hakar, S., and Miller, J. (2004). METEOR-S WSDI:

A Scalable Infrastructure of Registries for Semantic

Publication and Discovery of Web Services. Journal

of Information Technology and Management.

ICEIS 2007 - International Conference on Enterprise Information Systems

286