A Framework For Semantic Web Service Retrieval

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 [email protected]

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

Agent 1

1:Call 4:S ugges tion

P lanner (Web S ervice Combination)

5:Call Invocation Interface

R etrieval Interface

Invocation E ngine

R etrieval E ngine

6:Call

Web S ervice Agent 1.1

3

2:Call

3:S earch & E valuation

Web S ervice Agent 1.2

Web S ervice 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/infoagents/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://www106.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.