Working with large wsdl, can we trim it?

Question

My webservice provider give me a large WSDL file, but we are going to use only a few function inside.

I believe that the large WSDL have negative impact to the appli

Answer 1

In short, your answers are "No tool, but you can DIY".

I wish there are simple tool can do it because my WSDL contains too many unused function and schema of data structure.

If I can automate it, WSDL -> trimmed WSDL -> generate client stubs classes. Nothing unused will be generated, no misuse, no maintenances required, we will not touch on the generated code, and I can really focus on the code which in use. Smaller JAR, shorter XML parse time. If the WSDL get updated, I will had only to rebuild client stubs classes and run unit test.

I tried to keep off from human invoked. It takes time, easily to get mistake, and have to redo every time every little change on the original WSDL.

I am not conversant on the WSDL schema. I am thinking can it be done by XSLT?

Answer 2

I haven't used the tools that you're talking about, but you can successfully execute web service methods without the code ever touching a WSDL file.

This seems like a good time to run a quick test. Cut everything from the WSDL file except what you need to execute one of the simpler methods you plan to use. Reference that copy of the WSDL instead. If it works, you know what to do next!

Answer 3

The problem is not with the size of the WSDL itself. It's the size of the generated code that matters. For instance, if you use Axis2 to generate your code from a large WSDL, you'd end up creating a Request/Response class for every WSDL operation, as well as the classes of their return types. You'd end up with a huge stub class later on, which could affect performance since it would import classes that are required by web service operations that you don't need.

There's no easy tool to do that. I usually use notepad++ to do that, and YES you could always make mistakes while doing it.

Another common mistake is choosing to generate both Sync and Async style methods, when most of the time (In my case at least), you'd only use Sync style methods. This could dramatically increase the size of your stub as well.

Answer 4

The size of the WSDL will have zero impact on performance... unless you are downloading it and/or parsing it for every request. And if you are doing the latter, don't. It need only be processed when the service changes, and the service should always change compatibly, with continuing support of old messages (at least for some overlapping time period).

You should consider processing a WSDL to be a program change, and do it as you would any release, with versioning, and testing, etc.

Answer 5

You could just manually remove the <wsdl:operation> elements corresponding to the methods you don't need and see if that's enough. You should be able to remove those elements without touching the rest of the file.

Answer 6

There is no need to trim the WSDL. If you're set on going down this path, simply delete anything in the stub classes that you don't need. Just make sure to test it as you go to make sure everything is still working.