Testing a Web service using IBM Data Studio and the Data Web Services Test
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.
the SOA_FEMALEPERSONNEL Web service that you built and deployed in Part 11,
perform the following steps:
Select the SOA_FEMALEPERSONNEL
Web service, right-click, and select Build and Deploy:
If youre following along in this series, you will recall
that the SOA_FEMALEPERSONNEL Web service you built before cant use the Data
Web Services Test Client; this is why you have to rebuild and redeploy the Web
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
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.
The Data Web
Services Test Client opens within IBM
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 doesnt
accept input parameters (like the operations weve exposed within the Web
service deployed in this series), then this section will inform you of that.
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 thats 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, its 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.
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 wasnt
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 Ive
discussed thus far in this article):
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
This is an example of the Response String for our Web service with a
SOAP binding type:
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:
from the Operations section and the JSON binding type radio
button (new in the Data Web Services Test Client), and then click Submit
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
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
wasnt 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.