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.
Part 1 of this series showed how to use WebSphere Studio Application Developer to develop and unit test a Web service. This article, Part 2 of the series, shows how to use Application Developer to publish the Web service in the WebSphere UDDI Registry, preview version so that the Web service can be used by others. This article also shows how to find a Web service in the UDDI Registry and create a client of the published Web service using Application Developer.
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 2 of the series, is that Application Developer includes the UDDI Explorer, a tool for interacting with UDDI-compliant registries. See Part 1 of the series and the references for more information on Application Developer.
WebSphere UDDI Registry, preview version
UDDI Registry is a UDDI Version 1-compliant registry for Web services intended for deployment to a private intranet environment. UDDI Registry allows Web services developers to publish and test their internal e-business applications in a secure, private environment. UDDI Registry supports the 20 SOAP-based APIs defined by Version 1 of the UDDI specifications, and provides persistence for published entities through a relational database. UDDI Registry includes a Web-based graphical user interface that supports publishing and querying of businesses, services, and other UDDI-compliant entities without programming. UDDI Registry runs on WebSphere Application Server Version 4.0 and IBM's DB2 database. See the Resources section for instructions on obtaining UDDI Registry.
Configuring Application Developer to work with UDDI Registry
For this article, both Application Developer and UDDI Registry were run on the same machine. As mentioned in Part 1 of this series, Application Developer includes and runs its own instance of WebSphere Application Server 4.0 for testing Web services; note that this "test" version of WebSphere Application Server 4.0 is not available to applications outside of Application Developer. As mentioned above, UDDI Registry requires a "production" installation of WebSphere Application Server 4.0 and, in fact, will install it if it is not available.
When simultaneously running Web services in Application Developer
and running UDDI Registry, as we do for this article, conflicts arise, as both
instances of WebSphere Application Server 4.0 attempt to use the same set of
IP ports. Fortunately, it is quite easy to configure the Application Developer
WebSphere Test Environment to eliminate the port conflict by editing the WebSphere
Application Server 4.0 configuration file named server-cfg.xml.
The easiest way to change the port information is to open Application Developer's Server perspective.
In the Server Configuration view, expand Server Configurations and double-click on WebSphere Administrative Domain.
Figure 1. Server Configuration view in the Application Developer

This launches an editor for the server configuration.
In the server configuration editor, click on the Ports tab (at the bottom of the editor) and you will see the following pane:
Figure 2. After clicking the Ports tab in the server configuration editor, this panel opens. Use this panel to change port numbers.

You must change all the port numbers except for the Object level trace port. If your production WebSphere Application Server 4.0 is installed with the default port numbers (as it will be if you use the UDDI Registry installation process), simply add 2 to the other ports -- i.e. change 9000 to 9002, 7000 to 7002, 9070 to 9072 and 900 to 902. If your production WebSphere Application Server 4.0 has different ports, you may have to experiment. When you have saved the changes, close the editor. You can now simultaneously run the test WebSphere Application Server 4.0 in Application Developer and the production WebSphere Application Server 4.0 that supports UDDI.
Publishing a Web service to UDDI Registry using Application Developer
We'll first publish the WeatherForecast Web service created
and tested in Part 1. To do so, we'll use the Application Developer UDDI Explorer.
The information for a WSDL (Web Services Description Language) Web service published
in a UDDI registry contains a reference (URL) to the WSDL documents describing
the Web service. We'll name the host for the UDDI Registry the uddiHost, and
name the host identified in the WSDL URL the wsdlHost. The WSDL documents contain
the information required by a client to actually invoke the Web service (for
example, the location attribute of the soap:address
element). We'll name the host for the Web service, wsHost, and the host for
the client using the UDDI Registry or the Web service, clientHost. In general,
all of these hosts can be different.
In Part 1 of this series, we only required a wsHost and a clientHost; Application Developer's WebSphere Test Environment provided both. For publishing the Web service, we require a clientHost, a uddiHost and a wsdlHost. The clientHost is the Application Developer UDDI Explorer, the uddiHost is the production WebSphere Application Server 4.0 and the wsdlHost is the test WebSphere Application Server 4.0. Therefore, Application Developer, Application Developer's WebSphere Test Environment, and the UDDI Registry must all be running to successfully publish the Web service.
To publish the Web service, go to Application Developer, select the Web Perspective and select the WForecast project. Then select File => Export. On the UDDI Export pane, simply click Finish to start the UDDI Explorer:
Figure 3. The UDDI Explorer

