Zalety systemu „Przekazywanie wiadomości” a systemu „Na podstawie zdarzeń”

Moje pytanie pochodzi z nieco niewykształconej perspektywy.

Jakie są względne zalety systemu „ przekazywania wiadomości ” w porównaniu z systemem „ opartym na zdarzeniu ”.

Dlaczego jeden miałby wybierać jeden nad drugim? Jakie są ich mocne i słabe strony?

Chciałbym wiedzieć nie tylko „w teorii”, ale także „w praktyce”.

EDYTOWAĆ:

Konkretny problem :

Chcę zbudować system komponentów wtykowych, które zachowują się jak usługi na małą skalę (każda z nich wykonuje jakieś małe zadanie lub dostarcza informacji).

Usługi mogą:

• być warstwowe, aby dane wyjściowe jednej usługi mogły działać jako jeden z danych wejściowych do drugiego
• mają hierarchie przechowywania, aby jedna usługa mogła być zawarta przez inną bez określonej relacji przepływów międzygałęziowych, jak wspomniano w poprzednim zdaniu

Celem systemu jest przełożenie pojedynczego przepływu zdarzeń niskiego poziomu w innym systemie na informacje i funkcjonalność wyższego poziomu, a ponadto zapewnienie kanału z powrotem do drugiego systemu zapewniającego jedną serię zdarzeń.

Mogę podać więcej szczegółów, jeśli to nie wystarczy.

Po dłuższym rozejrzeniu się. To i to prawdopodobnie lepiej opisuje moją sytuację.

Wygląda na to, że pasuje do mojej sytuacji: http://akka.io/

Z mojego doświadczenia wynika, że ​​jedyną szczególną różnicą jest to, że w większości systemów przekazywania wiadomości, nadawca wiadomości jest świadomy (i często deklaruje), kto jest odbiorcą wiadomości.

Zamiast więc zgłaszać zdarzenie i każdy, kto jest przypisany do zdarzenia, które je otrzymało, nadawca definiuje jakiś identyfikator docelowego odbiorcy lub logicznej grupy odbiorców, a następnie albo wysyła wiadomość bezpośrednio do nich, albo przechodzi przez brokera wiadomości (chociaż system operacyjny może być postrzegany jako broker komunikatów w systemie opartym na zdarzeniach).

Oczywiście istnieje przypadek wątków, o którym Telastyn wspomina o implementacji zdarzeń przez C #, ale nadal możesz stworzyć swój własny model pub / sub, który będzie działał w różnych wątkach.

To są jabłka i pomarańcze:

System sterowany zdarzeniami może reagować na zdarzenia przekazywane jako wiadomości (komunikaty w tym kontekście są niezmiennymi, niepodzielonymi danymi ), gdy zdarzenia są wywoływane. To jest projekt czysto architektoniczny.

System przekazywania wiadomości może być sterowany przez zdarzenia, które tworzą i przekazują wiadomości. Jest to wyłącznie projekt implementacyjny.

Obie nie wykluczają się wzajemnie.

Przykład: Możesz zaimplementować projekt sterowany zdarzeniami w dowolnym języku, który może być również środowiskiem przekazywania komunikatów, jak w Erlang.

Wiele nieporozumień między „przekazywaniem wiadomości” a „oparte na zdarzeniach” dotyczy szczegółów architektonicznych a implementacyjnych. Widziałem (i pisałem) systemy sterowane zdarzeniami, które faktycznie używają komunikatów dostarczonych przez system operacyjny do ich realizacji. Zgaduję, że naprawdę odnosisz się do pomysłów architektonicznych.

Jak wiele osób już zauważyło, „przekazywanie wiadomości” i „oparte na zdarzeniach” nie są wystarczająco dobrymi warunkami, aby uniknąć dwuznaczności.

Jakie są względne zalety systemu „przekazywania wiadomości” w porównaniu z systemem „opartym na zdarzeniu”.

Przekazywanie wiadomości

Zacznę od zgadywania, że ​​kiedy mówisz o systemie przekazywania wiadomości, mówisz o systemie, w którym jeden obiekt przekazuje wiadomość do określonego innego obiektu. Kiedy myślę o systemie opartym na tym paradygmacie, bardziej ogólnie myślę o systemie, w którym obiekt, który wykrywa coś, wie, o kim trzeba powiedzieć. (Nie precyzuję, skąd to wie, tylko że wie.)

Ten rodzaj architektury jest bardzo dobry dla systemów, w których producenci i konsumenci są dobrze znani. Albo producent wiadomości wie, kto musi ją otrzymać, albo konsument musi wiedzieć, od kogo otrzymać wiadomość.

Jeśli piszesz aplikację bankową, można się spodziewać, że naprawdę chcesz wiedzieć, do kogo wysyłasz swoje transakcje i do kogo.

Na podstawie zdarzenia

Drugi system, o którym myślę, że myślisz, kiedy mówisz, że system „oparty na zdarzeniu” to taki, w którym obiekt wywołuje „zdarzenie”, nie wiedząc, kto (jeśli ktokolwiek) zareaguje na to.

