A Framework for Semantic Web Service Retrieval

Doris Janssen1, Alexandre Lins1, Thomas Schlegel1, Michael Kühner1,

Gerhard Wanner2
1
Fraunhofer Institute for Industrial Engineering (IAO), Nobelstr. 12, D-70569 Stuttgart,
Germany
{Doris.Janssen, Alexandre.Lins, Thomas.Schlegel, Michael.Kuehner}@iao.fraunhofer.de
2
University of Applied Sciences, Schellingstr. 24, D-70174 Stuttgart, Germany
wanner@hft-stuttgart.de

Abstract. In this paper, we focus on the problem of retrieving semantic

information about web services. We develop a framework for bringing together
technologies of web service retrieval (as provided by UDDI) and languages of
semantic description of web services (as provided by OWL-S) and show the
application of such a framework.

1 Introduction

Web services have already proven their strength in providing organizations with
access to remote services that are hosted in as well as outside these institutions. This
rather basic but powerful functionality provides a basis for more advanced techniques
like the composition of web services, which will allow for the provision of complex
services that are assembled from existing “atomic” services.
It becomes clear that for composition within a dynamic web service environment,
there is a need for more than the currently available, rather syntactic and static meta
information and design time composition. Web services in a heterogeneous
environment often become unavailable, change versions or are replaced by other
services. Therefore, the rapidly changing landscape of web services needs
descriptions which allow the run-time search and inspection of web services to reach
the goal of dynamic search and composition.

2 Related Work

To support these goals of dynamic search and composition, some technologies are
already available: WSDL [1] and UDDI [2] are standards that are widely used in this
context, but they contain rather no semantics, that are needed for intelligent
combination of services. OWL-S [3] instead is a quite new OWL [4] ontology,
containing structures for storing semantic information about a web service, that would
2 Doris Janssen, Alexandre Lins, Thomas Schlegel, Michael Kühner, Gerhard Wanner

help to classify a web service and get information about what a service does and how
it works.
We think that intelligent retrieval and automatic composition of web services can
only be done using the more powerful abilities of a semantic description for web
services, as offered by OWL-S. Yet, these languages are the first step towards more
intelligent systems. In order to do the second step of retrieval and dynamic
combination of web services, some active modules are needed:
• Retrieval: A web service retrieval mechanism (similar to an UDDI-Requester)
could match semantic descriptions of web services with the request and then
retrieve the appropriate web service. While already first steps in this direction have
been accomplished [5], a common approach to access these directories
semantically is still missing.
• Invocation: Web service invocation engines could support the invocation of
services, check security issues, take part in service level agreements, etc..
• Composition: Planners could compose processes from different service
components and execute them.
While the problem of dynamic web service invocation seems to be solved (using e.g.
WSIF [6]) and there is currently a lot of work done for the composition of web
services (e.g. BPEL4WS, also some parts of OWL-S), regarding the retrieval of web
services other functionalities yet only basically implemented exist. For the problem of
retrieving services there are prototypic solutions and suggestions like “Matchmaker”
[7] and “Semantic Discovery Systems” [8], and for planning there has been developed
the “Web Service Composition Via AI Planning module” within IBM’s ETTK [9].
These are first prototypes to show concepts, and they still bring disadvantages with
them, like being stand alone or lacking public availability and acceptance.
Within ETTK of IBM, the “pluggable discovery framework” allows easy
combination of different, underlying retrieval mechanisms, like UDDI or WSIL [10].
Yet, this framework concentrates on realization of discovery mechanisms, without
using methods for semantic discovery that would be necessary to improve current
discovery methods.
In this article, we therefore present a framework for development and operation of
web services on the Java platform, where the different modules can simply be
plugged in. We will especially focus on an API for discovery and retrieval of Web
Services that implements the connection with different service discovery engines, and
that provides operations for semantic discovery of web services described by OWL-S.

3 Holistic Vision of the Framework

A framework that supports all activities needed to act with semantic java web
services, like shown in Figure 1, can help coping with the question of handling web
services semantically, even more when services are possibly described in different
languages. The SemanticServiceRegistryAPI (SSRA) is such a framework covering
retrieval and invocation as well as planning and dynamic combination of web
services.
 A Framework for Semantic Web Service Retrieval 3

P lanner
Agent 1 1:Call (Web S ervice
4:S ugges tion Combination)

5:Call 2:Call
Invocation Interface R etrieval Interface
Invocation E ngine R etrieval E ngine

