In part 12 of this series, Paul Zikopoulos delves into the Web Services Explorer, one of the testing facilities for your Web services that is included in IBM Data Studio Version 1.1 and Version 1.2.
In the first eleven parts of this series, Ive introduced you to some of the many features available within the IBM Data Studio integrated development environment (IDE) thats available for use with the IBM data servers. Specifically, Ive shown you how to set up and use database connection objects, the features available when working with these 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, and how to create an SQL statement using either the SQL Builder or the SQL Editor in IBM Data Studio. Ive also shown you how to take the FEMALEPERSONNEL SQL statement built in previous installments and quickly turn that into a stored procedure using IBM Data Studio, and finally how to wrap both the SQL statement and the stored procedure as a Web service.
In Part 11, I showed you how to use SOAP to invoke the SQL statement that you wrapped as a Web service. I have a lot more to show you because IBM Data Studio comes with a number of rich testing interfaces that make it easy to sanity check your Web services. In this article, Im going to delve into the Web Services Explorer, one of the testing facilities for your Web services that is included in IBM Data Studio Version 1.1 and Version 1.2. In Data Studio Version 1.2, the IBM Data Web Services Test Client became the preferred testing facility for IBM Data Web Services (IBM DWS); however, Im covering the Web Services Explorer in this article because many users are still running Data Studio Version 1.1. In the next part of this series, I will show you how to test your Web services using the IBM Data Web Services Test Client.
Getting ready for this article
I assume in this article that you performed the steps in DB2 9.5 and IBM Data Studio Part 11: Transforming Business Logic into a Web. 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. The Servers tab should look like this:
Testing IBM Data Web Services in IBM Data Studio
In Data Studio Version 1.2, there are two testing facilities that help you test and perform quality assurance on your Web services. When you built and deployed your Web service in Part 11, you saw the Test box in the Deploy Web Service window:
The previous figure shows the same options that you used to create your Web services in Part 11. As you can see, your Web service was only enabled for testing using the Web Services Explorer. In order to select the Launch Web Services Explorer after deployment check box, you have to deploy the Web service to a server. (As you can see, the Server radio button is selected.) The Web Services Explorer testing option is not available if you select the Build deployable files only, do not deploy to a Web server radio button this restriction does not apply to the Data Web Services Test Client.
Using the Web Services Explorer to test a Web service
Since the Web service you created in Part 11 is enabled for testing using the Web Services Explorer, you can test your Web service by right-clicking the SOA_FEMALEPERSONNEL Web service project, and selecting Launch Web Services Explorer:
The Web Services Explorer window opens (and should look similar to the window you saw in Part 11). Test the FEMALEPERSONNEL Web service (it wraps the FEMALEPERSONNEL SQL statement) as you did in Part 11. To do this, select the appropriate Web service (note that you are selecting the SOAP invocation of this service) and click Go in the Actions pane. The results of this operation are shown in the Status pane.
As you can see, the Status pane shows the results of your Web service. You can maximize the Status pane view by double-clicking anywhere within the label. (See the highlighted rose portion of the figure below; I added the color for emphasis.)
Double-clicking the highlighted area again toggles the Status pane back to its regular size. You can see that the Web service test results are formatted for viewing this default presentation mode is referred to as the Form view in IBM Data Studio.
You can resize any of the panes in the Web Services Explorer by clicking within the rose areas shown below, and dragging a specific pane vertically or horizontally:
You can click Source in the Status pane to see the SOAP request and response envelopes for this SOAP-invoked Web service:
The SOAP Request Envelope is how an application would invoke the Web service using the SOAP protocol. The SOAP Response Envelope shows the response from the database to the application that invoked the Web service. As you can see, XML is at the core of SOAP response and request envelopes; for this reason, XML is often referred to as the payload for Web services.
If you consider the transactional nature of Web services and the new era of application opportunities that they create, it should become clear why the handling of XML data in a data server is poised to become one of the most differentiating features of a data server. This is one of the main reasons why IBM invested in the pureXML technology found in DB2 software because it enables IT shops to store and search the XML in ways never available before. Now imagine a business that wants to store its credit risk scores or transactions for governance and reporting purposes; that business operations output is in XML if it comes from a SOAP-invoked Web service and the actual transaction can be stored in DB2 software with all its fidelity in its natural form.
To return to the form view, click Form.
You use the Actions window to test the Web service. This pane can display either the source code or the form that IBM Data Studio automatically provides to test the Web service. As with the Status pane, you can toggle between the form and the source views using the appropriate links:
The automatic form generation to test Web services in IBM Data Studio is a very useful feature that allows database administrators (DBAs) to quickly test their Web services without the need for help from a development team to invoke the service. This way, DBAs can be assured that the Web service is returning data that they expect before passing it to the Web development team; they dont have to interrupt the Web development for basic testing.
The Web services built in this tutorial dont take input parameters, and therefore the benefits of the auto-form generation may not be as apparent. Consider exposing a stored procedure, called STAFFSELECTOR, that was built from the following SQL statement: SELECT * FROM STAFF WHERE DEPT=:DEPTNUMB. This stored procedure returns personnel details of an enterprises staff based on a department number. If you exposed this stored procedure as a Web service, IBM Data Studio would auto-generate a form that looks similar to this one:
As you can see in the previous figure, the auto-generated form has the DEPTNUMB field where you can specify the input parameter. To test this Web service, a DBA simply enters an input parameter in this field and clicks Go to pass the input parameter to the Web service and invoke it.
So far Ive shown you how to test your SOAP-based Web services. You can use the Web Services Explorer to test your REST-based Web services as well. Its outside the scope of this article to delve into the technical aspects of REST-based Web services, but they are invoked using HTTP GET and POST methods using a simple URL. (This should be apparent if you look closely at the artifacts that IBM Data Studio automatically creates for you in the Navigator pane.)
You can see in the previous figure that the Navigator pane in the Web Services Explorer has three expandable artifacts. Each has a suffix that identifies the way in which the Web service will be invoked (SOA_FEMALEPERSONNELHTTPGET method using REST, SOA_FEMALEPERSONNEL HTTPPOST method using REST, or SOA_FEMALEPERSONNEL SOAP using SOAP).
For example, to test your Web service using the REST protocols GET method, expand the appropriate artifact in the Navigator pane and invoke it in the same manner you tested the SOAP invocation of the same Web service:
Notice that when you invoke this Web service using the REST protocol, there is no Source link as was the case in the SOAP-invoked Web service test. Thats because when you invoke a Web service using the REST protocol, you simply pass a URL from the requesting application to the data server.
You can see the output of a REST-based Web service is also in XML format:
As Ive previously noted, REST-based Web services are invoked with a simple URL; therefore, it stands to reason that you should be able to open a Web browser and invoke the Web service that you built and locally deployed on the started IBM WebSphere Application Server Community Edition application server thats running on your server.
IBM Data Studio generated a WSDL file for your Web service invocations, and within that file you can quickly copy and paste the URL for the corresponding Web service. The convenience of this feature will help immensely when you test your Web service using a REST-based invocation.
To test your REST-based Web services directly from a Web browser, perform the following steps:
1. Select the URL of the deployed Web service project, as shown below:
2. Copy and paste the URL from the WSDL URL field in the Actions pane. In this example, the URL that points to the WSDL file is: http://localhost:8080/DatabaseJournalProjectSOA_FEMALEPERSONNEL/wsdl.
3. Open a Web browser window.
4. Enter the URL from Step 2 into the browsers address field, and press Enter. The WSDL file is displayed:
5. Since we want to invoke our Web service using the REST protocol and the associated HTTP GET method, scroll to the bottom of the WSDL file and locate the <http:address location> element for the GET <wsdl:port binding> invocation of the Web service:
Note: Ensure that you only select the URL highlighted in the previous figure; note that this does not include the quotation marks ( ) that surround the URL.
6. Copy and paste the URL from the previous step into your Web browser. This will create an error:
Note: Im only including this step to make the invocation of the Web service more procedural and easier to follow. As you become more accustomed to calling REST-based Web services, you can simply skip this step.
7. Append the name of the Web service created in this series (FEMALPERSONNEL) to the URL entered in the previous step, and then press Enter. For example: http://localhost:8080/DatabaseJournalProjectSOA_FEMALEPERSONNEL/FEMALPERSONNEL.
As you can see, your Web service was invoked using the REST protocol directly from your Web browser:
Wrapping it all up
In this article, I showed you how to use the IBM Web Services Explorer to test multiple message protocols to invoke the Web service that you created in this series. Whats more, I showed you how easy it is to invoke your Web service using the REST protocol directly from any Web browser by leveraging the WSDL file that IBM Data Studio automatically created for you. In the next article, Im going to introduce you to the Data Web Services Test Client; I feel this is a more feature-rich and capable testing tool, but its only available for IBM Data Studio Version 1.2 and later, which is why I wanted to ensure that you knew how to use the IBM Web Services Explorer too.
» See All Articles by Columnist Paul C. Zikopoulos
IBM, DB2, pureXML, and WebSphere are trademarks or 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.
The opinions, solutions, and advice in this article are from the authors 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 authors knowledge at the time of writing.