Testing your Web services using the Data Web Services Test Client

Tuesday Dec 23rd 2008 by Paul Zikopoulos
Share:

Paul Zikopoulos introduces you to the Data Web Services Test Client that's available in IBM Data Studio Version 1.2 or later

In the first twelve parts of this series, I’ve introduced you to some of the many features available within the IBM Data Studio integrated development environment (IDE) that’s available for use with the IBM data servers. Specifically, I’ve shown you how to set up and use database connection objects, how to generate an overview diagram of your database architecture, how to build OLE DB functions that can be used to easily integrate data from external data sources that have an OLE DB provider, how to create an SQL statement using either the SQL Builder or the SQL Editor in IBM Data Studio, and how to take an SQL statement and quickly turn it into a stored procedure. I’ve also shown you how to wrap both an SQL statement and a stored procedure as a Web service, and how to test your Web service using the Web Services Explorer.

In this article, I’m going to introduce you to the Data Web Services Test Client that’s available in IBM Data Studio Version 1.2 or later.

Getting ready for this article

I assume in this article that you performed the steps in “Part 12: Testing your Web Service using the Web Services Explorer”. From there, all you need to do in order to follow the steps in this article is ensure that the application server you defined and deployed your Web services to in Part 11 is started and running such that the Servers tab looks like this:

Click for larger image
the Servers tab

I assume that your Data Project Explorer view looks similar to the following view:

Data Project Explorer

Why the need for the Data Web Services Test Client?

The Data Web Services Test Client provides a number of advantages over the Web Services Explorer for testing your Web services. For example, the Data Web Services Test Client includes options for testing additional message protocols and binding types such as JSON and HTTP POST, which just aren’t available with the Web Services Explorer. In addition, the Data Web Services Test Client provides a richer interface and visualizations of the request and response headers and documents. With the Web Services Explorer, you had to navigate through different views to see the request and response envelopes, and didn’t have easy access to other key artifacts such as the WSDL file and more.

Perhaps the best part is that the Data Web Services Test Client is deployed with your Web services. In other words, you can open it on your Web server using a Web browser; there is no need to install IBM Data Studio. (If you recall, in the last part of this series I noted what I like most about the Data Web Services Test Client: you can test services such as a REST-based Web service using a browser without all of the manual steps required by the Web Services Explorer.) Of course, you can use the Data Web Services Test Client within IBM Data Studio too, if you have this software installed. Depending on your role in your organization, this may be a benefit. I’ll show you how to test the Web service we built in the last part of this series using the Data Web Services Test Client launched both ways--from within IBM Data Studio, and separately from a Web browser.

Testing a Web service using IBM Data Studio and the Data Web Services Test Client

To use the Data Web Services Test Client to test a Web service, you have to ensure that you include it during the deployment phase of the Web Service. When you build and deploy a Web service using IBM Data Studio you have the option to automatically launch the Data Web Services Test Client in a browser-based window within IBM Data Studio after the Web service successfully builds.

To test the SOA_FEMALEPERSONNEL Web service that you built and deployed in Part 11, perform the following steps:

1.  Select the SOA_FEMALEPERSONNEL Web service, right-click, and select Build and Deploy:

Select Build and Deploy

If you’re following along in this series, you will recall that the SOA_FEMALEPERSONNEL Web service you built before can’t use the Data Web Services Test Client; this is why you have to rebuild and redeploy the Web service.

2.  The Deploy Web Service window opens. In your Deploy Web Service window, specify the options shown below, and click Finish.

specify the options in your Deploy Web Service window

These are the same settings used in Part 12, except for those in the Test box.

Test box

In this case, the Include Data Web Services test client and Launch test client after deployment check boxes are selected, and the Launch Web Services Explorer after deployment check box is not selected.

As its name suggest, the Launch test client after deployment check box instructs IBM Data Studio to launch the Data Web Services Test Client if the deployment (or redeployment in this case) of the Web service is successful.

3.  The Data Web Services Test Client opens within IBM Data Studio:

Data Web Services Test Client

As you can see in the previous figure, there are a number of different fields in this window, and the client looks quite different from the Web Services Explorer.

The Operations section lists the Web services that are deployed on the application server:

The Operations section

As you can see, both the FEMALEPERSONNEL SQL statement and the SP_FEMALEPERSONNEL stored procedure are part of the deployed Web service.

The Parameters section is used to pass input parameters to the invocation of the Web service. If the operation you want to test doesn’t accept input parameters (like the operations we’ve exposed within the Web service deployed in this series), then this section will inform you of that. For example:

No input parameters for this operation

However, if you had a stored procedure that accepted an input parameter, the Parameters section might look like this:

Parameters section

You can see in the previous figure that empno is an input parameter for a stored procedure that’s exposed as a Web service. You can see the Data Web Services Test Client tells you the type of input parameter the Web service is expecting. (In this case, it’s a string as indicated by the xsd:string entry in the empno field.) If you want to pass the Web service a NULL value for the input parameter, you would select the Null? check box.

In the Binding Types section, you select the radio button that corresponds to the test interface for the deployed Web service. As you can see, this is a lot easier than in the Web Services Explorer, where you had to individually seek out the corresponding binding type and invoke the Web service. In addition, more binding type options are available for testing, such as the JSON binding type, which feeds Web 2.0 technologies.

Binding Types

The WSDL links takes you to the generated WSDL file that describes this Web service:

The WSDL links takes you to the generated WSDL file that describes this Web service