3:S earch & E valuation

6:Call

Web S ervice Web S ervice Web S ervice

Agent 1.1 Agent 1.2 Agent 1.3

Fig. 1. Framework for operation of semantic web services.

A web service can make use of a planner service in order to synthesize complex
processes, combined out of different web services as suggested by [5]. For retrieving
web services, a retrieval module is provided, as well as an invocation module for the
act of invoking and negotiating quality of service. All modules are built to be used
separately as well as together and can be accessed via a web service interface. In this
paper, we will especially focus on the retrieval module.
The service discovery framework addresses the web service retrieval. It defines a
set of interfaces and associated methods that enables the developer to access Semantic
Web Services registries. It is designed to be open and therefore it is able to work with
different implementations of registry technologies. Moreover, it provides a set of
methods to perform query and update operations on the registry using a Java
representation of the OWL-S ontology. The implementation of the framework should
be able to manage connection issues, handle client requests and forward them to the
registry, process the responses and return the results back to the client.
The Java API for XML Registries (JAXR) [11] provides a basic framework for
accessing XML registries, which can be used to build upon. JAXR is composed of a
set of interfaces and associated methods for manipulating registry data objects and
perform operations on the registry. Moreover, the API is open, meaning that one can
provide specific implementations to access registries based on different technologies,
such as UDDI and ebXML [12]. A lack of JAXR is that the design constructs used to
represent registry objects are not fit to represent OWL-S constructs, so enhancements
have to be made. The service discovery framework leverages off the JAXR API to
provide a tool that enables the creation and management of OWL-S service
descriptions from a Java application. On one hand, the API takes advantage of some
of the design constructs provided by the JAXR API specification. On the other hand,
it provides a tool that is based on OWL-S concepts and therefore is more intuitive for
the developer accessing a semantic-based registry.
4 Doris Janssen, Alexandre Lins, Thomas Schlegel, Michael Kühner, Gerhard Wanner

4 Architecture of the service discovery framework

This paper focuses on the development of the service discovery framework. For such
a framework, different requirements exist:
• Object Model
For an integrated framework, a consistent object model (data types, etc.) is
important. It helps integrating the different modules and forms a common basis.
Within OWL-S, a XML data model for describing services semantically already
exists. This data model should therefore be used. So within the API an object
model has to be provided that represents the design constructs of OWL-S in Java
and allows the developer to manipulate these constructs.
• File Processing
Descriptions of services are usually stored in ordinary data files, for example in an
XML format. Therefore, the API has to provide functions regarding the processing
of the OWL files into the constructs defined in the object model and vice versa.
This includes design constructs that define methods for reading and writing
services, service profiles, service groundings and service models objects from and
to OWL files lying on the file system.
• Registry Operations
The main objective of the API is to provide the functionality to perform service
discovery and maintenance operations on remote registries. A requirement for the
API is therefore to provide design constructs and functions that allow the developer
to perform insertion, update, deletion and query operations on a remote registry.
The API must provide operations that are based on the object model to be defined
as part of the framework. An important point that must be mentioned regards the
granularity of the operations. A requirement here is that the API must provide
methods that allow the developer to perform insertion, update and deletion
operations for services, service profiles, service groundings and service models on
remote registries. Query operations that return collections of services, profiles,
groundings and models must also be provided by the API. The definition of
operations for these types of objects is important as they are the main design
constructs in OWL-S and in fact encapsulate the other constructs defined in the
ontology.
• Openness
As already discussed, a number of tools and technologies for the semantic web are
currently under research and development, including registries based on semantic
web technologies. For this reason, a requirement for the API is that it should be
open enough to provide implementations for the different types of OWL-S-based
registries that are to become available in the future. Openness is usually achieved
by the specification of interfaces that define a basic set of design constructs and
associated operations from which different implementations can be derived.
Openness also means to provide support for the configurability of the tool,
allowing the developer to use design constructs for configuring specific points of
the implementation without needing to change the program. As a result of this
requirement, the API will be able to support different technologies of registries.
 A Framework for Semantic Web Service Retrieval 5

• Extensibility
The OWL-S specification defines a basic ontology for the semantic description of
services. A requirement for the API then is that it must be extensible enough to
provide support for these new types and relationships to be created in the future.
Extensibility can be achieved by the provision of general objects from which the
new types can be derived, and the specification of methods based on these objects
that can be overridden to support the new constructs that are to be created.
• Security
Security is an important issue regarding applications that interact with remote
parties. Remote registries should implement mechanisms that allow them to verify
the identity of a client application and the operations they are allowed to perform.
On the other side, the clients must be able to provide the authentication and
authorization information that the registries need to authorize the operations to be
performed. The API must define constructs that support the configuration and
processing of authentication and authorization information. An important
requirement, though, is that these design constructs should be extensible enough to
provide support to the different authentication mechanisms supported by the
registries.
• Other Issues
As the API provides functionality to perform operations on remote parties, two
other important aspects are performance and reliability. Performance plays an
important role on performing remote functions as the network lying between the
parties slows down the execution of the operation. Also reliability is an important
aspect on remote operations. In fact, it is important for the system to guarantee that
messages sent between client and server do not get lost in the network for the
operations to get completed. The API does not provide support in its design
constructs to deal with aspects regarding performance and reliability, though.
Instead, it is up to the API implementer to guarantee that these requirements are
met according to the quality of the services they wish to provide in their
implementation, e.g. through caching and message timeout mechanisms.

Figure 2 presents the general organization of the service discovery framework. The
component on the top is a Java application that uses the framework to access different
remote registries. The framework is composed of two main modules. The first module
is a set of interfaces that are used by the Java application to perform operations on the
registries. The other module contains a set of one or more implementations of these
interfaces, which are responsible for carrying out operations on the registries.

Client
API
API Implementation

Registry

Fig. 2. Architecture of the discovery framework.

6 Doris Janssen, Alexandre Lins, Thomas Schlegel, Michael Kühner, Gerhard Wanner

This organization allows the developer to work with different implementations of

registries without needing to change the code. For example imagine the application
needs to access a registry whose communication is based on the HTTP protocol. In
the case an implementation of the framework that supports communication with
HTTP-based remote registries is available, the developer would only need to
configure the framework to work with this implementation, but the code that performs
the operations on the registry is kept unchanged. This characteristic is an advantage of
the framework, as there is no single standard for the development of registries based
on OWL-S at the moment, and registries that are implemented on the basis of
different technologies are expected to become available in the future.

4.1 Information Model

The information model is composed of a set of interfaces that are used to represent
OWL-S constructs inside a Java application. The idea is to provide an easy way to
manipulate these elements through the program and, at the same time, act as an
abstraction layer to hide the details of the XML constructs from the developers. The
interfaces are organized in the package de.fhg.iao.ws.owls.infomodel. Figure 3 shows
the class diagram for the information model.

Fig. 3. Class diagram for the information model.

The Service interface is used to represent the Service class defined in the OWL-S
specification. It basically defines methods that provide access to the ServiceProfile,
ServiceModel and ServiceGrounding interfaces. On the other hand, the ServiceProfile
and Profile interfaces have been defined to represent the ServiceProfile and Profile
classes that are described in the specification.
The Profile interface provides a set of methods that allows the developer to access
the various attributes of a profile. These attributes are represented in the model by the
interfaces Actor, ParameterDescription, ServiceCategory, and ServiceParameter. In
addition, the information model defines the interfaces Actor, GeographicRadius and
 A Framework for Semantic Web Service Retrieval 7

NAICS, which extend from ContactInformation, ServiceParameter and

ServiceCategory respectively, and just like them, other interfaces can be defined in
future that extend those interfaces.

4.2 Creating Service Descriptions

The framework defines constructs that allow developers to create service descriptions
using the interfaces defined in the information model described above. The first of
them is the ObjectFactory, an abstract class that defines factory methods the
developers can use to create the elements of a service description inside the Java
application. In addition to the more specific methods such as createService and
createServiceProfile, a generic method createObject is specified that allows for the
creation of other objects to be defined in the future. The code fragment below shows
how the factory is used.
ObjectFactory factory = ObjectFactory.newInstance();

Service service = factory.createService();

The other mechanism provided by the framework is the abstract class FileProcessor.
This class defines methods that allow the developer to transfer OWL-S service
descriptions from the files located in the file system to the objects in the application
and write them back if necessary. More specifically, it defines methods to read and
write services, profiles, service models and groundings descriptions. Furthermore, the
class defines properties and associated access methods which enable the developer to
configure the file processor characteristics, such as the XML parser to be used for file
processing. The code below shows how the file processor is used.
FileProcessor fileProcessor =
FileProcessor.newInstance();

Collection profiles =
fileProcessor.readServiceProfiles(profileFilename);

4.3 Connection Management

