from - web service java netbeans
Trabajando con wsdl grande, ¿podemos recortarlo? (7)
El tamaño físico del WSDL no debería importar si genera clases de stubs de cliente en tiempo de compilación (por ejemplo, a través de AXIS wsdl2java). Si está descargando el WSDL y analizándolo para cada solicitud, el tiempo de descarga probablemente empequeñecerá 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, es posible que desee considerar recortar el archivo o almacenar en caché los objetos analizados. Tenga cuidado al almacenar en caché o recortar el archivo, ya que deberá 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.
Mi proveedor de servicios web me da un gran archivo WSDL, pero vamos a usar solo algunas funciones dentro.
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, el tiempo de inicio y el uso de la memoria son problemas. WSDL grande significa que jax-ws tardará más en enlazarse y requerirá más memoria para la clase de stub.
¿Es posible que recortemos el archivo WSDL a una versión ligera? ¿Hay alguna herramienta para este propósito?
No creo que mi proveedor de servicios web genere otro WSDL para nosotros. Es posible que tengamos que hacerlo automáticamente en el script de compilación .
No es necesario recortar el WSDL. Si está decidido a seguir por este camino, simplemente elimine cualquier cosa en las clases de stub que no necesite. Solo asegúrate de probarlo mientras avanzas para asegurarte de que todo sigue funcionando.
No he usado las herramientas de las que está hablando, pero puede 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 desde el 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!
Puede eliminar manualmente los elementos <wsdl: operation> correspondientes a los métodos que no necesita y ver si eso es suficiente. Debería poder eliminar esos elementos sin tocar el resto del archivo.
En resumen, sus respuestas son "Sin herramienta, pero puede hacerlo bricolaje".
Deseo que haya una herramienta simple que pueda hacerlo porque mi WSDL contiene demasiadas funciones y esquemas de estructura de datos sin usar.
Si puedo automatizarlo, WSDL -> WSDL recortado -> generar clases de stubs de cliente. No se generará nada que no se utilice, no se usarán mal, no se requerirán mantenimientos, no tocaremos el código generado, y realmente puedo enfocarme en el código que está en uso. JAR más pequeño, tiempo de análisis de XML más corto. Si el WSDL se actualiza, tendré que reconstruir solo las clases de stubs del cliente y ejecutar la prueba unitaria.
Intenté alejarme de los humanos invocados. Lleva tiempo, es fácil equivocarse, y tiene que volver a hacer cada cambio pequeño en el WSDL original.
No estoy familiarizado con el esquema WSDL. ¿Estoy pensando que XSLT puede hacerlo?
El tamaño del WSDL tendrá un impacto cero 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. Solo se debe procesar cuando el servicio cambie, y el servicio siempre debería cambiar de manera compatible, con soporte continuo de mensajes antiguos (al menos durante un período de tiempo superpuesto).
Debería considerar el procesamiento de un WSDL como un cambio de programa, y hacerlo como lo haría con cualquier versión, con versiones y pruebas, etc.
El problema no está en el tamaño del WSDL en sí mismo. Es el tamaño del código generado lo que importa. 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 de WSDL, así como también las clases de sus tipos de devolución. Al final, terminaría con una gran clase de código auxiliar, 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 mientras lo haces.
Otro error común es elegir generar métodos de estilo Sync y Async, cuando la mayoría de las veces (en mi caso al menos), solo usaría métodos de estilo Sync. Esto también podría aumentar drásticamente el tamaño de su stub.