1 / 21

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

Automated Dynamic Invocation System for Web Service with a User-defined Data Type. EOOWS 2004 14 June ２００ 4 Takashi KOSHIDA Matsue National College of Technology Nara Institute of Science and Technology. Content. Introduction Some background/Problems ２ . System model

luana
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Automated Dynamic Invocation System for Web Service with a User-defined Data Type EOOWS 2004 14 June ２００4 Takashi KOSHIDA Matsue National College of Technology Nara Institute of Science and Technology

  2. Content • Introduction • Some background/Problems • ２.System model • About WSIF, an overview of this system • Implementation • ３.Experimental Results • Sample program • Our system • 4. Conclusion

  3. 1 Introduction • The B2B system is now widely used. • But it is limited to regular transactions. • However, SOAP,UDDI and WSDL have enabled world-wide dynamic business transactions. But, we think, too limited. • Because , there are three problems. It is difficult: • to discover the Web Service that we want to use、 • to know how to use it、 • and to make a client program for executing a Web Service.

  4. So, in this paper, we focused on the 3rd problem. 3. and to make a client program for executing a Web Service. And to solve it, we used WSIF. ・We have already developed the system for the primitive data type. ・Now we have realized a dynamic invocation system for user-defined data.

  5. WSDL UDDI registration/publish retrieval SOAP SOAP execution Service Requester SOAP Service Provider The make up of the Web Service • Web Service is the distributed processing technology on the Web. • XML is used for data exchange.

  6. 2 System model • About WSIF (Web Services Invocation Framework) • It makes stub-less dynamic invocation possible. • It requires WSDL description of Web Service. • But,for execution, it is necessary to specify correctly the WSDL URL, Web Service name, method name, input-and-output parameter names and types. • These are complex procedures. • More easily and automatically! • But, there are two output data types.

  7. About the types of output data • Two kinds of output data in Web Service: • Primitive data: • string, float or int etc. • User-defined data: • This type is composed of some primitive data types. • For example, employee data ( ID, name, age, position, address,….) • This data is transferred as a JavaBeans object. • So we must generate the JavaBeans code dynamically to deal with user-defined data.

  8. Input parameter name/type Output parameter name/type Primitive data in WSDL description <definitions name="TemperatureService" targetNamespace="http://www.xmethods.net/sd/TemperatureService.wsdl" xmlns:tns="http://www.xmethods.net/sd/TemperatureService.wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <message name="getTempRequest"> <part name="zipcode" type="xsd:string"/> </message> <message name="getTempResponse"> <part name="return" type="xsd:float"/> </message> <portType name="TemperaturePortType"> <operation name="getTemp"> <input message="tns:getTempRequest"/> <output message="tns:getTempResponse"/> </operation> </portType>

  9. User-defined data type input parameter name / type output parameter name / type User-defined data in WSDL description <wsdl:types> <schema targetNamespace="http://10.70.51.20:8080/axis/services" xmlns="http://www.w3.org/2001/XMLSchema"> <import namespace="http://schemas.xmlsoap.org/soap/encoding/"/> <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> </wsdl:types> <wsdl:message name="getTempMakerRequest"> <wsdl:part name="in0" type="xsd:string"/> </wsdl:message> <wsdl:message name="getTempMakerResponse"> <wsdl:part name="getTempMakerReturn" type="tns1:GData"/> </wsdl:message> “GData” type is made up of the two variables, “code” and “maker”. Both of these are string-type variables.

  10. 14 primitive data User-defined data in WSDL description (Zip2Geo) <types> <s:schema elementFormDefault="qualified" targetNamespace="http://ws.cdyne.com"> <s:element name="GetLatLong"> <s:complexType> <s:sequence> <s:element minOccurs="0" maxOccurs="1" name="zipcode" type="s:string"/> <s:element minOccurs="0" maxOccurs="1" name="LicenseKey" type="s:string"/> </s:sequence> </s:complexType> </s:element> <s:element name="GetLatLongResponse"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="GetLatLongResult" type="s0:LatLongReturn"/> </s:sequence> </s:complexType> </s:element> <s:complexType name="LatLongReturn"> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="ServiceError" type="s:boolean" /> <s:element minOccurs="1" maxOccurs="1" name="AddressError" type="s:boolean"/> <s:element minOccurs="0" maxOccurs="1" name="City" type="s:string" /> <s:element minOccurs="0" maxOccurs="1" name="StateAbbrev" type="s:string" /> <s:element minOccurs="0" maxOccurs="1" name="ZipCode" type="s:string" /> <s:element minOccurs="0" maxOccurs="1" name="County" type="s:string" /> <s:element minOccurs="1" maxOccurs="1" name="FromLongitude" type="s:decimal"/> <s:element minOccurs="1" maxOccurs="1" name="FromLatitude" type="s:decimal" /> <s:element minOccurs="1" maxOccurs="1" name="ToLongitude" type="s:decimal" /> <s:element minOccurs="1" maxOccurs="1" name="ToLatitude" type="s:decimal" /> <s:element minOccurs="1" maxOccurs="1" name="AvgLongitude" type="s:decimal" /> <s:element minOccurs="1" maxOccurs="1" name="AvgLatitude" type="s:decimal" /> <s:element minOccurs="0" maxOccurs="1" name="CMSA" type="s:string" /> <s:element minOccurs="0" maxOccurs="1" name="PMSA" type="s:string" /> </s:sequence> </s:complexType> <s:element name="LatLongReturn" type="s0:LatLongReturn" /> </s:schema> </types> In this case, “LatLongReturn” type is constituted from 14 variables.

  11. An overview of our system • Automated parameter setup and execution • First, the system discovers and retrieves the WSDL URL from the UDDI registry. • Downloads and analyzes the WSDL file. • Processing for user-defined data. • Then, setup the Web Service name, method name and input-and-output parameter names and types. • Finally,executes a Web Service. • The system that is applied to primitive type data has already been developed. • This new system is applicable to user-defined data.

  12. System Feature • To deal dynamically with user-defined data. • We used WSDL2Java/Runtime libraryto generate JavaBeans codes. • We utilized the Class/Methodlibrary to extract and execute the getter method dynamically.

  13. System Implementation • The system consists of three stages (Step1, Step2 and Step3). • Step1: • “UDDI retrieval and extraction of the WSDL URL” • Step2: • “dynamic Java code generation and analysis” • Step3: • “ WSDL file analysis, stub-less Web Service execution and extraction of the output result” • Fig.2.

  14. Step 1 WSDL data System workflow :1 tModel name, tModelKey and input parameter values retrieval UDDI Registry extract Web Service Server URL of WSDL file download Execution Extracted data Fig.2.

  15. Input parameter name/type Same name Output parameter name/type Web Service name Method name A part of WSDL description …………………………………………….. <message name="getRateRequest"> <part name="country1" type="xsd:string"/> <part name="country2" type="xsd:string"/> </message> <message name="getRateResponse"> <part name="Result" type="xsd:float"/> </message> <portType name="CurrencyExchangePortType"> <operation name="getRate"> <input message="tns:getRateRequest" /> <output message="tns:getRateResponse" /> </operation> </portType> ………………………………………… The system compares the name of these portions and distinguishes the parameter name of an input and an output.

  16. WSDL data Step 3 Step 2 WSDL2Java <types>,<message> <portType> data Java code for analyze and extract user - defined data (.java) Web Service name, compile method name, Nam espace javac Input parameter name and type Class file for user - defined Output parameter data (.class) name and type analyze and extract setting up Name and return WSIF API type of the getter Web Service Execution methods getter method invocation using Method object Execution Extracted data Fig.2. Output results System workflow :2 In Step3, our system first analyzes the types element in the WSDL file and extracts the input-and-output parameter names and types, the method name of Web Service. After execution, the system extracts the output results by invoking dynamically the getter methods using “Method” API. In Step2, the system generates and compiles the JavaBeans code that is mapped in the user-defined data. We use “WSDL2Java” for the code generation and “javac” for compilation. These commands are executed by using “Runtime.getRuntime (). exec ()” in this system and the compiled code is automatically stored in a “sub” directory. The system analyzes the compiled code using “Class” and “Method” API in Java reflect and we can get the getter method and its return type.

  17. 3 Experimental Results tModelkey tModel name Zip2Geo • We used the IBM UDDI registry for testing. Fig.3.

  18. Result of sample program (Fig.4.) WSDL URL sample program name Input parameter (zip code) D:\WSIF\wsif-src-2.0\wsif-2.0\build\samples>java complexsoap.client.dynamic.Run complexsoap/Zip2Geo.wsdl 10005 This zip code is in NEW YORK, NY in NEW YORK county It extends from longitude -74.011926 to longitude -74.011926 and from latitude 40.703235 to latitude 40.710265 All the parameters that are required for execution were previously specified manually in this program. And the JavaBeans code for a user-defined data and WSDL file are attached to this WSIF package.

  19. tModelKey tModel name Input parameters Results of our system (Fig.5.) D:\WSIF\wsif-src-2.0\wsif-2.0\build\samples>java IBMRunComp3 Zip2Geo UUID:E625DB10-56F0-11D8-B766-000629DC0A53 “” 10005 Reading WSDL document from http://ws.cdyne.com/ziptogeo/zip2geo.asmx? WSDL getCity = NEW YORK getStateAbbrev = NY getZipCode = 10005 getCounty = NEW YORK getFromLongitude = -74.011925 getFromLatitude = 40.703236 getToLongitude = -74.011925 getToLatitude = 40.710266 getAvgLongitude = -74.00837 getAvgLatitude = 40.70675 getCMSA = 5602 getPMSA = 5600 Our system (“IBMRuncomp3”) automatically discovers the Web Service’s WSDL file from the IBM UDDI registry and analyzes it. Then it sets automatically 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 results.

  20. 4 Conclusion • We developedan automated dynamic invocation systemfor Web Service with user-defined data. • Features • Retrieval of WSDL URL from the UDDI registry • Automated data extraction and setting from the WSDL description of Web Service • Stub-less execution using WSIF

  21. The UDDI registry is the core of Web Service technology. • But in practice, it is difficult to quicklydiscover necessary Web Services from the UDDI registry. Important ! • We have to make it easily for the registry to find those Web Service that users need.

More Related