Towards Automatic Selection of Web Services Using ... - CiteSeerX

Towards Automatic Selection of Web Services Using Graph Transformation Rules Jan Hendrik Hausmann, Reiko Heckel, Marc Lohmann Faculty of Computer Science, Electrical Engineering and Mathematics University of Paderborn Warburger Str. 100 33098 Paderborn {hausmann, reiko, mlohmann}@upb.de

Abstract: The Web service architecture promises to be highly dynamic. The idea is that a service requester can discover a needed service at runtime. Due to the fact that this discovery process relies on a semantic understanding of the offered services, it is presently performed manually at development time only. In this paper we propose to use graph transformation rules to describe the semantics of Web services. These rules provide precise semantic specifications needed for an automated service discovery in a visual and intuitive way.

1

Introduction

The Internet, or more specifically the WWW, offers a virtually unlimited source of information and services to a skilled human user. We can translate texts, get information on the temperature in holiday resorts, book flights, and order travel guides without once leaving the computer. Even more amazing is the fact that we do not even have to know who will offer us these services. Knowing Google will usually suffice to quickly find offers for our needs. The ultimate vision of Web services is to transfer this ability to programs. These programs should be able to locate and invoke services at runtime over the net to meet their own goals. This encompasses two problems: how to find these services and how to use them. In this paper, we will focus on the problem how to find them. Current Web technologies already enable much of the discovery process: The interface of an offered service (usually a method to be invoked) can be specified in the Web Service Description Language (WSDL) [CGMW02]. This specification along with some keywords describing basic information about a Web service can be registered at a central UDDI-server [CJ02]. This registry serves as a central information broker and supplies information on possible service providers to the requests of clients. If we drill down into the actual discovery process, we note some intriguing problems: Let us suppose we need a Web service to order a certain book. We would manually formulate this as a search request order book or bookstore online or buchladen if we were searching

for a German bookstore. Now how does an automated service pose its requirements towards the service registry? How do we make sure that its keywords match the ones used in the service description? How do we formulate a request? Moreover, if we do get results (see below) from several providers that claim to be a bookstore, which one do we invoke? • integer placeOrder(ISBN:Int, Address:String, CCData:Int) • integer placeOrder(ISBN:Int, Address:String, BankAcc:Int) A human might intuitively grasp what these methods do and some additional text might reveal that the method placeOrder actually returns an order number which we might want to keep. And even if our program would be smart enough to find book stores that offer a method placeOrder to order a book, could it choose the store that offers to pay by credit card? Nowadays these questions are answered in a rather straightforward way: A developer queries a UDDI-server for a service, selects a suitable service from the results and integrates the invocation of this service into his program (this is supported e.g. by WebSphere Studio [Fl03]). At runtime, the program can only try to execute the selected service. If this service is not available, e.g. due to network problems, the program cannot even automatically discover identical replacement services. This is quite far from the idea of dynamically discovering adequate services. In this paper, we will introduce ideas towards this advanced kind of service discovery. We will use ontologies to specify a shared and common understanding of a domain (Sect.2) and we will describe how to define contracts referring an ontology by using graph transformation rules (Sect.3). A contract defined by a service provider describes the semantics of a Web service. A contract defined by a service requester describes the semantics of a service the requester is searching for. To allow querying for a service automatically we will introduce ideas for criteria to decide automatically whether a contract of a service provider fulfills the requirements of a service requester. We will focus on a graphical notation to explain our ideas and refer to corresponding web technologies to indicate possible realizations.

2

Sample Ontology

Ontologies are a key enabling technology for the semantic web and thus for the automatic selection of Web services. “Ontologies are formal and consensual specifications for conceptualizations that provide a shared and common understanding of a domain, and communication that can be communicated across people and application systems” [FB03]. In the context of Web services, we use ontologies to describe the domains that are of interest for providers and requesters (e.g., business areas or technical domains). In particular, ontologies solve the problem of using the same keywords in service descriptions and requests. Fig. 1 shows a simplified ontology for ordering books. Ontologies are typically expressed in textual semantic web languages like RDF [LS99] or DAML+OIL [CvHH+ 01]. These

Ontology

Order

Bill 1

1 1 DeliveryAdress

1

PaymentMethod

payBy 1

1

1 * Book

BankTransfer

CreditCard

Figure 1: Ontology for selling products

