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

webservice asp net mvc

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 retorno de métodos particulares.

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

Mis pensamientos iniciales son que todo lo siguiente sería posible.

a) Proporcione métodos específicos de nueva versión dentro del servicio web existente, por ejemplo, getPerson_v1.4
b) Proporcione una copia completa del archivo .asmx con un nuevo número de versión, por ejemplo, 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) Anular 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 eso dentro de un WSDL

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

Answer 1

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

Answer 2

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

Podría verificar si hay un número de versión incluido como encabezado SOAP y asumir el número de versión existente si no se proporciona.

Luego 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 3

En el caso general, hay más para versionar un servicio web que solo 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.

Luego debe 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", estará cambiando el código de las clases de proxy del 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 4

Implementamos en directorios de versiones, por ejemplo:

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

etc.

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.