5.4 Debugging, Testing and Analyzing Web Services in JDeveloper

You can test and analyze web services in a number of ways. In the life cycle of generating a web service, you could:

Test the deployed web service using Oracle Enterprise Manager. Every deployed service has its own test page, so you can quickly test that the service functions as you expect. For more information, see Section 6.13.1, "How to Test ESB Services Using Oracle Enterprise Manager"
Then test the service using a generated proxy. For more information, see Section 5.3.1, "How to Create a Web Service Proxy".
Perform more detailed testing using the HTTP Analyzer, which allows you to examine the messages sent and received by the service. For more information, search for "Examining Web Services using the Http Analyzer" in JDeveloper's online help.
Once you are satisfied that the service is working correctly, build the UI and retest, using the debugger for the application alongside the HTTP analyzer to examine the XML traffic.

If you are using an external web service in an application, you can check that it conforms to WS-I Basic Profile 2.0. For more information, see Section 5.4.2, "Analyzing Web Services for Interoperability"

5.4.1 Debugging Web Services in JDeveloper

JDeveloper has a fully featured debugger that allows you to debug web services locally on JDeveloper's embedded OC4J server or remotely, either on a deployed version of JDeveloper's OC4J server or on another remote server. For more information, search for "About Debugging Web Services" in JDeveloper's online help.

Note:

Although you can debug a PL/SQL web service, what you are debugging is the Java class generated by JDeveloper to wrap the PL/SQL for deployment as a web service. Therefore, the correct way to ensure that a PL/SQL web service runs as expected is to debug the PL/SQL before you create a web service from it.

5.4.1.1 Locally Debugging a Web Service

Tip:

You need to turn off JDeveloper's proxy settings before locally debugging the service. Remember to turn them back on when you have finished debugging.

When you locally debug a web service, you run the web service in JDeveloper's embedded OC4J server. There are two ways to locally debug the service, and in both cases you create a sample Java client for the web service. The sample Java client contains methods to run against each exposed method in the web service, and it acts as a proxy to the service. You can:

Put breakpoints in the web service class, and then run a sample Java client against it. This procedure allows you to debug the service class itself.
Put breakpoints in the sample Java client.

5.4.1.2 Remotely Debugging a Web Service

JDeveloper lets you debug a web service that is deployed remotely. The web service could be deployed to an external instance of OC4J on the local machine, or it could be a service located on a remote machine. In either case, you will need a connection to the remote server, and the remote server must be running in debug mode.

5.4.2 Analyzing Web Services for Interoperability

A key issue facing web services is how interoperable web services actually are. The important feature of web services is that they use common standards to avoid the problems that earlier solutions, for example CORBA, had. However, the standards themselves are being written at the same time as organizations are writing, deploying, and using web services. This has led to interoperability issues such as web services being written using different standards.

The Web Services-Interoperability Organization (WS-I) was formed by Oracle and other industry leaders to address these issues of interoperability, and to provide tools so that web services can be tested to see how well they interoperate. For more information about WS-I, including the specification, see the web site of The Web Services-Interoperability Organization (WS-I), at www.ws-i.org.

JDeveloper helps you to test the interoperability of web services by analyzing a web service for conformity to the WS-I Basic Profile 1.1. First you have to download a WS-I–compliant analyzer. This is available from the WS-I web site as well as from independent vendors. A set of test assertions is used to find out how well a web service conforms to the basic profile, and information is recorded about the following:

Discovery when a web services has been found using a UDDI registry. If the service has not been found using the Find Web Services wizard, this section of the report returns errors in the Missing Input section.
Description of a web service's WSDL document, where the different elements of the document are examined and con-conformities are reported. An example of a failure in this section is a failure of assertion WSI2703, which gives the message "WSDL definition does not conform to the schema located at http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd for some element using the WSDL-SOAP binding namespace, or does not conform to the schema located at http://schemas.xmlsoap.wsdl/wsdl/2003-02-11.xsd for some element using the WSDL namespace."
Message. This tests the request and response messages when the connection is made to the web services and it sends its reply.

To do this in JDeveloper, search for "WS-I Basic Profile" in JDeveloper's online help and follow the instructions.

Figure 5-19 shows part of the WS-I report of the Credit Service in the SOA Order Booking application.

Figure 5-19 Example of a WS-I Profile Conformance Report

Description of "Figure 5-19 Example of a WS-I Profile Conformance Report"

The report produced is wsi-report.html, and it is located in the directory where the WS-I test tools are located. In this case, the report shows that the CreditService.wsdl is conformant and can be used for contract driven development of Credit Service in the SOA Order Booking application. See Figure 5-20.

Figure 5-20 Summary Section of the WS-I report of CreditService.wsdl

Description of "Figure 5-20 Summary Section of the WS-I report of CreditService.wsdl"

5.4.3 Using the HTTP Analyzer

JDeveloper has a very useful tool, the HTTP Analyzer, that monitors and records the request/response TCP packets and allows you to see the contents of SOAP messages passed when a proxy connects to a web service and the service returns a response.

When you start the HTTP Analyzer, it updates the proxy settings in JDeveloper so that all TCP data is sent through an intermediate port and then on to your original proxy, if one is defined. The proxy settings are restored when you turn the HTTP Analyzer off, or when you exit JDeveloper.

Once you complete the Wizard, you can use the WSDL to create a data control. You can then use the data control to declaratively create a JSF page that can collect the information.

You need to have generated a proxy to a working web service. For more information, see Section 5.3.1, "How to Create a Web Service Proxy"

To use the HTTP Analyzer the web service:

Display the HTTP Analyzer. From the View menu, choose HTTP Analyzer.
Click the green button to start the analyzer.
Run the generated proxy. The HTTP Analyzer displays the request/response packets.

For further information, search for "Using the Http Analyzer" in JDeveloper's online help.