soap - Mejores prácticas de WSDL

gsoap

Question

Estoy desarrollando una aplicación SOAP que se integra con un tercero. Creo que el WSDL de este tercero es muy extraño. Soy bastante nuevo en SOAP, así que no quiero pedirles que lo solucionen si no está roto. Aquí hay algunas cosas que he notado que considero incorrectas al respecto, aunque estoy seguro de que técnicamente es un documento válido (de ahí la razón por la que escribí "mejores prácticas" en el título). Además, estoy usando gSOAP como mi biblioteca SOAP, que puede ser el motivo por el que creo que algunas de estas cosas son raras (soy incluso más nuevo en SOAP que en SOAP en general).

1. tienen interfaces especificadas para SOAP 1.1 y SOAP 1.2 en el mismo WSDL. Esto hace que gSOAP genere el doble de clases que necesita, ya que solo voy a usar 1.2.

2. todos sus espacios de nombres son http://tempuri.org . Eso no debería ser así, ¿verdad?

3. a pesar de definir un grupo de llamadas RPC, su WSDL usa el formato del documento. Estoy pensando en pedirles que cambien al formato RPC porque parece que gSOAP no generará métodos que tomen los parámetros de tipo C ++ para el formato del documento. En cambio, crea una nueva clase para cada entrada de función API y datos de respuesta. Tendré que escribir otra capa de envoltura alrededor de las cosas de GSOAP para proporcionar una API razonable para el resto de mi aplicación si no puedo solucionarlo. Además, AFAICT, el XML que irá y regresará sería exactamente el mismo que ahora si cambiaran a RPC, así que no creo que sea difícil.

4. los elementos tienen minOccurs = 0, sin embargo, cuando envío solicitudes sin ellos, obtengo errores que indican que son necesarios (a veces incluso acumula rastros de excepciones de punteros nulos). Deben especificarlos como minOccurs = 1 si son necesarios, ¿no?

5. casi todas las funciones del servicio web especifican una respuesta que incluye un número entero para indicar el éxito (realmente un booleano) y una cadena de mensaje de error. ¿Deberían estar usando fallas SOAP para esto? Creo que sería más fácil de manejar para mi aplicación si fuera un error, ya que gSOAP me permitirá resolverlo fácilmente (e imprimir el mensaje de error trivialmente).

Por supuesto, no tengo grandes esperanzas de que esta compañía de terceros cambie su WSDL simplemente porque se los haya pedido. Al menos aprenderé algo ... por lo que sé, ninguno de estos es incorrecto o incluso cuestionable. Gracias por tu ayuda.

Answer 1

Lo que ha encontrado es la pereza típica de un tercero al crear sus servicios web. Me imagino que no tendrás mucha suerte tratando de razonar con ellos, sin embargo, puedes editar manualmente el WSDL para eliminar las 1.1 definiciones.

Answer 2

1 - Probablemente consideran esto una característica. :-)

2 - Eso es horrible.

3 - Mucha gente lo recomienda. Se llama formato envuelto.

4 - Estás en lo cierto.

5 - Depende Teóricamente, probablemente estés en lo cierto, pero en la práctica, muchos kits de herramientas SOAP no tienen un soporte muy bueno para las fallas SOAP, por lo que pueden haber elegido deliberadamente no usar excepciones.

Answer 3

Me parece que el tercero con el que intentas interactuar tampoco conoce los servicios web.

Según su descripción, suena muy típico de una implementación de servicio web Microsoft ASP.NET, el tercero escribe un poco de VB o C # para interconectar lo que tienen para ofrecer, lo empuja a un servidor ASP.NET y lo llama un día, dependiendo en el motor ASP.NET para generar automáticamente el WSDL a petición.

Podría pedirles que no proporcionen las definiciones de SOAP 1.1, pero no creo que lo ayuden, porque no saben cómo. Podrías preguntarles por qué el espacio de nombres es tempuri.org y estoy seguro de que su respuesta sería algo así como "Tendremos que analizar eso" cuando lo que realmente quieren decir es "¿Lo es?" porque ellos tampoco saben por qué.

