The main ingredients of the WSDK are:
- A runtime server where Web services and client applications are run and tested. The server is a subset of the WebSphere Application Server capable of running J2EE components relevant to Web services. The server also has a UDDI Server which is used for the publishing and discovery of Web services.
- A series of tools which deal with many of the common tasks associated with building and running Web services.
- A graded series of Sample applications which provide examples of how Web services and Web service clients are coded, starting with the basics and moving on to more sophisticated aspects such as Security.
- A comprehensive set of Documentation covering all aspects of the WSDK, including learning paths through Web services concepts, how to use the WSDK tools, and descriptions of the Sample applications.
The typical developer workstation, running either Windows or Linux, should be able to run WSDK, as WSDK makes only modest demands on the system. The download size is about 160 Mb, which expands to about 200 Mb on disk, including the Java SDK that it uses.
The WSDK is designed for ease-of-use. An installation wizard provides a quick install with minimal configuration. Simple command-line tools are provided to manage the runtime server and to install and control applications in the server.
The major new feature of WSDK V5.1 compared with previous versions is that the Web services tools are available as Eclipse Plug-ins. This enables developers to build Web services and Requester applications using the Eclipse graphical development environment, combining the ease of use of WSDK with the power of the Eclipse tools. The WSDK sample applications have also been enhanced so that they can be used directly in the Eclipse environment.
Building Web services from existing Java components
One of the great features of Web services is that you can build them from existing Java components, without the need for lots of new programming, simply by using the tools provided by WSDK. The Java component can be a simple Java class (called a Bean) or a more complex piece of code such as a Stateless Session Enterprise Java Bean (EJB) component.
When run as a Web service, the code executes inside the runtime server. This applies not only for code originally designed to run in an Application Server, like an EJB component, but also for code that was originally designed to run stand-alone. The WSDK tools take care of packaging the code into a form (an EAR file) which can be deployed onto the server, including generating all the necessary additional files such as deployment descriptors and WSDL files.
Exposing an existing Java component as a Web service is shown by the Sample applications which are part of the WSDK. The simplest sample is Sample1, shown in Listing 1, which is really the Hello World of Web services, which you can find in the c:\WSDK_v5\apps\Sample1\src\provider directory.
Listing 1. Hello.java (from Sample1)
package com.ibm.wsdk.Sample1;
public class Hello {
String msg="Hello";
public String getGreeting(String name) {
return msg+" "+name+"!";
}
}
|
This class takes a name as a parameter and returns the name with Hello tacked onto the beginning of the name.
This simple Java class is made into a Web service using the Bean2WebService tool. Bean2WebService creates an EAR file containing the original Hello class, plus a set of other files necessary for the deployment of this class as a Web service. The tool also deploys the EAR file to the runtime server. All that is needed is to start the Web service application running using another command supplied with WSDK:
appserver startapp Sample1WebService |
Sample1, like most of the sample applications, also contains a ready-written client application which can call the Web service. This is conveniently provided in a pre-built form in the c:\WSDK_v5\apps\Sample1\classes\requester directory, but the source code and build commands for the client are also provided as a guide.
Other samples provided with WSDK deal with more advanced Web services, including Web services built from EJB components and Web services which use Security between the client and the Web service. All the samples are covered in the WSDK documentation, covering how to run the samples and how to build the samples from scratch.
Creating Web services from WSDL definitions
So far, we have discussed how you can create Web services from some existing Java code. You can also create Web services in another way -- from a definition of the Web service interface held in a WSDL file. This second way of building Web services is important where the definition of the Web service is laid down in advance, for example by a business partner in a supply chain, or where a client is needed for a Web service written by another business.
WSDL files define Web services interfaces. WSDL stands for Web Services Description Language and is a standard defined by w3c.org. WSDL is a definition held in XML format of one or more Web services. Each service is described in terms of an operation which acts on an input message and produces an output message. The messages can be simple (the single text string in Sample1, for example) or more complex (a document representing an Order, for example). The operations and the forms of the messages are all defined in the WSDL file, along with the location of the Web service on the Web (a URL like http://localhost:6080/Sample1WebService/services/Sample1).
When creating Web services from Java code, the Bean2WebService or EJB2WebService tools generate the WSDL file. Listing 2 is the WSDL file for Sample1, which defines the location of the service, the operations possible, and the input and output parameters.
Listing 2. WSDL for Hello.java (from Sample1)
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
targetNamespace="http://Sample1.wsdk.ibm.com"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://Sample1.wsdk.ibm.com"
xmlns:intf="http://Sample1.wsdk.ibm.com"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<schema targetNamespace=
"http://Sample1.wsdk.ibm.com" xmlns="http://www.w3.org/2001/XMLSchema">
<element name="getGreeting">
<complexType>
<sequence>
<element name="in0" type="xsd:string"/>
</sequence>
</complexType>
</element>
<element name="getGreetingResponse">
<complexType>
<sequence>
<element name="getGreetingReturn" type="xsd:string"/>
</sequence>
</complexType>
</element>
</schema>
</wsdl:types>
<wsdl:message name="getGreetingRequest">
<wsdl:part element="intf:getGreeting" name="parameters"/>
</wsdl:message>
<wsdl:message name="getGreetingResponse">
<wsdl:part element="intf:getGreetingResponse" name=
"parameters"/>
</wsdl:message>
<wsdl:portType name="Sample1Interface">
<wsdl:operation name="getGreeting">
<wsdl:input message=
"intf:getGreetingRequest" name="getGreetingRequest"/>
<wsdl:output message=
"intf:getGreetingResponse" name="getGreetingResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="Sample1SoapBinding" type=
"intf:Sample1Interface">
<wsdlsoap:binding style="document" transport=
"http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getGreeting">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getGreetingRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="getGreetingResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="Sample1InterfaceService">
<wsdl:port binding="intf:Sample1SoapBinding" name="Sample1">
<wsdlsoap:address location=
"http://localhost:6080/Sample1WebService/services/Sample1"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
|
WSDK contains a tool which helps build a Web service or a Web service client from a WSDL file of this type. This tool is called WSDL2WebService.
WSDL2WebService is used in two steps:
- WSDL2WebService is used with the -createService option and it reads the WSDL file and creates a skeleton implementation of the Web service and optionally the Web service client as a series of Java files. The skeleton provides all of the interface code necessary to expose the function as a Web service. Once the skeleton implementation files are created, the Java code that actually implements the service is added to the skeleton files -- a task for the programmer to provide the business logic.
- Once the Web service implementation is ready, WSDL2WebService is used for a second time, but with the -createEar option. This packages up the Web service code into an EAR file which is then deployed to the runtime server.
Sample 6 and Sample 7 in WSDK show the process of building Web services from WSDL definitions in this way.
Using WSDK Web services tools with the Eclipse IDE
A major new feature of WSDK 5.1 is that the Web services tools are supplied as Eclipse plug-ins, as well as in the Command Line format supplied with previous releases of WSDK. This means that you can use the productive and easy-to-use programming environment of the Eclipse IDE to build Web services and Web services client applications.
If you have the Eclipse IDE installed on your workstation, you can choose to install the WSDK Web services tools into your Eclipse environment. At the same time, the WSDK Web service Samples are also installed into the Eclipse environment ready for you to use.
When you create new Projects within the Eclipse IDE, you are able to perform tasks such as publishing a Java Bean as a Web service using Wizards built into the Eclipse environment.
For example, you can create a Web Project in Eclipse and then build a simple Java Bean in the Project. You could use the simple bean from Sample1 of the WSDK as a starting point, if you like. Once you have the Bean ready, with at least one method written, you can generate a Web service from the Bean and deploy it to the runtime server. Do this by selecting the New > Other... dialog and then selecting Web Services in the left column and Web Service in the right column, as seen in Figure 1.
Figure 1. New Web services dialog
The Web service wizard then displays a series of dialog panels asking for details about the Web service, including:
- Whether you want to generate client proxy code for the Web service, which is useful if you are going to write a client application to use your Web service
- Whether you want to test your Web service as soon as it has been created
- Which Java method(s) to expose as Web services (see Figure 2)
- Which style to use in the WSDL file (see Figure 2).
Figure 2. Web service Java Bean dialog
When you press the Finish button on the final dialog panel of the wizard, the Web service files are generated and are deployed to the runtime server and started. If you chose to generate client proxy code, the client code is also created at the same time. If you chose to Test your Web service, you will see some new windows in your Eclipse environment, like those shown in Figure 3, with the titles Methods, Inputs and Result.
These windows let you to test your Web service interactively. The Methods window contains a list of the different Web service methods that you created -- in Figure 3, there is just one method, getGreeting. Select the method you want to test, and the Inputs window then shows a set of entry fields, one for each of the input parameters for your Web service. In Figure 3, there is just one parameter called name. Type in suitable values for each of the parameters and press the Invoke button -- this will call your Web service. The result returned by the Web service is displayed in the Result window -- in Figure 3, this is the text Hello Matt. You can try the Web service again using new parameters using the Clear key in the Inputs window.
Figure 3. Interactive test dialog
The combination of WSDK with the Eclipse environment provides a productive and simple-to-use combination for creating Web services.
Interoperability of Web services and WS-I
One of the attractions of Web services is the promise of Interoperability -- the potential for one system to call on a Web service on a different system without being concerned about the technology used to implement the Web service. Web services are independent of the programming language, independent of the operating system, and independent of the supplier of the application server used to run the Web service.
Web service interoperability is possible largely because Web services are defined in terms of the messages that flow between the clients and the Web service provider, rather than in terms of programming interfaces. The messages are defined in terms of XML -- a data format that is itself independent of programming languages and operating system considerations.
To ensure Web services interoperability between Web services implementations provided by different vendors on different platforms, the Web Services Interoperability Organization (WS-I.org) has been established. WS-I is an open industry organization supported by all of the major companies involved in Web services. WS-I does not define standards -- instead, WS-I defines Profiles which define how the various Web services standards (such as WSDL, SOAP, UDDI) should be used in order to guarantee interoperability.
WS-I has completed and published Basic Profile 1.0 -- the first profile which addresses standard Web services. WSDK V5.1 provides support for Basic Profile 1.0. The WSDK tools can generate conforming Web services and the Sample applications are written to conform to Basic Profile 1.0. This should help ensure interoperability with other conforming Web services implementations, which is an important and valuable goal.
Building Microsoft .NET clients to WebSphere Web Services
As a practical example of interoperability, WSDK V5.1 has built Sample Web Services which can be consumed by clients running on Windows built using Microsoft .NET tools. The combination of a Microsoft .NET client calling Web services running in a WebSphere server is chosen as it is likely to be a common configuration in many installations.
The WSDK documentation contains a guide to building a Microsoft .NET client using the Visual Basic .NET tools. A step-by-step process is shown for creating a client to the Sample1 Web service, including both a graphical interface and also the underlying code for invoking the Web service and returning the results.
You can build similar .NET client applications for the more complex Web service samples in WSDK.
The WebSphere SDK for Web Services Version 5.1 is available for free download from the IBM Web site (see Resources for a link). If you would like to use the WSDK tools with the Eclipse IDE, you get a free download of Eclipse (see Resources for a link).
You can use the WSDK to develop and test Web services, and it is a great toolkit for learning all about Web services, but it is not intended for any type of production use. When you want to put your Web services into production use, you will need to run them on a production version of the WebSphere Application Server. For more information about WebSphere Application Server, see the Resources.
WSDK is a toolkit which focuses on Web services. For a development environment which addresses the complete range of development activities, including a graphical development environment with an extensive set of wizards and facilities for debugging code, try WebSphere Studio -- and in particular WebSphere Studio Application Developer.
- You can find more information about WebSphere SDK for WebServices, including the download package.
- You can also find more information about WebSphere Application Server.
- To learn about the Eclipse IDE, or to get the download package, look at the Eclipse website.
- Get details about the WebSphere Studio Application Developer.
- Find information about the Web Services Interoperability Organization, plus the definition of the Basic Profile 1.0, on the WS-I Web site.
Dr. Mike Edwards is a Strategic Planner in the IBM Java Technology Center in Hursley, England. He is responsible for technical planning for future IBM products, including the IBM Java SDKs and Web services-related products. Before working on WSDK, Mike was involved in the planning of Java SDK 1.4.0 and was a member of the Expert Group for JSR 059, which defined the specification for J2SE 1.4.0. Mike is also a member of the Expert Group for JSR 166, Concurrency Utilities, which will be part of J2SE 1.5.0. Mike received his Ph.D. in Elementary Particle Physics from Birmingham University. You can contact Mike at mike_edwards at uk.ibm.com.




