WS-I Basic Profile Testing with the STAR Workbench

Part I: TCP/IP Monitoring and Analysis

Summary

One of the requirements for a STAR Web Service implementation is to verify that it is compliant to the WS-I Basic Profile 1.0. However, how is a system verified for compliance? STAR Workbench contains a set of tools that will verify that the STAR Web Service implemented meets the required specifications outlined in the profile.

By David Carver, Standards for Technology in Automotive Retail

Requirements

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

STAR Workbench 2.0 - While prior versions of the STAR Workbench may work this article has been written for 2.0.
Java EE Tools - installed into the STAR Workbench using the Ganymede Update Site. This will install the necessary WS-I Tools and TCP/IP Monitor.
Network connection to the STAR Web Service being tested.
The ability to change the end points that your STAR web service client communicates too. This includes the ability to change the URL port number.
SOAP UI 2.0.2 - This is an optional install, it may provide a faster interface for setting up a client if you don't already have one to test against the server implementation.

Introduction

WS-I.org maintains a set of testing and analysis tools for verifying compliance with the WS-I Basic Profile 1.1 specification. These tools are command line based, and provide both tools for monitoring the TCP/IP traffice and verfying the compliance of a WSDL. However, not everybody is comfortable with setting up command line based tools. The STAR Workbench as well as the freely available SOAP UI application, both have graphical user interfaces for the various WS-I testing and analysis tools.

The STAR Workbench contains the following tools:

TCP/IP Monitor - The TCP/IP monitor can be used to analysis and capture HTTP traffic, and analysis it for compliance with the WS-I Basic Profile 1.1.
WSDL Validator - The WSDL Validator built into the workbench allows for the validation of a particular WSDL as it's being developed to verify complaince against the WSDL portions of the WS-I specifications.

	WS-I Validation Report
Currently there is no graphical interface into running and generating the WS-I Validation Report. This can be done through the command line. Also, the validation report, requires eclipse to be running in order to be generated. A user can submit the xml files created by the eclipse tools through the WS-I command line tools to have the report generated. Bug 74931 has been opened requesting the ability to generate these report from with in eclipse.

WS-I Validation Report

Currently there is no graphical interface into running and generating the WS-I Validation Report. This can be done through the command line. Also, the validation report, requires eclipse to be running in order to be generated. A user can submit the xml files created by the eclipse tools through the WS-I command line tools to have the report generated. Bug 74931 has been opened requesting the ability to generate these report from with in eclipse.

The sections that follow will discuss how to setup the TCP/IP monitor as well as how to use the WSDL validator to help verify compliance while doing development work for a STAR Web Service implementation.

TCP/IP Monitor and Analysis

The TCP/IP monitor in the STAR Workbench functions the same way that the WS-I Tools can. All configuration is done through the graphical user interface. The TCP/IP monitor setup is done through the Preferences. It can be found under Windows->Preferences->Run/Debug->TCP/IP Monitor. This is shown in Figure 1, “TCP/IP Monitor Preference Page” .

Figure 1. TCP/IP Monitor Preference Page

Monitoring a Port

The TCP/IP monitor works as a man-in-the-middle. It takes requests directed to a specific port, and forwards them onto the the server at a specified port. It captures the information sent and received from both the client and server and puts it into a log file.

In order to capture the port, the TCP/IP Monitor needs to know which ports to monitor and where to forward them. Each port that is monitored needs to have an entry in the preference page. To add a port to be monitored, select the ADD button, and the New Monitor dialog will appear as shown in Figure 2, “New TCP/IP Monitor” .

Figure 2. New TCP/IP Monitor

New Monitor Options

Local Monitoring Port - This is the port on the local computer that the TCP/IP should monitor for requests that are going to be redirected to the server. This may be set to any valid TCP/IP port. The client application should be set to send it's requests to this port.
Host name -Is the name or ip address of the server where the packets should be redirected. This is not the same port number as the TCP/IP monitor itself.
Port - The port on the server that the request are redirected too. This should be the port where the web service server is listening for requests.
Type - The type of connection that is being made. The default option is what will be used for STAR Web Services. The default is HTTP. The other choice is TCP/IP, and will monitor byte level information for other protocols. The monitor may be used to capture any TCP/IP related traffic at the monitoring port specified.
Timeout - The length of time in milliseconds before the monitor will time out a request to the server. It is suggested to adjust this as appropriate for your particular server needs. Typically 600 milliseconds should be enough to send and receive responses.
Start Monitor Automatically - If this is checked, then when the STAR Workbench is automatically started the next time the TCP/IP Monitor will be started as well. Unless you plan to do a lot of monitoring or that is your sole use of the workbench, it is recommended to leave this unchecked. The monitor can be started manually through the preference page.

Capturing a Log

To capture a log file, make sure that the TCP/IP monitor is started. This is done by selecting the configuration to be started and pressing the START button on the preference page. The monitor will start and quietly monitor for any activity on the designated monitoring port. When it hears activity it will show the monitor view.

Figure 3. Captured Log

Figure 3, “Captured Log” shows out that has been captured from a session. Both the input from the client and output from the server are captured and logged.

Log Analysis

The captured logs can be analysized by select the validate log button (Figure 4, “Validate Log Button”). This will run the log analysis Wizard and ask for the following information.

Figure 4. Validate Log Button

Procedure 1. Log Validation Steps

Select the location to save the logfiles and provide a filename for the log.

Figure 5. Save Log File
If a WSDL is to be attached to the log file for analysis, check the WSDL box. A log file can be analysised without the wsdl.

