oparte na komunikatach a oparte na zdarzeniach podejścia do integracji aplikacji

Question

Zastanawiałem się, czy istnieje wyraźne rozróżnienie między środowiskami opartymi na komunikatach i środowiskami zdarzeniowymi, gdy odwołujemy się do SOA lub oprogramowania pośredniego, a ogólnie w przypadkach integracji aplikacji i przedsiębiorstw. Rozumiem, że interfejs użytkownika przypomina model oparty na zdarzeniach, w którym nasz system przechwytuje działanie użytkownika.

Ponadto oczywiste jest, że komunikator obsługuje systemy na podstawie publikuje/zapisz, synchronicznym lub asynchroniczną komunikację, transakcje itp

Ale jest jakaś różnica w kontekście intergration middleware/soa/aplikacji? (poziom architektury). Próbuję skonsultować źródła takie jak wikipedia (here i here), ale nadal jestem nieco zdezorientowany. Kiedy deweloper powinien preferować jedno rozwiązanie względem drugiego?

Czy istnieją przykłady lub przypadki, w których jedno podejście ma więcej sensu niż inne? Lub wszelkie wszechstronne zasoby i przewodniki dotyczące wdrażania każdego z nich?

Wielkie dzięki za wgląd.

Answer 1

Krótka odpowiedź na pytanie "czy istnieje wyraźne rozróżnienie" brzmi "nie".

Terminy nie są całkiem zamienne, ale sugerują tę samą podstawową architekturę - w szczególności, że będziesz wyzwalać zdarzenia lub wiadomości.

Pierwszy artykuł, o którym wspominasz, dotyczy niskiego poziomu hydrauliki, MOM lub pub-sub "bus", który transportuje wiadomości w Twoim imieniu. Architektura oparta na zdarzeniach jest tym, co budujesz na podstawie tej struktury.

Termin "zdarzenie sterowane zdarzeniami", a jednocześnie ma zastosowanie do kodu GUI, nie jest tak naprawdę na tym samym poziomie abstrakcji. W takim przypadku jest to niewielki wzorzec w porównaniu z budowaniem całego przedsiębiorstwa wzdłuż linii komunikatów/zdarzeń.

Answer 2

Architektura sterowana zdarzeniami może być zaimplementowana z komunikatorami lub bez nich. Przesyłanie wiadomości jest jednym ze sposobów komunikacji w sposób rzetelny i gwarantowany, który producent przekazuje konsumentom. Zwłaszcza, gdy producenci i konsumenci są naprawdę rozdzieleni i mogą być hostowani na różnych serwerach/maszynach wirtualnych/środowiskach i nie mają bezpośredniego dostępu do pamięci współdzielonej.

Jednak w szczególnych przypadkach - gdy konsument zdarzenia jest funkcją/wywołaniem oddzwonienia zarejestrowanym w tej samej aplikacji lub gdy konsument musi być wykonany synchronicznie, wówczas subskrypcja zdarzeń może zostać zaimplementowana bez powiadamiania.

Answer 3

Jak to jest ładnie przedstawione w artykule this, aby zrozumieć projekt oparty na zdarzeniach, zamiast patrzeć na to, co prezentuje, musimy obserwować, co kryje i to nic więcej niż tylko podstawowe programowanie; "Stos wywołań".

W projekcie opartym na zdarzeniach definicja wywołania metody znajduje się tuż za oknem. Nie ma już dzwoniącego i kelnera. To jest pocałunek na pożegnanie z sekwencją i zamówieniem połączenia. System nie musi wiedzieć, w jakiej kolejności rzeczy muszą się wydarzyć. Dlatego też udostępniona przestrzeń pamięci, która jest niezbędna dla stosu wywołań, staje się niepotrzebna.

Jednak w środowisku Call Stack nie tylko osoba wywołująca musi wiedzieć, co dzieje się dalej, ale musi być w stanie powiązać funkcję z nazwą metody.

Aplikacje zorientowane komunikacyjnie są domyślnie usuwane z pamięci współużytkowanej. Wydawca i subskrybent nie muszą udostępniać miejsca w pamięci.Z drugiej strony wszystkie inne funkcje (tj. Kolejność, sprzęganie nazw metod i tym podobne) nie są potrzebne.

Jeśli przekazywanie komunikatów zostało zaprojektowane w celu zachowania zgodności z aksjomatami architektury sterowanej zdarzeniami, można je uznać za identyczne. W przeciwnym razie istnieje ogromna różnica między nimi.

Answer 4

Jeśli stosujemy podejście oparte na zdarzeniach, zwykle chcemy wysłać obiekt źródłowy w tym zdarzeniu - komponent, który opublikował wydarzenie. Tak więc w subskrybencie możemy uzyskać nie tylko dane, ale także wiedzieć, kto opublikował to wydarzenie. Na przykład. w rozwoju mobilnym otrzymujemy widok, który może być przyciskiem, obrazem lub niestandardowym widokiem. I w zależności od rodzaju tego widoku możemy użyć innej logiki w subskrybencie. W takim przypadku możemy nawet dodać trochę przetwarzania wstecznego, zmodyfikować komponent źródłowy - np. dodaj animację do tych widoków źródła.

Gdy stosujemy podejście oparte na komunikatach, chcemy opublikować tylko komunikat z pewnymi danymi. Nie ma znaczenia dla subskrybenta, który opublikował tę wiadomość, chcemy tylko otrzymać dane i je przetworzyć.

Answer 5

Oto punkt widzenia Typesafe/Reactive na pytanie Jonasa Bonér. Z trzeciego akapitu this blog post: "Różnica polega na tym, że wiadomości są kierowane, wydarzenia nie są - wiadomość ma wyraźnego adresowalnego adresata, podczas gdy wydarzenie właśnie się dzieje dla innych (0-N), aby je obserwować."

Answer 6

Architektura oparta na zdarzeniach i architektura napędzana wiadomościami to dwie różne rzeczy i rozwiązuje dwa różne problemy.

Sterowanie zdarzeniami Architektura koncentruje się na sposobie uruchamiania systemu. Większość wyzwalaczy uważanych za zdarzenia w kontekście EDA to zdarzenia generowane za pomocą innych środków niż klawiatura i mysz. Jest to EDA, jeśli pozwala nam to jednoznacznie myśleć o generatorze zdarzeń, kanale zdarzeń, silniku przetwarzania zdarzeń.

Klawiatura i mysz to oczywiste generatory zdarzeń, jednak obsługa tych zdarzeń jest już zajęta przez różne środowiska wykonawcze i środowiskowe, a jako architekt nie musimy się tym martwić. Istnieją inne zdarzenia, które są specyficzne dla określonej domeny, to o czym ma myśleć Architekt. Przykład - Zdarzenia zarządzania łańcuchem dostaw - wybór, opakowanie, wysyłka, dystrybucja, sprzedawca detaliczny, sprzedany itp. Z perspektywy technicznej aplikacji przemysłowych typu IoT są to zdarzenia - odczyt RFID, odczyt bio-metryczny, dane z czujników, skanowanie kodów kreskowych, zdarzenia generowane przez system są zdarzeniami, które wymagają szczególnej uwagi, ponieważ te zdarzenia wpływają na funkcjonalność systemu.

Koncentracja na technologii wiadomości polega na integracji systemów rozproszonych poprzez przekazywanie wiadomości z jednego modułu do innych modułów systemu przy użyciu standardowego oprogramowania pośredniczącego zorientowanego na wiadomości.

Answer 7

To pytanie zostało zadane dawno temu. Myślę, że bardziej nowoczesne i jasne odpowiedzi podane przez Reactive Manifesto w Message-Driven (in contrast to Event-Driven):

wiadomość jest jakiś element danych, który jest wysyłany do określonego przeznaczenia. Zdarzenie jest sygnałem emitowanym przez komponent po osiągnięciu danego stanu. W systemie opartym na komunikatach adresowalni odbiorcy oczekują na nadejście wiadomości i reagują na nie, w przeciwnym razie drzemią. W sterowanych zdarzeniami odbiornikach powiadomień systemowych są one dołączane do źródeł zdarzeń, tak aby były wywoływane podczas emitowania zdarzenia. Oznacza to, że system sterowany zdarzeniami koncentruje się na adresowalnych źródłach zdarzeń, podczas gdy system oparty na komunikatach koncentruje się na adresowalnych adresatach. Komunikat może zawierać zakodowane zdarzenie jako jego ładunek.