WSDL Implementations

WSDL Implementations

Because WSDL is a bridge technology in the sense that it bridges SOAP and UDDI, you’re unlikely to find a WSDL toolkit that stands by itself. The two most popular WSDL implementations, therefore, are parts of other toolkits:

   The Microsoft SOAP Toolkit. This toolkit, covered in depth in Chapter 15, is pri-marily aimed at developers who want to work with SOAP in a Microsoft environ-ment, although it does support Microsoft’s UDDI implementation.

   The IBM Web Services Toolkit (WSTK). This toolkit provides WSDL support, sev-eral security enhancements, UDDI integration, and support for the IBM WebSphere application server. The WSTK also includes the open-source Web Services Description Language for Java Toolkit (WSDL4J).

WSDL the Microsoft Way

First, refer to the section “The Microsoft SOAP Toolkit,” of Chapter 15 for a step-by-step illustration of how to generate WSDL files with the Microsoft SOAP Toolkit. The result-ing WSDL file is shown in Listing 15.2. This file is standard WSDL, and it’s generated automatically, so there is little to say about the file itself. However, the Microsoft imple-mentation requires another file to map the invoked Web Service operations to COM object method calls. This additional file is expressed in the Web Services Markup Language (WSML), which is Microsoft’s proprietary language for this particular pur-pose. The Microsoft SOAP Toolkit generates WSML files automatically; see Listing 15.3 for an example.

WSDL the IBM Way

The WSTK runs on Linux or Windows 2000/NT 4 and requires a recent installation of the Java Development Kit (JDK). Download the WSTK from http://www.alphaworks. ibm.com/tech/webservicestoolkit. The version used for this book is 2.4, but IBM warns developers to consider the toolkit to be alpha code.

The WSTK comes with several useful utilities, including the following:

   A limited version of IBM’s WebSphere Application Server, suitable for running Web Services. It also supports the latest full version of WebSphere.

   Apache SOAP (which IBM originally produced and released as open source) and AXIS, which is an open-source SOAP implementation.

WSDL4J, the WSDL Toolkit for Java.

   The XML4J XML Parser, which includes the Apache Xerces Java-based XML parser.

   LotusXSL-Java (based on Apache Xalan Java), which is an Extensible Style Language Transformations (XSLT) processor for transforming XML documents into HTML, text, or other XML document types.

   IBM UDDI4J, which is IBM’s UDDI Toolkit for Java (more about this part of the WSTK later in the chapter), as well as a preview of IBM’s UDDI Registry software.

   A demo implementation of Reliable HTTP (HTTPR).

   A prototype implementation of the XML Key Information Service Specification (X-KISS), which is part of the XML Key Management Specification (XKMS). X-KISS is a protocol for a trust service (that is, a third-party key registry) that resolves public key information contained in certain XML documents.

   A Web Services for Browser (WS4B) plug-in that provides programmatic access to any UDDI node from a standard browser.

                        The installation of the WSTK is straightforward, except that you must select a UDDI registry for the toolkit to access. You can use the local one provided with the toolkit or configure the toolkit to access a public registry. To use the WSTK, you must first have a Java client that accesses a Web Service. The toolkit comes with a Java class that is sup-posed to access a stock quote service provided by Nasdaq, but Nasdaq apparently no longer provides this service. For our example, therefore, we wrote a simple client that returns a placeholder instead of accessing a true Web Service, as shown in Listing 16.1.

                LISTING 16.1      Demo Client Application MyClass.java

                        public  class  MyClass

                        {

                        public  int  MyMethod  (String  arg)

                        {

                        return  47;

                        }

                        public  static  void  main  (  String[]  args  )

                        {

                        System.out.println(  “output”  );

                        }

                        }

Next, we use the WSTK to generate the WSDL wrapper for our application. Launching the toolkit takes you to the dialog box shown in Figure 16.2.

From here, select Java Class and click Next to get to the Java Class WSDL Generator dialog box, as shown in Figure 16.3.

Type in the necessary information about your client application and click Next to select your wrapper class methods, as shown in Figure 16.4.

Select the methods in your application you wish to expose. Your methods shouldn’t have red dots by them, or you will have to modify the WSDL manually to support complex data types that the WSTK cannot handle.

Finally, click Next to confirm your selection, as shown in Figure 16.5.

