This series of articles employs IBM tools and technologies to develop and deploy Web services-based applications. Specifically, the articles describe how to use the IBM WebSphere Studio Application Developer to develop and test Web services and Web applications, how to deploy the Web services on IBM WebSphere Application Server, and how to publish and find Web services in the IBM WebSphere UDDI Registry.
The first article in this series (see the Resources section) showed how to use WebSphere Studio Application Developer to develop and unit test a Web service. The second article showed how to use Application Developer to publish the Web service in the WebSphere UDDI Registry, preview version so that it can be used by others; the second article also showed how to find a Web service in the UDDI Registry and create a client of the published Web service using Application Developer. This article, the fourth and final part in the series, shows how to deploy the completed Web service to a production WebSphere Application Server, Version 4.0 and then run the application using the production version of the Web service.
WebSphere Application Server Version 4.0
WebSphere Application Server Version 4.0 is a fully supported J2EE-compliant Web application server. It includes built-in support for the fundamental technologies that enable Web services. These technologies include XML, SOAP, WSDL and UDDI. WebSphere Application Server 4.0 simplifies the way Web services are deployed to the application server by integrating the standard Apache SOAP deployment mechanism with the J2EE EAR-based application deployment model.
Essentially, WebSphere Application Server 4.0 embeds a servlet-based gateway to the Apache SOAP engine into each enterprise application along with a pre-deployed registry of Web services that will be exposed. Optionally, you can serve the WSDL documents that describe the Web services by adding those to the enterprise application archive in the form of a new Web module (WAR file). The enterprise application deployment descriptor is modified to enable access to the Web services through the SOAP gateway.
WebSphere Studio Application Developer
WebSphere Studio Application Developer offers the application developer a number of capabilities, including Web application development and testing, XML development and testing, and Web services development and testing (which is the focus of this series). Of particular interest for this article, Part 4 of the series, is that Application Developer generates J2EE enterprise archive files. Further, Application Developer EAR files containing Web services are tailored to match the requirements for deploying Web services in WebSphere Application Server, Version 4.0.
This article assumes that you want to deploy a Web service into a production WebSphere Application Server 4.0 environment that already contains deployed J2EE applications. If this is not the case, Application Developer offers a much simpler way of deploying a Web service (or any J2EE application developed in Application Developer) based on Application Developer's ability to define the production Application Server 4.0 as a "remote" application server and then deploy applications to that remote server. See Application Developer's online help documentation for more information.
There are basically two steps in deploying the Web service:
- Export the Web service from Application Developer.
- Install the application in Application Server 4.0.
Exporting the Web service
Exporting the WeatherForecast Web service that we created in Part 1 is mechanically very simple, since Application Developer maintains the EAR for a Web project. However, there are some additional considerations. First, it is a good idea to add a description of the enterprise application. To do so, open the J2EE perspective in Application Developer, expand Enterprise Applications, and you will see the applications created in the first three parts of the series. See Figure 1 below.
Figure 1. J2EE perspective in Application Developer
Double-click on the WForecastEAR application. You will now see the application editor as shown in Figure 2 below.
Figure 2. The application editor
You can add a description in the Application description field.
The next consideration is a bit more subtle. Remember that when Application Developer created the Web service from the JavaBean, it created a proxy and a set of JSPs to test the Web service, all of which are in the EAR module. While these components could be removed from the EAR module, it is useful to leave them to allow testing of the Web service after installation in Application Server 4.0. There is a catch, however. Application Developer's built-in Web server is configured to listen on port 8080 so that it does not interfere with a production Web server that defaults to listen on port 80. Therefore, the proxy generated by Application Developer sets the URL for the Web service to http://localhost:8080/WForecast/servlet/rpcrouter. The proxy can't contact the Web service deployed in a production Application Server 4.0 (unless the production Web server happens to be listening on port 8080).
To fix this "glitch," in the Navigator view of the
Web Project perspective, expand WForecast/source/proxy/soap/forecast
and then open WeatherForecastProxy.java. Change line 16:
private String stringURL = "http://localhost:8080/WForecast/servlet/rpcrouter";
to
private String stringURL = "http://localhost:80/WForecast/servlet/rpcrouter";
Save the file.
A similar problem exists with the WSDL files describing the service. Both the "binding" and "service" files reference port 8080. You should edit them to reference port 80 instead. Once this is accomplished, the application is ready to be exported.
To export the Web project, in the Navigator view of the Web Project perspective, select WForecastEAR, and then select File => Export. In the Export dialog, select EAR file and then click Next. In the EAR Export dialog, make sure that the resource to export is WForecastEAR and select a destination for the EAR file. Then, click Finish. Application Developer will export the EAR file to the specified location.
Figure 3. The EAR Export dialog box
Installing the application in WebSphere Application Server 4.0
This article shows the proper procedure for WebSphere Application Server, Advanced Single Server Edition, Version 4.0. The procedure will differ slightly for other versions and editions.
To install the Web service in WebSphere Application Server 4.0, you must first start Application Server, then start the Administrator's Console, and log in. In the Console's left panel, expand Nodes and select Enterprise Applications. Then, in the right pane, select Install.
Figure 4. WebSphere Application Server 4.0 window
In the first pane of the Console's Application Installation
wizard, in the Path field, enter the path for the WForecastEAR.ear
file; this should match the destination chosen when exporting the EAR file from
Application Developer. Then, click Next. In the next pane, accept the
defaults and click Next. Then, click Finish. WebSphere Application
Server will install the Web server EAR file, and you will then see Figure 5
below.
Figure 5. The WForecastEAR.ear file is now added to the Enterprise Applications list
Be sure to select Plug-in configuration needs to be regenerated. This will allow WebSphere Application Server to update the configuration for the HTTP server to direct the Web service URL to Application Server. In the subsequent pane, click Generate. After the update is complete, you will again see the above pane. Now, select Configuration needs to be saved. In the subsequent pane, click OK.
Stop WebSphere Application Server and stop your HTTP server. Then, restart your HTTP server and then restart Application Server. The WeatherForecast Web service is now ready.
Now, the Web service is installed in the production WebSphere Application Server, with the following architecture. See Figure 6 below.
Figure 6. The Web service architecture
You can test the Web service using the sample client used in Application Developer's WebSphere Test Environment, since this was installed as part of the enterprise application. Point your browser to the following URL: http://localhost/WForecast/sample/WeatherForecast/TestClient.jsp.
You will see Figure 7 below which looks like the test figures in Part 1.
Figure 7. Web browser pointed to TestClient.jsp
Now, select getForecast in the Methods pane. Enter TX in the State field, and Austin in the City field. Then, select Invoke. You will see something like Figure 8 below.
Figure 8. Web browser result after clicking Invoke
Testing the Web application with the newly deployed Web service
Now that you've confirmed the Web service is deployed and running in the production WebSphere Application Server environment, it would be interesting for us to make the application created in Part 3 use that Web service, rather than the Web service that was deployed in Application Developer's WebSphere Test Environment. Figure 9 below shows the architecture.
Figure 9. The Web service architecture
We will make a copy of the WFClient1 Web project. To do so,
create a new Web project called WFClient2. Don't forget to add soap.jar
and xerces.jar to the Java Build Path. These actions are described
in Part 1 of this series. From the WFClient1 Web project, copy the source/helper
folder, the source/proxy folder, and webApplication/forecast.jsp
into the WFClient2 project. Now close the WFClient1 Web project (right-click
and select Close Project).
Unfortunately, you can't just run WFClient2 and expect it to use the Web service deployed in WebSphere Application Server. The WFClient1 Web project was created to use the Web service deployed in Application Developer's built-in WebSphere run time. As I've already mentioned, the URL for the Web service used by the WFClient2 copy of the Web service proxy references port 8080 rather than 80. The simplest solution is to edit the existing proxy to use port 80, as described above.
After editing the proxy, run forecast.jsp
in the WFClient2 project. After the JSP is fully compiled, you will see the
following results, which should look the same as in Part 3.
Figure 10. The results as seen in the browser after forecast.jsp is compiled
You can now select a state and city. Figure 11 below shows what will be displayed if you select Boston, MA.
Figure 11. The results displayed in the browser if you select Boston, MA
This article walked through the steps necessary to use WebSphere Studio Application Developer to export a Web service that was developed and tested within Application Developer. It showed how to deploy the Web service into a production WebSphere Application Server 4.0 environment and test the Web service in that environment. Finally, it demonstrated how to use the deployed Web service from an application running in Application Developer. The combination of Application Developer and Application Server 4.0 highly automates the process, making the creation, testing, and deployment of Web applications much easier.
| Name | Size | Download method |
|---|---|---|
| workspace.zip | 10 KB | FTP |HTTP |
Information about download methods
- Part
1 of the series describes how to create a Web service using Application
Developer.
- Part
2 of the series describes how to publish and import a Web service using
Application Developer.
- Part
3 of the series describes how to create an application using the Web service.
Greg Flurry is an STSM currently working in IBM's Emerging Technologies group. His responsibilities include advancing IBM's e-business technologies, and specifically, IBM's Web services technologies. You can contact Greg at flurry@us.ibm.com.
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
