The software reads service descriptions from various sources, matches a request against a service, and composes a com- plex service from atomic services.
Toward Semantic Composition of Web Services with MOVE J¨urgen Dorn
Albert Rainer ec3 - Electronic Commerce Competence Center Donau-City Strasse 1, Vienna {juergen.dorn, albert.rainer, peter.hrastnik}@ec3.at}
Peter Hrastnik
Abstract This paper describes a software solution for the WSChallenge 2006. We introduce the MOVE framework that has been applied to this challenge. Also, the architecture, algorithms, and software components are discussed. The software reads service descriptions from various sources, matches a request against a service, and composes a complex service from atomic services. The framework is open and different kind of solvers and reasoning tools can be plugged in. We show an example which uses the Answer Set Programming software DLV [1][3] as solver for the composition task.
Figure 1. Architecture of the MOVE framework.
2.1. WSDL Reader
1. Introduction MOVE is a framework for the design and execution of business processes in virtual enterprises. The framework is based on Java, open-source components and the Eclipse development environment. Processes are modeled graphically and transformed into an executable representation. Main focus is laid on Web service integration. For the semantic part of the WS-Challenge 2006, we have extended the framework in such a way that it can deal with basic semantic aspects such as subclass relationships.
2. Architecture The architecture encompasses the components WSDL Reader, Repository Handler, Discoverer, Composer, and Transformer. The framework is itself a Web service based on WSDL and SOAP and can easily be integrated into other environments. Figure 1 illustrates the architecture of the software agent. Java interfaces describe the functionality of each component. The particular code that implements a component is exchangeable as long as it complies with the Java interface of the according component.
The WSDL Reader component reads WSDL documents and converts the WSDL info to a Java data structure. Based on the concrete implementation, WSDL documents can be read from various sources. Files on a local file system, resources that can be described by URIs, and other sources such as UDDI are possible.
2.2. WSDL repository handler The WSDL repository handler component offers comfortable access to a set of WSDL data by employing the Iterator design pattern. We implemented two different repository handlers for different repository sizes. One loads all documents at program start. This is suitable for small static repositories only. The other handler is for large dynamic repositories that “lazy-loads” WSDL documents just before they are needed.
2.3. Discoverer The discoverer is responsible for finding Web services that match a request. As described in [2], a match can be either of type exact, plug-in, subsumes, or fail. An exact
match describes the situation where a service fulfills all requirements exactly. A situation where a service exceeds the requirements is called plug-in match. A subsumes match occurs whenever a service does not fulfill the requirements completely and additional means are required in order to use the service. Finally, a matching request can fail at all if the considered service does not comply to any of the requirements. Note, that this describes the case where the output of a service provider has to fulfill the requirements. For the input side of the service the situation is reversed, that is, the service is the requester and the appropriate input has to be provided. Figure 2 illustrates these concepts. It shows a service with input and output parts and their respective data types.
%inertia has(D,T1):-has(D,T),not -has(D,T1),#succ(T,T1). %guess actions a0(T) v -a0(T):-has(X,T),isa(X,name). has(clientid,T1):-a0(T),#succ(T,T1). a1(T) v -a1(T):- has(X,T),isa(X,clientid). has(euAddress,T1):-a1(T),#succ(T,T1). %end guess actions %types: thing is abstract supertype isa(name,thing). isa(clientid,thing). isa(address,thing). isa(euAddress,address). isa(usAddress,address). isa(bigname,name). %class hierarchy inference isa(X,X):-isa(X,Y). isa(X,Z):-isa(X,Y),isa(Y,Z). %costs, each action costs 1 unit :˜a0(T).[1:1] :˜a1(T).[1:1] %initial has(bigname,0). goal:- has(X,T),isa(X,address). % goal constraint, omit solutions without goal :-not goal.
This piece of code shows (part of) a planning example that uses a type hierarchy. Provided is type bigname and requested is an address. Action a0 accepts bigname (since it is a name) and asserts clientid. Action a1 delivers euAddress which is accepted by the goal since it is also an address. Figure 2. Illustration of matching services to provided/requested types. The service will be satisfied if it gets the exact type or a type that extends the input type (parts 1,3 on input). However, it is considered a failure if the provided type subsumes the input type (part 2 on input). On the other side, the requester will not be surprised when it gets the same or an extended type from the service (part 1,2 on output), but it will treat a result as failure when the delivered type subsumes the requested type (part 3 on output).
2.4
Composer
The composer component consists of an interface that provides a generic compose method with provided and resultant data as well as a reference to the discoverer component as parameters. Thus, the interface abstracts from the actual composer implementation. For instance, the goal in the Web service composition challenge is to combine services together only with respect to their inputs and output types and these types are accumulated until the request is fulfilled. In order to solve such a problem a fast but relatively simple search procedure can be plugged-in. If services depend on a certain state of the world and can alter this state a more complex planning algorithm has to be applied to deal with this problem.
2.5. Transformer The transformer generates various representations of the composer’s results like XPDL or BPEL4WS transformations (for Web service processes) or SVG representation to view the result in a two-dimensional vector graphic.
3. Conclusion In this paper, we introduced how we created a solution for the challenges of finding and composing Web services within the MOVE framework. First, our solution allows to look up service descriptions from arbitrary sources. Second, we have defined an interface that allows to plug in solvers that perform the task of composing complex services from elementary ones for a given/required input/output. Finally, our solution is not a stand-alone research prototype but embedded in MOVE, a comprehensive Web service framework
References [1] T. Eiter, W. Faber, N. Leone, and G. Pfeifer. Declarative problem-solving using the DLV system, pages 79–103. Kluwer Academic Publishers, Norwell, MA, USA, 2000. [2] M. Paolucci, K. P. Sycara, and T. Kawamura. Delivering semantic web services. In WWW (Alternate Paper Tracks), 2003. [3] A. Rainer. Web Service Composition using Logic Programming. PhD thesis, Vienna University of Technology, 2006.
