Trabajando con wsdl grande, ¿podemos recortarlo?

Question

Mi proveedor de servicios web me dio un archivo WSDL grande, pero solo usaremos algunas funciones internas.

Creo que el gran WSDL tiene un impacto negativo en el rendimiento de la aplicación.

Usamos el servicio web en la aplicación del cliente, tiempo de inicio y uso de memoria son cuestiones.Un WSDL grande significa que jax-ws tardará más en vincularse y necesitará más memoria para la clase stub.

¿Es posible que recortemos el archivo WSDL a una versión ligera?¿Existe alguna herramienta para este propósito?

No creo que mi proveedor de servicios web genere otro WSDL para nosotros.Puede que tengamos que hazlo automáticamente en el script de compilación.

Answer 1

En resumen, sus respuestas son " Ninguna herramienta, pero puede hacer bricolaje " ;.

Desearía que haya una herramienta simple que pueda hacerlo porque mi WSDL contiene demasiadas funciones y esquemas de estructura de datos no utilizados.

Si puedo automatizarlo, WSDL - > WSDL recortado - > generar clases de stubs de cliente. No se generará nada sin usar, no se usará mal, no se requerirán mantenimientos, no tocaremos el código generado, y realmente puedo concentrarme en el código que está en uso. JAR más pequeño, menor tiempo de análisis XML. Si se actualiza el WSDL, solo tendré que reconstruir las clases de apéndices del cliente y ejecutar la prueba unitaria.

Traté de mantenerme alejado de los humanos invocados. Lleva tiempo, fácilmente equivocarse, y tener que rehacer cada vez que se realiza un pequeño cambio en el WSDL original.

No estoy familiarizado con el esquema WSDL. Creo que XSLT puede hacerlo?

Answer 2

El tamaño del WSDL no tendrá ningún impacto en el rendimiento...a menos que lo esté descargando y/o analizando para cada solicitud.Y si estás haciendo lo último, no lo hagas.Sólo es necesario procesarlo cuando el servicio cambia, y el servicio siempre debe cambiar de manera compatible, con soporte continuo para mensajes antiguos (al menos durante algún período de tiempo superpuesto).

Debería considerar procesar un WSDL como un cambio de programa y hacerlo como lo haría con cualquier versión, con control de versiones, pruebas, etc.

Answer 3

El problema no está en el tamaño del WSDL en sí. Lo que importa es el tamaño del código generado. Por ejemplo, si usa Axis2 para generar su código a partir de un WSDL grande, terminaría creando una clase de Solicitud / Respuesta para cada operación WSDL, así como las clases de sus tipos de retorno. Terminaría con una gran clase de código auxiliar más adelante, lo que podría afectar el rendimiento ya que importaría las clases requeridas por las operaciones del servicio web que no necesita.

No hay una herramienta fácil para hacer eso. Usualmente uso notepad ++ para hacer eso, y SÍ, siempre puedes cometer errores al hacerlo.

Otro error común es elegir generar métodos de estilo Sync y Async, cuando la mayoría de las veces (al menos en mi caso), solo usaría métodos de estilo Sync. Esto también podría aumentar drásticamente el tamaño de su trozo.

Answer 4

No he usado las herramientas de las que estás hablando, pero puedes ejecutar con éxito métodos de servicio web sin que el código toque un archivo WSDL.

Este parece ser un buen momento para ejecutar una prueba rápida. Corte todo del archivo WSDL, excepto lo que necesita para ejecutar uno de los métodos más simples que planea usar. Haga referencia a esa copia del WSDL en su lugar. Si funciona, ¡ya sabes qué hacer a continuación!

Answer 5

No hay necesidad de recortar el WSDL. Si está configurado para seguir este camino, simplemente elimine cualquier cosa en las clases de código auxiliar que no necesite. Solo asegúrese de probarlo a medida que avanza para asegurarse de que todo sigue funcionando.

Answer 6

Puede eliminar manualmente < wsdl: operation > elementos correspondientes a los métodos que no necesita y vea si eso es suficiente. Debería poder eliminar esos elementos sin tocar el resto del archivo.

Answer 7

El tamaño físico de WSDL no debería importar si genera clases de apéndices de cliente en tiempo de compilación (por ejemplo, a través de AXIS wsdl2java). Si está descargando WSDL y analizándolo para cada solicitud, la descarga el tiempo probablemente eclipsará el tiempo de análisis. Considere almacenar en caché el archivo localmente si el tiempo de descarga se convierte en un problema. Si el tiempo de análisis se convierte en un problema, puede considerar recortar el archivo o almacenar en caché los objetos analizados. Tenga cuidado al almacenar en caché o recortar el archivo, ya que necesitará integrar cualquier cambio cuando su proveedor emita un nuevo WSDL. Considere actualizar su WSDL en caché / recortado cada vez que se reinicie el servicio o en algún intervalo.