Listing 1 shows the signature of the States bean, the Cities bean, the Forecast bean, and the Forecasts bean. See my earlier article or the source code for more detail. The three beans for the most part are standard data beans. The Cities bean and the Forecasts bean have "add" methods used by the WeatherForecast bean to insert information.

Listing 2 shows the signature of the WeatherForecast bean. Note that the getStates()method returns a States bean, the getCities()method returns a Cities bean, and the getForecast() method returns a Forecasts bean.

Creating a Web Service from the Bean
We will use the WSAD Web Service wizard to create the Web service from the WeatherForecast bean. To create the Web service, select the WeatherForecast bean and then right-click and select New>Other. You will see the dialog shown in Figure 2. You must select Web Services in the left panel and Web Service in the right panel. Now hit Next to go to the next dialog.

Now you will see the panel shown in Figure 3. We do not want to publish the Web service, so leave that box unchecked. We do want to generate a proxy to support testing, so check that box. We do not want to test the generated proxy, so hit Next to go to the next panel.

In the resulting Deployment Settings panel, shown in Figure 4, you can choose the runtime protocol and target server type. At this time, the only protocol option is SOAP. There are a number of server options, including WebSphere versions 4 and 5. As indicated in the panel, the default protocol is SOAP and the default server is WebSphere v5, which is what we want, so simply leave the defaults selected. Hit Next to go to the next panel (not shown), which simply confirms that you've chosen the right JavaBean. Hit Next to go to the next panel.

You should now see the Java Bean Identity panel, shown in Figure 5. If this were more than just an exercise, you would also want to ensure that the Web service URI is unique, but that is not necessary in this case. This panel allows the developer to use HTTP-like processing scope for a Web service, i.e., request, session, or application scope. The WeatherForecast bean is designed to operate with session scope, so you must change the Scope field to "Session". Setting the scope to Session ensures a new instance for each user, allowing caching of information from the NWS to work properly.

The WSDL document fields show new features in WSAD v5.0. The WSAD wizard now produces, by default, separate WSDL documents for the interface, binding, and the service WSDL elements. In fact, the wizard produces two different bindings, one for the protocol chosen in the previous step, in this case SOAP/HTTP, and one for a Java binding. This new default behavior enables advanced features beyond the scope of this article. If you want the wizard to generate a single WSDL document, simply use the same name in the interface, binding, and service documents. The default values of those fields are acceptable for this exercise, so select Next.

You will now see the JavaBean Methods panel, shown in Figure 6, which allows you to select which methods in a JavaBean to expose in the Web service. In this case, we want to expose all the methods, so no changes are needed. Notice that SOAP encoding is automatically selected for both the input strings and the output JavaBeans. This is exactly as desired, so select Next.

You will now see the Binding Proxy Generation panel, shown in Figure 7, which allows you to select which type of binding you want the generated proxy to use for the Web service. In this case, we want to use the SOAP binding, so no changes are needed.

Since we want to generate a SOAP-based Web service and the corresponding proxy, and we don't want to generate a test client for the proxy or publish information about the Web service to a UDDI registry, you can select Finish.

The Web Service wizard now generates the WSDL files describing the Web service, generates a SOAP deployment descriptor for deploying the Web service in the WebSphere Application Server, deploys the Web service in the WebSphere Test Environment provided by WSAD, and starts the WebSphere Test Environment to make the Web service available for use.

Artifacts Generated by WSAD
Figure 8 shows the server-side artifacts generated by the WSAD Web services wizard. You can see the WSDL documents and associated schema documents generated from the WeatherForecast bean as part of creating the Web service. The WSDL is placed in the Web Content folder in the WF Web project.

By default WSAD generates a three-part WSDL description of the Web service, supported by schema definition files. The "interface" WSDL file describes the abstract interface definition. The "binding" WSDL file describes the binding of that definition to a concrete transport; the "service" WSDL file describes the actual URI for the Web service. It is instructive to examine the WSDL generated by WSAD to see how the returned beans are described.

Listing 3 shows an excerpt from the interface file, WeatherForecast.wsdl. The most important element in the file is the WSDL portType element. This excerpt shows only the getForecast operation included in the portType. Note that the interface file imports schema definition files that define the structure of the JavaBeans used in the interface.

The schema definition corresponding to the Forecast JavaBean (shown in Listing 4) is quite straightforward, containing a single complex type definition. Note that it and all the other JavaBean definitions are placed in the namespace "http://beans.forecast/", which corresponds to the name of the package in which the original beans are defined.

