Ventajas de usar un cliente dinámico con JAX-WS

Question

¿Cuáles son las ventajas de utilizar un cliente dinámico con servicios JAX-WS en lugar de simplemente usar clases de cliente generadas? ¿Cuales son las desventajas?

** En mi caso particular, estoy usando Apache CXF, no estoy seguro de qué otras bibliotecas permitan clientes "dinámicos".

- Pensé que no necesitaba agregar esto, pero ... Estoy buscando ventajas no obvias (sé ... subjetivas). No necesito que otra persona me diga que una ventaja de no usar clases generadas es que no necesito generar clases.

Answer 1

La ventaja es evitar generar e incluir código. En algunos entornos, eso es un problema. Si no existe una barrera en su entorno para incluir el código generado, entonces el cliente dinámico es una mala idea, ya que es más lento y engorroso.

El cliente dinámico es más lento porque el código (de los cuales escribí algunos) debe:

1. analizar el WSDL y esquema
2. generar código
3. compilar el código

Se es más engorroso porque no tiene clases de beans para ningún objeto complejo en su modelo de datos. Necesitas usar la reflexión.

Tenga en cuenta que el cliente dinámico es diferente de la interfaz de invocación.

Answer 2

La ventaja de utilizar un cliente dinámico es que no necesita haber generado los stubs antes del tiempo de ejecución. Esto le permite invocar genéricamente servicios que puede que no conozca en tiempo de ejecución.

Answer 3

Bueno, la documentación CXF es bastante clara acerca de las ventajas de Dynamic Clients:

CXF soporta varias alternativas para permitir que una aplicación se comunique con un servicio sin el SEI y clases de datos. JAX-WS especificó la API JAX-WS Dispatch, así como también la interfaz Provider para leer y escribir XML. Esta página, sin embargo, describe las facilidades dinámicas del cliente de CXF. Con clientes dinámicos, CXF genera clases SEI y bean en tiempo de ejecución, y le permite invocar operaciones a través de API que toman Objetos, o mediante el uso de la reflexión para llamar a los servidores proxy completos.

En otras palabras, no es necesario las definiciones de clases como se muestra en el ejemplo siguiente documentación:

JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance(); 
Client client = dcf.createClient("echo.wsdl"); 

Object[] res = client.invoke("echo", "test echo"); 
System.out.println("Echo response: " + res[0]); 

En cuanto a las desventajas, que son obvias (y este es el precio a pagar): estás manipulando cadenas, perdiste la escritura fuerte.

Answer 4

Las clases de clientes generadas son geniales si sabe con precisión a qué servicio web va a llamar su código de cliente y que no va a cambiar a lo largo de la vida de su cliente.

Si cualquiera de estos no es el caso, entonces tendrá que pensar en cómo su cliente manejará estas situaciones. La API de envío le brinda la flexibilidad de generar la llamada del servicio web sobre la marcha sin tener un conocimiento previo del servicio al que se accede. Esto obviamente tiene el costo de que su código necesite soportar las opciones de configuración requeridas para construir esa llamada.

Con todo esto, una cierta cantidad de responsabilidad recae en el desarrollador/mantenedor de la interfaz del servidor para no introducir cambios que rompan el código del cliente.

Answer 5

Tuve una conversación similar con un compañero de trabajo el otro día. Él estaba usando el cliente de Spring, que requiere el uso de una interfaz para compilar el cliente, pero luego Spring inyecta el código real para que la interfaz funcione. Básicamente se redujo a la más antigua de las sierras entre nosotros, cosas como proxies dinámicos generalmente introducen algún tipo de impuesto al rendimiento, él está bien con eso, comencé a escribir controladores de dispositivo de vida, y por lo tanto estoy completamente predispuesto a favor de la velocidad. Ganancias más rápidas/más pequeñas en lo que a mí respecta, y como no estoy limitado a entornos tan limitados ... diablos, mi teléfono Droid hace que todos los sistemas en los que trabajé, incluidos los mainframes, en mis primeros 10 años parezcan profesionalmente insignificantes. Bajaré del lado de la velocidad. La réplica común para esto es que hay muchos otros cuellos de botella que son el problema "real", y que este problema es insignificante contra ellos ... y puede ser cierto ... pero todo ayuda. Si lees las cosas desde Steve Souders y sus compatriotas ... los usuarios pueden notar un cambio de tan solo 400 milisegundos ... no necesariamente registran que las cosas son más lentas, pero su reacción es diferente. Entonces, como no puedo hacer nada con respecto a la velocidad de la red, la sobrecarga del índice de la base de datos, etc., entonces al menos puedo hacer el mejor trabajo posible con las cosas en las que puedo influir. ¡Menos mal! ¡¡Lo siento por eso!! ¡Saliendo de la tribuna ahora! ;)

Answer 6

DII(Dynamic Invocation Interface) Client: Con el DII, un cliente puede llamar a un procedimiento remoto incluso si la firma del procedimiento remoto o el nombre del servicio son desconocidos hasta el tiempo de ejecución.

Debido a su flexibilidad, un cliente DII se puede utilizar en un intermediario de servicios que descubre dinámicamente los servicios, configura las llamadas remotas y ejecuta las llamadas.

• Ventajas

  • Aquí tenemos que crear la interfaz Java simples que describen las operaciones apoyadas por el servicio web para el acceso. Por lo tanto, no es necesario que los talones generados automáticamente tengan acceso al servicio.
  • El uso de punto final genera WSDL y Stubs sobre la marcha, es decir, en tiempo de ejecución.

• Desventajas

  • Incluso en este estilo tenemos que conocer el servicio web antes de crear el cliente.
  • En comparación con Generado Stub (GS) funciona lentamente debido a WSDL y stubs genera en tiempo de ejecución.