Figure 6. Select WSDL
If no wsdl, then select finish and the validation results dialog will be displayed. This dialog provide the results of the analysis and if any errors are found where to find more information. See Figure 7, “Validation Results Dialog”.

Figure 7. Validation Results Dialog

	Note
	There appears to be a bug in the WS-I Results Validation dialog within the workbench. The problems are not displayed in the problems view like the dialog says. A bug has been opened with the eclipse web tools platform in regards to this issue.

The log files that were captured can also be run through the standard WS-I command line tools. This will allow for the WS-I HTML report to be generated which specifies which tests have passed and which tests have failed. The HTML report is useful to have for auditing purposes. There is an open enhancement request to allow for the generation of the report from within the Web Tools WS-I tools, but until that time the WS-I report will need to be run manually from the command line.

WS-I XML Log

The TCP/IP Monitor produces an xml file with the captured information. The WS-I provides an XSL stylesheet that can be used to transform this log into an html file that can be viewed within a browser.

Example 1. WS-I Monitor Log


<log timestamp="2008-07-08T13:12:41.791"
    xmlns="http://www.ws-i.org/testing/2004/07/log/"
    xmlns:wsi-monConfig="http://www.ws-i.org/testing/2004/07/monitorConfig/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <monitor version="1.0" releaseDate="2003-03-20">
    <implementer name="IBM" location=""/>
    <environment>
      <runtime name="Java(TM) 2 Runtime Environment, Standard Edition" version="1.5.0_12-b04"/>
      <operatingSystem name="Linux" version="2.6.24-19-generic"/>
      <xmlParser name="Apache Xerces" version="Xerces-J 2.9.1"/>
    </environment>
    <wsi-monConfig:configuration>
    <wsi-monConfig:comment>Comment</wsi-monConfig:comment>
      <wsi-monConfig:logFile replace="true" location="URL">
      <wsi-monConfig:addStyleSheet href="null" type="null" />
    </wsi-monConfig:logFile>
      <wsi-monConfig:logDuration>600</wsi-monConfig:logDuration>
      <wsi-monConfig:cleanupTimeoutSeconds>3</wsi-monConfig:cleanupTimeoutSeconds>
      <wsi-monConfig:manInTheMiddle>
      </wsi-monConfig:manInTheMiddle>
    </wsi-monConfig:configuration>
  </monitor>

<messageEntry xsi:type="httpMessageEntry" ID="1" conversationID="1" type="request" timestamp="2008-07-08T13:11:52.141Z">
<messageContent>&lt;soapenv:Envelope xmlns:soapenv=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:tran=&quot;http://www.starstandards.org/webservices/2005/10/transport&quot;&gt;
   &lt;soapenv:Header&gt;
      &lt;tran:payloadManifest&gt;
         &lt;!--Zero or more repetitions:--&gt;
         &lt;tran:manifest contentID=&quot;?&quot; namespaceURI=&quot;?&quot; element=&quot;?&quot; relatedID=&quot;?&quot; version=&quot;?&quot;/&gt;
      &lt;/tran:payloadManifest&gt;
   &lt;/soapenv:Header&gt;
   &lt;soapenv:Body&gt;
      &lt;tran:ProcessMessage&gt;
         &lt;!--Optional:--&gt;
         &lt;tran:payload&gt;
            &lt;!--Zero or more repetitions:--&gt;
            &lt;tran:content id=&quot;?&quot;&gt;
               &lt;!--You may enter ANY elements at this point--&gt;
            &lt;/tran:content&gt;
         &lt;/tran:payload&gt;
      &lt;/tran:ProcessMessage&gt;
   &lt;/soapenv:Body&gt;
&lt;/soapenv:Envelope&gt;</messageContent>
<senderHostAndPort>localhost:8089</senderHostAndPort>
<receiverHostAndPort>localhost:8088</receiverHostAndPort>
<httpHeaders>POST /mockstarTransport HTTP/1.1&#xd;
Content-Type: text/xml;charset=UTF-8&#xd;
SOAPAction: &quot;http://www.starstandards.org/webservices/2005/10/transport/operations/ProcessMessage&quot;&#xd;
User-Agent: Jakarta Commons-HttpClient/3.0.1&#xd;
Content-Length: 744&#xd;
Host: localhost:8088&#xd;
&#xd;
</httpHeaders>
</messageEntry>
<messageEntry xsi:type="httpMessageEntry" ID="2" conversationID="1" type="response" timestamp="2008-07-08T13:11:52.364Z">
<messageContent>&lt;soapenv:Envelope xmlns:soapenv=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:tran=&quot;http://www.starstandards.org/webservices/2005/10/transport&quot;&gt;
   &lt;soapenv:Header&gt;
      &lt;tran:payloadManifest/&gt;
   &lt;/soapenv:Header&gt;
   &lt;soapenv:Body&gt;
      &lt;tran:ProcessMessageResponse/&gt;
   &lt;/soapenv:Body&gt;
&lt;/soapenv:Envelope&gt;</messageContent>
<senderHostAndPort>localhost:8088</senderHostAndPort>
<receiverHostAndPort>localhost:8089</receiverHostAndPort>
<httpHeaders>HTTP/1.1 200 OK&#xd;
Content-Type: text/xml; charset=utf-8&#xd;
Content-Length: 313&#xd;
Server: Jetty(6.1.x)&#xd;
&#xd;
</httpHeaders>
</messageEntry>
</log>

Trademarks

Eclipse is a registered trademark of the Eclipse Foundation.

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 .