Versiones de flujo de trabajo WF4 donde el contrato de service cambia

Acabo de implementar con éxito un sistema WF4 de "control de versiones" utilizando el service de routing de WCF. Tenía un service de flujo de trabajo de versión 1 al que agregué una nueva actividad de Decisión y lo guardé como un service de versión2. Así que ahora tengo 2 puntos finales (con contratos de service idénticos, es decir, todas las actividades de recepción son las mismas para ambos services) y un enrutador que verifica el contenido de un post (una cadena "versionId" en el object que todas mis recepciones aceptan como argumento) para decidir qué punto final golpear.

Mi pregunta es, si bien funciona bien cuando no se realizan cambios en el contrato de service, ¿cómo puedo manejar la necesidad de agregar o quitar methods de mi contrato de service y crear un service de versión3? Mi idea original era que, cuando agrego la reference de service a mi cliente, utilizo el último punto final del service de flujo de trabajo para get el contrato de service más reciente. Luego, en el file de configuration, cambio el punto final al que me conecto al punto final del enrutador. Pero esto no funcionará si v1 y v2 tienen un contrato diferente que v3. Mi proxy tendrá los methods de v3 y olvidará todo sobre v1 y v2.

¿Alguna idea de cómo manejar esto? ¿Debo crear una interfaz de contrato de service real en mi solución de flujo de trabajo (en lugar de solo proporcionar un nombre de service en mis actividades de recepción)?

Si el contrato de WCF cambia, su cliente deberá conocer las operaciones adicionales y cuándo llamarlas. He utilizado los marcadores activos, contiene la operación WCF, desde el almacén de persistencia en algunas aplicaciones para que la aplicación cliente se adapte dinámicamente al flujo de trabajo al verificar los marcadores activados y habilitar / deshabilitar los controles de la interfaz de usuario en function de eso. El cliente aún tendrá que actualizarse cuando se agreguen nuevas operaciones a una nueva versión del flujo de trabajo.

Aunque WCF era joven, escuché algunas voces que sostenían que el control de versiones de los endpoints (para los web services) debería lograrse utilizando una estructura de carpetas. Nunca llegué al punto de probarlo, pero analizar las consecuencias de esa estrategia me parece una solución espléndida. No tengo experiencia en producción de WCF, pero estoy a punto de lanzar una solución bastante completa usando la versión 4.0 de .NET (ASP.NET, WCF, WF …) y en esta etapa argumentaría que usar una estructura de carpetas para versiones separadas de puntos finales sería una buena solución.

La esencia de tal estrategia sería nunca cambiar o eliminar el contrato de un punto final (una versión específica) hasta que esté 100% seguro de que ya no se usa. Mientras sus services evolucionan, simplemente agregará nuevos contratos y puntos finales. Esto podría conducir a la duplicación del código si uno no es un desarrollador tan estructurado como debería ser. Pero al presentar una fachada de service, la duplicación sería insignificante

He pasado por la misma situación. Puede mantener la versión con la ayuda de la implementación personalizada. guarde la URL del service de flujo de trabajo en la database. E invocarlos según el deseo.

Puede get la información sobre cómo llamar al Servicio WF con la URL del cliente.

http://rajeevkumarsrivastava.blogspot.in/2014/08/consume-workflow-service-45-from-client.html

Espero que esto ayude