What's in the WSDK?

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 publishing and discovering Web services.
• A series of command line 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 120 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 minimum configuration. Simple command-line tools are provided to manage the runtime server and to install and control applications in the server.

Back to top

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 it can also be done 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.

The Sample applications, which are part of the WSDK, show how to expose an existing Java component as a Web service. The simplest sample is shown in Listing 1, which is really the Hello World of Web services. Here’s the code for the Hello.java class, which is in the C:\WSDK_v5\apps\Sample1\src\provider directory:

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

Listing 1, 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 mode 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.

Back to top

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 Listing 1, 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 shows the WSDL file for Listing 1, which defines the location of the service, the operations possible, and the input and output parameters:

<?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:

1. 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.
2. 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.

Back to top

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 (for example WSDL, SOAP, UDDI) should be used in order to guarantee interoperability.

WS-I is in the process of completing Basic Profile 1.0 -- the first profile which addresses standard Web services. At the time of writing (May 2003), Basic Profile 1.0 is at the Board Approval draft level, and is due to become the official published profile within a couple of months.

WSDK V5.0.1 provides support for the draft version of Basic Profile 1.0. The WSDK tools can generate conforming Web services, and the Sample applications are written to conform to the draft Basic Profile 1.0. This should help ensure interoperability with other conforming Web services implementations, which is an important and valuable goal.

Back to top

Building Microsoft .NET clients to WebSphere Web Services

As a practical example of interoperability, WSDK V5.0.1 has built Sample Web Services which can be consumed by clients running on Windows, built using Microsoft .NET tools. This combination of a Microsoft .NET client calling on 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 Listing 1 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.

Back to top

Taking the next steps

The WebSphere SDK for WebServices Version 5.0.1 is available for free download from the IBM Web site (see Resources for a link).

You can use the WSDK to develop and test Web services and 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, based on command-line tools. 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.

Resources

• Download the WebSphere SDK for WebServices.
  
  
• You can find more information about WebSphere Application Server.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• What's in the WSDK?
• Building Web services from existing Java components
• Creating Web services from WSDL definitions
• Interoperability of Web Services and WS-I
• Building Microsoft .NET clients to WebSphere Web Services
• Taking the next steps
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

Dig deeper into SOA and Web services on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers