Compatibilidad hacia atrás y Servicios Web

Question

Pues yo soy un poco nuevo en servicios web y una situación recientemente llegó hasta donde hemos añadido un elemento a un tipo de datos que recibe devuelve al cliente.Los clientes se quejaron de que este rompió su implementación, debido a que se ahogaron en el nuevo elemento que no esperaba.(estamos en la prestación de los servicios a través de Axis2).

Para mí esto parece un inofensivo cambio de que el cliente debe ser capaz de manejar correctamente (he trabajado con algunos de los no-web-servicio marcos donde la adición opcional de la información era totalmente aceptable).Se podría entender si se elimina o cambia el nombre de algunos de los campos que eso iba a causar problemas para el cliente.

Básicamente, yo esperaría que el wsdl para actuar como una interfaz.Si hacemos un cambio que, en esencia, los subtipos de la interfaz, yo esperaría que el cliente felizmente ignorar elementos extraños.Es sólo un corto venida de servicios web, o es que hay una sana forma de hacer el pasivo cambios en los servicios de modo que los nuevos clientes pueden obtener los datos adicionales mientras que los viejos clientes 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 de espera "recibir" y lo que se espera "retorno". La analogía más cercana a esto sería en C cambiar el prototipo de una función sin cambiar la función en sí, ellos no coinciden y que causa problemas.

Cuanto más específico sea el WSDL es el comportamiento que usted está más "garantizar" a estar en su lugar.

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

1. Versión sus definiciones WSDL y servicios que pueda redirigir publicar versiones anteriores a versiones más recientes
2. Utilice los tipos de retorno de datos más abstractos, como XML para ocultar los datos de complejidad o cambiantes.

2 tiene un poco más de riesgo, pero puede ser controlada con XSDs u otras tecnologías. Sus proyecto en particular se dictan lo que es aceptable.

Answer 2

En el pasado, cuando se trata de API WebService expuestas, siempre he ido con la filosofía fecha de versiones. Por desgracia, lo que tiene que hacer frente a la compatibilidad hacia atrás para cualquier API que suelte al público una vez que estás fuera de modo "beta" (y, a veces incluso entonces).

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

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

De esta manera queremos conocer qué versión era la última simplemente marcando la estructura de carpetas, y nuestros clientes no tener que preocuparse por romper cambios hasta que estuvieran listos para actualizar. Trabajado 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

WSDL es, efectivamente, se publicó el JABÓN de la interfaz de su servicio web.Muchos clientes utilizan para generar su cliente de proxy que se exponga todo su webservice métodos en el lenguaje de programación elegido.La mayoría de estos código generado por los clientes son muy frágiles y se elige lanzar una excepción en caso de que un elemento que no reconocen (es decir,no en el WSDL), en lugar de ignorarlo.Algunos están más relajados, y es realmente hasta que el cliente la tecnología que utilizan es decir,Microsoft del nuevo DataContract han IExtensibleData interfaz de sus clientes, específicamente contener datos que no reconoce, de modo que ellos ignoran en gran parte de las incógnitas.

El JABÓN y el código generado por el cliente de proxy se presta a este tipo de problemas debido a que generan los clientes que desean comprender "todo el esquema' en lugar de sólo los bits que están interesados en.La alternativa es la utilización de un Analizador de Xml y simplemente tire de los bits que se necesitan.

Si el servicio web está en desarrollo o cambio constante, a continuación, el JABÓN no es realmente la mejor opción, porque esto significa que con cada cambio que se tiene que regenerar, reconstruir y volver a implementar su servicio a los clientes.Dependiendo de su situación, puede que desee considerar la posibilidad de proporcionar DESCANSO+VARICELA (Plain Old Xml) de los servicios web, en cambio, como su más simple de analizar, ya que no tiene la sobrecarga de JABÓN, puede ser llamado a través de una normal URL y consumida por los entornos que no tienen un SOAPClient de la biblioteca (por ejemplo,directamente en un navegador, el uso de AJAX)

Answer 4

Una respuesta posible sería el uso de grupos de sustitución para permitir que los modelos abstractos en el XSD de importar. La posibilidad de procesar un grupo Dicha sustitución aún no se ha validado con los marcos que está utilizando para invocar esos servicios.