By default, the UDDI Explorer uses the publicly accessible IBM Test Registry (see the Resources section below). We want to point the UDDI Explorer to the local UDDI.
To point the UDDI Explorer to the local UDDI Registry, select UDDI Main in the UDDI Navigator pane of the UDDI Explorer. The Actions pane changes to show entry fields for a Registry Name and Inquiry URL. Enter Local UDDI Registry in the name field and http://localhost/services/uddi/inquiryAPI in the URL field, and press Go. The Explorer adds the Local UDDI Registry to the list in the Navigator pane.
Now select Local UDDI Registry in the Navigator pane. You will see the Actions pane change:
Figure 4. A view of the Actions pane in the UDDI Explorer

If you expect to be using the local UDDI Registry again (and
this article will), you should exploit the UDDI Explorer's ability
to remember "Favorites." You can add Local UDDI Registry
to the favorites list by selecting Add to Favorites (indicated
by the
icon in the Actions pane). The UDDI Explorer will remember the information
for the UDDI and you won't have to enter it again; you can simply
expand Favorites in the Navigator pane.
Before publishing the WeatherForecast Web service, you must
first publish a business, since all services must be owned by a
business. To do so, select Publish Business Entity (indicated
by the
icon in the Actions pane). You will be prompted to enter the publish
URL, a user ID and a password. The URL is http://localhost/services/uddi/publishAPI
and you can use the pre-configured user ID and password, uddiUser
and uddiPwd respectively. Then, select Go. You should receive
a message indicating that "Login to registry Local UDDI Registry
succeeded."
The Actions pane of the UDDI Explorer changes to allow you to enter information about the business:
Figure 5. A view of the changed Actions pane of the UDDI Explorer.

Now you can use this panel to enter information about the business.
The Name is required, but everything else is optional. You can type in a description in the Description field. In the Identifiers table, you can click Add to add a row to the table. You can enter various information, for example, a phone number. Make sure you select the checkbox on the left of any row you add to include that row in the classification.
In the Categories table, to categorize the business, click Add to add a row to the table. To categorize the business as weather-related, in the Type column selection list, select UNSPSC, and then click Browse. A new window pops up; it allows you to select from various UNSPSC categories. For this business, it makes sense to select Meteorology, which is a sub-category of Research and Science-Based Services. Make sure you select the checkbox on the left of any row you add to include that row in the classification.
When you have added all the information you want, click Go to add the business entity to the registry. When the business is published, you will see a confirmation in the Status pane of the UDDI Explorer that the business was successfully published.
To publish the WeatherForecast Web service, you must first
expand Local UDDI Registry in the Navigator pane. You will
see the business you just added. Select it, and the Actions pane
changes to show the information about the service. Click Publish
Business Service (indicated by the
icon in the Actions pane).
The Actions pane now offers you the opportunity to enter the location of the WSDL implementation file and a description of the service and to categorize the service. Select the Browse button next to the WSDL field. The UDDI Explorer launches a dialog that allows you to select the Web project and WSDL file URL for the Web service you wish to publish:
Figure 6. A UDDI Explorer dialog that allows you to select the Web project and WSDL file URL for the Web service that you want to publish

Notice that the UDDI Explorer automatically fills in the required URL for the WSDL implementation file that is required to publish the WeatherForecast Web service (the embedded WebSphere Application Server 4.0 instance in Application Developer must be running for automated entry of the URL). Click Go to enter the URL into the UDDI Explorer Actionspane.
You can also enter a description of the services:
Figure 7. A view of the Actions pane of the UDDI Explorer, with the Description field filled in

We have picked a sub-category of meteorology for categorizing the service, and have also categorized it as a United States-only service.
Click Go to publish the service. When the service is published, you will see a confirmation in the Status pane of the UDDI Explorer that the service interface and the service were successfully published.
While not strictly necessary, it would be helpful to verify that the business and service really were published in the UDDI Registry. To do so, point a browser at http://localhost/services/uddi/home.jsp. Hit UDDI Login in the menu and enter uddiUser and uddiPwd as the user ID and password when prompted. You will see a table of businesses published by UDDI User, the name that corresponds to the user ID, uddiUser. You will see the Weather Business listed in the table. Select the button in the Show Services column of the table for the Weather Business row. You will then see WeatherForecastService listed in the table showing the services for the Weather Business.
Figure 8. WeatherForecastService is now listed in the IBM UDDI Registry table