El espacio de nombres está controlado por una directiva de compilación en el código y tempuri.org es el valor predeterminado de Microsoft (no recuerdo lo que se llama atmósfera lo siento). Por supuesto, el valor del espacio de nombres en realidad no importa mucho (aparte de simplemente parecer raro), ya que realmente solo tiene la intención de proporcionar un identificador de cadena único para la resolución de nombres de variables. Tal vez las otras cosas se pueden controlar de manera similar, no sé, realmente no conozco los servicios web o ASP.NET ni nada de eso, tampoco soy un gran admirador de la tecnología.

Answer 4

En primer lugar, nadie escribe realmente WSDL, es generado por herramientas. Las herramientas de los proveedores probablemente inserten las URL CORRECTAS para el espacio de nombre y probablemente tengan algunos botones de opción que digan - V1.0, V1.1, Ambos. Probablemente, el proveedor tenía algún código no SOAP existente y utilizó algunas herramientas para envolverlos como un servicio SOAP.

¡Nadie escribe WSDL así que no deberías leerlo! Obtenga un juego de herramientas decente, algo así como SOAPUI decodificará el WSDL y le permitirá navegar sin que su cabeza explote. Es Java pero es la mejor herramienta de prueba en cualquier idioma en el que codifique.

Mi experiencia en SOA se basa principalmente en Java, donde no se puede elegir entre bibliotecas y herramientas. C ++ es probablemente menos maduro en esta área, pero realmente parece que el problema es la elección de la herramienta en lugar del WSDL. En el mundo real, se le presentará WSDL menos que perfecto, por lo que su herramienta debería ser capaz de manejarlo de manera razonable.

Answer 5

Encuéntrese con esto ahora mismo y descubra que debe escribir el prefijo correctamente, el prefijo debe ser un trabajo seguido de DOS guiones bajo ''youtns__methodname''

por ejemplo

typedef double xsd_double;
int ns__add(xsd_double a, xsd_double b, xsd_double &result);
int ns__sub(xsd_double a, xsd_double b, xsd_double &result);
int myns__sqrt(xsd_double a, xsd_double &result);

esto generará dos archivos wsdl después de ejecutar soapcpp2: ns.wsdl y myns.wsdl

¿Pero es usted define su método de esta manera (un guión bajo)

int ns_add(xsd_double a, xsd_double b, xsd_double &result); // wrong 

el spapcpp2 no generará nada.

Answer 6

Me gustaría ser un poco más general sobre las mejores prácticas para la creación de WSDL:

1. Contrato primer desarrollo
A diferencia de James, enfatizaría fuertemente en el uso del método Contract-First, porque permite al desarrollador usar todas las capacidades de XML (restricciones, patrones, ...) y desde allí es bastante fácil generar código para cualquier lenguaje de programación. Otra razón es que el esquema en <wsdl: types> es el contrato entre los dos sistemas que se comunican entre sí. Si el desarrollador crea el código WSDL, se pueden introducir dependencias técnicas en el lenguaje de programación específico (tipos de datos, ...).

2. Documento / estilo literal
La validación de SOAP con codificación RPC puede ser complicado, las consultas XPATH y las transformaciones XSLT también son simplemente imposibles, y este estilo ya no se usa.

RPC / literal también causa problemas al validar el XML (cuenta para ciertas convenciones de nomenclatura). Algunos motores SOAP eliminan los espacios de nombres definidos por esquema, por lo que la validación se vuelve imposible.

Al utilizar el estilo Documento / literal, el cuerpo SOAP se procesa completamente como un documento XML, que se puede validar, transformar y consultar de forma estándar.

3. Separación de preocupaciones
Separe la definición del esquema del archivo WSDL mediante las directivas <import ..> y <include ..>. Esto fomenta la reutilización de esquemas y la separación de espacios de nombres en diferentes archivos .xsd y también reduce el tamaño del archivo;)