The term connection management is used to describe the tasks related to the
establishment of connections with remote parties. Connection establishment is an
important step because it allows partners to negotiate communication details such as
protocols, security issues, message format, and mode of communication. Based on the
constructs defined in the JAXR API, this framework defines a set of interfaces and
classes that abstracts the developer from connection management details, by
providing a set of specific methods that deal with the issues described above. Figure 4
shows the class diagram for the connection management model.
8 Doris Janssen, Alexandre Lins, Thomas Schlegel, Michael Kühner, Gerhard Wanner

Fig. 4. Class diagram for connection management.

Figure 4 shows the abstract class ConnectionFactory that is responsible for creating
connections. Moreover, the class provides methods to set and get general properties of
the connection, ensuring an easy configuration of the framework allowing for the
configurability of the framework. Connections are represented by the Connection
interface that defines methods for managing connection issues such as authentication
information and communication mode. Finally, a RegistryService interface is defined
that specifies methods that give access to registry operations. These operations are
actually defined on another set of interfaces to be discussed ahead. The code below
shows how to create a connection using the framework.
ConnectionFactory connectionFactory =
ConnectionFactory.newInstance();

Properties properties = new Properties();

properties.setProperty("registryUrl",
"http://localhost:8080/RegistryServer");

connectionFactory.setProperties(properties);

Connection connection =
connectionFactory.createConnection();
The connection management model itself provides a clear separation between
configuration, connection management and registry functionality issues. Furthermore,
it allows the framework to support different types of registry technologies. Most
important though, is that it abstracts the developer from implementation details. The
developer does not need to program and maintain these modules as they are already
 A Framework for Semantic Web Service Retrieval 9

provided by the framework. In addition, if the application needs to interact with a

registry that was developed based on some other technology, the developer does not
need to change his program. He will only need to search for an implementation that
supports that specific registry technology and change the configuration properties of
the factory to work with this new implementation.

4.4 Life cycle Operations

Life cycle operations are used for operations regarding the creation, update and
deletion of objects on a remote registry. The JAXR API defines a pair of interfaces
related to life cycle management that can be accessed through the RegistryService
interface. Following the JAXR model, the framework defines a set of interfaces
regarding life cycle operations, making adaptations whenever necessary. Figure 5
shows the class diagram for the life cycle management model.

Fig. 5. Class diagram for life cycle management.

The interface RegistryService provides access to a BusinessLifeCycleManager

interface that defines specific methods for performing save and delete operations on
remote registries. Moreover, a LifeCycleManager interface is defined that specifies
generic methods to save and delete objects, which provides extensibility for the
framework by allowing the developer to save and delete different types of objects that
may be created in the future. The provision of these methods eliminates some of the
work the developers would have to do for performing operations on the registry,
including building the request and processing the responses that are returned
according to the different registry technologies. The code below shows how a service
profile description can be saved using the framework.
RegistryService registryService =
connection.getRegistryService();

BusinessLifeCycleManager lifeCycleManger =
registryService.getBusinessLifeCycleManager();
10 Doris Janssen, Alexandre Lins, Thomas Schlegel, Michael Kühner, Gerhard Wanner

BulkResponse response =
lifeCycleManger.saveServiceProfiles(profiles);

4.5 Query Operations

The framework must provide functionality for querying service descriptions. Figure 6
shows the class diagram for the query model for the framework.

Fig. 6. Class diagram for query management.

The figure shows a RegistryService that provides access to the

BusinessQueryManager and DeclarativeQueryManager interfaces. The interface
BusinessQueryManager defines methods that allows the developer to perform specific
find operations on the registry that search for services, profiles, service models, and
service groundings descriptions, based on a profile object and filters that are
submitted as parameters to the call. The interface DeclarativeQueryManager, on the
other hand, defines methods to perform declarative queries on the registry; in case the
registry would support declarative languages such as DQL [13]. The code fragment
below shows how to search for service descriptions using the framework. The
requester provides a profile to be matched and optionally a collection of filters that
are supported by the registry implementation and that can be used to refine the search.
BusinessQueryManager queryManager =
registryService.getBusinessQueryManager();

BulkResponse response =
queryManager.findServices(profile, filters);

Collection services = response.getCollection();

For defining find methods that allow the developer to query for any type of objects
based on the identification of these objects, the QueryManager interface is used. The
QueryManager plays a key role on the extensibility of the framework, allowing to
search for new types of objects that were not included for search in the specification.
 A Framework for Semantic Web Service Retrieval 11