This confirms that you have successfully published the Web service to the UDDI Registry. This same procedure works with any UDDI Version 1-compliant registry, assuming you have a valid user ID and password.
You've now published a WSDL Web service in a UDDI registry, but what if you want to find a WSDL Web service in a UDDI registry and use that service? Application Developer offers the ability to "import" and use WSDL Web services. To start, create a new Web project. We'll use the name, IWSClient, and give the EAR the name, IWSClientEAR (see Part 1 of the series for details). Select the new project in the Navigation view, and select File => Import. Then, select UDDI and click Next. In the UDDI Import pane, click Finish. This starts the UDDI Explorer.
Figure 9. The UDDI Import pane

In the UDDI Explorer Navigator pane, expand Favorites and you will see the Local UDDI Registry added to the UDDI Explorer Favorites in the previous activity. Expand Local UDDI Registry and you will see the operations that you can take on the UDDI.
Select Find Business Services. In the Actions pane, you can enter a partial service name. For this example, simply enter wea and select Go. The UDDI Explorer finds the relevant services published in the UDDI Registry and displays the results in the Navigator pane:
Figure 10. The UDDI Explorer finds the relevant services published in the UDDI and displays the results in this Navigator pane

Select WeatherForecastService, and the Actions pane now offers a description of the service, as shown below:
Figure 11. The Actions pane now displays a description of the service

Select Import to Workbench (indicated by the
icon in the Actions pane) to import the WSDL. The Actions pane requests
that you confirm that you want to import the WSDL for the Web service
to the IWSClient project in Application Developer. Click Go.
The Status pane indicates success, displaying the message "WeatherForecast-service.wsdl
was successfully imported into Web project IWSClient." You
can now close the UDDI Explorer.
The Application Developer Navigator view now shows that the WSDL file has been imported into the IWSClient project:
Figure 12. The Application Developer Navigator view showing that the WSDL file has been imported into the IWSClient project

In this section, we will use the imported WSDL document to
generate a test client for the WeatherForecast Web service. In this case, Application
Developer's WebSphere Test Environment acts as the clientHost and the wsHost.
Even though the clientHost and the wsHost will once
again be the same, the procedures described will work for Web services hosted
by a different wsHost.
To test the Web service, we need to generate a proxy and a a test client, covered in detail in Part 1. The procedure is slightly different, as shown in the following description. To create the proxy for the Web service from the imported WSDL file, select the IWSClient project, and select File => New => Other. From the New dialog, select Web Services in the left pane and Web Service Client in the right pane.
Figure 13. The New dialog

Then, select Next. You will see the first pane of the Web Services wizard. Verify that the IWSClient Web Project is identified, and select Next.
You'll now see the Web Services File Selection pane. The WSDL file should be selected, so you can click Next.
Figure 14. Application Developer's Web Service File Selection pane

On the following Binding Proxy Generation pane, click Next. Also click Next on the Test Client pane.
On the subsequent Sample Generation pane, select Generate a sample, then Launch the sample, and then click Finish.
Application Developer generates a proxy that the sample client can use to access the Web service described by the WSDL. Further, Application Developer launches the sample client:
Figure 15. The sample client is now launched in the Application Developer

You can now test the Web service (and the proxy) as demonstrated in Part 1 of this series.
This article walked through the steps necessary to use WebSphere Studio Application Developer to publish a WSDL Web service to a UDDI-compliant registry, specifically the WebSphere UDDI Registry. Further, the article showed how to use Application Developer to find Web services in a UDDI registry, import the WSDL describing Web service, and then use the Web service. Application Developer automates, thereby greatly simplifying a number of steps in the process, making the creation and testing of Web services applications much easier.
| Name | Size | Download method |
|---|---|---|
| workspace.zip | 10 KB | FTP |
Information about download methods
- Part 1 of the series describes how to create a Web service using Application
Developer.
- Part 3 of the series describes how to create an application using the Web
service.
- Part 4 of the series describes 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.
- The IBM developerWorks tutorial, Creating a complete Web service, provides an explanation of the example Web service
and discusses earlier versions of the tools described in this article.
- The IBM Test Registry.
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.
Comments (Undergoing maintenance)





