example - SoapUI vs Java Web Service Client
apache cxf web service (3)
Si un servicio web SOAP funciona bien a través de SoapUI (produciendo las respuestas SOAP correctas), mientras que construir un cliente de servicio web en Java utilizando diferentes API / frameworks para llamar a este servicio web enfrenta diferentes problemas, ¿es seguro considerar estable este servicio web? y los problemas son del lado del consumidor?
Estoy haciendo una pregunta genérica aquí, ya he pedido una detallada que probablemente sea demasiado larga para leer. Me interesa más el concepto que mi implementación real, por lo que si puede responder mi pregunta sin consultar mi publicación más larga, hágalo.
ACTUALIZACIÓN : me he dado cuenta de que incluso si el WSDL es compatible con WS-I y funciona correctamente a través de SoapUI, esto no es suficiente para concluir que el servicio web no está roto. Como dijo @jtahlborn, SoapUI es muy tolerante con los servicios web dañados, y podría engañarle fácilmente para que crea que su servicio web funciona bien, que es lo que sucedió en mi caso.
Estoy construyendo la respuesta SOAP en el ESB y mi problema fue que utilicé un espacio de nombres que se definió en el WSDL pero no en el esquema. SoapUI recibió la respuesta y me la mostró (con el espacio de nombres incorrecto); este problema podría haberse evitado si activara la opción de validación de respuesta .
También es digno de mencionar que en el cliente de servicio web Java que creé para probar mi servicio web, la respuesta no se pudo cargar en el objeto de salida (apareció un error NullPointerException cuando intenté acceder al objeto de salida), esto se debió a el problema del espacio de nombres y comenzó a funcionar correctamente una vez que arreglé el espacio de nombres.
Es muy probable que el consumidor (cliente) tenga fallas ... Si el cliente se genera usando wsdl2java, es una gran posibilidad tener errores en él ... y si está utilizando algunas funcionalidades especiales que son válidas (conforme a w3c), entonces no use No se sorprenda ... los clientes generados a veces hacen esto ... incluso algunas bibliotecas usadas para generar clases de Java o bibliotecas para generar los servicios web están llenas de errores ...
Muchas de las cosas no son compatibles con bibliotecas conocidas y de uso frecuente ... (No quiero dar nombres, pero wsdl4java no es perfecto) ..
Si está utilizando seguridad o algo así ... mayores posibilidades de tener errores tanto en el servidor como en el lado del cliente :)
quizás si nos dices cuál es el problema, podemos ayudarte ...
Existen herramientas de prueba de WS-I para verificar que su servicio web cumpla con los perfiles de interoperabilidad de servicios web . Si su servicio se adhiere al perfil básico WS-I, y SoapUI puede llamarlo, los problemas son definitivamente del lado del consumidor.
EDITAR: bueno, o entre ambos ...
SoapUI puede verificar su wsdl para ver si cumple con WS-I, consulte http://www.soapui.org/SOAP-and-WSDL/working-with-wsdls.html .
SoapUI es un producto fantástico. una de las cosas que lo convierte en un gran producto, sin embargo, es que es muy tolerante con los servicios web mal definidos. en nuestro producto, nos ocupamos de muchos servicios web, y un comentario frecuente sobre un problema en nuestro producto es "funciona bien en SoapUI". Hemos aprendido de la peor manera que SoapUI tolerará todo tipo de servicios web rotos. Entonces, en resumen, trabajar con SoapUI no es una prueba de que su servicio web esté bien definido.