¿Cuál es la mejor manera de Versión un servicio web ASP.NET 2.0?

Question

Estoy manteniendo un servicio web SOAP (ASP.NET versión 2.0) y tengo que hacer algunos cambios que modificarán los valores de devolución de métodos particulares.

¿Cuál es el método generalmente aceptado para hacer esto sin romper las implementaciones existentes?

Mi idea inicial es que todo lo siguiente sería posible.

a) Proporcione métodos específicos de la nueva versión dentro del servicio web existente, p. getPerson_v1.4
b) Proporcione una copia completa del archivo .asmx con un nuevo número de versión, p. http: /www.example.com/AdminWS_V1_4.asmx. Esta no es una idea que disfruto ya que el servicio tiene más de 50 métodos y copiar ese código para cambios a 2/3 métodos parece demasiado código duplicado.
c) Anule el constructor del servicio web para permitir el paso de un número de versión. Esto no parece funcionar, y en la reflexión no estoy seguro de cómo se representaría en un WSDL

¿Existe una forma generalmente aceptada de hacer esto, o las personas tienen consejos basados ​​en sus experiencias en esta área.

Answer 1

En el caso general, hay más para versionar un servicio web que simplemente nombres de métodos de versiones y nombres de archivos .asmx. Idealmente, la interfaz de un servicio web (su WSDL) debe ser un contrato permanente y nunca debe cambiar. Una de las implicaciones sería que los clientes que no necesitan la funcionalidad modificada nunca tendrían que cambiar y, por lo tanto, nunca necesitarían volver a someterse a prueba.

En lugar de romper el contrato existente, debe crear un nuevo contrato que contenga las operaciones modificadas. Ese contrato podría "heredar" del contrato existente, es decir, podría "agregar los métodos al final". Sin embargo, tenga en cuenta que también debe colocar el nuevo contrato en un nuevo espacio de nombres XML: el espacio de nombres básicamente identifica el WSDL y el espacio de nombres, pero cambiar el WSDL sería mentira.

Debería implementar este nuevo contrato en un nuevo punto final (archivo .asmx). Si esto no está en un directorio diferente, o incluso en un sitio web diferente, realmente no importa. Lo que importa es que los clientes que deseen la nueva funcionalidad pueden consultar el nuevo WSDL en la nueva URL y llamar al nuevo servicio en su nueva URL, y estar contentos.

Tenga en cuenta que un efecto de cambiar un contrato existente es que la próxima vez que se realice una "Actualización de referencia web", será cambiando el código de las clases proxy de cliente. En la mayoría de las tiendas, cambiar el código requiere volver a probar y volver a implementarlo. Por lo tanto, debería pensar en "solo agregar métodos" como "solo agregar algún código de cliente que deba probarse e implementarse", incluso si el código de cliente existente no utiliza los nuevos métodos.

Answer 2

desplegamos a los directorios de versión, por ejemplo:

http://www.example.com/soap/v1/ http://www.example.com/soap/v2/ http://www.example.com/soap/v3/

etc.

Answer 3

A menos que cambie la mayor parte de las firmas de los métodos con cada nueva versión, me gustaría ir con (a) - nombres de métodos versionados. Así es como lo hacen nuestros proveedores y funciona bien para nosotros.

Answer 4

Acabo de pensar en otra posible solución que parece bastante limpia.

Pude consultar el número de versión incluido como encabezado SOAP y asumir el número de versión existente si no se proporciona.

Puedo hacer que el código se comporte de manera diferente para diferentes versiones sin cambiar las firmas de método. Esto es posible ya que los valores de retorno de los servicios web son objetos XML, por lo que la firma del método permanece igual pero el contenido del XML cambia en función de la versión.

Answer 5

Tengo el mismo problema de control de versiones con los servicios web que estoy desarrollando. Hacemos que nuestros usuarios pasen un número de versión de esquema en el encabezado. Nos dicen qué versión del esquema XML quieren volver. De esta manera, siempre somos compatibles con versiones anteriores y el código no está duplicado.

En mi trabajo, no podemos decirle al cliente que tienen que cambiar la URL al servicio web cuando lo versionamos. En las grandes corporaciones, cambios tan pequeños como una URL pueden llevar meses de pruebas. Tengo la sensación de que no debes romper la conexión de tus clientes. Lo que hacemos es agregar nuevas funciones a la última versión. Cuando el cliente solicita las nuevas funciones, si las quiere, se ven forzadas a actualizar al esquema más nuevo.