How should I compensate for a bad WSDL?

Question

I've come across several examples of SOAP-based web services where automated tooling fails to build a client that works.

Investigating these examples leads me to believe that the WSDL the service uses to describe itself doesn't quite match the service that's being provided. Maybe a wrong type somewhere, a different data structure - something.

I'm unsure what the most appropriate response is - if we assume that the obvious one (get the provider to fix their stuff) isn't available.

Some options I can think of:

• Make a fixed WSDL?
• Hack the generated code?
• Any other options?
• No good options?

What good experiences have people had? What works in a real environment?

Thanks

Answer 1

I'd try for the first option, make a fixed wsdl. If that doesn't work then you could fall back on hacking the generated code.

Of course if the service is radically different from the WSDL you might not have much luck with those 2 options.

If you're lucky there's another way. Some web service frameworks support returning a dynamically generated WSDL.

I know with an AXIS 1.4 service you can do a GET on the service url + '?WSDL' and get back a dynamically generated WSDL.

e.g. http://foo.com/service/?WSDL

Answer 2

First I would try to confirm if the tool created a correct binding for the WSDL. If the WSDL is correct and the tool generates bad bindings which do not result in correct SOAP request / response processing, the tool author might provide a fix or a workaround.