Automated Dynamic Invocation System for Web Service with a User-defined Data Type

Size: px

Start display at page:

Download "Automated Dynamic Invocation System for Web Service with a User-defined Data Type"

Victoria Morris
5 years ago
Views:

1 Automated Dynamic Invocation System for Web Service with a User-defined Data Type Takashi Koshida 1,2 and Shunsuke Uemura 2 1 Department of Information Engineering, Matsue National College of Technology, 14-4 Nishi-Ikuma, Matsue, Shimane , Japan takashi@matsue-ct.ac.jp 2 Graduate School of Information Science, Nara Institute of Science and Technology , Takayama, Ikoma, Nara , Japan {takas-ko, uemura}@is.naist.jp Abstract. We developed and implemented an automated dynamic invocation system for Web Service with a user-defined data type. This system can automatically discover the WSDL file describing Web Service from UDDI registry. After analyzing the WSDL file, the system extracts and automatically sets up the parameters needed for dynamic invocation. Furthermore, the system dynamically generates and compiles the Java code for a user-defined data type. By analyzing the Java code, the system extracts the getter method and its return type. The system then invokes the getter method using the Method object. In this newly devised system we developed using Java reflect, JAXP, UDDI4J, WSDL4J and WSIF API. We present the experimental results and demonstrate the validity of this system by invoking published Web Services as practical examples. 1 Introduction Web Service is a distributed processing program that uses SOAP [1] as a data access protocol and executes data exchange in XML format. SOAP is an XML-based protocol intended for exchanging structured information in a distributed environment. Recently, practical use research of Web Service has progressed based on UDDI [2] and WSDL [3]. Also, the composition and integration of Web Services has been researched and developed using technologies like BPEL4WS [4] and DAML-S [5]. UDDI is the name of a group of web-based registries that reveal information about a business or other entity and its technical interfaces. By accessing any of the public UDDI registries, anyone can search for information about Web Services that are made available by or on behalf of a business [6]. UDDI data structure consists of four elements. The businessentity element gives information about an enterprise that provides Web Services. The businessservice element describes the Web Services. The bindingtemplate element contains technical information about Web Services. These three elements together form a nested structure. The tmodel element has the specification of Web Services provided.

2 WSDL is an XML-based language for describing network services as a set of endpoints operating on messages containing either document-oriented or procedureoriented information [7]. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. WSDL provides a uniform way of describing the abstract interface and arbitrary protocol bindings of Web Services. A WSDL file constructs the following elements in the definition of network services: The types element is a container for data type definitions using some type system (such as XSD) and a user-defined data is defined by using the types element. The message element is an abstract, typed definition of the data being communicated. The operation element is an abstract description of an action supported by the service. The porttype element is an abstract set of operations supported by one or more endpoints. The binding element is a concrete protocol and data format specification for a particular port type. The port element is a single endpoint defined as a combination of a binding and a network address. The service element is a collection of related endpoints. The name attribute in porttype is the Web Service name deployed in the server and the name attribute in operation is the Web Service s method name. Up to this time, whenever we executed a Web Service, we had to create the client program that incorporates a stub program. This step placed a burden on the user. However, after developing WSIF [8,9], we can use a Web Service dynamically without developing a stub program. But, as explained below, there is a problem when we use WSIF. The problem is, that when we execute Web Service by using WSIF, we must specify the WSDL s URL describing the Web Service, method name and input parameters correctly. So to do this, we must confirm beforehand the WSDL URL, method name and input parameter s type/value. Furthermore, we have to create the client program that embeds WSIF APIs to execute dynamically the Web Service. These are fairly complex procedures and difficult to carry out. To resolve this situation, we developed the system with the characteristics shown below and we have already executed it successfully for the primitive data type [10,11]. (1) This system automatically discovers the WSDL URL from the UDDI registry and downloads/analyzes the WSDL file from the server of Web Service provider. (2) This system automatically extracts and sets up the Web Service method name and input-and-output parameters. (3) This system dynamically executes the Web Service without a stub program. But for the Web Service with a user-defined data type, we could not execute dynamically using the process described above. So, in this paper, we focus on the problem of dynamic utilization of Web Services with a user-defined data type and propose the solution for a practical use-case. 2 System Model The most important feature of our system is to deal dynamically with a user-defined data type. To realize this, we used the Axis WSDL2Java [12] program. The Axis WSDL2Java provides us with the Java code that represents a user-defined data type. WSDL2Java analyzes the WSDL file describing Web Service and can generate the

