java - registros - libros auxiliares ejemplos

¿Cómo reducir el tamaño de memoria de los objetos de código auxiliar de cliente Apache CXF?

Question

La aplicación cliente de mi servicio web usa Apache CXF para generar stubs de clientes para hablar con varios servicios web. Los objetos de código auxiliar de servicio web CXF generados tienen una huella de memoria bastante grande (10 a 15 objetos de servicio web requieren más de 64 MB de memoria). ¿Hay alguna manera de reducir la huella de objetos CXF?

Answer 1

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

Answer 2

Tomamos un enfoque diferente para el cliente CXF. No he examinado su huella de memoria, que no es un problema en nuestro contexto, pero ciertamente es un método de desarrollo más simple 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;

Simplemente lo hacemos (por supuesto, hemos creado algunas clases de utilidades para simplificar aún más las cosas) para cualquier WS que queramos conectar en tiempo de ejecución (siempre que tengamos su interfaz Java). Nuestro objetivo era hacer que todo el WS fuera lo más transparente posible para los programadores. Realmente no tenemos interés en WSDLs y XSDs per se . Sospechamos que no estamos solos.

Answer 3

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

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

En segundo lugar, simplemente podamos el WSDL para eliminar las partes que no eran relevantes para nosotros y regeneramos a los clientes. De esa manera, si llamáramos a un método de servicio, su cliente no contendría en masa 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 se actualiza el WSDL (por ejemplo, nuestro socio lanza una nueva versión de su servicio web), tenemos que dedicar tiempo a crear wsdls reducidos. Supongo que la solución ideal sería lograr que nuestro socio reconozca nuestros problemas y se haga cargo de los WSDL reducidos.