Using WS-I Test Tools

An Oracle JDeveloper How To Document
Written by Susan Duncan
March, 2004

Contents

Introduction
Install Test Tools
Test the WSDL description of a service
Test the messages of a running service
Test the Discovery of a service via a UDDI registry

Troubleshooting
Conclusion

Introduction

The Web Services-Interoperability Organization (WS-I) was formed by Oracle and other industry leaders to promote the interoperability of web services technologies across a variety of platforms, operating systems, and programming languages. JDeveloper provides tools that allow you to test the interoperability of web services by checking that the services conform to the WS-I Basic Profile 1.0.

WS-I analyzes web services for interoperability across three areas:

A set of test assertions is used to test a web service for conformity across these areas.

This How To document describes the steps to analyze a service for conformance to the Basic Profile using JDeveloper's integrated WS-I testing environment. The TCP Monitor is used to monitor and log running web services and you can use any WS-I conformant analyzer and test assertions (called the testing tools) to check conformance with the Basic Profile. In this document, you use the tools provided by WS-I.

Using JDeveloper a tested web service can be:

Install Test Tools

  1. Download and extract the Java version of the testing tools from http://www.ws-i.org/implementation.aspx. At the time of writing, the latest version of the tools available is WS-I Testing Tools - Board Approval Draft (v1.0.1) for testing Basic Profile version 1.0
  2. In JDeveloper, open the Preferences dialog and navigate to the WS-I Testing Tools preferences.
    1. Set the Home Location to your stored testing tools location
    2. A Test Assertions document is included as part of the testing tools that you downloaded in the step above so you can leave the Specify Test Assertions Document check box blank. However, if you wish to use your own set of assertions, specify its location here.
    3. You will use JDeveloper's TCP Monitor to monitor and log your services. Check the checkbox and specify where you want the log to be stored.
    4. If you do not want to overwrite the log file each time you run the TCP Monitor, then uncheck the checkbox and each run will be appended to the same wsi-log document.

Test the WSDL description of a service

This How To uses an Oracle J2EE web service as an example, you can also generate an Apache SOAP web service and a JAX-RPC web service using the JAX-RPC extension available from OTN. It is outside the scope of this How To to provide a detailed description of publishing and running a web service.

Running the Analyzer against the WSDL file

  1. Create HelloWorld Java class

    public class HelloWorld
    {
    public HelloWorld()
    {
    }
    public String sayHello(String name)
    {
    return "Hello" + name;
    }
    }

  2. Publish as Oracle J2EE web service named HelloService
  3. If the Log window is not open, use the menu View -> Log Window to display it
  4. Use context menu of generated HelloService to analyze the WSDL file


  5. Note that the log window returns the messages from the WS-I testing tool. The WS-I tools and output are fully integrated into the JDeveloper IDE

    D:\wsi-test-tools>
    D:\myJDEV\jdev\mywork\wsia.bat -config "D:\mywork\1555\jdev\mywork\analyzerConfig.xml"
    WS-I Analyzer Tool, Version: 1.0, Release Date: 2003-10-16Copyright (C) 2002-2003 by The Web Services-Interoperability Organization and Certain of its Members. All Rights Reserved.
    Use of this Material is governed by WS-I licenses included within the documentation.
    verbose .................... false
    Assertion Results:
    type ..................... all
    messageEntry ............. true
    assertionDescription ..... false
    failureMessage ........... true
    failureDetail ............ true
    Report File:
    replace .................. true
    location ................. D:\wsi-test-tools\java\wsi-report.xml
    Style Sheet:
    href ................... ../common/xsl/report.xsl
    type ................... text/xsl
    testAssertionsFile ......... file:/D:/wsi-test-tools/common/profiles/BasicProfileTestAssertions.xml
    WSDL Reference:
    WSDL Element:
    type ................... port
    namespace .............. http://mypackage/HelloWorld.wsdl
    name ................... HelloWorldPort
    parentElementName ...... helloService
    wsdlURI .................. file:/D:/mywork/1547/jdev/mywork/WSI_Test/Project/src/mypackage/IHelloService.wsdl

    Please wait while the specified artifacts are analyzed...
    WS-I conformance report has been created.

  6. Note that the WS-I Profile Conformance Report (wsi-report.html) is generated and opened for viewing

Reading the Conformance Report

  1. Scroll down to the Summary section. Note that, overall, this WSDL file has failed. Also note that the report is broken into the three areas (discovery, description, message)



  2. Scroll down to the Artifact: discovery section. The discovery section covers the conformance of a web service's entry in a UDDI registry. In this example a UDDI registry was not used - so all the assertions are flagged as Missing Input. Note: Missing inputs do not constitute failure, however you should check that you are expecting missing inputs (as in this case).



  3. Scroll down to the Artifact: description section
  4. Scroll down through the Summary Table and notice that there are entries in the Passed, Failed, Not applicable and Missing Input sections
  5. In the Entry list table click on the Reference Id for the types type.
  6. Scroll down until you come to assertion WSI2122. If this assertion has failed, click on the assertion link to navigate to the test assertions document. This is an interesting failure as it appears that the WS-I test assertions are failing the WSDL file because the schema definition is not valid.
  7. Open the WSDL file HelloService.wsdl in the xml code editor.
  8. If the line numbers are not displayed use menu Tools -> Preferences -> Code ditor -> Line Gutter and set the Show Line Numbers checkbox
  9. Scroll down the WSDL file until you find the <types> definition

    <types>
    <schema
    targetNamespace="http://mypackage/IHelloService.xsd"
    xmlns="http://www.w3.org/2001/XMLSchema"
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"/>
    </types>

    This is valid XML Schema, the <schema> element ends with an inline /> but the test assertion fails it . If you did not check the reason for this assertion failure, then you might think that this service would not interoperate between systems as it is not conformant to WS-I Basic Profile 1.0. However, this XML styling is valid and is not likely to cause interoperability problems.
  10. Return to the report and scroll down to assertion WSI2406


    This assertion fails as the use attribute is encoded and not literal. Web services can be either encoded or literal. JDeveloper 10g web services were designed to a previous convention where encoded types were the norm. The WS-I Basic Profile has chosen the literal as its standard for interoperability. This does not mean that an encoded type web service will not be interoperable across other systems. Nor does it mean that Oracle J2EE 1.3 web services cannot consume literal type web services. JDeveloper automatically generates any types necessary to consume all types of services (including .NET services). JDeveloper's JAX-RPC extension (J2EE 1.4) offers developers the choice of generating services with encoded or literal types
  11. Check any Missing Input assertions to ensure that they are expected to be missing for the service you are testing
  12. Scroll to the Artifact:message section of the report. This section of the report tests the conformancy of the messages being passed between a client and a web service. In this example we are testing a WSDL file only, so all the inputs to this section are flagged as missing

Test the messages of a running service

To test the HelloService you will run it using the embedded OC4J in JDeveloper and generate a sample Java client to call it. It is outside the scope of this How To to provide detailed steps on achieving this

Running the Analyzer against the WSDL file

  1. Run the HelloService you create earlier using the embedded OC4J
  2. Generate a Sample Java Client and add the following line to the Main method

    System.out.println(stub.sayHello(" to you "));
  3. Run the client and review the output in the Log window

    hello to you
    Process exited with exit code 0.

  4. Open the TCP Packet Monitor from the View menu and click the green Start button



  5. Run the client again. Note the message is captured in the TCP Packet Monitor



  6. Stop the monitor by clicking the red button. The wsi-log files (.xml and .html) are created and listed in the navigator. the wsi-log.html is opened in the editor
  7. Now that you have the log file you can use the analyzer to analyze the file and produce the conformance report. Select the wsi-log.xml file in the navigator
  8. Choose Analyze WS-I Log File from the context menu
  9. In the Validate WSDL page the WSDL location, service name and port details have been retrieved from the log report
  10. Click Finish to start the analysis. Note that the analyzer messages are displayed in the log window
  11. The wsi-report.html is created and opened in the editor. Note that any previous report is overwritten - if you want to retain previous reports you need to copy them from the file system.

Reading the Conformance Report

  1. Scroll down to the Summary section. Note that, overall, this service has failed. Again, the report is broken into the three areas (discovery, description, message)
    The Description and Discovery sections should be the same as in the WSDL report created earlier in this example
  2. Under the Summary section, click on the message link to navigate to the Artifact:message section
  3. If the table shows all the assertions as Missing Input, then there is a mismatch between the endpoint that is named in the conformance report and the endpoint that is being returned over the wire. See Troubleshooting
  4. Scoll down to assertion WSI1308
    The HelloService has failed this assertion as it is using an encoding style rather than being literal (see notes above against assertion WSI2406). Again, this failure does not mean that this service will not interoperate but that it does not conform to the standard set by WS-I Basic Profile 1.0.
  5. Scroll down to WSI1104. This is a warning rather than a failure. Click on the link to the test assertion WSI1104. From there click on the link to Basic Profile requirement R1115. This takes you directly to the relevant section of the Basic Profile. Note the language used:

    R1115 An INSTANCE SHOULD use a "415 Unsupported Media Type" HTTP status code
    if the Content-Type HTTP request header did not have a value consistent with the value
    specified for the corresponding binding of the input message.

  6. Compare that with the wording of R1125 (scroll up the document a little):

    R1125 An INSTANCE MUST use a 4xx HTTP status code for responses that indicate a problem with the format of the request.


    The Basic Profile has a number of 'guiding principles', for instance:

    Strength of requirements
    The Profile makes strong requirements (e.g., MUST, MUST NOT) wherever feasible; if there are legitimate cases where such a requirement cannot be met, conditional requirements (e.g., SHOULD, SHOULD NOT) are used. Optional and conditional requirements
    introduce ambiguity and mismatches between implementations.

Test the Discovery of a service via a UDDI registry

In this release of JDeveloper you can test the WSDL file of a web service from a UDDI registry entry. You cannot use JDeveloper to analyze the Discovery portion of the Basic Profile that checks conformance of the UDDI Registry entry itself.

  1. In the JDeveloper Connections Manager, expand the UDDI Registry node
  2. Locate the WSDL you wish to test for WS-I Basic Profile conformance. Note, the steps for locating the WSDL are outside the scope of this How To document


  3. Choose WS-I Analyze WSDL from the context menu
  4. Browse the generated wsi-report.html Description section for conformance failures and warnings

Troubleshooting

Problem Possible Solution
Message Assertions all have Missing Input You are running a WSDL analysis only so only the Description assertions are tested

The machine name and port no. captured in the wsi-report.html do not correspond to the name and port being returned 'over the wire'. This is most likely to occur when you are running the service in the embedded OC4J. Check that the port number is 8988 (in the WSDL file) before you start to run the TCP Packet Monitor. Also, try changing the machine name to the IP_address or the hostname (in lower case). See the JDeveloper online Help topic Analyzing Web Services Running in the Embedded Server for more details

Service Name and Port No. of WS-I Analyze Web Service Wizard are blank The web service is not running. Deploy and start the service or use the embedded OC4J
The machine name and port no. do not correspond (see above)
TCP Packet Monitor does not capture request and response data Check your proxy settings. If you have problems making connections from JDeveloper you may need to change the proxy server settings you use. For example, if you are connecting to an IP address behind a proxy server, and your machine is also behind the same proxy server, then make sure that JDeveloper's web proxy preferences exclude the IP address you are trying to connect to. For more information see JDeveloper online Help topic Proxy Settings and the TCP Packet Monitor
Discovery section of wsi-report.html has missing inputs JDeveloper does not test the Discovery assertions of WS-I Basic Profile 1.0
Search by Category of IBM/Microsoft Public registry does not return enough rows Sometimes providers place restrictions on the number of rows that are returned by a Category search. There is now way to get round this. Category searching is most effective when used for private UDDI instances.

Conclusion

JDeveloper seemlessly integrates the testing of web services against WS-I Basic Profile 1.0. You can test both the description and messages of services. It is up to the user to decide whether failure to meet a specific Basic Profile requirement will impact the interoperability of a particular service in their environment.

Further Information
WS-I
JDeveloper JAX-RPC Extension
OTN Web Services Technology Centre

 

false ,,,,,,,,,,,,,,,