You will get an error message at this point if the WSDL generation tool is unable to wrap the methods you have selected.

Clicking the Finish button will generate two WSDL files plus a deployment descriptor file. The first file the toolkit generates is the WSDL service implementation description, as shown in Listing 16.2.

LISTING 16.2  Generated File MyClass_Service.wsdl

<?xml  version=”1.0”  encoding=”UTF-8”?>

<definitions  name=”MyClass_Service”

targetNamespace=”http://www.myclassservice.com/MyClass”

xmlns=”http://schemas.xmlsoap.org/wsdl/” xmlns:interface=”http://www.myclassservice.com/MyClass-interface” xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/” xmlns:types=”http://www.myclassservice.com/MyClass” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>

<import location=”http://localhost:8080/wsdl/MyClass_Service-interface.wsdl” namespace=”http://www.myclassservice.com/MyClass-interface”>

</import>

<service name=”MyClass_Service”>

<documentation>IBM WSTK V2.4 generated ➥ service definition file</documentation>

<port binding=”interface:MyClass_ServiceBinding” name=”MyClass_ServicePort”>

<soap:address location=”http://localhost:8080/soap/servlet/rpcrouter”/> </port>

</service>

</definitions>

Note that Listing 16.2 contains an import element and a service element, but no mes-sage, portType, and binding elements. Instead, these elements are included in the ser-vice interface file, which is imported via the import statement. The service interface file is shown in Listing 16.3.

LISTING 16.3  Generated File MyClass_Service-interface.wsdl

<?xml  version=”1.0”  encoding=”UTF-8”?>

<definitions name=”MyClass_Service” targetNamespace=”http://www.myclassservice.com/MyClass-interface” xmlns=”http://schemas.xmlsoap.org/wsdl/” xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/” xmlns:tns=”http://www.myclassservice.com/MyClass-interface” xmlns:types=”http://www.myclassservice.com/MyClass-interface/types/” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>

<message  name=”InMyMethodRequest”>

<part name=”meth1_inType1” type=”xsd:string”/> </message>

<message  name=”OutMyMethodResponse”>

<part name=”meth1_outType” type=”xsd:int”/> </message>

<portType name=”MyClass_Service”> <operation name=”MyMethod”>

<input message=”tns:InMyMethodRequest”/> <output message=”tns:OutMyMethodResponse”/>

</operation>

</portType>

<binding name=”MyClass_ServiceBinding” type=”tns:MyClass_Service”> <soap:binding style=”rpc”

transport=”http://schemas.xmlsoap.org/soap/http”/> <operation name=”MyMethod”>

<soap:operation soapAction=”urn:myclass-service”/> <input>

<soap:body

encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/” namespace=”urn:myclass-service”

use=”encoded”/>

</input>

<output>

<soap:body

encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/” namespace=”urn:myclass-service” use=”encoded”/>

</output>

</operation>

</binding>

</definitions>

By separating the service implementation from the service interface, the WSTK allows the service to be changed without affecting the interface, thus providing for greater reuse and flexibility. This approach is an example of good design that is allowed, but not required, by the WSDL specification. The service interface document is created by a ser-vice interface provider, whereas the service implementation document is put together by the service provider. Although these two organizations may be the same entity, in prac-tice they are typically different organizations.

In addition to the service and service interface files, the WSTK also produces a deploy-ment descriptor file, as shown in Listing 16.4.

LISTING 16.4  Generated File DeploymentDescriptor.xml

<isd:service xmlns:isd=http://xml.apache.org/xml-soap/deployment

id=”urn:myclass-service” checkMustUnderstands=”false”>

<isd:provider type=”java” scope=”Application” methods=”MyMethod”> <isd:java class=”MyClass” static=”false”/>

</isd:provider>

</isd:service>

The deployment descriptor file correlates each service with its URI. The WSTK’s SOAP engine contains a hashtable of services deployed on the server, and the deployment descriptor provides the keys to the hashtable. The deployment descriptor serves a similar purpose for the WSML file in the Microsoft implementation, where the deployment descriptor provides a correlation to Java methods in each deployed service, whereas the Microsoft SOAP Toolkit uses WSML to correlate to COM object method calls.

Once these three files are written, you have successfully deployed your Web Service, and you should see the dialog box shown in Figure 16.6.