Jaka jest różnica między Saga, menedżerem procesów a podejściem opartym na dokumentach?

Rozumiem, że wszystkie trzy pojęcia są związane z długofalowymi transakcjami.

Menedżer procesów jest, jak rozumiem, skończoną maszyną stanową, która po prostu reaguje na zdarzenia i wydaje polecenia. Nie zawiera żadnej logiki biznesowej, po prostu robi routing. Jego celem jest doprowadzenie cię do ostatecznego stanu, w którym wiesz, że Twoja transakcja zakończyła się sukcesem lub nie powiodła się.

Jak na razie dobrze.

Ale teraz moje problemy w zrozumieniu zaczynają się:

  • Co to jest saga w przeciwieństwie do menedżera procesów?
  • istnieje również podejście oparte na dokumentach, jak wspomniano w CQRS sagas - czy dobrze je zrozumiałem? ... Jak rozumiem, dokument to tylko "kartka papieru", na której robisz notatki i wręczasz je. Jak to pasuje do koncepcji poleceń i zdarzeń?

Czy ktoś może wyjaśnić różnice i-co mnie szczególnie interesuje-które z tych pojęć jest dobre do czego, a kiedy czego potrzebujesz? Czy wzajemnie się wykluczają? Możesz przejść całą drogę tylko z jednym z nich? Czy istnieją scenariusze, w których potrzebujesz więcej niż jednego? …?

 32
Author: Community, 2013-03-20

4 answers

[[0]} spójrz na projekt CQRS Journey na MSDN:

Http://msdn.microsoft.com/en-us/library/jj591569.aspx

Wyjaśnienie terminologii

Termin saga jest powszechnie używany w dyskusjach CQRS w odniesieniu do fragment kodu, który koordynuje i przekierowuje wiadomości między ograniczonymi konteksty i agregaty. Jednak dla celów niniejszych wytycznych preferuje użycie terminu menedżer procesów w odniesieniu do tego typu kodu artefakt. Są dwa powody tego:

Istnieje dobrze znana, wcześniej istniejąca definicja terminu saga, która ma inne znaczenie niż ogólnie rozumiane w stosunek do CQR. Termin menedżer procesów jest lepszym opisem roli pełnionej przez tego typu artefakt kodowy.

Chociaż termin saga jest często używany w kontekście CQRS wzorzec, ma już istniejącą definicję. Zdecydowaliśmy się na wykorzystanie termin kierownik procesu w tym poradniku, aby uniknąć nieporozumień z tym istniejąca definicja.

Termin saga, w odniesieniu do systemów rozproszonych, był pierwotnie zdefiniowane w artykule "Sagas" Hectora Garcia-Molina i Kennetha Salem. W artykule zaproponowano mechanizm, który nazywa sagą jako alternatywa dla wykorzystania rozproszonej transakcji do zarządzania długotrwały proces biznesowy. Gazeta uznaje, że biznes procesy często składają się z wielu etapów, z których każdy wiąże się z transakcją, i że ogólnie spójność można osiągnąć grupując te pojedyncze transakcje w rozproszone transakcja. Jednak w długotrwałych procesach biznesowych, za pomocą transakcje rozproszone mogą mieć wpływ na wydajność i współbieżność systemu ze względu na blokady, które muszą być utrzymywane przez czas transakcji rozproszonej.

 23
Author: Jakub Konecki,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-03-20 15:39:56

Czym jest Saga w przeciwieństwie do menedżera procesów?

Intencja tych wzorców jest inna. Menedżer procesów jest wzorcem przepływu pracy, który może, jak mówisz, być zbudowany na maszynie stanowej. Menedżer procesów zachowa stan pomiędzy komunikatami i będzie zawierał logikę w celu określenia, które działania należy podjąć w odpowiedzi na wiadomość (na przykład przejście stanu lub wysłanie innej wiadomości). Niektóre frameworki błędnie odnoszą się do nich jako sagas.

Natomiast Saga (zgodnie z oryginalnymi definicjami) jest wzorem mającym na celu pomoc w zarządzaniu awariami. Obejmuje ona wiele obiegów pracy w różnych systemach, gdzie każdy z nich pozwoli na podjęcie jakiejś formy działania kompensacyjnego w późniejszej transakcji w przypadku awarii w innym miejscu.

Ta kompensacja jest cechą charakterystyczną sagi. Zauważ, że sama saga nie wie jaka może być akcja kompensacyjna. Sagi są często realizowane używając wzoru poślizgu.
Czy wzajemnie się wykluczają? Możesz przejść całą drogę tylko z jednym z nich?

Nie wykluczają się wzajemnie - jest prawdopodobne, że na przykład system uczestniczący w SAGA może używać menedżera procesów do obsługi swojego procesu przetwarzania.

Inne Zasoby

Niektóre z tych postów mogą pomóc dostarczyć więcej szczegółów i podać przykłady:

 30
Author: James Nugent,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-11-29 09:41:39

Saga nie ma stanu, podczas gdy menedżer procesów ma.

Kolejna różnica - menedżer procesów jest maszyną stanową, a Saga Nie.

Saga nie ma

  • Stan maszyny stan
  • Stan danych (niektóre dane)

.. i Process Manager ma

  • Stan maszyny stan
  • Stan danych (niektóre dane)

Czytaj więcej na moim blogu: http://blog.devarchive.net/2015/11/saga-vs-process-manager.html

 8
Author: Kirill Chilingarashvili,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-03 07:00:01

Zarówno menedżer procesów, jak i saga przesyłają wiadomość przez wiele etapów przetwarzania, gdy wymagane kroki mogą nie być znane w czasie projektowania i mogą nie być sekwencyjne.

Process manager pattern jest trwałym harmonogramem zdarzeń, który zawiera logikę specyficzną dla procesu i utrzymuje centralny punkt kontroli decydujący o tym, co należy wykonać po zakończeniu procesu. Menedżerowie procesów utrzymać stan tak na przykład powiedzieć, że płatność została pobrana od klienta, fakt, że zamówienie musi teraz być wysłane do nich jest utrzymywany w Menedżerze procesów.

Wzór menedżera sagi. Hermetyzuje logikę procesu, decydując, co należy wykonać po zakończeniu procesu. Saga nie posiada stanu, więc decyduje, co robić dalej w oparciu wyłącznie o treść przychodzącej wiadomości lub wydarzenia. Tak więc w przypadku, gdy płatność jest pobierana przez proces, proces ten tworzy również nową wiadomość wskazującą, że zamówienie musi zostać wysłane, w tym, co należy wysłać i do kogo. Wiadomość zawiera również dodatkowe informacje o płatności, więc jeśli coś poszło nie tak wysyłając zamówienie, Płatność zostanie zwrócona.

 2
Author: andrew pate,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-12-22 12:43:00