Web Service Discovery and Composition with MOVE Jürgen Dorn ec3 - electronic commerce competence cente
[email protected]
Peter Hrastnik ec3 - electronic commerce competence center
[email protected]
Abstract This paper describes how a software solution of the EEE-05 challenge can be integrated in the MOVE framework. It introduces the MOVE framework and relates the EEE-05 challenge solution and the MOVE framework. The solution’s software components and architecture is introduced as well as the used algorithms. In addition, a suggestion for a reasonable further component that uses the EEE-05 challenge solutions is given.
1. MOVE1 Framework MOVE is a framework for designing and execution of processes in virtual enterprises. The framework is based on Java, open-source components and the Eclipse development environment. Main focus is laid on Web service integration. Processes are modelled graphically and transformed into XPDL. XPDL processes are executed with a workflow engine. A Web service is an activity in an XPDL process. We have defined specialized Web services called infrastructure Web services [3] that provide common services in a Web service integration framework. Frequently used infrastructure Web services include for example the transformation of XML documents and the discovery of Web services at process run-time. A further infrastructure Web service is the composition of Web services from discovered Web services. We developed the solution for the EEE-05 challenge in the MOVE framework by providing new infrastructure Web services.
2. Components For the contest we use infrastructure Web services that depend on additional components that encapsulate access to WSDL documents. Amongst various operations on a set of WSDL documents, the discoverer infrastructure Web service detects single Web services based on provided parts and resultant parts as requested in the contest also. The composer infrastructure Web service uses the discoverer to compose several Web services as requested in the contest. The composer can use the Web service interface of the discoverer. However, because of performance reasons we prefer direct 1
MOVE is an acronym for Management and Optimization of Virtual Enterprises.
Albert Rainer ec3 - electronic commerce competence center
[email protected]
Java function calls (i.e. the composer and the discoverer run in the same Java Virtual Machine) for the contest. S Transformer O Composer A P Discoverer WSDL Repository Handler WSDL Reader
UDDI
Files
Internet URI
URI
Figure 1: Components Figure 1 illustrates the architecture of the software agent. We partitioned the software in multiple layers, whereas each layer uses the functionality of the layer(s) that is (are) directly beneath it. Java interfaces describe the functionality of each layer. The particular code that implements a layer is exchangeable as long as it complies with the Java Interface of the according layer.
2.1. WSDL reader The WSDL reader layer 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 filesystem, resources that can be described by URIs (e.g. WSDL documents in the internet) and many other sources are possible. The method how the WSDL information is transferred to a corresponding Java datastructure is not predetermined as well. For the EEE-05 challenge, we implemented a WSDL reader that reads files from the local filesystem and uses WSDL4J [4] to transfer WSDL information to a Java data structure. WSDL4J is a library that complies with the JWSDL [1] standard. JWSDL provides a standard for Java APIs that can be used for representing, manipulating, reading and writing WSDL. Future implementations may consider UDDI and URI sources and may use specialized SAX parsers instead of the extensive WSDL4J library for performance reasons.
2.2. WSDL repository handler The WSDL repository handler layer offers comfortable access to a set of WSDL data by employing the Iterator design pattern [2]. We implemented two differ-
ent repository handlers for different repository sizes. One loads all WSDL documents at program start a priori. This is suitable for small static repositories only. Thus, we developed an implementation for large dynamic repositories that “lazy-loads” WSDL documents just before they are needed. Because of performance reasons, we consider also repository handlers that incorporate caching strategies. This is important if access to WSDL sources is slow and unreliable, as it is the case with WSDL documents in the Internet.
2.3. Discoverer The discoverer is responsible for discovering Web services in several ways and implements thereby the EEE-05 discovery challenge. It offers mainly set operations on the repository. The solution for the contest is based on abstracting the problem to set operations: Let WS be a Web service, DC a discovery challenge, P a set of provided parts and R a set of resultant parts, so that e.g. R WS is the set of resultant parts of WS. If the expression “PWS ⊆ PDC && RDC ⊆ RWS” evaluates to true, then DC can be fulfilled by WS.
2.4. Composer The composer component consists of an interface that provides a generic compose method with provided and resultant data as well as the discoverer component as parameters. Thus the interface abstracts from the actual composer implementation. For the implementation we have chosen to apply partial order planning (POP) technique, see e.g. [5]. In contrast to pure search techniques like bi-directional search POP has the advantage to create plans that allow for the parallel execution of independent services. Additionally, future enhancements as for instance services that depend on certain states (e.g. logged-in) can be integrated easily with POP. The POP algorithm is sound and complete. That is, if the algorithm returns a "complete" plan, then any total ordering implied by it solves the planning problem (soundness). And, if there is a solution to a planning problem, the POP algorithm will eventually solve it (completeness). Example: We use a simplified Lisp-style notation for describing Web services and problems. A problem defines the data that are provided initially and the desired goal that should be achieved by a service (composition). ((problem p1 (provided a ) (resultant f))) ;(svc-name(parts in)(parts out)) ((s0 (a)(b c)) (s1 (b)(d)) (s2 (b)(e)) (s3 (d e c )(f))) When processed with POP a resulting plan for this example is depicted in Figure 2.
Figure 2: Services ordering example Start and end nodes are virtual services that provide respectively require the data from the problem. The arrows denote the ordering of services. As can be seen from this ordering, services s1 and s2 do not depend on each other and could be executed in parallel.
2.5. Transformer On top of the composer layer, we have built an additional component that is not demanded by the EEE-05 challenges. The transformer layer 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 twodimensional vector graphic.
3. Conclusion In this paper, we introduced how we created a solution of the EEE-05 challenges in the MOVE framework. We discussed completed developments as well as possible future extensions of the system.
4. References [1] Duftler, M. J. et al., “Java APIs for WSDL (JWSDL)”, available from ftp://www-126.ibm.com/ pub/wsdl4j/JWSDLFinalRelease/1.0/jsr110-1.0.pdf, cited 2004-11-11. [2] Gamma, E. et al., Design Patterns, AddisonWesley Professional, 1995-01-15. [3] Hrastnik, P., “Execution of Business Processes Based on Web Services”, International Journal of Electronic Business (IJEB), Vol. 2, No. 5, Geneva, Inderscience Enterprises Ltd., September-October 2004. [4] IBM, “WSDL4J Project”, available from http://www-124.ibm.com/developerworks/projects/ wsdl4j/, cited 2004-11-11. [5] Weld. D., “An introduction to least-commitment planning”, AI Magazine, pages 27-61, Winter 1994.
