2010-09-15 12 views

Respuesta

4

NServiceBus soporta flujos de trabajo a través de "sagas", http://nservicebus.com/Sagas.aspx

La diferencia clave es que Sagas es más fácil de probar la unidad y que usted no tiene que preocuparse acerca de la consistencia ya que el uso subyacente de NSB de colas y DTC se asegura los pasos fallidos se vuelven a intentar automáticamente

Udi tiene un podcast discutir todo esto:

http://www.udidahan.com/2007/10/23/podcast-durable-services-with-wcf-wf-and-nservicebus/

En pocas palabras: si utiliza NSB no habría necesidad de la OMI para MS WF.

+0

Esto no es correcto. Los flujos de trabajo son mucho más que sagas. Incluso el propio Udi dice que: http://www.udidahan.com/2007/12/17/no-more-workflow-for-nservicebus-please- welcome-the-saga. Además, ¿dónde están todas las implementaciones de patrones comunes? http://www.workflowpatterns.com/patterns/resource/ – Den

10

me gustaría dar mis 2 centavos:

estoy trabajando en el nuevo proyecto con un dominio bastante complejo, donde algunos flujos de trabajo de dominio pueden evolucionar y cambiar en algunos escenarios diferentes. Hemos estado analizando las posibles soluciones para organizar los diferentes Servidores de aplicaciones (servicios WCF). La primera solución arquitectónica que analizamos fue utilizando un patrón Service Bus + PubSubs (nservicebus, rhino ESB, masstransit, Shuttle ESB ...). La otra solución que analizamos fue WF 4.0. Estamos cerca de tomar la decisión y por ahora WF 4.0 es el elegido uno porque:

  • flujos de trabajo se modelan mediante workflow diagrams
  • flujo de trabajo diagram designer can be embedded en una aplicación personalizada, que puede ser utilizado para desarrollar flujos de trabajo durante la producción, ya que son definido en XAML.
  • PubSubs patrón con sagas, de alguna manera diluiría cómo se modela el flujo de trabajo y en algunos escenarios complejos que sería difícil tener una visión clara de cómo funciona el flujo de trabajo
  • WF 4.0 Servicios de flujo de trabajo es on top of WCF, para que pueda tener Enviar/Recibir actividades que hablan con puntos finales de WCF. Por lo tanto, tenemos toda la potencia y flexibilidad de WCF: seguridad, comunicaciones fiables, MSMQ, WS * normas, ...
  • WF 4.0 servicios se pueden alojar en Appfabric: escalabilidad, facilidad de mantenimiento, supervisión y solución de problemas fáciles

Hay una estafa que ya estamos analizando, que es el hecho de que WF 4.0 no admite máquinas de estado (como en la versión 3.5). Aunque MSFT explains how to implement state machines utilizando las nuevas actividades Fowchart enviados con 4,0

Espero que esto ayude,

Juanjo

+0

[WF4 State Machine] (http://blogs.msdn.com/b/endpoint/archive/2011/04/20/wf4-state-machine-user) -experience.aspx) está disponible ahora. – TrueWill

8

puedo estar de acuerdo con @Andreas Öhlund. Esto es como decir "Tengo C# y .NET Framework, entonces, ¿por qué necesito comprar un sistema ERP?" La respuesta de @juanjo.arana es mucho más equilibrada.

El NServiceBus documentation for Sagas es una página (5 pantallas en mi monitor). El libro Pro WF tiene 850 páginas. (Lo he leído, no es de relleno.) El libro Professional K2 blackpearl (que habla de un sistema completo de BPM) tiene 870 páginas (el recuento de Amazon está desactivado).

Incluso WF 4 (excepto SharePoint) no es un sistema BPM con todas las funciones. Falta un modelo de seguridad de nivel de actividad, bloqueo ("Bob ha reclamado esta orden de trabajo, pero aún no la ha completado"), versiones avanzadas y generación de informes. Puedes construir todas estas cosas, pero no están en la "caja".

Mire la sección Tiempos de espera de la página NServiceBus Sagas. Compare eso con el método visual de hacer un expiration in WF 4. Imagine hacer un seguimiento de esto en un flujo de trabajo complejo, donde se requieren tiempos de espera (escalados) cada vez que un administrador desea que se le notifique que un empleado está tardando demasiado tiempo en un sistema de procesamiento de documentos.

Acepto que los flujos de trabajo a veces son exagerados y que pueden ser difíciles de probar. (Hay ways to unit test WF 4). Pero no me gustaría construir un flujo de trabajo estilo BPM en el mundo real con NServiceBus.

Cuestiones relacionadas