Listing 5 shows excerpts of the schema definition corresponding to the Forecasts JavaBean. It defines a complex type corresponding to an array of the Forecast JavaBean and a complex type corresponding to the Forecasts JavaBean itself, which references the array complex type. The other schema definition files are similar to these two.

Listing 6 shows excerpts from the binding WSDL file, WeatherForecastBinding.wsdl. The key element is the WSDL binding element. The binding file imports the interface file described above to pick up the definition of the portType for the type attribute of the WSDL binding. Since this is a SOAP/HTTP binding, extensibility elements identify it as a SOAP binding and define operations using SOAP encoding. As before, only the getForecast operation is shown.

The service WSDL file, WeatherForecastService.wsdl (shown in Listing 7) imports the binding file to pick up the definition of the binding used in the binding attribute of the port element. Since it uses a SOAP/HTTP binding, the port element contains an extensibility element identifying the URI of the Web service. The key element in this file is the WSDL port element, a child of the WSDL service element.

WSAD 5.0 creates a new Web project, WFClient, to contain the artifacts generated (see Figure 9). The proxy, WeatherForecastProxy, is analogous to the WeatherForecast bean in the WF Web project. The new project also contains a set of "data" beans used by the proxy that are analogous to the data beans in the forecast.beans package of the WF Web project. These beans are generated solely from the WSDL without any knowledge of the implementation in the original package. This allows a client implementation to use the beans exactly as the original beans would be used, but to be totally independent of the Web service implementation. Note in particular that the new beans have exactly the same package, as well as the same class names, as the original beans. This is a significant new feature of WSAD 5.0.

Listing 8 shows excerpts of the WSAD-generated proxy. Note that the signature of the proxy contains the same business methods as the Web service. Also note that the return values correspond to the client-side bean types generated by WSAD.

Listing 9 shows excerpts of the most complex of the client-side beans, forecast.beans. Forecasts. Note that it extends a special class, com.ibm.etools.xsd.bean.runtime. AnyType. This class allows generic handling of beans constructed from schema by WSAD. The other beans are constructed similarly. This capability is much improved in WSAD 5.0.

Testing the Web Service and Proxy
TestWF (shown in Listing 10) is a simple test program for the Web service; it uses the proxy generated by the WSAD Web Service wizard. You should create the program in the default package in the WFClient project. You must add the variable "MAILJAR" to the Java Build Path property for the project to successfully compile and run the program.

You can run the program with the Web service configured to access the NWS over the Internet or to run against some "canned data" used when the Web service does not have access to the Internet (access is controlled by the OFFLINE property in the forecast.properties file). The test program calls all three operations on the Web service. The test program produces the following result when configured to actually contact the NWS.

The first state: AK
The first city: Anchorage
The first forecast: Wednesday night -
Low 21, 20% chance of precipitation.

Using the Web Service
Now we will create a client of the Web service using only the WSDL, as would be done by finding the WSDL for a Web service in a UDDI registry. Navigate to and select the WeatherForecastService.wsdl file in the WF Web project. Right-click on it and select New>Other. In the resulting panel (see Figure 2), select Web Services on the left side and Web Service Client on the right and then select Next. You will see the Web Service Client wizard shown in Figure 10. Select Next. The resulting panel allows you to verify that you have selected the correct WSDL document. Select Next.

Now you will again see the Binding Proxy Generation panel shown in Figure 7, which allows you to select which type of binding you want for the Web service. In this case, we want the SOAP binding and proxy, so no changes are needed. However, we want to create a new client project, so in the Project field, enter "WFClientB" and then select Finish.

Figure 11 shows the results produced by WSAD. Notice that the results are identical to those produced above for the WFClient project used in testing the Web service (see Figure 9). This gives extra assurance that testing of the Web service and client artifacts by the provider will use the same artifacts used by the consumer of the Web service. This symmetry is new in WSAD 5.0.

You can copy the above test program into the default package in the WFClientB project. As before, you must add the variable MAILJAR to the Java Build Path property for the project. When you run the program, you will get identical results, assuming the same configuration.

The first state: AK
The first city: Anchorage
The first forecast: Wednesday night -
Low 21, 20% chance of precipitation.

Summary
This article showed that WebSphere Studio Application Developer version 5 Web service tools have improved the handling of somewhat complex parameters and return values over version 4. See the Readme file installed with WSAD and also the Mapping properties topic in the WSAD help information for limitations on the handling of simple and complex data types. If you find something WSAD cannot handle, you can always create your own serializers and deserializers; WSAD allows you to specify the (de)serializers in the Java to XML Mappings and XML to Java Mappings panels in the Web Service wizard, but that is beyond the scope of this article.

Reference