asp.net - sirve - windows workflow foundation tutorial

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

Estoy evaluando WF para su uso en la línea de aplicaciones de negocios en la web, y me encantaría escuchar algunas de las cuentas de primera mano 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 cuando se trabaja en procesos complejos que cambian con frecuencia.

Realmente me gusta la idea de WF, sin embargo, parece ser relativamente desconocida y muchos de los comentarios anteriores que he mencionado mencionan que es abrumadoramente complejo una vez que te involucras.

Si está sobredimensionado hasta el punto de que es inutilizable (o una mala compensación) para un proyecto de tamaño 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 por adelantado!

Brian, no puedo responder a tu comentario, pero de todos modos, al versionar 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.

Considero que MS WF es 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.

Hemos usado 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 allí (tokens de correlación, wtf ??)

Nunca probé WFF, pero recuerdo leer este artículo sobre WFF por Leon Bambrick, donde básicamente dice que todo el género de herramientas de desarrollo de software es una tontería. Podría ayudarte a decidir de una manera u otra.

Realmente depende de lo que quieras hacer con eso. 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.

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á tiempo para entender el concepto (es decir, el Modelo de actividad); pero definitivamente es utilizable, incluso para "pequeñas tareas".

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

Las principales razones para el uso incluyen:

Modelar visualmente los requerimientos del negocio.
Separar la lógica de su negocio de las reglas comerciales y las reglas de externalización como archivos XML.
Separar el flujo de su negocio de su aplicación mediante la externalización de sus flujos de trabajo como archivos XML.
Creación de procesos de larga ejecución con la capacidad automática de reaccionar si nada ha sucedido durante un período prolongado de tiempo. Por ejemplo, una factura no pagada.
Persistencia automática de flujos de trabajo de larga ejecución para mantener bajo el uso de recursos y permitir que un proceso y / o máquina se reinicien.
Seguimiento automático de flujos de trabajo que ayudan con los requisitos del negocio.

WF se presenta 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. Consulte aquí http://msmvps.com/blogs/theproblemsolver/archive/2008/08/06/using-a-transactionscopeactivity-with-a-wcf-receiveactivity.aspx para obtener más información. 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.

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

Acerca del modelado visual de los requisitos comerciales. 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.

Tuvimos un proyecto en el trabajo que me involucró en el uso de Workflows. La idea (de la administración) era que los programadores estadounidenses escribiríamos 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.

La administración se vendió con esta idea de que los no programadores usaran Workflow para ayudar a desarrollar software, y fue 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 compañías 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.

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.

He estado usando Workflow 4.0 durante los últimos meses y, aunque me ha impresionado en gran medida, me resulta extremadamente 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 del 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 (¡gracias por cierto, Maurice!), Y me dejaron sin su ayuda.

Entonces, en resumen, creo que tiene potencial, pero estarías bastante enojado por aprenderlo aún. Espera más capacitación, documentación y libros; de lo contrario, estarás a ciegas.

El año pasado completamos una aplicación que funciona con WF, que ahora se utiliza como la columna vertebral de un sistema increíblemente grande que es utilizado por un banco muy grande 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.

Pregunta relacionada: ¿ Cuándo usar Windows Workflow Foundation? Mi respuesta allí:

Es posible que necesite WF solo si cualquiera de los siguientes es verdadero:
Tienes un proceso de larga duración.
Tienes un proceso que cambia con frecuencia.
Quieres un modelo visual del proceso.
Para obtener más detalles, consulte la publicación de Paul Andrew: ¿Para qué sirve Windows Workflow Foundation ?
No confunda ni relacione WF con programación visual de ningún tipo. Está mal y puede llevar a decisiones de arquitectura / diseño muy malas.

Entonces, 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.