¿Cuáles son sus experiencias con Windows Workflow Foundation?

Question

Estoy evaluando WF para su uso en la línea de aplicaciones de negocios en la web, y me gustaría escuchar algunas de las últimas cuentas de esta tecnología.

Mi principal interés aquí es mejorar la mantenibilidad de los proyectos y tal vez aumentar la productividad de los desarrolladores al trabajar en procesos complejos que cambian con frecuencia.

Me gusta mucho la idea de WF, sin embargo, parece ser relativamente desconocida y muchos de los comentarios anteriores que he mencionado mencionan que es abrumadoramente compleja una vez que se mete en ella.

Si está sobredimensionado hasta el punto de que es inutilizable (o una mala compensación) para un proyecto pequeño a mediano, eso es algo que necesito saber.

Por supuesto, ha estado fuera desde finales de 2006, por lo que tal vez haya madurado. Si ese es el caso, esa es otra información que sería muy útil.

¡Gracias de antemano!

Answer 1

Windows Workflow Foundation es un producto muy capaz, pero todavía muy en su primera versión :-(

Las principales razones para el uso incluyen:

1. los requerimientos del negocio de modelado visual
2. La separación de su. lógica de negocio de las reglas de negocio y reglas de externalización como archivos XML.
3. Separación del flujo de negocios de su aplicación mediante la externalización de sus flujos de trabajo como archivos XML
4. Creación de procesos de larga ejecución con la capacidad automática de reaccionar si no ha sucedido nada durante un período de tiempo prolongado. Por ejemplo, una factura no pagada.
5. Persistencia automática de flujos de trabajo de larga ejecución para mantener el uso de recursos fuera de servicio y permitir que un proceso y/o máquina se reinicien.
6. Seguimiento automático de flujos de trabajo que ayudan con los requisitos del negocio.

WF viene como una biblioteca/marco por lo que la mayoría de las veces necesita escribir el host que ejemplifica el tiempo de ejecución de WF.Dicho esto, usar WCF hospedado en IIS es una solución viable y ahorra mucho trabajo. Sin embargo, el acoplamiento WCF/WF es menos que perfecto y necesita un trabajo serio. Vea aquí http://msmvps.com/blogs/theproblemsolver/archive/2008/08/06/using-a-transactionscopeactivity-with-a-wcf-receiveactivity.aspx para más detalles. Espere bastantes cambios/mejoras en la próxima versión.

WF (y WCF) son bastante centrales para muchas cosas nuevas que salen de Microsoft. Puede esperar algunos anuncios interesantes durante el PDC.

BTW mantener varias versiones de un flujo de trabajo en ejecución requiere un poco de trabajo, pero que es principalmente .NET estándar. Acabo de hacer una serie de entradas de blog sobre el tema a partir aquí: http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx

Acerca de los requisitos de negocio visual de modelado. En teoría, esto funciona bastante bien con una separación de intención e implementación. Sin embargo, en la práctica, dejará caer bastantes actividades adicionales en un flujo de trabajo puramente por razones técnicas, y eso de alguna manera frustra el propósito, ya que tiene que decirle a un analista de negocios que ignore la mitad de las formas y líneas.

Answer 2

Realmente depende de lo que quieras hacer con él. Solo lo he usado un poco, pero en comparación con productos más maduros como MetaStorm (sé técnicamente que es un BPM, pero todavía hay un componente de flujo de trabajo), Process Choriographer e IBM MQ workflow, no hay comparación. Simplemente no es lo suficientemente maduro. Por otro lado, es gratis donde los otros no lo son y probablemente pueda hacer el trabajo. No sé si colocaría una operación de varios millones de dólares, pero con los más pequeños, le daría otra oportunidad. El verdadero obstáculo que enfrentará es el cambio en el proceso de pensamiento que requiere. Si no tiene desarrolladores que hayan trabajado anteriormente con sistemas estatales, eso puede ser un verdadero obstáculo.

Answer 3

Hemos utilizado WF en una gran aplicación de SharePoint y puedo decir que está bien. Tiene mucho poder y flexibilidad. y, como Kevin menciona, una vez que asimilas los conceptos subyacentes de los flujos de trabajo, puedes hacer prácticamente todo lo que quieras con él.

Por otro lado, tiene algunos problemas realmente serios, como la falta de control de versiones, que realmente puede dañar su aplicación en el futuro. Nos hemos visto obligados a implementar hasta 3 versiones paralelas del mismo flujo de trabajo denominadas xxx-v1, xxx-v2 y xxx-v3 para mantener instaladas las instancias anteriores y que las nuevas instancias usen las versiones actualizadas. Un verdadero dolor en el culo. Ah, y también hay algunos conceptos realmente no intuitivos (tokens de correlación, wtf ??)

Answer 4

Considero a MS WF como una biblioteca de flujo de trabajo de bajo nivel en lugar de un producto de flujo de trabajo de empresa completamente desarrollado como K2. Le permitirá construir una aplicación habilitada para el flujo de trabajo, pero no es en sí misma una aplicación de flujo de trabajo. Mi experiencia en esta capacidad ha sido positiva, aunque hemos tenido que construir una gran cantidad de nuestra propia infraestructura a su alrededor (un pub/sub framework, un administrador de vida worlkflow, etc.). Gran parte de la documentación disponible es bastante simplista y no cubre la creación de una aplicación de flujo de trabajo empresarial basada en MS WF.

Answer 5

Brian, no puedo responder a su comentario, pero de todos modos, al hacer versiones me refiero a hacer cambios en el código subyacente del flujo de trabajo sin interrumpir las instancias en ejecución, y aplicar graciosamente actualizaciones a los flujos de trabajo existentes. No estoy seguro acerca de 'stock' WF, pero al menos en el entorno de SharePoint no existe el concepto de versiones de flujo de trabajo, por lo que las nuevas versiones tienen que implementarse como flujos de trabajo completamente diferentes, lo que se convierte en una pesadilla de mantenimiento. Esto no tiene nada que ver con la "rehidratación", la rehidratación es el proceso mediante el cual se restablece la actividad de un flujo de trabajo "latente" después de algún evento o cambio de estado. Eso se maneja de forma transparente por el tiempo de ejecución del flujo de trabajo.

Answer 6

WF está integrado en SharePoint (WSS 3.0), y he creado bastantes flujos de trabajo para varios sitios web de SharePoint, por lo que puedo contar mi experiencia de WF en SharePoint. Comparado con otros marcos de flujo de trabajo, WF puntúa bien. Es estable (no he experimentado ningún error misterioso), los flujos de trabajo son bastante fáciles de diseñar (gracias al diseñador de flujo de trabajo en Visual Studio) y puede utilizar flujos de trabajo secuenciales y también de máquina de estados.

No es perfecto, por supuesto, y un desarrollador definitivamente necesitará algún tiempo para entender el concepto (de, por ejemplo, el Modelo de actividad); pero definitivamente es utilizable, incluso para "pequeñas tareas".

Answer 7

pregunta relacionada: When to use Windows Workflow Foundation? Mi respuesta allí:

Es posible que necesite WF sólo si cualquiera de los siguiente es cierto:

1. Usted tiene un proceso de larga duración.
2. Tiene un proceso que cambia con frecuencia.
3. Desea un modelo visual del proceso.

Para obtener más información, consulte la publicación de Paul Andrew : What to use Windows Workflow Foundation for?

No confunda ni relacione WF con programación visual de ningún tipo. Está mal y puede llevar a muy malas decisiones de diseño/arquitectura .

Por lo tanto, si tiene tales requisitos, entonces WF es un buen candidato. Por supuesto, es relativamente complejo, pero mencione que los problemas que intenta resolver también son complejos (y, a veces, muy complejos). En mi humilde opinión, es muy complejo, por ejemplo, para deshidratar/rehidratar objetos que tienen controladores de eventos adjuntos (con eventos que se pueden desencadenar cuando el objeto no está en la memoria).

No puedo juzgar lo que quiere decir con "proyecto pequeño a mediano", pero en general diría que si su proyecto tiene al menos dos requisitos de la lista anterior, entonces puede considerar a WF como una solución.

Answer 8

nunca trató WFF, pero recuerdo haber leído this article about WFF by Leon Bambrick donde básicamente dice que todo el género de herramientas de desarrollo de software es un disparate. Podría ayudarte a decidir de una manera u otra.

Answer 9

Teníamos un proyecto en el trabajo que me involucraba en el uso de Workflows. La idea (de la administración) era que los programadores estadounidenses escribiéramos las actividades de flujo de trabajo junto con el "motor" y el marco. Luego, los no programadores se encargarían de todo lo demás compilando sus propios flujos de trabajo en dlls que el motor cargaría automáticamente.

Gestión fue vendido en esta idea de no programadores que usan flujo de trabajo para ayudar a desarrollar el software, y era casi una completa pérdida de tiempo. El problema que estábamos tratando de resolver con este proyecto era relativamente complejo y sabíamos desde el principio que el software tendría que modificarse casi constantemente (sus cálculos dependían de otras empresas y gobiernos).

El resultado final fue que no pudimos hacer que los módulos de Workflow fueran lo suficientemente genéricos como para que los demás los usen. Entonces los programadores fueron los que se vieron obligados a trabajar con Workflows, y todo lo que Workflows hizo fue ponerse en nuestro camino.

Answer 10

año pasado completó una aplicación que trabaja con WF, ahora se utiliza como columna vertebral de un sistema increíblemente grande que es utilizada por un gran banco para su proceso de hipoteca. El proceso de PE tiene muchos pasos, desde la solicitud del cliente hasta la aprobación del crédito.

Aunque fue un éxito, hubo tantos problemas y crisis a lo largo del camino. Y no valdrá la pena para cualquier proyecto de menor tamaño.

Answer 11

He estado usando Workflow 4.0 para los últimos meses y aunque en su mayoría impresionado, he encontrado que es muy difícil de aprender.

Para la versión más reciente (que viene con .NET 4.0 RC), existe la siguiente documentación en la web, en cualquier libro o no hay cursos de capacitación disponibles. Solo he encontrado artículos relacionados con la ahora difunta versión 3.0. Incluso la documentación de MSDN es liviana en el suelo.

El diseñador de flujo de trabajo no es tan intuitivo como debería ser de ninguna manera, por lo que aprender es muy difícil. He tenido que confiar en las respuestas de una sola persona en StackOverflow (¡gracias por cierto, Maurice!), Y me dejaron sin su ayuda.

Así que en resumen, creo que tiene potencial, pero que sería muy loco para aprender todavía - esperar a más formación, documentación y libros de lo contrario se le va en ella ciego!

Answer 12

Difícil de aprender. Muy flexible. No debe confundirse con una herramienta visual para usuarios finales, solo para programadores. No estoy seguro de si me gusta el enfoque de propiedad dependiente.