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.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.