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

1.  Select the SOA_FEMALEPERSONNEL Web service, right-click, and 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.

These are the same settings used in Part 12, except for those in the 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:

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:

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:

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

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.

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.)

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):

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:

This is an example of the Response String 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:

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":{}}.