3

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

brabster
  • 42,504
  • 27
  • 146
  • 186
  • 3
    The WSDL defines a contract, if the contract is wrong then it needs to be fixed. – RichardOD Sep 24 '09 at 14:16
  • 4
    @RichardOD, sure, in an ideal world. But some companies/individuals just aren't that interested in upholding their side of the contract. And sometimes there's nothing you can do about that in the real world – Glen Sep 24 '09 at 14:26
  • 1
    @Glen, then that's akin to using an unsupported product which, in my world, would imply i really shouldn't be using it in the first place. You don't just walk into a business you want to work with, hand them a contract and expect them to comply. They have to provide you with their side of the contract. If they don't or won't, it kinda means they don't want to do that kind of business and it's probably not a good idea to try and force them. And modifying their provided WSDL is borderline code-cracking. – nicerobot Mar 21 '10 at 16:57
  • @nicerobot As Glen has said though in the real world you are sometimes in a situation where there is no choice and you have to make the best of a bad situation, for instance when a client insists on using a particular service it may be that you need to fix the wsdl to get it to work which is far from 'code cracking'. It's perfectly acceptable to use your own local wsdl file to describe a remote service as long as you are aware that changes to the service won't be picked up by your local version. It's not ideal but just the way it is sometimes. – Jimbo Apr 03 '13 at 13:19

2 Answers2

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

Glen
  • 21,816
  • 3
  • 61
  • 76
1

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.

mjn
  • 36,362
  • 28
  • 176
  • 378