languages are optimized for automated processing and not for intuitive understanding by a human user. The Unified Modeling Language (UML [Ob01]) on the other hand is the visual standard notation in Software Engineering and its class diagrams are widely accepted for visualizing domain concepts and structures (like ontologies). It is thus preferable to confront users (like the developer) with a UML representation of the ontology and employ automated transformations to the machine-readable languages (e.g. [BKK+ 01]). The same idea underlies our approach to employ graph transformations to specify the semantics of Web services (see next section). Again, we use an intuitive visual notation to represent the concepts that can later be encoded into text-based web languages like WSDL. Although existing semantic web languages like DAML+OIL or OWL are not developed to express rules there is research going on to develop rule languages like DAML-L or RuleML that are based on RDF.

3

Extending Ontologies with Rules

The semantic description of a Web service represents a contract specifying the meaning and purpose of a Web service [CFNO02]. According to [FB03] a contract consists of a pre- and a post-condition. The pre-condition characterizes the situation before some behavior is executed (i.e. the requirements) and the post-condition characterizes the situation after the execution of the behavior, i.e. its effects. Such a contract can be visualized using the formalism of graph transformation rules (see Fig. 2 for an example). The left hand of the rule encodes the pre- , the right hand side the post-conditions. Both sides are given here as object diagrams typed over the given ontology. In the context of Web services both the provider offering a service and the client requesting a service have to formulate a contract. The following paragraphs subsequently deal with the contract of the provider, the contract of the client and the matching of the two. A provider can use contracts to specify the semantics of its offered services. The preconditions of this contract specify the information that must be provided for the service to execute sucessfully. Regard the example in in Fig. 2. This Web service for ordering books expects information about a credit card, a book and a delivery address as its input. In the postconditions the contract specifies the effects of the service invocation: An order for the

Provider Rule specified book and a bill for this order are created. We can see that the service behaves like we intuitively expected from its name (and gain the additional information that this service requires us to pay by credit card). For an automatic match, these expectation also have to be formalised using contracts on the client side. ccp : CreditCard

ccp : CreditCard

op : Order

bp : Book

dap : DeliveryAdress

bp : Book

bip : Bill

dap : DeliveryAdress

Figure 2: Example rule to describe the semantics of a Web Service

A service requester has to describe the service it is searching for on a semantical level, i.e. it must specify what the service should do. In the case of a service requester, the pre-conditions describe the information the service requester is willing to deliver as input to a service. In the example in Fig. 3 information about the book, the delivery address and the credit card is offered. The post-condition describes what the service requester expects as consequences of a Web service call from a service provider: An order that contains a product and a delivery address. This is a minimal demand of the service requester to order a book. The bill is not part of the postconditions as we are primarily interested in ordering a book (paying for it is a kind of unwelcome side effect from the client’s point of view). Another example for a client rule can be found in Fig. 4. In this rule the client also offers information about its bank account to facilitate payment by bank transfer.

Client Rule (Post of client is subset of Post of provider):

ccr1 : CreditCard

ccr1 : CreditCard

or1 : Order

br1 : Book

dar1 : DeliveryAdress

br1 : Book

dar1 : DeliveryAdress

Figure 3: Example rule 1 of a service requester

To decide automatically which contracts of a service provider fulfill the demands of a service requester, an algorithm has to compare the pre- and post-conditions described by both the service requester and the service provider. A fundamental requirement for this comparison is that client and provider rules are typed over the same ontology, i.e. they have the same understanding about concepts like order or book. If we compare the contracts of Fig. 2 (provider rule) and Fig. 3 (request) we note that the client provides every information the service requires (book, address and credit card). The service in turn produces all the results expected by the client (creation of the order). We can formalize this by using

Client Rule (Pre of client is superset of provider, and Post also):

btr2 : BankTransfer

ccr2 : CreditCard

btr2 : BankTransfer

ccr2 : CreditCard

or2 : Order

br2 : Book

dar2 : DeliveryAdress

br2 : Book

dar2 : DeliveryAdress

Figure 4: Example rule 2 of a service requester