3 Java code for a user-defined data. We combined WSDL2Java and javac commands to compile using Runtime Java class library in our system. Then we analyzed the code using the Class and Method APIs, and acquired dynamically the getter method name and its return type. Finally, we execute the getter method using invoke method in Method API and get the output result. 2.1 About a User-defined Data Type A user-defined data is represented by the types element in WSDL definition. This is a variable that is composed of primitive data types. The SOAP specification is such that only one input and one output is allowed in the messages that are sent across the Internet from one computer to another. So, if there are some output parameters, the user uses the types element in WSDL definition. As an example, the content of a types element is shown in Fig.1. In Fig.1, the name attribute in complextype element represents the name of a user-defined type and also the return type of Web Service method. In this case, the return type is "GData". The "GData" data type is constructed from the data of the element under the sequence tags. In this case, there are two string type data in the "GData". When we use this Web Service, we have to inform WSIF that a particular XML type actually maps to a particular Java class. And we have to generate the particular Java class for the GData data type. So in our system we use WSDL2Java for this purpose. <wsdl:types> <schema targetnamespace=" rvices" xmlns=" <import namespace=" ing/"/> <complextype name="gdata"> <sequence> <element name="code" nillable="true" type="xsd:string"/> <element name="maker" nillable="true" type="xsd:string"/> </sequence> </complextype> <element name="gdata" nillable="true" type="tns1:gdata"/> </schema> Fig. 1. An example of a user-defined data in WSDL document

4 2.2 System Implementation Our system consists of three stages. Step1 is a UDDI retrieval and extraction of the WSDL URL. Step2 is a dynamic Java code generation and analysis and Step3 is a WSDL file analysis, stub-less Web Service execution and extraction of the output result. The workflow is shown in Fig. 2. We developed this system using Java reflect, JAXP [13], UDDI4J [14], WSDL4J [15] and WSIF API. The UDDI4J is the Java class library to access and analyze the UDDI registry data structures and the WSDL4J reads and analyzes WSDL s data structures. In Step1, we first have to discover the WSDL URL for the Web Service retrieving the IBM UDDI registry [16]. We used UDDI4J API for these procedures. Our system requires both the tmodel name and tmodelkey to identify the Web Service; because there are some Web Services with the same tmodel name. The tmodelkey is the worldwide unique key value that consists of 128 bits. The system retrieves the tmodel element in the UDDI registry by using the tmodel name and tmodelkey value specified as input parameters. If both values correspond, then the system retrieves the overviewurl element in the overviewdoc element. The content of the overviewurl element is the WSDL URL for the Web Service. In Step2, the system executes dynamic Java code generation and analysis part. In this part, the system generates and compiles the Java code that is mapped in the userdefined data in Web Service. We use WSDL2Java for the code generation and javac for compilation. These commands are executed by using Runtime.getRuntime (). exec () in system and the compiled code is automatically stored in a sub directory. The system analyzes the compiled Java code using Class and Method API in Java reflect and we can get the getter method and its return type. We developed newly these procedures. In Step3, our system first analyzes the types element in the WSDL file using JAXP API. We extract the correct input-and-output parameter names and types from types, message and porttype element data. Also, the method name of Web Service can extracted from the name attribute in the operation in the porttype element. By dealing with the transactions described above, some parameters required for the dynamic invocation of Web Service are set in our system and the Web Service s operation is executed. Of course, the Java code for a user-defined data is used in the maptype method that maps a particular XML type to a particular Java class. After execution, the system extracts the output results by invoking dynamically the getter methods using Method API. Newly we devised this means. In this Step, we use the information of the getter method that is obtained in Step 2. Thus, we developed a fully automated dynamic invocation system with a user-defined data type.

5 tmodel name, tmodelkey and input parameter values extract URL of WSDL file Step 1 retrieval UDDI Registry Web Service Server download Step 3 WSDL data Step 2 <types>,<message> <porttype> data analyze and extract Web Service name, method name, Namespace Input parameter name and type Output parameter name and type setting up WSIF API Web Service Execution WSDL2Java Java code for user-defined data (.java) compile javac Class file for user-defined data (.class) analyze and extract Name and return type of the getter methods The getter method invocation using Method Output results Execution Extracted data Fig. 2. System workflow

