2012-01-11 15 views
9

TLDR: cómo creo servicios WCF que son compatibles con versiones anteriores - es decir, cuando despliegue una nueva versión del servicio en el servidor, todos los clientes en las versiones anteriores puede seguir utilizando el servicio.Haciendo servicios WCF compatibles con versiones anteriores


Estoy creando un servicio web que permitirá a las aplicaciones cliente recuperar una lista de plugins. Al menos tendré una operación como FindPlugins(string nameOrDescription) que, en el servidor, hará una búsqueda y devolverá una lista de objetos.

Desafortunadamente, no puedo garantizar que todos mis clientes se actualizarán con cada nueva versión de mi servicio; es más, estoy seguro de que muchos de ellos se arrastra a la última versión, y tendrá versiones antiguas - la edad, no puedo estar seguro, pero sé que van a ser viejo :)

Si se crea una nueva operación de servicio, cambiar el esquema o realizar algún tipo de operación de interrupción en el lado del servidor, listo. Necesito diseñar compatibilidad hacia atrás en todo momento.

Aquí hay un ejemplo. Digamos que devuelvo una lista de Plugin s, cada una de las cuales tiene un nombre y una descripción, y despliego v0.1 de mi servicio. Luego, agrego un enlace de descarga e implemento eso como v0.2 de mi servicio.


Algunas opciones que veo son:

  • clientes force para actualizar a la última servicio (no viable)
  • Romper el servicio para los clientes antiguos (no viable)
  • Anexar una número de versión para cada operación y solo consume las operaciones específicas de la versión (por ejemplo, FindPluginsV1, FindPluginsV2) - no parece práctico con múltiples operaciones
  • de un nuevo servicio con cada nueva versión - no parece práctico
+0

¿Se pueden satisfacer sus requisitos agregando más operaciones de servicio? –

+0

@hugh sí, como mencioné, puedo incluir un número de servicio (por ejemplo, v1) en cada operación; o, al tener diferentes servicios (por ejemplo, V1Service, v2Service). Pero no me gusta ese enfoque debido a la duplicación/mantenimiento. – ashes999

Respuesta

0

Si nos fijamos en este artículo http://blogs.msdn.com/b/craigmcmurtry/archive/2006/07/23/676104.aspx

El primer ejemplo el tipo da va a satisfacer sus necesidades. Tiene la ventaja de que los clientes existentes no se romperán, y puede agregar tantas operaciones de servicio nuevas como desee de esta manera.

[ServiceContract] 
public interface IMyServiceContract 
{  
    [OperationContract(IsOneWay=true)]  
    public void MyMethod(MyDataContract input); 
} 

[ServiceContract] 
public interface IMyAugmentedServiceContract: IMyServiceContract 
{  
    [OperationContract(IsOneWay=true)]  
    public void MyNewMethod(MyOtherDataContract input); 
} 

El cambio de la implementación del servicio:

public class MyOriginalServiceType: IAugmentedServiceContract { } 
9

WCF es compatible con versiones anteriores de forma predeterminada.

En el siguiente enlace de MSDN contiene una lista de todos los posibles cambios de un contrato WCF y describe su efecto en los clientes antiguos:

que es más importante, las siguientes operaciones no causa que los clientes antiguos se rompan:

Contratos de servicio (métodos)

  • Añadiendo parámetros de método: El valor predeterminado se usará cuando se llame desde clientes anteriores.
  • Eliminación de parámetros de métodos: los valores enviados por clientes antiguos se ignorarán en silencio.
  • Agregar nuevos métodos: Obviamente, los clientes antiguos no los llamarán, ya que no los conocen.

contratos de datos (clases personalizados para pasar datos)

  • Adición de propiedades no se requiere.
  • Eliminación de propiedades no requeridas.

Por lo tanto, a menos que marque el nuevo campo DownloadLink como IsRequired (por defecto es falsa ), el cambio debe estar bien.

Cuestiones relacionadas