Ten rodzaj architektury opartej na zdarzeniach jest bardzo dobry dla systemów, w których producent nie dba o to, kto zużywa zdarzenie lub gdzie konsument tak naprawdę nie dba o to, kto wyprodukował zdarzenie.

Ogólnie rzecz biorąc, systemy te są świetne tam, gdzie nie znasz relacji między konsumentami a producentami i gdzie oczekujesz, że związek będzie dynamiczny.

Jednym z używanych przeze mnie systemów był system, w którym aplikacja składała się z dynamicznie konfigurowanych modułów (wtyczek), które były ładowane w czasie wykonywania. Gdy moduł został załadowany, rejestrowałby zdarzenia, na których mu zależało. W rezultacie powstał system, w którym bardzo łatwo było rozszerzyć funkcjonalność.

Na przykład powiedzmy, że warunek A wywołał Zdarzenie EA, które normalnie spowodowało odpowiedź RA. Obiekt, który spowodował odpowiedź RA, po prostu zarejestrował się, aby otrzymać zdarzenie EA i działał na nim, gdy dotarł. Powiedzmy, że chcemy dodać nową odpowiedź do EA o nazwie RA_1. Aby to zrobić, po prostu dodajemy nowy obiekt, który szuka EA i generuje odpowiedź RA_1.

Oto kilka przykładów (używając terminologii):

• „przekazywanie wiadomości” : Twój szef każe ci wypełnić arkusz czasu pracy.
• „sterowane zdarzeniami” : Sekretarz działu wysyła wiadomość e-mail do wszystkich, przypominając im, że ich harmonogramy są dzisiaj wymagane.

W SOA masz pojęcie komunikatów poleceń i komunikatów zdarzeń . Potrzebne jest jedno i drugie.

Jednak komunikaty poleceń mają wyższe sprzężenie behawioralne z punktem końcowym odbiorcy, ponieważ wyraźnie prosi punkt końcowy o wykonanie jakiejś funkcji. Nie musi być powiązany z określonym punktem końcowym (można to skonfigurować lub określić w czasie wykonywania).

Z drugiej strony komunikaty o zdarzeniach nie łączą się behawioralnie między nadawcą / odbiorcą, ponieważ nadawca nie ma pojęcia, co odbiorca zrobi z wiadomością. Nie wie nawet, czy ktoś subskrybuje to wydarzenie.

Aby uzyskać więcej informacji, zapraszamy do zapoznania się z moją stroną autobusu serwisowego tutaj: http://www.servicebus.co.za

Z mojego doświadczenia wynika, że ​​największą różnicą między nimi jest to, że wiadomości w systemie przekazywania wiadomości są obiektami pierwszej klasy, podczas gdy zdarzenia w systemach sterowanych zdarzeniami są znacznie prostsze. Wiadomości mają tendencję do przenoszenia informacji, które mogą być przetwarzane, przechowywane, wyszukiwane i wysyłane ponownie. Wydarzenia mają tendencję do przenoszenia mniejszych, bardziej skoncentrowanych fragmentów informacji, które są natychmiast konsumowane, a następnie odrzucane. Zazwyczaj są one wysyłane ze źródła zdarzeń bezpośrednio do jednego lub kilku ujść zdarzeń, podczas gdy wiadomości są częściej kierowane między kilkoma odbiornikami i mogą być konwertowane / tłumaczone / pakowane lub w inny sposób przetwarzane w dowolnym punkcie na trasie. Używają podobnych technologii (autobusy, kolejki, filtry itp.), Ale są naprawdę różnymi zwierzętami.

Z praktycznego punktu widzenia wiadomości są zazwyczaj realizowane jako blok pamięci, który jest kopiowany z przestrzeni adresowej nadawcy do przestrzeni adresowej odbiorcy (lub w inny sposób jest wymuszany jako niezmienny obiekt), dzięki czemu natychmiast zyskujesz bezpieczeństwo wątków.

W niektórych przypadkach przekazywania wiadomości nadawca musi określić odbiorcę, ale w niektórych innych przypadkach możesz po prostu opublikować wiadomość w skrzynce pocztowej, a każdy może nasłuchiwać wiadomości w tej skrzynce, więc istnieje pewna elastyczność w zakresie ich ścisłego powiązania. Oczywiście możesz mieć skrzynkę pocztową, w której umowa brzmi: „Wyślę wiadomość do tej skrzynki pocztowej, gdy wydarzenie się wydarzy”.

W przypadku wydarzeń rejestrujesz delegata lub telefon zwrotny u właściciela wydarzenia. W programowaniu obiektowym oznacza to, że właściciel zdarzenia przechowuje odniesienie do obiektu, który zarejestrował się w celu odebrania zdarzenia. Może to czasem prowadzić do koszmarów księgowych, próbując dowiedzieć się, jaki obiekt zapomniał wyrejestrować moduł obsługi zdarzeń. Oznacza to, że cel nie może zostać wyrzucony, dopóki właściciel zdarzenia nie zostanie wyrzucony, nawet jeśli cel nie robi już nic użytecznego.

Osobiście wybrałbym przekazywanie wiadomości o zdarzeniach, z wyjątkiem przypadków, w których zdarzenia są wymuszane na tobie, takich jak programowanie GUI systemu Windows itp.