Pregunta

Estoy evaluando el uso de WF en aplicaciones de línea de negocios en la web y me encantaría escuchar algunos relatos recientes de primera mano sobre 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 trabajan en procesos complejos que cambian con frecuencia.

Realmente me gusta la idea de WF, sin embargo, parece ser relativamente desconocida y muchos comentarios antiguos con los que me he topado mencionan que es abrumadoramente complejo una vez que te adentras en él.

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

Por supuesto, ha estado disponible desde finales de 2006, por lo que quizás haya madurado.Si ese es el caso, ¡ese es otro dato que sería muy útil!

¡Gracias de antemano!

¿Fue útil?

Solución

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

Las principales razones de uso incluyen:

  1. Modelar visualmente los requisitos comerciales.
  2. Separar su lógica de negocios de las reglas de negocios y externalizar las reglas como archivos XML.
  3. Separar su flujo de negocios de su aplicación externalizando sus flujos de trabajo como archivos XML.
  4. Crear procesos de larga duración con la capacidad automática de reaccionar si no ha sucedido nada durante un período prolongado de tiempo.Por ejemplo, una factura que no se paga.
  5. 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 reinicie.
  6. Seguimiento automático de flujos de trabajo que ayudan con los requisitos comerciales.

WF viene como una biblioteca/marco, por lo que la mayoría de las veces es necesario escribir el host que crea una instancia del tiempo de ejecución de WF.Dicho esto, usar WCF alojado en IIS es una solución viable y ahorra mucho trabajo.Sin embargo, el acoplamiento WCF/WF no es perfecto y necesita un trabajo serio.Mira 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 de las novedades que surgen de Microsoft.Puede esperar algunos anuncios interesantes durante el PDC.

Por cierto, mantener en ejecución varias versiones de un flujo de trabajo requiere un poco de trabajo, pero eso es principalmente .NET estándar.Acabo de hacer una serie de publicaciones de 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 entre intención e implementación.Sin embargo, en la práctica, eliminará bastantes actividades adicionales en un flujo de trabajo simplemente por razones técnicas y eso frustra el propósito, ya que debe decirle a un analista de negocios que ignore la mitad de las formas y líneas.

Otros consejos

Pregunta relacionada: ¿Cuándo utilizar Windows Workflow Foundation? Mi respuesta ahí:

Es posible que necesite WF solo si alguno de los siguientes es verdadero:

  1. Tienes un proceso de larga duración.
  2. Tienes un proceso que cambia con frecuencia.
  3. Quieres un modelo visual del proceso.

Para más detalles, vea la publicación de Paul Andrew: Para qué utilizar Windows Workflow Foundation?

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

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

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

Hemos utilizado WF en una aplicación SharePoint de gran tamaño y puedo decir que está bien.Tiene mucha potencia y flexibilidad.y, como menciona Kevin, una vez que asimiles los conceptos subyacentes de los flujos de trabajo, puedes hacer prácticamente lo que quieras con ellos.

Por otro lado, tiene algunos problemas realmente serios, como la falta de control de versiones, lo que realmente puede dañar tu aplicación en el futuro.Nos hemos visto obligados a implementar hasta 3 versiones paralelas del mismo flujo de trabajo denominado xxx-v1, xxx-v2 y xxx-v3 para mantener las instancias antiguas en ejecución y que las nuevas utilicen las versiones actualizadas.Un verdadero dolor de cabeza.Ah, y también hay algunos conceptos realmente no intuitivos (fichas de correlación, ¿qué carajo?)

Teníamos un proyecto en el trabajo en el que participé utilizando flujos de trabajo.La idea (de la gerencia) era que nosotros, los programadores, escribiéramos las actividades del flujo de trabajo junto con el "motor" y el marco.Luego, los no programadores se encargarían del resto compilando sus propios flujos de trabajo en archivos dll que el motor cargaría automáticamente.

