Testing your Web services using the Data Web Services Test Client - Page 2

December 23, 2008

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.








The Network for Technology Professionals

Search:

About Internet.com

Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers