Automated Dynamic Invocation System for Web Service with a User-defined Data Type
description
Transcript of Automated Dynamic Invocation System for Web Service with a User-defined Data Type
1
Automated Dynamic Invocation System for Web Service with a
User-defined Data Type
EOOWS 200414 June 200 4Takashi KOSHIDA
Matsue National College of TechnologyNara Institute of Science and Technology
2
Content
1. Introduction• Some background/Problems
2 . System model• About WSIF, an overview of this
system• Implementation
3 . 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:1. to discover the Web Service that we
want to use 、 2. to know how to use it 、3. 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
Web Service is the distributed processing technology on the Web.
XML is used for data exchange.
The make up of the Web Service
Service Requester
Service Provider
SOAP
SOAP
SOAP
retrieval registration/publish
execution
UDDI WSDL
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
<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>
Primitive data in WSDL description
Output parameter name/type
Input parameter name/type
9
<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>
User-defined data in WSDL description
User-defined data type
input parameter name / type
output parameter name / type
“GData” type is made up of the two variables, “code”
and “maker”. Both of these are string-type variables.
10
<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>
14 primitive data
User-defined data in WSDL description (Zip2Geo)
In this case, “LatLongReturn” type is constituted from
14 variables.
11
An overview of our system Automated parameter setup and execution
1. First, the system discovers and retrieves the WSDL URL from the UDDI registry.
2. Downloads and analyzes the WSDL file.3. Processing for user-defined data.4. Then, setup the Web Service name, method name
and input-and-output parameter names and types.
5. 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 library to generate JavaBeans codes.
We utilized the Class/Method library 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
System workflow :1
extract
retrieval
UDDIRegistry
tModel name, tModelKeyand input parameter values
download
WSDL data
URL ofWSDL file
Extracted data
Execution
Web ServiceServer
Step 1
Fig.2.
15
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> …………………………………………
Input parameter name/type
Output parameter name/type
Web Service name
Method name
Same name
The system compares the name of these portions and distinguishes the parameter name of an input and an output.
16
System workflow :2
Fig.2.
Step 2
setting up
WSDL data
compile
analyze and extract
WSDL2Java
Java code for user-defined data (.java)
Class file for user-defined data (.class)
javac
Name and return type of the getter
methods
analyze and extract
Web Service name, method name,
Namespace
Input parameter name and type
Output parameter name and type
WSIF API
Web Service Execution
getter method invocation using Method object
Extracted data
Execution
Step 3
<types>,<message><portType> data
Output results
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 We used the IBM UDDI registry for testing.
tModelkey
tModel name
Zip2Geo
Fig.3.
18
Result of sample program (Fig.4.)
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.
WSDL URLsample program name
Input parameter (zip code)
19
D:\WSIF\wsif-src-2.0\wsif-2.0\build\samples>java IBMRunComp3 Zip2Geo UUID:E625DB10-56F0-11D8-B766-000629DC0A53 “” 10005
Reading WSDL document fromhttp://ws.cdyne.com/ziptogeo/zip2geo.asmx? WSDL getCity = NEW YORK getStateAbbrev = NY getZipCode = 10005getCounty = NEW YORKgetFromLongitude = -74.011925getFromLatitude = 40.703236getToLongitude = -74.011925getToLatitude = 40.710266getAvgLongitude = -74.00837getAvgLatitude = 40.70675 getCMSA = 5602 getPMSA = 5600
Input parameterstModel name
tModelKey
Results of our system (Fig.5.)
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
We developed an automated dynamic invocation system for 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
4 Conclusion
21
The UDDI registry is the core of Web Service technology.
But in practice, it is difficult to quickly discover necessary Web Services from the UDDI registry.
We have to make it easily for the registry to find those Web Service that users need.
Important !