4.6 Responses and Exceptions

The proposed framework follows the response and exception model defined in the
JAXR API. This model specifies the BulkResponse interface that encapsulates
responses and exceptions returned by the registry. It defines methods that allow the
developer to access a collection of objects sent by the registry as response and a
collection of exceptions. The model also defines the RegistryResponse interface that
allows the developer to check the ID of the request that generated the response and
the status of the response. Figure 7 shows the class diagram for the response model.

Fig. 7. Class diagram for response model.

The features defined in the RegistryResponse interface are important because they
provide support for asynchronous communication. This means that in the case of an
operation taking a lot of time to execute, the application does not need to block
waiting for the response. It can get the ID of the request provided by the
RegistryResponse and use it to check the response later on, using a method defined in
the RegistryService. The developer can use the status information or a specific
method to check if the response is already available. The code fragment below shows
how this can be done.
BulkResponse response =
lifeCycleManager.saveServiceProfiles(profiles);

String requestId = response.getRequestId();

...

BulkResponse response =
registryService.getBulkResponse(requestId);

Collection serviceIds = response.getCollection();

In addition to the response model, an exception model has been defined that is slightly
different from the one defined in the JAXR API. It basically defines a
12 Doris Janssen, Alexandre Lins, Thomas Schlegel, Michael Kühner, Gerhard Wanner

RegistryException that is used to represent exceptions occurred during operations on

the registry. This exception extends the JAOException that is used to represent more
general exceptions. Finally, an UnsupportedOperationException that also extends the
JAOException has been defined to represent operations not supported by a remote
registry.

5 Implementation

A proof-of-concept implementation of the framework has been developed that

provides the basic functionality defined in the framework specification. As there is no
registry based on OWL-S technology available, the first implementation of the
framework is based on an UDDI registry and some basic reasoning operations have
been coded inside the framework itself only for testing and demonstration purposes.
For developing an application using this specific implementation of the framework,
the developer uses the design constructs of the framework for creating, reading and
writing OWL-S service descriptions and to connect to the remote UDDI registry to
perform save, delete and query operations. In the implementation layer, JAXR is used
for connectivity and for operations on the registry. When a save or delete operation is
called, the framework implementation translates the OWL-S objects into
JAXR/UDDI objects and uses the API to carry out the operation. Later, when the
results of the operation are returned from the registry, the implementation reads them
and translates them into objects defined in the framework.
The implementation shows that realizing the design constructs defined in the API
specification is viable, and that a number of different implementations is actually
possible.

6 Conclusion

In this paper we have presented a Java framework for the discovery of Web Services
using registries based on OWL-S descriptions.
The overall idea behind this concept is to allow for semantic discovery and
retrieval of web-services using ontology standards and mechanisms that have been
and still are created by the semantic-web community. Such an integrative approach
forms a main step towards autarkic and self-organizing web-services, which compose
new services from existing ones worldwide by handling requests received from users
or other systems.
As a framework for such systems has to support different purposes and allow
interoperability and general interconnection, it should integrate semantic functionality
like OWL and OWL-S directory information and interpretation. For sure, a sole
OWL-S description for a web service in most cases will not suffice, additional
descriptions in other OWL dialects are necessary to describe a service fully. Our
approach is therefore, using JAXR as a standard, to provide an API that enables
developers to create and manipulate OWL-S service descriptions and perform
operations on remote registries. To accomplish this, the framework takes advantage of
 A Framework for Semantic Web Service Retrieval 13

the basic design constructs of JAXR that provide support for connection, life cycle
and query management, thus expanding and adapting a standard interface for these
specific requirements.
This organization itself is a great advantage of the framework as it separates the
concepts of connection management, life cycle operations and query operations on
specific interfaces and abstracts the developer from implementation details. In
addition, the framework provides a set of interfaces and associated methods for
representing and manipulating OWL-S constructs inside a Java program, including
reading and writing service descriptions on the file system and other data sources and
sinks. As in practice domain specific OWL ontologies will be used in conjunction
with OWL-S descriptions, which makes necessary further research and
standardization activities concerning the question how to integrate these ontologies
without having to adapt the API each time new domains are introduced.
While UDDI has been chosen as the web service registry at the moment, the ability
to use UDDI semantically is very limited even though in version 2.0 and 3.0 some
improvements have been made. Taxonomies, which can be included in an UDDI
registry, offer some possibilities like inheritance retrieval, when the taxonomies used
are well-defined for that purpose. Further mechanisms are currently not available. As
soon as intelligent mechanisms like reasoning are needed, current specifications of
UDDI provide no more support. This leads to the suggestion of focusing on the
development of a semantic based registry standard in the near future. The
development and standardization of such a dedicated registry will be crucial for broad
access to the possibilities of semantic retrieval of web services.

