How to reduce memory size of Apache CXF client stub objects?

My web service client application uses Apache CXF to generate client stubs for talking to several web services. The generated CXF web service stub objects have quite a large memory footprint (10 - 15 web service objects take more than 64 MB of memory). Is there any way开发者_Python百科 to reduce the CXF object footprint?

We had similar problems with Axis. The problem we had was that we wanted to do many concurrent calls to the web service and the Axis clients generated using the WSDL caused each client to use a lot of memory. The clients arent thread safe, so we had to create one client per request.

We had two choices. First we could prune the generated code - but that was not nice for maintenance reasons.

Second, we simply pruned the WSDL to remove the parts that were not relevant to us, and regenerated slimmed down clients. That way, if we called one service method, it's client wouldn't contain bulk for unrelated methods which that thread wouldn't be using.

Worked quite well, but is still a maintenance nightmare, because any time the WSDL gets updated (e.g. our partner releases a new version of their web service), we need to spend time creating cut down wsdls. The ideal solution I guess would be to get our partner to recognise our problems and take ownership of the cut down WSDLs.

We took a different approach to the CXF client. I haven't looked into its memory footprint, which isn't an issue in our context, but it's certainly a simpler method of development than creating stubs. It looks something like this:

JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();

factory.setAddress(endpoint);
factory.getServiceFactory().setDataBinding(new AegisDatabinding());
factory.setServiceClass(myInterface.class);
Object client = factory.create();
((BindingProvider) client).getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPERTY, true);

myInterface stub = (myInterface)client;

We just do that (of course we've built some utility classes to simplify things further) for any WS we want to hook up to at runtime (provided, of course, we have its Java interface). Our goal was to make the whole WS thing as transparent to the programmers as possible. We really have no interest in WSDLs and XSDs per se. We suspect that we're not alone.

If your SOAP needs are very basic, you could look into kSOAP2 which is really memory efficient. It is designed to run fine in a J2ME phone application.