When working with large wsdl, can we crop it?

Question

My webservice provider gives me a large WSDL file, but we will use only a few functions internally.

I believe that a large WSDL adversely affects application performance.

We use the web service in the client application, startup time and memory usage . A large WSDL means that jax-ws will take longer to bind and require more memory for the stub class.

Is it possible that we are trimming the WSDL file into a lite version? Is there any tool for this purpose?

I don’t think my webservice provider will create another WSDL for us. We may need to do this automatically in the build script .

Answer 1

In short, your answers are: "There is no tool, but you can do DIY."

I want a simple tool to be able to do this because my WSDL contains too many unused functions and data structure schemas.

If I can automate it, WSDL -> trim WSDL -> create client stub classes. Nothing unused will be created, there will be no abuse, there is no need for maintenance, we will not touch on the generated code, and I can really focus on the code that is used. Smaller JAR, shorter XML parsing time. If the WSDL is updated, I only have to rebuild the stub classes and run the unit test.

I tried to get away from the call of man. It takes time, it’s easy to get an error, and you have to redo every time every small change in the original WSDL.

I do not understand the WSDL scheme. I think this can be done using XSLT?

Answer 2

I did not use the tools you are talking about, but you can successfully execute web service methods without the code ever relating to the WSDL file.

This seems like the right time for a quick test. Cut everything from the WSDL file, except what you need to execute one of the simpler methods that you plan to use. Link to this copy of WSDL. If this works, you know what to do next!

Answer 3

No need to trim WSDL. If you are going to follow this path, simply delete something in the necessary classes that you do not need. Just make sure you check it out when you go to make sure it still works.

Answer 4

You can simply manually remove the <wsdl: operation> elements corresponding to methods that you do not need and see if this is enough. You must remove these elements without touching the rest of the file.

Answer 5

The physical size of the WSDL should not matter if you create client stub classes at compile time (for example, via AXIS wsdl2java.) If you download WSDL and parse it for each request, then loading time will probably outshine the parse time. Consider caching the file locally if download time becomes a problem. If parsing time becomes a problem, you may want to crop the file or cache the analyzed objects. Be careful 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 / truncated WSDL each time the service restarts or at some interval.

Answer 6

The size of the WSDL will have zero impact on performance ... unless you download it and / or parse it for each request. And if you do the latter, do not do this. It needs to be processed only if the service is changing, and the service should always change compatible with the constant support of old messages (at least for some overlapping period of time).

You should consider processing WSDL to change the program and do it, like any release, with versions, testing, etc.

Answer 7

The problem is not the size of the WSDL itself. It matters the size of the generated code. For example, if you use Axis2 to generate code from a large WSDL, you must create a Request / Response class for each WSDL operation, as well as return type classes. You will later receive a huge stub class, which can affect performance, as it will import the classes that are required for web service operations that you do not need.

There is no simple tool for this. I usually use notepad ++ for this, and YES, you can always be wrong with this.

Another common mistake is that you choose both Sync and Async methods, when most of the time (in my case, at least) you used only Sync style methods. It can also significantly increase the size of your stub.