=Paper=
{{Paper
|id=None
|storemode=property
|title=Integrating Semantic Web Services and Matchmaking in ebXML Registry
|pdfUrl=https://ceur-ws.org/Vol-667/smr22010_submission_5.pdf
|volume=Vol-667
|dblpUrl=https://dblp.org/rec/conf/semweb/SchulteSS10
}}
==Integrating Semantic Web Services and Matchmaking in ebXML Registry==
https://ceur-ws.org/Vol-667/smr22010_submission_5.pdf
Integrating Semantic Web Services and
Matchmaking into ebXML Registry
Stefan Schulte, Melanie Siebenhaar, and Ralf Steinmetz
Multimedia Communications Lab (KOM)
Technische Universität Darmstadt, Germany
schulte@kom.tu-darmstadt.de
Abstract. While the “Universal Description, Discovery and Integra-
tion” (UDDI) service registry standard has drawn great attention by
the research community, it has not been widely adopted by the software
industry. Objections towards UDDI include technical as well as concep-
tional arguments. Being an official ISO standard and providing a num-
ber of features UDDI is missing, “Electronic Business using Extensible
Markup Language” (ebXML) Registry could be an adequate alternative
for the implementation of service registries and/or repositories. However,
little work has been done regarding the integration of Semantic Web Ser-
vices (SWS) into ebXML Registry.
In this paper, we present a solution extending the ebXML Registry by
capabilities to handle and provide SWS. This includes a concept for the
integration of SWS into ebXML Registry as well as a prototypical imple-
mentation using SAWSDL and the open source framework freebXML.
1 Motivation
One of the primary application areas of SWS is service discovery, which has
been a major topic from the very beginning of SWS research [19], [22]. In most
scenarios, services are registered at some kind of service catalogue, which can
be searched by (potential) service consumers. Apart from proprietary solutions,
the SWS research community has mostly deployed UDDI as service registry
standard and a multitude of solutions to include SWS into such registries have
been proposed (cp. Section 2).
Even though UDDI is still deemed to be one of the key building blocks of
service-oriented computing, it suffers from some major drawbacks. While con-
ducting research on query formulation, we had to learn that it is difficult to
use UDDI as a starting point for an advanced query formalism applied in SWS
discovery [25].
A comparison of some major features provided by ebXML Registry and
UDDI, which are important for the selection of a registry standard, are shown
in Table 1: First, UDDI provides by default only a registry, where metadata
about artifacts is stored. The actual artifacts (e.g., service descriptions mak-
ing use of the “Web Service Description Language” (WSDL)) are not stored in
UDDI. Instead, references to these artifacts are published in the registry. This
2 Stefan Schulte et al.
Table 1. Comparison of Registry Standards ebXML and UDDI (cp. [3], [28])
Category/Feature ebXML Registry 3.0 UDDI 3.0
Service description standards WSDL 1.1 WSDL 1.1
Registry YES YES
Repository YES NO
Object-oriented information model and API YES NO
Extensible information model YES NO
User-defined queries YES NO
SQL query syntax YES NO
XML query syntax YES YES
JAXR API YES YES
aspect of UDDI has been deemed as a major drawback by the software industry,
as it makes it difficult to establish service life cycle management for Service-
oriented Architectures1 (SOA) and therefore, service and SOA governance [28].
In contrast to UDDI, the ebXML Registry provides both, a registry and a corre-
sponding repository. Hence, besides the metadata, also the artifacts themselves
are published in ebXML Registry.
Second, UDDI makes use of a relatively flat data model, which cannot be
extended, whereas ebXML Registry offers an object-oriented and extensible in-
formation model and Application Programming Interface (API). Finally, while
both registry standards can be used by utilizing the “Java API for XML Reg-
istries” (JAXR), which provides a uniform way for communicating with a reg-
istry, search facilities differ as ebXML offers enhanced querying capabilities by
providing SQL support and user-defined queries in comparison to UDDI, which
is only able to process XML-based queries.
Regarding the integration of an advanced query formalism into a service
registry (cp. [25]), this is a major point and has been our main motivation
to restrain from making use of UDDI. As there has been little work on the
application of ebXML Registry in a generic SWS discovery framework, we have
developed our own solution which is presented in this paper.
The remainder of this paper is structured as follows: In Section 2, we will
give an overview of SWS integration approaches into registries. Afterwards, we
give an overview on ebXML Registry. In Section 4, we introduce a solution to
integrate SWS into ebXML Registry and a first implementation including an
interface for matchmakers. The paper closes with a conclusion and an outlook
on our future work.
1
http://www.zdnet.com/blog/service-oriented/ibm-acknowledges-bypassing-
uddi-calls-for-new-soa-registry-standard/864,
http://www.computing.co.uk/vnunet/news/2188598/ibm-calls-soa-discovery,
accessed at 2010-09-04
Integrating Semantic Web Services and Matchmaking into ebXML Registry 3
2 Related Work
The integration of SWS descriptions in service registries has been examined
in a multitude of approaches, mostly making use of UDDI as service registry
standard. In their seminal work on SWS, Paolucci et al. present the integration
of “DARPA agent markup language for services” (DAML-S) profiles in UDDI
[22]. The authors propose the mapping of a service profile to UDDI records.
Besides the DAML-S/UDDI mapping, an external matchmaker architecture is
suggested by the authors, which uses DAML ontologies publicly available on the
Web for semantic capability matching. In this approach, it is possible to search
for services using UDDI keyword-based search and a capability matching engine,
if requests are specified in the DAML-S format. Several authors have proposed
enhancements of the work by Paolucci et al., e.g., regarding the usage of UDDI-
internal matchmakers [1], the application of the “Web Ontology Language for
Web Services” (OWL-S) or semantically enhanced WSDL instead of DAML-S
[26], [27], or the integration of functionalities enabling the usage of semantic
search in UDDI on the client-side instead of altering the UDDI implementation
[17].
There are further approaches to integrate SWS into service registries in gen-
eral SWS frameworks, with METEOR-S [29] and the “Web Service Modeling
eXecution Environment” (WSMX) being prominent examples. However, in both
approaches the actual registry is more a means to an end than in the focus
of the work. In an early “Web Service Modeling Ontology” (WSMO) Registry
Working Draft, UDDI was intended to provide registry functionalities [12]. How-
ever, for WSMX, which is the reference implementation of WSMO, no further
information is given if a particular registry standard has been applied or not. In
fact, WSMX’s Resource Manager is an internal registry [11]; furthermore, it is
stated that an ebXML- or UDDI-based registry could be used for WSMX data
persistence [5]. More recently, Kourtesis et al. have proposed a combination of
SAWSDL, OWL DL, and UDDI (Version 2.0) for semantically enhanced Web
service discovery in the FUSION Semantic Registry [16]. While this framework
does not rely on any specific SWS standard, the reference implementation pre-
sented is based on SAWSDL. Neither the UDDI server nor its specification API
are altered, but are wrapped in the semantic registry.
A different approach to the integration of semantic information in service
registries has been implemented in PYRAMID-S [23]. Actually, PYRAMID-S
is an overlay to service registries which uses a hybrid peer-to-peer topology to
manage heterogeneous service registries. The aim of the framework is to allow
unified Web service publication and discovery, which does not adhere to a partic-
ular service registry standard. As PYRAMID-S facilitates the usage of different
service registry standards, it is necessary to define mediators for the designated
standards. Mediators for UDDI (based on [6]) and ebXML (based on [4]) have
already been defined. There are several differences between PYRAMID-S and
the work at hand: Most importantly, in PYRAMID-S, only those matchmakers
provided by ebXML Registry are explicitly regarded. The authors give no in-
formation on how to extend a registry’s matchmaking capabilities. As ebXML
4 Stefan Schulte et al.
Registry does not provide any semantic matchmaker, matching is limited to
syntax-based query statements and “non-fuzzy” semantic matchmaking, i.e., a
semantic annotation in a service advertisement has to be exactly the same as
specified in a service request. Furthermore, Pilioura and Tsalgatidou make use of
their own WSDL variant, namely PS-WSDL and do not regard, e.g., SAWSDL
or OWL-S.
Dogac et al. introduce another approach, which incorporates the integration
of “Web Ontology Language” (OWL) ontologies into ebXML registries in order
to enhance service discovery [8]. The work by Dogac et al. has been committed
as an OASIS Committee Draft for an ebXML Registry Profile for Web Ontology
Language [7], which could be used to integrate OWL-S services into ebXML. No-
tably, this work is limited to OWL Lite, while OWL-S ontologies are written in
OWL DL [2]; there is no information given on how this contradiction is handled.
The authors define a mapping of OWL elements to ebXML class hierarchies,
which can be performed automatically from a given OWL ontology. Concern-
ing the suggested mapping, OWL classes are represented through classification
nodes in ebXML, while RDF properties are modeled using ebXML associations.
This allows to represent whole OWL class hierarchies through ebXML elements.
Finally, stored procedures are defined in order to handle the OWL semantics,
e.g., to obtain all the super- or subclasses of a given class. These stored pro-
cedures can then be utilized by users in order to retrieve appropriate services
that are classified using the OWL classification nodes from the ebXML registry
[8]. This way, this solution is very inflexible, as it does not account for inferred
semantic relationships and relies on querying predefined semantic hierarchies.
In their work on making use of SPARQL as means to define preconditions
and effects in SWS descriptions, Iqbal et al. also use ebXML Registry [13]. The
registry is used to store SAWSDL-based service descriptions, while SPARQL-
based conditions are stored separately in the repository infrastructure. The au-
thors state that their ebXML-based service repository does not (yet) allow to
query for the integrated semantic metadata. The authors suggest to store the se-
mantically enhanced service descriptions within the ebXML infrastructure and
indicate a mechanism to reference additional semantic information in form of
SPARQL-based conditions. Unfortunately, the details of this approach are not
stated explicitly.
As it can be seen, existing solutions to integrate SWS into ebXML Registry
are either constricted to the elements needed in a particular matchmaking ap-
proach [8], [13] and/or rely on the existing matchmakers provided by ebXML
Registry [23]. In contrast, the solution at hand has been designed in order to
provide a generic framework for SWS discovery using ebXML Registry.
3 ebXML Registry – Overview
In 1999, ebXML2 has been initiated by OASIS and the United Nations/ECE
agency CEFACT. In general, it provides a modular suite of specifications for en-
2
http://www.ebxml.org/geninfo.htm, access at 2010-09-04
Integrating Semantic Web Services and Matchmaking into ebXML Registry 5
ExtrinsicObject
WSDL:service Service WSDL:portType
[ObjectType=PortType]
1
1..*
1 ExtrinsicObject
WSDL:port ServiceBinding WSDL:binding
[ObjectType=Binding]
Fig. 1. Mapping WSDL Information to the ebXML RIM
terprises to perform business over the Internet (e.g., message exchange, registra-
tion of services), from which the specifications for registries and repositories are
relevant within the work at hand. In this context, two documents are currently
available as approved OASIS standards: the ebXML Registry Information Model
(RIM) [9] and the ebXML Registry Services and Protocols (RS) [10]. ebXML
RIM and ebXML RS have been standardized as ISO 15000, Parts 3 and 4, re-
spectively. The former specifies the underlying data model of the registry, i.e.,
the metadata classes, whose instances are used to describe the objects stored
in the repository, and the latter describes the functionalities provided by the
registry and the protocols used for interacting with the registry.
An ebXML registry may further implement different profiles, each defining
a processing standard as well as extensions and restrictions of the core ebXML
features for a specific type of content. The ebXML Registry Profile for Web
Services (WS) defines the publication, management and discovery of Web service
artifacts [21]. The RIM classes which are relevant for the registration of Web
services in an ebXML registry implementing the Web Service profile are depicted
in Figure 1.
A service is represented by an instance of the Service class, which itself con-
tains one or more instances of the ServiceBinding class providing technical in-
formation (e.g., the access URI) on how to access a concrete service instance in a
specific way. The class ExtrinsicObject represents the primary metadata class
for items stored within the repository [9]. To specify the type of content submit-
ted to the repository represented by an instance of the ExtrinsicObject class,
classification schemes are used. In standard ebXML implementations, WSDL
files are stored as ExtrinsicObject instances and classified with the WSDL
classification node. When submitting a WSDL document to the registry, a corre-
sponding Cataloging Service is invoked which performs a mapping of the WSDL
components to the ebXML RIM [21]. This is due to the fact, that the default ser-
vice information model as part of the RIM also supports the registration of other
types of services than Web services [9], i.e., represents a generic service model.
Consequently, the components which are specific to a certain kind of service have
to be stored as extrinsic objects and classified using custom-built classification
6 Stefan Schulte et al.
schemes. So far, ebXML WS has only been defined for WSDL 1.1-based service
descriptions.
4 Solution Approach and Prototypical Implementation
In order to integrate SWS into ebXML and provide appropriate service discovery
facilities, it is necessary to provide solutions for the following issues:
– Integration of SWS descriptions
– Integration of query formulations
– Integration of matchmaking capabilities
Regarding the integration of query formulations, we refer to our former work
presented in [25]. In the following, we will focus on the integration of SWS and
the provision of a matchmaking interface in ebXML; query formulation is only
regarded if necessary to complete a particular consideration. Afterwards, we
present a prototypical implementation using freebXML 3.1 3 .
4.1 Integration of SWS Descriptions
In order to integrate SWS descriptions into ebXML Registry, it is necessary to
enhance the ebXML RIM by a new classification node, e.g., called SWS. Using
the newly created object type SWS, it is possible to classify SWS objects and to
distinguish between non-semantic and semantic Web services. The handling of
these new objects has to be implemented in the corresponding ebXML Registry
realization (cp. Section 4.4). We determine SWS descriptions to be published
using a subclass of the new classification node SWS; the corresponding WSDL
information is published by the standard publication mechanism. In doing so,
we assume SWS descriptions to make use of a WSDL grounding, as provided by,
e.g., WSMO and OWL-S [14], [15], [18].
SAWSDL services can be published without any modifications using the stan-
dard WSDL cataloging service of ebXML registrations. However, it is still neces-
sary to publish the semantic information described in SAWSDL using a separate
node in order to make a differentiation for syntax- and semantic-based service
discovery.
4.2 Integration of Matchmaking Capabilities
Per se, ebXML Registry offers syntax-based matchmaking capabilities based on
service queries defined using SQL or so-called ebXML filters [10]. In order to
enable semantic-based service discovery, it is necessary to provide new match-
making facilities.
Therefore, within the work at hand, an exemplary matchmaker is directly in-
tegrated into a service registry as proof-of-concept. A direct integration mecha-
nism for matchmakers into registries demands a generic concept, i.e., the creation
3
http://ebxmlrr.sourceforge.net/
Integrating Semantic Web Services and Matchmaking into ebXML Registry 7
and provision of interfaces. In doing so, further matchmakers can be introduced
without changing existing classes, but only through the implementation of ad-
ditional classes.
Since the registry should also provide semantic matching capabilities, the
management of ontologies has to be addressed. Regarding service (information)
life cycle management as well as service and SOA governance, (information
about) ontologies need to be managed by a service registry itself. Ontologies
needed in matchmaking depend on the services published in a registry. Thus,
a flexible mechanism for the management of ontologies is required, so that new
ontologies can be added at any time. For this, a semantic reasoning engine can
be integrated into a service registry in conjunction with an ontology knowl-
edge base, where arbitrary ontologies can be registered. For example, a service
provider could register the necessary ontologies together with the service of-
fers at publication time. If a query is enhanced with semantic information, the
syntax-based part can be directed to the standard search facilities provided by
a registry and the additional semantic information can be directed to semantic
matchmakers to allow for real reasoning support.
4.3 freebXML – An Open Source Reference Implementation of
ebXML Registry
Registry
Web Browser Web UI Java UI Admin Tool Client
R R R Layer
JAXR API Registry
R
Client
JAXR Provider API Layer
R
HTTP SOAP
QueryManager LifeCycleManager
Authentication and Authorization
Registry
Persistence Server
SQLPersistenceManager RepositoryManager
RDBMS
Fig. 2. The freebXML Architecture
8 Stefan Schulte et al.
For our prototypical implementation, freebXML 3.1 was used and enhanced.
freebXML is an open source reference implementation of the OASIS ebXML Reg-
istry standards [9], [10]. freebXML is made up from a registry, where metadata
about artifacts can be published, and a repository, where the actual artifacts are
stored. In general, an ebXML registry may implement different profiles, i.e., pro-
vide functional enhancements for a specific type of content. Concerning profiles,
freebXML implements, among others, ebXML WS [21]. Basically, the freebXML
architecture comprises the three parts depicted in Figure 2: the Registry Client
Layer, the Registry Client API Layer and the Registry Server.
The Registry Client Layer depicts possible registry client types, which may
be represented by a Web browser with direct HTTP access for querying purposes
only, a thin client Web User Interface (UI) running within some Web container,
that can be accessed via a Web browser, a fat client Java UI running on a client
machine and a command line interface, e.g., in the form of an administration tool.
Instances of the last three client types are provided by the freebXML registry.
The Registry Client API Layer is the subsequent layer in the architecture.
It is represented by the JAXR API, which provides standard Java interfaces to
access the registry. The JAXR API requires a JAXR provider, which represents
an implementation of the JAXR API. The freebXML registry contains its own
JAXR Provider, which represents an advanced implementation of the JAXR
API.
Concerning the freebXML Registry Server, a HTTP and a SOAP interface
are provided. For browsing and discovery capabilities, the HTTP and the SOAP
interface offer a binding to the QueryManager interface, while the SOAP inter-
face also provides a binding to the LifeCycleManager interface for publishing
content. Furthermore, modifying access to the registry requires user authentica-
tion and authorization. For this, a security layer is part of the registry server.
In order to store content and metadata, an abstract persistence layer is defined
by the registry. For the actual storage of content and metadata, a relational
database management system (RDBMS ) is used. By default, freebXML makes
use of Apache Derby, which runs in the same Java Virtual Machine as the registry
server. To manage the persistence of the registry server and the repository items,
an SQL persistence manager interface and an repository manager interface are
provided, respectively.
A comprehensive presentation of the freebXML registry architecture is given
at the project’s Web page4 .
4.4 Prototypical Implementation
Based on the defined requirements, we have prototypically enhanced freebXML
as a generic SWS discovery framework. As SWS formalism, we make use of
SAWSDL and WSDL 1.1. Furthermore, we make use of a “query by example”-
approach, i.e., a SAWSDL description needs to be provided by the service re-
quester. In the following, the integration of SAWSDL into ebXML Registry, an
4
http://ebxmlrr.sourceforge.net/
Integrating Semantic Web Services and Matchmaking into ebXML Registry 9
Client Client
Web Browser ebXML Client
R R
HTTP Server HTTP Server
Web Container
Storage
ebXML
JAXR Provider
R
SAWSDL
R
LifeCycleManager SWSCataloger
R
Ontologies
Registry/ WSDL
Repository Cataloging Service
Fig. 3. Enhanced ebXML Architecture (Publishing)
interface for arbitrary matchmakers, and the utilization of an example match-
maker are presented.
Apart from freebXML, the following major software components have been
used in our prototypical implementation:
Apache Tomcat 5.0.28 is the Web container freebXML is deployed to,
Java JDK 5.0 Update 22 is deployed for enhancements of freebXML and the
development of a registry client, and
Apache HTTP Server 2.2 is used to store Web service descriptions and on-
tologies.
Integration of SAWSDL into ebXML Registry: For SAWSDL-based ser-
vice descriptions, a classification node SAWSDL has to be created in the registry;
as presented in Section 4.1, SAWSDL is derived from SWS. Generally, depending
on the type of content, an associated cataloging service, which extracts the re-
quired information from submitted services, is invoked on publication time. The
information is then mapped to instances of the ebXML RIM representing the
content’s metadata, while the actual content is stored within the repository,
In detail, by submitting SAWSDL documents to the registry, they are clas-
sified using SAWSDL. The LifeCycleManager (cp. Figure 3) of the registry makes
a call to the appropriate cataloging service associated with the SAWSDL object
10 Stefan Schulte et al.
type. For this, a new cataloging service SWSCataloger has been developed. On
invocation, the SWSCataloger first makes a call to the standard WSDL Cata-
loging Service of freebXML, which performs a normal publication of the WSDL
information associated with the SWS document.
Finally, the published WSDL information has to be associated with the
SAWSDL representation of the service. For this, ebXML provides the ability
to relate any two objects in the registry using arbitrary relationship types. The
resulting registry and repository objects are then passed to the LifeCycleMan-
ager, which submits the contents to the Storage database of freebXML.
org.freebxml.omar.server.query
QueryManagerImpl
submitAdhocQuery(...): AdhocQueryResponseType
<