Over the past few days I've been trying to work with a series of web-services which act as a gateway to a legacy host system. The web-services themselves are exposed over the Internet and built using the Apache Axis 1.0 toolkit. Web-services that are built using Axis tend to use a lot of imports in the WSDL contract which can sometimes be fun to work with. If you come across problems interoperating with Axis from .NET these two patches might be useful.
Anyway, as I took a closer at the contract it seems that they were trying to secure the messages with WS-Security so I decided to throw the WSDL into WSEWSDL2.EXE which comes with WSE 2.0 SP3. Unfortunately thats when the pain started - there were a number of faults in the WSDL contract which meant it wouldn't work without significant hand editing. Since thats how I think the WSDL contracts got into that state I'm a bit loathed to do that, but it did get me thinking about the importance of interoperability when implementing web-services.
The .NET stack does a pretty reasonable job of abstracting away the job of producing a standards compliant WSDL contracts, but its also very aggressive at ensuring the proxy code it generates is based on equally well formed WSDL and it barfs if something looks out of place. In this case the WSDL file was importing all sorts of wierd XSD files.
Unfortunately I can't really post the files up here but I did want to have a rant. By the end of today I was pulling my hair out with frustration as I was manually working through the files trying to make them compliant but at what point do you say the service vendor has just cocked up and all they have is tag soup?
I propose a new standard, if you want to say you support web-services in your marketing-ware thats fine. But make sure you put a <wswh:whatever /> header in there so us geeks can ensure we don't waste any time on you. Sheesh!