Saturday, November 20, 2010

WsiHero: A GUI utility for web services WSI validation


Download WsiHero (3MB)

Last week was an important moment for web services interoperability: WS-I has approved the final versions of Basic Profile (BP) 1.0 and 2.0 and of Reliable Secure Profile (RSP) 1.0. These profiles are a set of rules which web services vendors and consumers are expected to comply with in order to support interoperability. The original profile goes back to 2004 and was highly successful in improving web services interoperability.

So how do we test our web services for WSI profiles compliance?
The WSI site contains a deliverables section which has a few command line utilities to check the services. Using these command lines directly has some overhead like a learning curve for all the options, preparing the input wsdl / soap files in the specific log format, and repeating this manual task every time.

I have written the WsiHero utility to make this validation simpler.

How to become a WSI hero?
If you want to easily validate your service for WSI compliance and become a WSI hero then Download WsiHero. It is a GUI application which saves you the need to deal with the WSI command line and its strict log format.

Download WsiHero (3MB)

1. Ensure Microsoft .Net framework 2.0 or higher is installed (

2. Ensure Java 5 or higher is installed (

3. Download WsiHero and extract it to some folder, for example c:\program files\WsiHero.

4. Since it is not legal for me to distribute the WSI command line utility, please download it by yourself as follows:

Download these two zip files to your machine:

Do not extract them, just put them as .zip in the WsiHero folder (c:\program files\WsiHero). Do not change their names.

In case the direct links do not work for some reason here is how to get the above files from the WSI site: From the "deliverables" section of the site download "BP 1.2 and 2.0 Test Tools package" and "Reliable Secure Profile Delivery Package".

1. Run WsiHero.exe from its folder.

2. Paste a Wsdl or a Soap file location into the text box and press "Add".


  • Location can be a local disk path or a Url.
  • If the file contains Soap it must have the .Xml extension. Otherwise it is assumed to be a Wsdl.

    For example any of the following can be put in the text box:


    If you do not have any Wsdl available you can to use

    3. Repeat step (2) any number of times.

    4. Click the arrow near the validation button and choose the validation type you want to perform:

  • For Soap 1.1 services choose "Basic Profile 1.2".
  • For Soap 1.2 services choose "Basic Profile 2.0".
  • For secured / reliable services choose "Reliable Secure Profile 1.0" (you may want to test such services also with one of the former options).

    After a few seconds (depending on the input size) the WSI report will appear:

    I plan to open source and enhance this utility soon.
    Let me know if you have any problem or a feedback.


    What's next? get this blog rss updates or register for mail updates!

    Moshe said...

    Yaron, you don't stop surprising.

    tatman said...

    thank you for your tool. definitely nice to be able to not have to dig through the command line sometimes.

    Do you have some information that can help explain the reports generated?

    I ran WSDL file (that svcutil cannot import). The report generated doesnt seem to report anything meaningful.

    Yaron Naveh (MVP) said...

    Hi Matt

    There are a lot of checks there so you would need to be more specific. Which error did the report show?

    One common gotcha is that you run BP 1.2 on a wsdl with Soap 2.0 or vice versa.

    Anonymous said...

    Get Error "Could not load file or assembly 'System.Core, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089'" when pushing 'Show Wsi Report'

    It looks like a dependency to .Net 3.5, although there's only .Net 2 listet on the dependencies.

    Alberto Pereto said...

    Fantastic Tool!

    Alberto Pereto said...

    Fantastic Tool!

    Unknown said...

    Hi Yaron,
    Just wondering if you released the code of WsiHero

    Yaron Naveh (MVP) said...

    Hi Elkin

    I've put the code here:

    This code actually does not compile at the moment (some missing ui library) but in any case it is very much at the prototype level so it is just for reading.

    RTercero said...

    Hello Yaron,

    I'm unable to download the zip. Is there any problem downloading the file? I wish you could check.


    Yaron Naveh (MVP) said...


    Try again now

    RTercero said...

    Hi Yaron,

    I downloaded the zip and run a few checks. Thank you for wsihero, it's a really good app.


    Askar said...

    Hello Yaron. Does your tool operate under Java 8? It says 'execution of 'java' failed', though in cmd I have 'java' accessible (java -version works fine). Is there a direct way to run java command to perform checks using your package?

    Yaron Naveh (MVP) said...

    I have not tried it under java 8. wsiheo calls standard wsdl validation command lines. the source is here:

    ccuenca said...

    Hi! Yaron! Thanks for this great tool! very useful. i have a question, There is a way to run the app from command line??

    Yaron Naveh (MVP) said...

    not yet, unfortunetely

    ccuenca said...

    Ok Yaron! Thanks for the info

    Unknown said...


    A generic question about WS-I tools: are you able to define how much of the WS-I Basic Profile 2.0 is covered by the WS-I tools (and thus by your tools) ?
    Can we assume this can be use to determine the full compliancy agains WS-I Basic Profile 2.0 ?

    For example, there are some "dynamical" requirements in S-I BP 2.0 such as R1149 (If a RECEIVER detects one of the error conditions specified in Section 6.4 of the Web Services Addressing 1.0 - SOAP Binding, it MUST generate a fault using the [Code], [Subcode], and [Subsubcode] listed for that particular error condition): is this kind of tools able to detect any mistake in the data flow ?

    Thanks for your answer

    Yaron Naveh (MVP) said...

    Hi, I'm using the public WSI validator utility so I'm not sure how they achieve it. Possibly some items cannot be conformed by their tool.

    Unknown said...

    OK, thanks for the answer. In the meantime, I checked the XSL, and it seems that: apart from MTOM part of the Profile, there are:
    - 146 requirements are validated with WS-I BP Tools (4 more that may be validated with WS-Addressing tools)
    - 15 requirement are marked as not testable or not tested

    The 15 non testable requirements are:
    - In a two-way exchange, if a fault is generated by the RECEIVER , the original SOAP response must not be transmitted
    - RECEIVER must interpret a SOAP message as a fault when the soap:body has a single soap:fault child
    - An instance must use an HTTP 2xx status code on a response to indicate success
    - In a DESCRIPTION, a wsoap12:fault must specify the contents of the SOAP 1.2 fault Detail element.
    - In a DESCRIPTION, a policy that contains the wsam:Addressing assertion must be attached to either a wsdl:port, a wsdl:binding or a wsdl:binding/wsdl:operation
    - An envelope described with an rpc-literal binding must namespace qualify the descendants of part accessors for parameters and return value, as defined by the schema in which their types are defined
    - mustUnderstand, VersionMismatch fault transmission should disregard ReplyTo and FaultTo headers
    - Any imported XML schema must use XML version 1.0
    - A binding in a description may contain soap:body elements that specify zero parts
    - A wsdl:message may contain wsdl:parts that use the elements attributes, provided that those parts are not referred to by a soap:body in an rpc-literal binding
    - A wsdl:porttype may have zero or more wsdl:bindings that refer to it defined in the same or other wsdl documents
    - If an instance receives an envelope that is inconsistent with its WSDL description, it should generate a fault with a faultcode of client unless a mustUnderstand or VersionMismatch fault
    - An envelope may contain more than one instance of each header in the corresponding description
    - A description may use any construct from XML Schema 1.0
    - WSDL description must use XML 1.0

    ==> I guess we can assume that the WS-I tools are quite exhaustive.

    Thanks for you work, by the way, it is quite useful

    Sue said...

    Hi Yaron,
    unfortunately I cannot download the tool.
    Can you please help me on this?