cqrs - trilogia - ¿Cuál es la diferencia entre una saga, un administrador de procesos y un enfoque basado en documentos?
trilogia duologia (4)
Lo que entiendo es que los tres conceptos están relacionados con las transacciones de larga duración.
Un administrador de procesos es, a mi entender, una máquina de estados finitos que simplemente reacciona a los eventos y emite comandos. No contiene ninguna lógica comercial, solo tiene enrutamiento. Su objetivo es llevarte a un estado final, donde sabes que tu transacción ha tenido éxito o ha fallado.
Hasta aquí todo bien.
Pero ahora comienzan mis problemas en comprender:
- ¿Qué es una saga en contraste con un administrador de procesos?
- También está el enfoque basado en documentos, como se menciona en las sagas de CQRS: ¿los entendía bien? ... como yo lo entiendo, un documento es solo una "hoja de papel" donde toma notas y se lo entrega. ¿Cómo encaja eso en el concepto de comandos y eventos?
¿Puede alguien explicar las diferencias y en qué me interesaría especialmente? ¿Cuál de estos conceptos es bueno para qué, y cuándo es necesario? ¿Son mutuamente excluyentes? ¿Puedes seguir todo el camino con solo uno de ellos? ¿Hay escenarios en los que necesita más de uno? ...?
¿Qué es una saga en contraste con un administrador de procesos?
La intención de estos patrones es diferente. Un administrador de procesos es un patrón de flujo de trabajo que, como usted dice, puede construirse encima de una máquina de estados. Un administrador de procesos retendrá el estado entre los mensajes y contendrá la lógica para determinar qué acción se debe tomar en respuesta a un mensaje (por ejemplo, estado de transición o envío de otro mensaje). Algunos marcos incorrectos se refieren a estos como sagas.
Por el contrario, una saga (de acuerdo con las definiciones originales) es un patrón destinado a ayudar a gestionar las fallas. Implica múltiples flujos de trabajo a través de los sistemas, donde cada uno permitirá que se tome alguna forma de acción de compensación en una transacción posterior en el caso de una falla en otro lugar.
Esta compensación es la característica definitoria de una saga. Tenga en cuenta que la saga en sí no sabe cuál podría ser la acción compensatoria. Las sagas a menudo se implementan usando el patrón de enrutamiento de enrutamiento.
¿Son mutuamente excluyentes? ¿Puedes seguir todo el camino con solo uno de ellos?
No son mutuamente excluyentes: es probable que, por ejemplo, un sistema que participe en una saga pueda usar un administrador de procesos para manejar su parte del procesamiento.
Otros recursos
Algunas de estas publicaciones pueden ayudar a proporcionar más detalles y brindar ejemplos:
Eche un vistazo al proyecto CQRS Journey en MSDN:
http://msdn.microsoft.com/en-us/library/jj591569.aspx
Aclarando la terminología
El término saga se usa comúnmente en las discusiones de CQRS para referirse a un fragmento de código que coordina y enruta los mensajes entre contextos delimitados y agregados. Sin embargo, para los fines de esta guía, preferimos utilizar el término administrador de procesos para referirnos a este tipo de artefactos de código. Hay dos razones para esto:
Existe una definición conocida y preexistente del término saga que tiene un significado diferente al generalmente entendido en relación con CQRS. El término administrador de procesos es una mejor descripción del rol realizado por este tipo de artefactos de código.
Aunque el término saga se usa a menudo en el contexto del patrón CQRS, tiene una definición preexistente. Hemos elegido usar el término administrador de procesos en esta guía para evitar confusiones con esta definición preexistente.
El término saga, en relación con los sistemas distribuidos, fue definido originalmente en el documento "Sagas" por Héctor García-Molina y Kenneth Salem. Este documento propone un mecanismo que llama una saga como alternativa al uso de una transacción distribuida para administrar un proceso comercial de larga duración. El documento reconoce que los procesos de negocio a menudo se componen de múltiples pasos, cada uno de los cuales implica una transacción, y que la coherencia general se puede lograr mediante la agrupación de estas transacciones individuales en una transacción distribuida. Sin embargo, en los procesos comerciales de larga ejecución, el uso de transacciones distribuidas puede afectar el rendimiento y la concurrencia del sistema debido a los bloqueos que deben mantenerse durante la transacción distribuida.
Saga no tiene estado mientras que Process Manager lo tiene.
Otra diferencia: Process Manager es una máquina de estados, Saga no lo es.
Saga no tiene
- estado de máquina de estado
- estado de datos (algunos datos persistentes)
.. y Process Manager tiene
- estado de máquina de estado
- estado de datos (algunos datos persistentes)
Lea más en mi blog: http://blog.devarchive.net/2015/11/saga-vs-process-manager.html
Tanto Process Manager como Saga enrutan un mensaje a través de múltiples pasos de procesamiento cuando los pasos requeridos pueden no conocerse en el momento del diseño y pueden no ser secuenciales.
El patrón de gestor de procesos es un programador de eventos duradero que encapsula la lógica específica del proceso y mantiene un punto central de control que decide qué ejecutar una vez que se completa un proceso. Los gerentes de procesos mantienen el estado, por ejemplo, dicen que un cliente tomó un pago, y el hecho de que ahora se les debe enviar una orden se conserva en el administrador de procesos.
Patrón de administrador de saga. Encapsula la lógica del proceso y decide qué ejecutar luego una vez que se completa un proceso. Una saga no tiene ningún estado, por lo que decide qué hacer a continuación basándose por completo en el contenido del mensaje o evento entrante. Entonces, en el caso de que un proceso tome un pago, ese proceso también crea un nuevo mensaje que indica que ahora se debe enviar un pedido, incluyendo lo que se debe enviar y a quién. El mensaje también contiene información de pago adicional, de modo que si algo fallara al enviar el pedido, el pago se reembolsará.