1

Automated Dynamic Invocation System for Web Service with a

User-defined Data Type

EOOWS 200414 June ２００ 4Takashi KOSHIDA

Matsue National College of TechnologyNara Institute of Science and Technology

2

Content

1.　 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: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 !