Note: When you click the WSDL link, it uses the same browser window within IBM Data Studio to display the contents of the WSDL file. The problem is that when you are finished with the WSDL file, the Data Web Services Test Client window that you were using is no longer open. To return to it, you can right-click within the WSDL window and select Back. If you ever want to launch the Data Web Services Test Client, even without building and deploying a Web service, simply ensure the target application server where the Web service is deployed is started, and then select the Launch Data Web Services Test Client option. (This option is only available if the Web service has already been built and deployed. In this article you had to rebuild and redeploy the Web service because it wasn’t originally built to support the Data Web Services Test Client.)

Data Project Explorer

The Console section is where you can view the request and response strings for the Web service. At the top of this section are Minimize and Maximize buttons that you can use to collapse and expand the upper section of the Data Web Services Test Client (the portions I’ve discussed thus far in this article):

The Console section

4.  Select FEMALEPERSONNEL from the Operations section and the SOAP binding type radio button, and then click Submit Request (which becomes highlighted when you select an operation and a binding type).

After the Web service executes, you can inspect the Request String and Response String sections for the respective documents. This is an example of the Request String for our Web service with a SOAP binding type:

an example of the Response String for our Web service with a SOAP binding type

This is an example of the Response String for our Web service with a SOAP binding type:

an example of the <strong>Response String </strong>for our Web service with a SOAP binding type

5.  Select FEMALEPERSONNEL from the Operations section and the HTTP GET binding type radio button, and then click Submit Request.

Compare the Request String and Response String sections with their counterparts in the previous step. You can see that the Request String documents are quite different (indicative of the different binding type used to invoke the Web service). While the Response Header of the Response String is different, as you would expect, the Response Document (the data within an XML document) is the same:

Compare the Request String and Response String sections with their counterparts

6.  Select FEMALEPERSONNEL from the Operations section and the JSON binding type radio button (new in the Data Web Services Test Client), and then click Submit Request.

Again, compare the various request and response documents with those for the previous two binding types. For example, the way a Web 2.0 application would invoke this Web service using the JSON notation would look like this: {"FEMALEPERSONNEL":{}}.

As I mentioned earlier, you only need to rebuild and redeploy a Web service using the Include Data Web Services test client option if the Web service wasn’t originally built with this option. At this point in this series, our Web service is now deployed with this option. Therefore, in future sessions, once the hosting application server is started, you can test your Web service by bringing up the Data Web Services Test Client directly from the Data Project Explorer view as detailed in the note in Step 3, or directly from a Web browser as detailed in the next section.



Testing a Web service using the Data Web Services Test Client without IBM Data Studio

One of the main benefits of the Data Web Services Test Client is that it can be launched and used to test your Web services independently of the IBM Data Studio IDE.

To launch the Data Web Services Test Client from a Web browser without a local copy of IBM Data Studio installed, enter the URL of your application server and the Web service of the form: http://server:port/context_root.

The server keyword is the hostname (or IP address) of the application server. In this series, since I’ve assumed you’ve installed IBM WebSphere Application Server Community Edition on your local machine, you can just use localhost to represent the IP address or hostname of your server.

The port keyword is the port number that the application server is listening on for incoming requests. We defined this when we configured the target application server in the Servers tab in Part 11 “Transforming Business Logic into a Web Services”.

If you don’t remember this port number, in the Servers tab, select that target application server, right-click, and select Open, as shown below:



in the Servers tab, select that target application server, right-click, and select Open

The Server Overview window opens:

The Server Overview window opens

The HTTP Port field in the Port Configuration section shows the port that this application server is listening on; the default port number that IBM WebSphere Application Server Community Edition (Application Server/CE) listens on is port 8080.

In the Security section, you can see the default user ID and password for the target installation for Application Server/CE. Use this user account information to log into Application Server/CE and manage the application server itself using the built-in link to the application server’s management console. To launch this console, select the application server, right-click, and select Launch Community Edition Console:

Launch Community Edition Console

The context_root keyword is a string that represents the data development project name, the name of the Web services project, and the name of the Data Web Services Test Client Web page. In this series, the name of the data development project is DatabaseJournalProjectSOA, the name of the Web service built is SOA_FEMALEPERSONNEL, and the Data Web Services Test Client application resides in the TestClient folder and is called testClient.html. Therefore, to launch the Data Web Services Test Client directly from any Web browser, in our example, you would enter the following URL: http://localhost:8080/DatabaseJournalProjectSOA_FEMALEPERSONNEL/TestClient/testClient.html as shown below:

the Data Web Services Test Client

At this point, just follow the steps outlined in this article to test the Web service; after all, it’s the same rich testing application that you used within IBM Data Studio.

Wrapping it all up

In this article, I showed you a richer testing interface provided by the IBM Data Web Services component called the Data Web Services Test Client. This client provides a richer and more user-friendly environment for testing your Web services. As I showed you, the Data Web Services Test Client can be launched from within IBM Data Studio or externally from a Web browser, with no installation of IBM Data Studio required. In the next article, we’re going to create a more complex Web service to introduce you to the Extensible Stylesheet Language Transformation (XSLT) capabilities of IBM Data Studio; I will show you how to transform the XML output from the Web services tested thus far into a format used for a target application.

» See All Articles by Columnist Paul C. Zikopoulos

Trademarks

IBM, DB2, and WebSphere are registered trademarks of International Business Machines Corporation in the United States, other countries, or both.

Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

Copyright International Business Machines Corporation, 2008.

Disclaimers

The opinions, solutions, and advice in this article are from the author’s experiences and are not intended to represent official communication from IBM or an endorsement of any products listed within. Neither the author nor IBM is liable for any of the contents in this article. The accuracy of the information in this article is based on the author’s knowledge at the time of writing.

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved