Copyright ©2008  Standards for Technology in Automotive Retail. All rights reserved.

WS-I TCP/IP Monitor and Analysis Tools Setup

Summary

The STAR Transport Guidelines require that STAR web service communication conforms to the WS-I Basic Profile 1.1 specification. As this requirement is fundamental to the interoperability of STAR web service implementations, it may be desirable to validate that individual implementations are compliant with this standard. The Web Services Interoperability Organization (WS-I) provides a set of tools that can be used to verify compliance to their published profiles. The tools can be used to verify a STAR Web Service for compliance with the WS-I Basic Profile 1.1 specification. This article will describe the steps necessary to get the WS-I Tools working with a STAR Web Service.

By Jason Loeffler, Karmak
Eric Jensen, America Honda
David Carver, Standards for Technology in Automotive Retail


Requirements

In order to verify WS-I compliance the following are required.

  • Interoperability Testing Tools 1.1 - either the Microsoft .NET or Java Tools can be used.

  • STAR Web Service - The STAR Web Service to be tested. A client and server are needed to test full compliance.

  • STAR Web Service WSDL Optional - A STAR WSDL is optional in order to test the compliance of the payload contained in the soap body. WSDL compliance can be tested separately.

Additional Requirements

  • Microsoft .NET 1.1[4] - if running the C# command line tools.

  • Java 1.4 or greater[5] - a java runtime environment should be installed.

    [Note]Note

    Make sure that the java runtime is available on the path environment variable and the JAVA_HOME environment variable is set.

Introduction

This article is written from the point of view of using the C# version of the tools. Configuration steps are similar for running and executing the WS-I Tools for Java.

[Note]Note

There are some differences between the Java and C# versions of the tooling. In particular the Java Tooling includes the source code as well as the binaries. This may be of benefit for investigation of why a test may not be passing. No source code is available for the Microsoft .NET tools.

Configuring the TCP/IP Monitor

In order to capture the necessary log information from both the client and server for the web service under test, a TCP/IP monitor sits in between the two and captures the log information. The Client directs its connections to the monitor, which forwards the requests to the server. Any server responses are then sent onto the client after being captured by the monitor. Once a conversation is done, a log of the entire conversation is created. There are several steps necessary to setup the TCP/IP Monitor for capturing the necessary information.

Procedure 1. Configuration

  1. In the WS-I testing tool base directory, create a directory named "custom" to store the configuration files and output files.

  2. Copy the sample monitor config file from the cs\samples directory to the custom directory.

  3. Open the monitor config file from the custom directory and make the following changes:

    1. Set the output log file location to the custom directory by editing the logfile element.

    2. Modify the path to the stylesheet to ensure the correct path exists when the log file is created.

    3. Remove all of the redirect elements that you don't need. A basic setup will only need one of these elements.

    4. Set the listenport value of the redirect element if the default port 9090 is not valid for your machine.

    5. Set the schemeAndHostPort element to the location of the web service that is to receive the request. If the web service is on the local machine at port 80, the default value should be ok.

When finished, the sample monitor config file will look like Figure 1, “Monitor Configuration” :

Monitor Configuration

Figure 1. Monitor Configuration


Configuring the Analyzer

The analyzer is takes the log files generated by the TCP/IP monitor and validates them against the WS-I Basic Profiles. A XML file is produced which contains the results. A stylesheet can be applied to generate an HTML report.

Procedure 2. Configure Analyzer

  1. Copy the sample analyzer config file from the cs\samples directory to the custom directory.

  2. Edit the file as follows:

    1. Modify the output report location in the reportFile element so that the report is created in the custom directory.

    2. Modify the stylesheet relative path in the reportFile/addStyleSheet element so that the report has the correct path to the stylesheet when it is created.

    3. Set the testAssertionsFile element value to the basic profile assertions file in the common\Profiles directory.

    4. Modify the logfile element value to contain the path to the file that was created with the monitor tool. From the example above, this path is ..\..\custom\customtracelog.xml

    5. Remove the uddiReference element as a UDDI server will not be used in the test.

    6. Modify the wsdlReference\wsdlElement[type] attribute to be of type “binding.”

    7. Modify the wsdlReference\wsdlElement[namespace] attribute to be the base namespace of the WSDL document.

    8. Modify the wsdlURI element value to contain the http or file URI to the WSDL document. In the example, an HTTP location is used.

    9. Modify the service location value to contain the URL at which the service can be contacted.

When finished, the file should look like Figure 2, “Analyzer Configuration” .

Analyzer Configuration

Figure 2. Analyzer Configuration


Running the Monitor

In order to capture log files, the TCP/IP Monitor needs to be running.

Procedure 3. Starting the Monitor

  1. The monitor can be run directly from the cs\bin location by providing the path to the config file as shown in Example 1, “Start TCP/IP Monitor”.

    Example 1. Start TCP/IP Monitor

    Monitor.exe -config ..\..\custom\customMonitorConfig.xml
                            

  2. Initiate some transaction against the web service, to provide sample SOAP messages for the tool to analyze later. Note that you’ll want to direct your requests at the monitor listener rather than your original web service location.

    For instance, in the example the web service exists at http://localhost:80/ScratchWebService/Service.asmx but when running the monitor, the web service should be accessed at http://localhost:9090/ScratchWebService/Service.asmx. The monitor listens to requests on the port specified in the config file, logs the activity and then redirects them to the original web service location.

  3. When finished, use CTRL-C in the command window to exit the Monitor. Note that the output file will not be created in the custom directory unless the tool exits properly. You should see the message: “Log file is in ..\..\\customtraceLog.xml” indicating that the log was written to the location you specified.

Run the Analyzer

The Analyzer evaluates the log files and any wsdl for compliance against the Basic Profiles.

Procedure 4. Analyze

  1. The analyzer tool can be run directly from the cs\bin location by providing the path to the config file.

    Example 2. Execute Analyzer

    Analyzer.exe -config ..\..\custom\customAnalyzerConfig.xml                        
                            

  2. The analyzer will examine the output from the monitor tool and probe the web service description (WSDL file) to evaluate its compliance and produce a report. When it is finished you will see the message: “Wrote conformance report to ..\..\custom\report.xml” indicating that the output report is available at the location you specified in the config file.

  3. The output can be viewed in a text editor or by viewing the report in a browser if the stylesheet was bound correctly in the file.

Conclusion

The output from the WS-I testing framework can be reviewed to determine compliance with the WS-I basic profile. In instances where the report indicates non-compliance, the specific items will contain details that should guide implementers towards corrective action. For further information, the WS-I web site contains information about the profile specifications and their usage. STAR-specific help can be obtained by contacting any STAR member or a STAR organization representative.

Resources

[1] Standards for Technology in Automotive Retail. STAR Transport Package. v2007v1. 21 Dec. 2007. 21 Jul. 2008. [ http://www.starstandard.org/index.php?n=SIGARCHITECTURE.Architecture ] .

[2] WS-I.org. Basic Profile 1.1 Second Edition. 1.1. 21 Apr. 2006. 21 Jul. 2008. [http://www.ws-i.org/Profiles/BasicProfile-1.1.html .

[3] WS-I.org. Interoperability Testing Tools 1.1. 13 Jun 2005. 21 Jul. 2008. [http://www.ws-i.org/deliverables/workinggroup.aspx?wg=testingtools] .

[4] Microsoft. Microsoft .Net Framework 1.1 Redistributable Package. 23 Apr. 2003. 21 Jul. 2008. [http://www.microsoft.com/Downloads/details.aspx?FamilyId=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en] .

[5] Sun Microsystems. Java 1.4.2. 21 Jul. 2008. [http://java.sun.com/j2se/1.4.2/download.html] .

Trademarks

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

This article is made available under the Eclipse Public License .