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 application performance.

We use the webservice in client appliction, startup time and memory usage are issues. Large WSDL means that jax-ws will takes longer to do binding and will takes more memory for the stub class.

Is is possible that we trim WSDL file to a lightweight version? Are there any tool for this purpose?

I do not think my webservice provider will generate another WSDL for us. We may have to do it auto in the build script.

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

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 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

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 5

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.

Answer 6

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 7

The physical size of the WSDL should not matter if you generate client stubs classes at compile time (e.g. via AXIS wsdl2java.) If you are downloading the WSDL and parsing it for each request then the download time will likely dwarf the parse time. Consider caching the file locally if the download time becomes an issue. If the parse time becomes an issue you may want to consider trimming the file or caching the parsed objects. Use care when caching or trimming the file as you will need to integrate any changes when your provider issues a new WSDL. Consider updating your cached/trimmed WSDL each time the service is restarted or at some interval.