Cómo reducir el tamaño de la memoria de los objetos stub del cliente Apache CXF?

Question

Mi aplicación de cliente de servicio web usa Apache CXF para generar stubs de cliente para hablar con varios servicios web. Los objetos stub del servicio web CXF generados tienen una huella de memoria bastante grande (10 - 15 objetos de servicio web toman más de 64 MB de memoria). ¿Hay alguna forma de reducir la huella de objeto CXF?

Answer 1

Tuvimos problemas similares con Axis. El problema que tuvimos fue que queríamos hacer muchas llamadas simultáneas al servicio web y los clientes de Axis generados con el WSDL provocaron que cada cliente usara mucha memoria. Los clientes no son seguros, por lo que tuvimos que crear un cliente por solicitud.

Teníamos dos opciones. Primero podríamos podar el código generado, pero eso no fue bueno por razones de mantenimiento.

En segundo lugar, simplemente eliminamos el WSDL para eliminar las partes que no nos eran relevantes y regeneramos los clientes reducidos. De esta forma, si llamamos a un método de servicio, su cliente no contendría volumen para métodos no relacionados que ese hilo no estaría usando.

Funcionó bastante bien, pero sigue siendo una pesadilla de mantenimiento, porque cada vez que WSDL se actualiza (por ejemplo, nuestro socio lanza una nueva versión de su servicio web), tenemos que perder tiempo creando wsdls reducidos. La solución ideal, supongo, sería lograr que nuestro socio reconozca nuestros problemas y tome posesión de los WSDL reducidos.

Answer 2

Tomamos un enfoque diferente para el cliente CXF. No he estudiado su huella de memoria, que no es un problema en nuestro contexto, pero ciertamente es un método más simple de desarrollo que la creación de stubs. Se ve algo como esto:

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; 

Acabamos de hacer que (por supuesto que hemos construido algunas clases de utilidad para simplificar aún más las cosas) para cualquier WS queremos enganchar hasta en tiempo de ejecución (siempre, por supuesto, nos tiene su interfaz Java). Nuestro objetivo era hacer todo el WS lo más transparente posible para los programadores. Realmente no tenemos ningún interés en WSDLs y XSDs per se. Sospechamos que no estamos solos.

Answer 3

Si sus necesidades de SOAP son muy básicas, puede buscar en kSOAP2, que es realmente eficiente desde el punto de vista de la memoria. Está diseñado para funcionar bien en una aplicación de teléfono J2ME.