7 Future Work

The next steps will be the improvement of the framework by reviewing and
improving the design constructs and fulfilling the need for including new methods for
accessing OWL-S registries. The specification and implementation are currently
being adapted to work with OWL-S version 1.0. Another important step is to provide
an implementation based upon a Matchmaker engine or an UDDI enhancement like
suggested by Akkiraju [5], as the current version is based on standard UDDI
registries. The ServiceModel and ServiceGrounding interfaces will be further
developed to provide a basis for invocation and composition modules. Finally, a
toolkit will derive from the combination of these modules and will allow the
developer to operate Semantic Web Services from a Java application.
The current results are available to the public as an open source project on
http://ssra.sourceforge.net.

Acknowledgements

This research has been conducted by the KOMPASS project, which is supported by
the German Ministry of Education and Research (BMBF).
14 Doris Janssen, Alexandre Lins, Thomas Schlegel, Michael Kühner, Gerhard Wanner

References

1. Christensen, E., Curbera, F., Meredith, G. and Weerawarana, S.: Web Services Definition
Language (WSDL) 1.1. Available at http://www.w3.org/TR/wsdl, 2001.
2. UDDI.org: The UDDI Technical White Paper. Available at
http://www.uddi.org/pubs/Iru_UDDI_Technical_White_Paper.pdf, 2000.
3. Martin, D., Burstein, M., Denker, G., Hobbs, J., Kagal, L., Lassila, O., McDermott, D.,
McIlraith, S., Narayanan, S., Paolucci, M., Parsia, B., Payne, T., Sirin, E., Srinivasan, N. and
Sycara K.: DAML-S and OWL-S 0.9 draft Release. Available at
http://www.daml.org/services/daml-s/0.9/, 2003.
4. Bechhofer, S., Harmelen, F., Hendler, J., Horrocks, I., McGuiness, D., Patel-Schneider, P.
and Stein, L.: OWL Web Ontology Language Reference. Available at
http://www.w3.org/TR/owl-ref/, 2003.
5. Akkiraju, R., Goodwin, R., Doshi, P. and Roeder, S.: A Method for Semantically Enhancing
the Service Discovery Capabilities of UDDI. Available at http://www.isi.edu/info-
agents/workshops/ijcai03/papers/Akkiraju-SemanticUDDI-IJCA%202003.pdf, 2003.
6. Duftler, M. J., Mukhi, N. K., Slominski, A. and Weerawarana, S.: Web Service Invocation
Framework (WSIF). Available at http://www.research.ibm.com/
people/b/bth/OOWS2001/duftler.pdf, 2001.
7. Kawamura, T., Paolucci, M., Payne, T. and Sycara K.: Semantic Matching of Web Services
Capabilities. In: Proceedings of the 1st International Semantic Web Conference (ISWC),
2002, pp. 333-347.
8. Mandell, D. and McIlraith, S.: Adapting BPEL4WS for the Semantic Web: The Bottom-Up
Approach to Web Service Interoperation. In: Proceedings of the Second International
Semantic Web Conference (ISWC2003), 2003, pp. 227--241.
9. Emerging Technologies Toolkit, IBM alpha Works Emerging Technologies, IBM
Corporation, Available at http://www.alphaworks. ibm.com/tech/ettk, 2004.
10.Ballinger, K., Brittenham, P., Malhotra, A., Nagy, W. A. and Pharies, S.: Web Services
Inspection Language (WS-Inspection) 1.0. Available at http://www-
106.ibm.com/developerworks/webservices/library/ws-wsilspec.html, 2001.
11.Najmi, F.: Java API for XML Registries (JAXR) version 1.0. Available at
http://java.sun.com/xml/downloads/jaxr.html, 2002.
12.ebXML: ebXML Technical Architecture Specification v1.0.4. Available at
http://www.ebxml.org/specs/ebTA.pdf, 2001.
13.Fikes, R., Hayes, P. and Horrocks, I.: DAML Query Language (DQL) Abstract
Specification. http://www.daml.org/2003/04/dql/dql, 2003.