![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
This series of four articles employs the latest IBM ®; WebSphere®; tools and technologies to develop and deploy Web services-based applications. Specifically, the articles describe how to use IBM WebSphere Studio Application Developer V5.0 (hereafter called Application Developer) to develop and test Web services and Web applications, how to deploy the Web services on IBM WebSphere Application Server V5.0 (hereafter called Application Server), and how to publish and find Web services in a UDDI Registry.
Part 1 of this series showed how to use WebSphere Studio Application Developer V5.0 to develop and unit test a Web service. Part 2 showed how to use Application Developer to publish and find Web services in a UDDI Registry. Part 3 showed you how to use Application Developer to create and test a Jakarta Struts-based Web application that uses a Web service. This article, Part 4, shows how to deploy the completed Web service to a production WebSphere Application Server, and then run the application using the production version of the Web service.
WebSphere Application Server V5.0
WebSphere Application Server V5.0 is IBM's J2EE-compliant Web application server. It includes built-in support for the fundamental technologies that enable Web services, including XML, SOAP, WSDL, and UDDI. WebSphere Application Server V5.0 simplifies the way Web services are deployed to the application server by integrating the Apache SOAP deployment mechanism with the J2EE EAR-based application deployment model.
WebSphere Application Server V5.0 embeds a servlet-based gateway to an enterprise-ready implementation of the Apache SOAP engine into each J2EE enterprise application, along with a pre-deployed registry of the Web services that will be exposed. Optionally, you can serve the WSDL documents that describe the Web services by adding them to the enterprise application archive (EAR) file 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 V5.0
WebSphere Studio Application Developer V5.0 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 is that Application Developer V5.0 generates J2EE EAR files ready for deployment in J2EE environments such as WebSphere Application Server V5.0. Furthermore, Application Developer EAR files containing Web services are tailored to match the requirements for deploying Web services in WebSphere Application Server V5.0.
Deploying a Web Service developed in WebSphere Application Server V5.0
This article assumes that you want to deploy a Web service into a production WebSphere Application Server V5.0 environment that already contains deployed J2EE applications. There are basically two steps in deploying the Web service:
- Export the application containing the Web service from Application Developer V5.0.
- Install the application in Application Server V5.0.
Before exporting the EAR module containing the Web service, you must account for differences between the development and deployment environments. When Application Developer created the Web service in Part 1, it created WSDL files describing the Web service. The Web service "endpoint" in the WSDL references the Application Developer WebSphere Test Environment (WTE), which defaults to listen on port 9080 so that it does not interfere with a
production
WebSphere server environment, which defaults to listen on port 80. To correct this for deployment in a production environment, in the J2EE view of the Web perspective, expand the WForecast project, expand the Web Content folder, expand the wsdl folder, and finally the forecast folder. Double-click on WeatherForecastService.wsdl to edit the file. Find the
<soap:address>
element near the end of the file and change the port to 80. save the file.
A similar problem exists with the proxy generated by Application Developer for testing the Web service. Remember from Part 1 that when Application Developer created the Web service from the Java bean, it created a proxy and a set of JSPs to test the Web service, all of which are in the EAR module (though in Application Developer V5.0, in a different Web project). 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 V5.0. The proxy generated by Application Developer sets the endpoint URL for the Web service to
http://localhost:9080/WForecast/servlet/rpcrouter
. The proxy can't contact the Web service deployed in a production Application Server V5.0 environment (unless the production Web server happens to be listening on port 9080). To fix this "glitch,", in the J2EE view of the Web perspective, expand the WForecastClient project, expand the Java Source folder, expand the proxy.soap package, and then open WeatherForecastProxy.java. In line 18, which contains the URL, change the port number to 80. Save the file.
Finally, it's a good idea to add a description of the enterprise application before exporting it. To do so, expand the WForecastEAR project, and then expand the META-INF folder. You'll see the application.xml file that describes the EAR, as shown in Figure 1. Double-click on the file to edit it.
Figure 1. The application.xml file in the Web Perspective.
You will now see the enterprise application editor, as shown in Figure 2. Click on the Overview tab, and then enter a description in the Description field. Save the file.
Figure 2. Enterprise Application Editor.
Now the application containing the Web service is ready to be exported. To do so, in the J2EE view of the Web perspective, select WForecastEAR and then select File => Export. In the Export dialog, select EAR file and then click Next. In the EAR Export dialog, shown in Figure 3, make sure that the resource to export is WForecastEAR, select a destination for the EAR file, and then click Finish. Application Developer will export the EAR file to the specified location.
Figure 3. EAR Export dialog.
Installing the application in WebSphere Application Server V5.0
This article shows you how to install the application in Application Server V5.0 for Windows. The procedure may differ slightly for other editions and versions of WebSphere Application Server.
To install the Web service in Application Server V5.0, start Application Server, start the WebSphere Administrative Console, and then log in. (To start Application Server, you may first have to stop the Application Developer WTE.) In the Administrative Console's left panel, expand Applications and select Install New Application. In the right pane, shown in Figure 4, in the Local Path field, enter (or browse to) the EAR file that you exported from Application Developer. Then click Next.
Figure 4. Installation: entering the EAR location.
In the subsequent panel, select the Generate Default Bindings option and click Next. In the next panel (called "Step 1: Provide options to perform the installation"), simply click Next. In the next panel, shown in Figure 5, select both the WForecast and ForecastClient Web modules to be installed in the
default_host
. Click Next.
Figure 5. Installation: Hosts for Web modules.
In the next panel (called "Step 3: Map modules to application servers"), again select both the WForecast and WForecastClient modules to be installed. Click Next. In the subsequent panel (called "Step4: Summary"), check that all the options you've chosen are correct, and then click Finish. In a few moments, you should see a confirmation that installation was successful, as shown in Figure 6. To complete the installation, click Save to Master Configuration. In the resulting Save dialog, click the Save button.
Figure 6. Installation: confirmation
After the Administrative application saves the configuration, it returns to the initial dialog. Now in the left panel, click Enterprise Applications. You will see a list of applications installed on your Application Server, similar to that shown in Figure 7. The WForecast application is stopped, as indicated by the red X in the right column of the application table. You must select the WForecastEAR and then click Start. The status will change to a green arrow, indicating that the application can be used. Congratulations! You've deployed the Web service in Application Developer.
Figure 7. Installation: application status.
The Web service and test client are now installed in the production Application Server environment. These make up the run-time architecture shown in Figure 8. The client, represented by the JSPs and the proxy, reside in one Web application, while the Web service and the associated SOAP server reside in another.
Figure 8. Web service architecture deployed in the Application Server.
You can test the Web service using the test client. Point a browser to the following URL (assuming Application Server is configured to listen for HTTP requests on port 80):
http://localhost/WForecastClient/sample/WeatherForecast/TestClient.jsp
. You will see something similar to Figure 9, which looks like the test figures in Part 1. This confirms successful deployment of the Web service.
Figure 9. Web browser pointed to TestClient.jsp.
Testing the Web application with the newly deployed Web service
Now that you've confirmed that the Web service is deployed and running in the production Application Server environment, it would be interesting to make the Struts-based application created in Part 3 use that Web service, rather than the Web service that was deployed in the Application Developer WTE. Figure 10 below shows the run-time architecture, which is quite typical of many real application environments. The Web service is deployed in one production Application Server environment, and the application that uses the Web service is deployed in another environment, in this case the Application Server Test Environment built into Application Developer (the WTE).
Figure 10. A typical Web service architecture.
There is some preparation required. An Application Server instance uses several ports. The architecture in Figure 10 requires two instances of Application Server, and the ports cannot be shared. Therefore, to enable two instances to run simultaneously, we must change the ports used by one them. It is easiest to change the ports used by the Application Developer WTE. To do so, go the Server Configuration view of the Web perspective. Double-click on the WebSphere V5.0 Test Environment to open its editor. Click the Ports tab in the editor, and then scroll down to see the Server Settings, as shown in Figure 11. In the HTTP transport list, you must change the second port from 9443. In the Advanced ports, you must change the ORB bootstrap port from 2809 and the SOAP connector port from 8880. In Figure 11, those three ports have been incremented by one. Save the configuration.
Figure 11. Configuring the server ports.
Remember that the proxy generated by Application Developer uses port 9080, as discussed above. To run the Struts-based application, you need to change the proxy to use port 80, the default for the production Application Developer when the Web service is running. The procedure is the same as described above for changing the proxy for the exported test client, though you must of course change the proxy in the
WFClient1
Web project. Save the proxy and start the test environment server.
To run the application, go the J2EE Navigator view, right-click on the WFClient1 project, and then click Run on Server. Application Developer will start a Web browser and point it at the URL for the project:
http://localhost:9080/WFClient1/
. You can drive the application the same way as shown in Part 3. Figure 12 shows the results of selecting Texas as the state and Austin as the city:
Figure 12. Running the Struts-based application.
This article showed you how to use WebSphere Studio Application Developer V5.0 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 V5.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 V5.0 and Application Server V5.0 highly automates the process, making the creation, testing, and deployment of Web applications quite simple.
Greg Flurry is an Senior Technical Staff Member on the IBM Software Group Emerging Technologies team at the IBM Austin Lab in Texas. His responsibilities include advancing IBM e-business technology. You can contact Greg at flurry@us.ibm.com.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