La gerencia estaba convencida de esta idea de que los no programadores usaran Workflow para ayudar a desarrollar software, y fue prácticamente una completa pérdida de tiempo.El problema que intentábamos 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 flujo de trabajo fueran lo suficientemente genéricos para que otros los usaran.Entonces, los programadores fueron los que se vieron obligados a trabajar con los flujos de trabajo, y lo único que hicieron los flujos de trabajo fue interponerse en nuestro camino.

He estado usando Workflow 4.0 durante los últimos meses y, aunque estoy muy impresionado, me ha resultado extremadamente difícil de aprender.

Para la versión más reciente (que viene con .NET 4.0 RC), prácticamente no hay documentación en la web, en ningún libro ni en cursos de capacitación disponibles.Sólo he encontrado artículos relacionados con la ya desaparecida versión 3.0.Incluso la documentación de MSDN es vaga.

El diseñador de flujo de trabajo no es tan intuitivo como debería ser, por lo que aprender es muy difícil.Tuve que confiar en las respuestas de una sola persona en StackOverflow (¡gracias, por cierto, Maurice!), y estaría lleno sin su ayuda.

En resumen, creo que tiene potencial, pero estarías bastante enojado si lo aprendieras todavía; espera más capacitación, documentación y libros, de lo contrario, ¡entrarás a ciegas!

El año pasado completamos una aplicación funcional con WF, que ahora se utiliza como columna vertebral de un sistema increíblemente enorme que utiliza un banco muy grande para su proceso hipotecario.El proceso de PE tiene muchos pasos, desde la solicitud del cliente hasta la aprobación del crédito.

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

Considero a MS WF como una biblioteca de flujo de trabajo de bajo nivel en lugar de un producto de flujo de trabajo empresarial completo como K2.Le permitirá crear una aplicación habilitada para 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 gran parte de nuestra propia infraestructura a su alrededor (un marco de pub/sub, un administrador de por vida del flujo de trabajo, etc.).Gran parte de la documentación que existe es bastante simplista y no cubre la creación de una aplicación de flujo de trabajo empresarial basada en MS WF.

Difícil de aprender.Muy flexible.No confundir con una herramienta visual para usuarios finales, sólo para programadores.No estoy seguro si me gusta el enfoque de propiedad de dependencia.

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é que técnicamente es un BPM, pero todavía hay un componente de flujo de trabajo), Process Choriographer y el flujo de trabajo IBM MQ, no hay comparación.Simplemente no es lo suficientemente maduro.Por otro lado, es gratuito donde los demás no lo son y probablemente pueda hacer el trabajo.No sé si le haría una operación multimillonaria, pero con otras más pequeñas le daría otra oportunidad.El verdadero obstáculo al que se enfrentará es el cambio en el proceso de pensamiento que requiere.Si no tienes desarrolladores que hayan trabajado con sistemas estatales antes, eso puede ser un verdadero obstáculo.

Brian, no puedo responder a tu comentario, pero de todos modos, por versionado me refiero a realizar cambios en el código subyacente del flujo de trabajo sin interrumpir las instancias que ya se están ejecutando y aplicar con elegancia las actualizaciones a los flujos de trabajo existentes.No estoy seguro acerca del WF 'stock', pero al menos en el entorno de SharePoint no existe el concepto de versiones de flujo de trabajo, por lo que las nuevas versiones deben 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 vuelve a activar un flujo de trabajo "inactivo" después de algún evento o cambio de estado.Esto lo maneja de forma transparente el tiempo de ejecución del flujo de trabajo.

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 con WF en SharePoint.En comparación con otros marcos de flujo de trabajo, WF obtiene una buena puntuación.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 flujos de trabajo en Visual Studio) y puede usar no solo flujos de trabajo secuenciales sino también de máquina de estado.

No es perfecto, por supuesto, y un desarrollador definitivamente necesitará algo de tiempo para comprender el concepto (por ejemplo,el Modelo de Actividad);pero definitivamente es utilizable, incluso para "pequeñas tareas".

Nunca probé WFF, pero recuerdo haber leído. este artículo sobre WFF de 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 forma u otra.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top