Compatibilidad con versiones anteriores y servicios web

Question

Así que soy un poco nuevo en los servicios web y recientemente surgió una situación en la que agregamos un elemento a un tipo de datos que se devuelve al cliente. Los clientes se quejaron de que esto rompió su implementación porque se ahogaba en el nuevo elemento que no esperaba. (estamos proporcionando los servicios a través de Axis2).

Para mí, esto parece un cambio inofensivo que el cliente debe ser capaz de manejar con elegancia (he trabajado con algunos marcos de servicios que no son web donde agregar información opcional era completamente aceptable). Podría entender si eliminamos o cambiamos el nombre de algunos campos que causarían problemas para el cliente.

Básicamente, esperaría que el wsdl actuara como una interfaz. Si hacemos un cambio que esencialmente subtipe esa interfaz, esperaría que el cliente ignore felizmente los elementos extraños. ¿Es solo una breve venida de servicios web, o existe una forma sensata de hacer cambios pasivos a los servicios para que los nuevos clientes puedan obtener los datos adicionales mientras que los clientes antiguos pueden actualizar en su tiempo libre?

Answer 1

WSDL en realidad actúa como un contrato de más de una interfaz. El WSDL describe exactamente lo que la operación espera "recibir" y lo que espera "devolver". La analogía más cercana a esto sería que C cambie el prototipo de una función sin cambiar la función en sí, no coincidirán y eso causa problemas.

Cuanto más específico es el WSDL, más comportamiento está "garantizando" que esté en su lugar.

Si necesita flexibilidad en sus datos devueltos (es decir, añadir/quitar campos, etc) que puede hacer uno de los siguientes:

1. Versión sus definiciones WSDL y publicar los servicios que pueda redirigir las versiones más antiguas a nuevas versiones
2. Utilice más tipos abstractos de devolución de datos, como XML para ocultar la complejidad o cambiar los datos.

2 tiene más riesgos, pero se puede gestionar con XSD u otras tecnologías. Sus requisitos particulares del proyecto determinarán qué es aceptable.

Answer 2

En el pasado, cuando lidiaba con API de WebService expuestas, siempre he ido con la filosofía de versión de fecha. Desafortunadamente, debes lidiar con la compatibilidad con versiones anteriores de cualquier API que liberes al público una vez que salgas del modo "beta" (y algunas veces incluso entonces).

Lo que hicimos fue realmente simple; en el día de la nueva API fue puesto en libertad, nos creamos una estructura de carpetas, así:

http://mydomain.com/path/to/service/2009/12/17/servicename.svc 

De esta manera sabríamos qué versión era la última simplemente marcando la estructura de carpetas, y nuestros clientes no tendrían preocuparse por romper los cambios hasta que estuvieran listos para actualizarse. Trabajó como un campeón para nosotros; la única cosa que podría haber cambiado era utilizar una sola carpeta por lo que sería más fácil para ver todos juntos:

http://mydomain.com/path/to/service/2009-12-17/servicename.svc 

Answer 3

Un WSDL es efectivamente su interfaz SOAP publicada de su servicio web. Muchos clientes usan esto para generar sus proxies de clientes que exponen todos sus métodos de servicio web en su lenguaje de programación preferido. La mayoría de estos clientes generados por código son muy frágiles y optarán por lanzar una excepción si ven un elemento que no reconocen (es decir, no está en el WSDL) en lugar de ignorarlo. Algunos son más relajados y depende de la tecnología del cliente que utilizan, es decir,Los nuevos DataContract de Microsoft tienen una interfaz IExtensibleData en sus clientes para contener específicamente los datos que no reconocen, por lo que ignorarán en gran medida los elementos desconocidos.

Los proxies de cliente generados por código y SOAP se prestan a este tipo de problemas porque generan clientes que desean comprender "todo el esquema" en lugar de solo los bits que les interesan. La alternativa es que usen un Xml Analizador y simplemente saca los bits que necesitan.

Si su servicio web está en desarrollo o en constante cambio, SOAP no es realmente su mejor opción, ya que con cada cambio tendrá que regenerar, reconstruir y volver a implementar sus clientes de servicio. Dependiendo de su situación, es posible que desee considerar la prestación de servicios web REST + POX (Xml normal antiguo), ya que es más simple de analizar, ya que no tiene la sobrecarga de SOAP, se puede llamar a través de una URL normal y consumirse en entornos que no tiene una biblioteca SOAPClient (p. ej. directamente en un navegador, usando AJAX)

Answer 4

Una respuesta posible sería usar grupos de sustitución para habilitar modelos abstractos en los XSD que importe. La posibilidad de procesar un grupo de sustitución de este tipo aún debe validarse con los marcos que está utilizando para invocar esos servicios.