Web Service Interoperability Testing

nospam@example.com (Sune Trudslev) — Mon, 01 Nov 2004 23:20:00 +0100

The Background

When creating web service today, Web Service Interoperability is getting to be a bigger and bigger issue. There are a number of choices for the server platform, but the it is definately best if the client platform is not restricted in any way. We want everybody to be able to use our web service.

WS-I is an organization working towards Web Service Interoperability "across platforms, operating systems, and programming languages". They have created some profiles that define a number of rules, that should ensure that your web service is interoperable. Ensuring that your web service complies to all these rules would, of course, be a monumental task, so there are ways to automate the actual testing, and that is what I am going to talk about today.

Getting Started

First you need to download the WS-I's Testing Tools which can be found on this page. Since I am talking about Web Service Interoperability in the context of .NET you should get the C# version of the testing tools.

Extract the zip file in the directory where you have your web WSDL file or files of your web service. It should be extracted to a subdirectory called wsi-test-tools.

Configuration

Now we need to create a configuration file for the testing tools, here is an example:

<?xml version="1.0" encoding="utf-8"?> <configuration xmlns="http://www.ws-i.org/testing/2003/03/analyzerConfig/" xmlns:wsi-common="http://www.ws-i.org/testing/2003/03/common/" xmlns:uddi="urn://uddi-org/api_v2/"> <description>This file contains the WS-I testing configuration for WebService.</description> <verbose>true</verbose> <assertionResults type="all" messageEntry="true" assertionDescription="true" failureMessage="true" failureDetail="true"/> <reportFile replace="true" location="..\..\..\REPORT_WebService.xml"> <addStyleSheet href="wsi-test-tools\common\xsl\report.xsl" type="text/xsl" alternate="false"/> </reportFile> <testAssertionsFile>..\..\common\Profiles\BasicProfileTestAssertions.xml</testAssertionsFile> <wsdlReference> <wsdlElement type="binding" namespace="http://tanis.dk/2004/10/29/services.wsdl"></wsdlElement> <wsdlURI>..\..\..\..\WebService.wsdl</wsdlURI> <serviceLocation>http://tanis.dk/blog</serviceLocation> </wsdlReference> </configuration>

We also need a batch file to run the tests. It could look like this:

@echo off cd wsi-test-tools\cs\bin Analyzer.exe -config ..\..\..\WebServiceConfig.xml cd ..\..\..

Running the tests

And now we are ready to run our tests:

The output

After we have run the tests we have a nice viewable report that holds all the different test details, and what went wrong, if some of them failed.

If everything goes well, this is what you should be seeing:

If there are any problems with the wsdl, it will show you so:

The report contains a summary over all the different tests as defined, and it shows which ones passed or failed:

Further down in the report you can read a detailed description of each test. If they failed you will get an explanation why it failed:

Conclusion

Ensuring Web Service Interoperability is not an easy task. There are lots of things to be aware of, but if you align yourself with a few good tools, it might just become easier.

Just my two cents.

"Contract-First" Web Service Development

nospam@example.com (Sune Trudslev) — Fri, 22 Oct 2004 21:28:00 +0200

I am working on a government project where alot of the data also needs to be available through a web service. An important issue in this web service project is that the contracts (wsdls) needs to be available and approved before the actual code is written. Here comes the necessity for "Contract-First" web service development.

First you need a WSDL (Web Service Definition Language) file that describes the web service. Personally I prefer the freedom of creating those types of files by hand, but there is also free software like CapeClear's SOA Editor available.

Just right-click the project name to create the stub code for your web service.

If you craft them by hand you need to know something about the actual format (which I would recommend anyway). A good tutorial about the wsdl format is this article and a good one about XML schemas is this article. Both on w3schools.com.

While it is possible to make some stub code for your server side web serivce code using the wsdl.exe utility that comes with the .NET FrameWork, Chistian Weyer has created a very cool little add-in for Visual Studio .NET called WsContractFirst. Creating the stub code for your web service server or client is as simple as just right clicking the project name.

It seems that Contract First and web service interoperability are the buzz words of web services at the moment. The tools to create them are still in their infancy, but it will definately be interesting to see where this is going.

I will write more on web service interoperability later. It is pretty easy to use the www.ws-i.org testing tools to test your wsdl. I will show how.

Sune Trudslev's WebLog - DotNet