subgraph relationships: If the preconditions of the provider are a subgraph of the preconditions of the client then the client provides all the information necessary to run the web service (and possibly some additional items). If the postcondition of the client is a subgraph of the postcondition of the provider then the service generates all effects expected by the client plus possible additional results (the service provider creates a bill that has to be paid by credit card). This subgraph relation can e.g. be proved by using tool support for testing the entailment-relation as specified in the RDF Semantics specification [Ha03] if the contracts are described with RDF. However, to decide whether a contract offered by a service provider fulfills the requirements of a service requester it is often not sufficient to prove simple subgraph relations. The service requester rule in Fig. 4 is almost the same as the rule in Fig. 3, but the service requester offers additionally a BankTransfer-object. In this case, the requester is willing to pay the order either by credit card or by bank transfer. Again, the left side of the rule of the service provider is a subgraph of the left side of the rule of the service requester. The problem using simple subgraph relations is that the right side of the rule of the service requester in Fig. 4 is not a subgraph of the right side of the rule of the service provider. Yet, the contract offered by the service provider intuitively fulfills the requirements of the service provider. The service requester only added additional information (BankTransfer), but he does not specify how a service provider has to handle this additional information. For an automatic decision, we have to decompose the graphical rules into a post-condition describing only the effects of an operation and a separate pre-condition describing the requirements. Therefore, we remove from the right side of a rule all objects that that are not modified (in the case of the requester rule the objects BankTransfer and CreditCard). This structure corresponds to a graph transformation rule with application conditions [HHT96].

4

Summary

In this paper, we sketched an approach to advance the service discovery by defining contracts based on an ontology on the provider as well as on the requester side. In particular, we explained our ideas of defining contracts with a proper visualization. Furthermore, we defined basic criteria to decide whether a contract offered by a service provider fulfills the requirements of a requester or not. The techniques proposed here serve to enable a fully

dynamic discovery of adequate Web services as a developer must only specify the client contract at development time and matching service providers can be detected at runtime. By using ontologies, it is ensured that all participants use the standardized terminology of a domain. Services within this domain can then be described by assembling contracts out of the ontology’s elements without the need for a complicated standardization of these services. Future work this topic includes a detailed refinement of the criteria to decide automatically whether a provider fulfills the requirements of a requester and a corresponding implementation based on semantic web languages. Other important questions are how to integrate this development of contracts into a development process and how to relate the semantic descriptions of a service with its function-based specifications like WSDL.

References [BKK+ 01]

Baclawski, K., Kokar, M. K., Kogut, P. A., Hart, L., Smith, J., III, W. S. H., Letkowski, J., und Aronson, M. L.: Extending uml to support ontology engineering for the semantic web. In: Gogolla, M. und Kobryn, C. (Hrsg.), UML 2001. LNCS. Springer-Verlag. 2001.

[CFNO02]

Champion, M., Ferris, C., Newcomer, E., und Orchard, D.: Web Service Architecture, W3C Working Draft. 2002. http://www.w3.org/TR/2002/WD-ws-arch-20021114/.

[CGMW02] Chinnici, R., Gudgin, M., Moreau, J.-J., und Weerawarana, S.: Web Services Description Language (WSDL) Version 1.2 Part 1: Core Language. 2002. http://www.w3.org/TR/wsdl12/. [CJ02]

Colgrave, J. und Januszewski, K.: Using WSDL in a UDDI Registry, Version 1.08. 2002. http://www.oasis-open.org/committees/uddi-spec/doc/bp/uddi-spec-tc-bpusing-wsdl-v108-20021110.htm.

[CvHH+ 01] Connolly, D., van Harmelen, F., Horrocks, I., McGuinness, D. L., Patel-Schneider, P. F., und Stein, L. A.: DAML+OIL (March 2001) Reference Description. 2001. http://www.w3.org/TR/daml+oil-reference. [FB03]

Fensel, D. und Bussler, C. The web service modeling framework. 2003.

[Fl03]

Flurry, G.: Web Services Development and Deployment with WebSphere V5 Tools and Technologies – Part 2: Publishing and Finding a Web Service in a UDDI Registry. 2003. http://www7b.software.ibm.com/wsdd/library/techarticles/0302 flurry/flurry2.html.

[Ha03]

Hayes, P.: RDF Semantics. 2003.

[HHT96]

Habel, A., Heckel, R., und Taentzer, G.: Graph grammars with negative application conditions. Fundamenta Informaticae. 26(3,4):287 – 313. 1996.

[LS99]

Lassila, O. und Swick, R. R.: Resource Description Framework (RDF) Model and Syntax Specification. 1999.

[Ob01]

Object Management Group. UML specification version 1.4. April 2001. http: //www.celigent.com/omg/umlrtf/.