Biblioteca para crear apéndices de Java para el servicio web

Question

Me gustaría saber si alguien puede recomendar una buena biblioteca para generar stubs de servicios web de Java como clientes.

Actualmente estoy usando un producto que ha incrustado un generador que solo necesita el WSDL y luego crea las clases y métodos necesarios.

Mi problema es que arroja advertencias y no crea ningún método para algunos servicios web que estoy tratando de usar.

El verdadero problema es que no explica cuál es el problema (así que puedo ir con el propietario del servicio web y modificarlo) ni me permite modificar la salida para que pueda solucionar el problema yo mismo.

Sin embargo, los propietarios de los servicios web (porque esto sucede con varios ws diferentes) dicen que su ws funciona bien y, en realidad, si uso soapUI realmente funcionan !!!

Eché un vistazo rápido a las bibliotecas utilizadas por soapUI y me veo prometedor.

Sé que hay Eje que debería hacer el trabajo, pero mi preocupación es que mi generador de fallas ya está usando esa biblioteca (lo que me hace pensar que volverá a fallar)

Y últimamente no sé si estas dos bibliotecas generan el código fuente de Java o solo tienen métodos como

Object [] args = ...;
service.inkvoke("updateCustomer", args );

Cuando me gustaría tener algo como:

CustomerWs cws = ....
cws.updateCustomer(custId, custName, custAddress /*etc*/ );

Entonces, ¿alguien tiene un generador de stubs BUENO que pueda recomendar?

_{Estoy a punto de codificar mi propia mano, pero definitivamente tomará varios días para ser aceptable}

Answer 1

¿Qué estás usando actualmente? Yo uso Axis Wsdl2Java como una tarea Ant. Genera los tipos de trozos que desea. Funciona muy bien, aunque configurar Eclipse para ejecutar la compilación fue un poco complicado en Eclipse (había un puñado de frascos que necesitaba rastrear e incluir). En mi hormiga buildfile se ve así:

<taskdef name="axis-wsdl2java" classname="org.apache.axis.tools.ant.wsdl.Wsdl2javaAntTask" />
<target name="foo">
<axis-wsdl2java
              output="${build.dir}"
              testcase="false"
              verbose="true"
              typemappingversion="1.2"
              url="http://ws.domain.com/url/of/WebService?wsdl" />
<!-- Compile, etc... -->
</target>

Answer 2

Tenga mucho cuidado cuando se refiera a " Axis " ;: Apache Axis 1 fue abandonado en principios de 2006 con errores de seguridad de subprocesos que conducen a puntos muertos y giros de CPU (los cuales experimentamos). Te arrepentirás profundamente de usarlo. Apache Axis 2 es una reescritura completa y puede valer la pena. Pero le sugiero que primero mire Apache CXF y Metro de Glassfish .

Actualización: Aquí hay informes de errores en el punto muerto y 100% de rotación de la CPU . Aquí está el parche propuesto de Cyrille Le Clerc de hace tres años, nunca comprometido.

Eliminamos nuestros puntos muertos y giros recodificando a nuestro cliente en Java directo. Y luego el servidor Axis se negó a hablar con nosotros, enviando errores HTTP 500. Necesitábamos afirmar falsamente que éramos un cliente de Axis para obtener una respuesta adecuada. La interoperabilidad SOAP no era una prioridad para el equipo del Eje 1.

Answer 3

Me gusta Apache CXF: se integra muy bien con Maven a través de un complemento, y funciona. Lo he estado usando durante un tiempo para la generación de código de código auxiliar del cliente, y en la última compañía en la que trabajé también lo usaban para la parte del servidor de WS.

En los últimos proyectos en los que trabajé con CXF + Maven + Subversion, no incluimos las clases generadas en Subversion, solo una copia del archivo WSDL: las clases stub se generaron en el " generate " gol de Maven.

Answer 4

Apache Axis 2 es el camino a seguir ... aunque es posible que deba jugar un poco para hacerlo bien. Es quizás la forma más común de hacerlo. ¿Quizás la herramienta que está utilizando se basa en el Eje 1?

Answer 5

Definitivamente sugeriría usar algo basado en API basadas en estándares. Eso significaría JAX-WS API's. Apache CXF y Metro son las dos implementaciones principales de JAX-WS, aunque JBoss también tiene una implementación. Axis2 tiene una implementación no certificada, pero no admite código gen.

La mejor parte del uso de una API basada en estándares es que si SÍ encuentra un problema con el producto, puede probar el otro. En muchos casos que he visto, el otro producto tampoco funciona, pero arrojará un mensaje de error diferente o similar que ayudó a diagnosticar el hecho de que realmente es un problema en nuestro propio código o wsdl.

Además, JAX-WS está integrado en Java6. Si planea ejecutar Java6, puede usarlo y no tener que lidiar con tarros adicionales y demás.

Answer 6

El último JAX-WS como parte del metro ( http://metro.dev.java.net ) es una bonita capa de abstracción. Me cuesta un poco adaptarme, pero fue mucho más intuitivo para mí que algunas de las otras opciones disponibles.