6 3 Experimental Results We used the IBM UDDI Registry to test our system and registered the Web Service Zip2Geo [17] to that as shown in Fig. 3. The Zip2Geo returns the city name, longitude and latitude as a user-defined data type from an input zip code. Fig. 3. The IBM UDDI Registry 3.1 The experimental result of the sample program We show the experimental result of the sample program provided in the WSIF package in Fig. 4. This program requires the WSDL s location and zip code. All of the parameters that are required for execution were previously defined manually in this program. The Java code for a user-defined data and WSDL file are attached in this WSIF package.

7 D: WSIF wsif-src-2.0 wsif-2.0 build samples>java complexsoap.client.dynamic.run complexsoap/zip2geo.wsdl This zip code is in NEW YORK, NY in NEW YORK county It extends from longitude to longitude and from latitude to latitude Fig.4. Experimental result of the sample program in WSIF package 3.2 The experimental result from our system On the other hand, our system ( IBMRuncomp3 ) automatically discovers the Web Service s WSDL file from the IBM UDDI registry and analyzes it. Then it sets the parameters that are required for the dynamic invocation of the Web Service and invokes dynamically the getter method using Method object to get the output result. We show the result of Zip2Geo Web Service in Fig.5. In this example, Zip2Geo is the tmodel name in the UDDI registry. If Web Service has a unique tmodel name, we can execute our system without specifying the tmodelkey value as an input parameter. First, we have to get the Java code for a user-defined data. The generated code is stored in a sub directory and compiled automatically. Then, our system executes the Zip2Geo Web Service. D: WSIF wsif-src-2.0 wsif-2.0 build samples>java IBMRuncomp3 Zip2Geo UUID: E625DB10-56F0-11D8-B DC0A53 "" Reading WSDL document from WSDL getcity = NEW YORK getstateabbrev = NY getzipcode = getcounty = NEW YORK getfromlongitude = getfromlatitude = gettolongitude = gettolatitude = getavglongitude = getavglatitude = getcmsa = 5602 getpmsa = 5600 Fig. 5. Experimental result of our system for the Zip2Gio Web Service

8 4 Conclusion We developed and implemented an automated dynamic invocation system for a Web Service with a user-defined data type and confirmed the validity of our system using the UDDI registry and a practical Web Service. We plan to generalize our system for Web Service with any user-defined data type. So, we have been testing for various different user-defined data types. We believe that to construct a useful system, we should apply the new technology to various use-cases. Through our research and development, we believe that the UDDI registry and WSDL are the core to and the most important architectures in Web Service. However, in practice, we think it is very difficult to identify quickly the Web Service that a user needs, from the UDDI registry. It is most important that we can easily discover those Web Services that we really need. As a next step, we propose to realize the most effective way to discover a desired Web Service form the UDDI registry using semantic technologies. References 1. SOAP, 2. UDDI, 3. WSDL, 4. BPEL4WS, 5. DAML-S, 6. UDDI, 7. WSDL, 8. WSIF, 9. Paul Fremantle: Applying the Web services invocation framework, loc=dwmain 10. T.Koshida and S.Uemura: An automatic set-up of Web Service method in WSIF, Proceedings of the 2004 IEICE General Conference, ISSN , D-9-5, (2004) 11. T.Koshida and S.Uemura: An Effective Dynamic Invocation for Web Service, Proc. International workshop on Business and Information 2004 (BAI2004), ISSN , Session3-3, (2004) 12. WSDL2Java (Apache-Axis), JAXP API, UDDI4J, WSDL4J, IBM UDDI registry, Zip2Geo,

SOAP Specification. 3 major parts. SOAP envelope specification. Data encoding rules. RPC conventions

SOAP Specification. 3 major parts. SOAP envelope specification. Data encoding rules. RPC conventions SOAP, UDDI and WSDL SOAP SOAP Specification 3 major parts SOAP envelope specification Defines rules for encapsulating data Method name to invoke Method parameters Return values How to encode error messages