Windows Workflow Foundation WF4 - Hosting de flujo de trabajo

Question

Para un cliente, el sistema que creamos debe admitir lo siguiente:
- Debe ser posible ejecutar varios flujos de trabajo y varias instancias de los mismos flujos de trabajo con un contexto diferente (datos diferentes /objetos de negocio).
- Algunos flujos de trabajo serán de larga ejecución, implicarán múltiples usuarios/sesión de cliente y esperarán la entrada de un usuario externo. Por lo tanto, los flujos de trabajo deben poder persistir y responder a alguna señal de una aplicación cliente. Y también significa que la ejecución de flujos de trabajo debe realizarse en una aplicación de servidor (¿verdad?).
- Quiero poder ejecutar todo tipo de flujos de trabajo en la aplicación de servidor, y no quiero tener que volver a implementar la aplicación de servidor cuando cambia un flujo de trabajo.

Lo primero que pensé fue en Servicios de flujo de trabajo. Después de una gran cantidad de investigaciones, llegué a la conclusión de que este no es el camino correcto, ya que Workflow Services básicamente ofrece la posibilidad de ejecutar actividades en una ubicación remota desde un flujo de trabajo iniciado en una aplicación cliente. ¿Es esto correcto? ¿O puedo usar los servicios de flujo de trabajo para el escenario anterior? La mayoría de los ejemplos y/o tutoriales son básicamente una combinación ReceiveSignal/Send con alguna lógica intermedia.

Básicamente quiero iniciar (desde una aplicación de cliente) el inicio de un flujo de trabajo con un contexto específico (en la aplicación de servidor de flujo de trabajo).

¿Cuál es el mejor enfoque?

¡Toda ayuda es muy apreciada!

Answer 1

En cuanto a sus necesidades:

Debe ser posible ejecutar múltiples flujos de trabajo y múltiples instancias de los mismos flujos de trabajo con un contexto diferente (diferentes objetos de datos/negocio).

Esto no es un problema con WF.

Algunos flujos de trabajo será de larga ejecución, implican múltiples usuarios/sesión de cliente y en espera de la entrada del usuario externo. Por lo tanto, los flujos de trabajo deben poder ser persistentes y responder a alguna señal desde una aplicación cliente. Y también significa que la ejecución de los flujos de trabajo debe hacerse en una aplicación de servidor (¿no?) .

WF está diseñado para tareas de larga duración que pueden interactuar con influencias externas. Sin embargo, eso no dice que sea fácil de lograr; no hay una solución universal en la que puedas conectar. Probablemente tendrá que diseñar actividades personalizadas que interactúen con Workflow Extensions que manejan la entrada de usuario en movimiento en el flujo de trabajo. Lo mismo ocurre con exponer el flujo de trabajo al exterior, aunque WF4 sí viene con una serie de actividades de WCF que podrían usarse para lograr esto.

Quiero ser capaz de ejecutar todo tipo de flujos de trabajo en la aplicación del servidor, y lo hago no quieren tener que volver a implementar la aplicación servidor cuando un flujo de trabajo cambios.

Esto es más difícil de lograr. Debe, como mínimo, separar los flujos de trabajo del código del servidor. La ruta más simple es almacenar su flujo de trabajo como xaml y load it at runtime desde, por ejemplo, una base de datos.

Otras opciones son utilizar algún tipo de marco de inyección de dependencia (como Structure Map o Unity) que carga el ensamblaje de flujo de trabajo en tiempo de ejecución. Si los flujos de trabajo cambian, puede soltar el nuevo ensamblaje en el servidor, cambiar su configuración y reiniciar. Alternativamente, puede aislar los ensamblados de su flujo de trabajo dentro de su propio Dominio de aplicación, cargarlos en tiempo de ejecución y descartar el dominio cuando deba volver a cargar una nueva versión. Cuál de ellos depende de sus requisitos; De hecho, estoy haciendo la tercera opción ya que tengo que cargar muchas versiones diferentes de ensamblados de flujo de trabajo en tiempo de ejecución, ejecutarlos al mismo tiempo y, a menudo, tienen recursos incorporados, lo que me impide seguir la ruta XAML.

Mi primer pensamiento fue Workflow Servicios. Después de una gran cantidad de investigación I concluyó que esta no es la ruta correcta ya que Workflow Services básicamente ofrece la posibilidad de ejecutar actividades en una ubicación remota desde un flujo de trabajo iniciado en una aplicación cliente. ¿Es esto correcto?

Estoy alojando mis flujos de trabajo dentro de una aplicación de servicio estándar de Windows. Tengo que administrar y mantener la interfaz de WCF que usa el cliente para interactuar con mis flujos de trabajo. Por lo que puedo decir, los servicios de flujo de trabajo parecen una opción viable para flujos de trabajo estables, si lo entiendo correctamente. Hospedar una aplicación en AppFabric también es una buena opción, y creo que es más simple que usar un servicio de Windows. Pero no importa cuál sea el host, tiene dos opciones: sus flujos de trabajo definen su contrato de servicio o debe definir el contrato de servicio y manejar toda la ejecución y comunicación con los flujos de trabajo que está administrando.

La primera es una buena opción para flujos de trabajo estables con una fachada simple. No parece una buena opción para usted, ya que debe cargar flujos de trabajo dinámicamente a medida que cambian; eso requiere lógica fuera del flujo de trabajo para manejar no solo las comunicaciones del cliente ("¡aquí hay una nueva versión del flujo de trabajo X!") sino también gestionar la vida útil del flujo de trabajo.

Parece que tendrá que encontrar algún tipo de aplicación de host (aplicación IIS WebService, servicio de Windows, AppFabric, Azure), definir su servicio WCF y ponerlo en línea, manejar las llamadas de los clientes, comunicar estas llamadas a su flujo de trabajo código de ejecución, que luego debe cargar y ejecutar estas llamadas y devolver el resultado a la cadena.

No puedo dejar de notar que pareces un poco mal preparado para el viaje que te espera. Recomiendo encarecidamente crear un prototipo que recoja ordenadamente la parte más central de sus requisitos. Una aplicación alojada (sugiero AppFabric) con un frontend WCF que carga un flujo de trabajo basado en XAML que procesa las llamadas de los clientes. Una vez que tenga la versión simple clave, puede ampliar el alcance para abarcar todos sus requisitos.