Publikuj / subskrybuj to paradygmat asynchronicznego przesyłania wiadomości. System pobiera informacje o zdarzeniach od wydawcy i wymaganiach dotyczących zdarzeń od subskrybenta, a także wysyła zdarzenia do subskrybentów, których wymagania są zgodne ze zdarzeniami. Nadawcy (zwani także wydawcami) nie wysyłają swoich wiadomości do określonych odbiorców (nazywanych subskrybentami). Zamiast tego opublikowane wiadomości są podzielone na klasy, bez informacji o subskrybentach, jeśli istnieją. Ten paradygmat daje subskrybentom możliwość wyrażenia zainteresowania wydarzeniem lub schematem wydarzeń, aby otrzymać powiadomienie o jakimkolwiek zdarzeniu generowanym przez wydawcę, odpowiadające jego zarejestrowanym zainteresowaniom. Zdarzenie jest propagowane asynchronicznie do wszystkich subskrybentów, którzy zarejestrowali swoje zainteresowanie tym wydarzeniem. Subskrybenci wyrażają zainteresowanie jednym lub kilkoma zajęciami i otrzymują tylko interesujące wiadomości, bez wiedzy o wydawcach, jeśli takie istnieją. Podstawowy model publikowania / subskrypcji przedstawiono na rysunku 6.1. Sercem tego modelu interakcji jest usługa powiadamiania o zdarzeniach, która działa jako mediator między wydawcami a subskrybentami. Ułatwia przechowywanie i zarządzanie subskrypcjami oraz sprawną realizację wydarzeń. Abonenci dzwonią do subscribe (), aby zgłosić swoje zainteresowanie wydarzeniem, bez znajomości rzeczywistego źródła lub wydawcy wydarzenia. Operacja Unsubscribe () kończy subskrypcję. Wydawca wywołuje publikowanie () w celu opublikowania lub wygenerowania zdarzenia. Każdy subskrybent jest powiadamiany o każdym interesującym go zdarzeniu za pomocą operacji notify (). Zaletą paradygmatu pub / sub jest oddzielenie wydawców od subskrybentów, co zapewnia większą skalowalność i bardziej dynamiczną topologię sieci. Oddzielenie między wydawcami a subskrybentami w tej opartej na zdarzeniach usłudze interakcji może odbywać się w czasie, przestrzeni i synchronizacji.
Strony zaangażowane w interakcję nie muszą się znać. Wydawcy nie wiedzą, ilu i którzy subskrybenci są zaangażowani w interakcję i odwrotnie; dotyczy to również subskrybentów. Nazywa się to rozprzęganiem przestrzeni. Rozdzielenie czasu umożliwia wydawcom, gdy subskrybent jest rozłączony, i odwrotnie, subskrybent może otrzymać powiadomienie o zdarzeniu, gdy wydawca jest rozłączony.
Odsprzężenie synchronizacji umożliwia subskrybentom powiadamianie o jakimś zdarzeniu podczas wykonywania pewnej równoległej czynności asynchronicznie, a wydawcy nie są również blokowani podczas tworzenia zdarzeń. Stąd produkcja i konsumpcja zdarzeń nie zachodzą w sposób synchroniczny. Niektóre zastosowania paradygmatu pub / sub to dostarczanie informacji o stanie magazynowym, system aukcyjny, kontrola ruchu lotniczego itp.
Zalety publikacji / subskrypcji
- Luźno powiązane. Wydawcy są luźno powiązani z subskrybentami i dlatego może nawet nie wiedzieć o ich istnieniu. Ponieważ temat jest w centrum uwagi, wydawcy i subskrybenci nie znają topologii systemu. Każdy może nadal normalnie działać niezależnie od drugiego. W tradycyjnym, ściśle sprzężonym paradygmacie klient-serwer klient nie może wysyłać komunikatów do serwera, gdy proces serwera nie jest uruchomiony, ani serwer nie może odbierać komunikatów, jeśli klient nie jest uruchomiony. Wiele systemów pub / sub oddziela nie tylko lokalizacje wydawców i subskrybentów, ale także oddziela ich czasowo.
- Skalowalne. W przypadku stosunkowo małych instalacji, pub / sub zapewnia lepszą skalowalność niż tradycyjny paradygmat klient-serwer. Odbywa się to za pomocą operacji równoległych, buforowania wiadomości, routingu opartego na drzewie lub sieci, itp. Jednak w miarę skalowania systemów z tysiącami serwerów współdzielących infrastrukturę pub / sub, ta korzyść nie jest osiągana zgodnie z oczekiwaniami.
Wady publikacji / subskrypcji
Główną wadą systemów pub / sub jest efekt uboczny ich głównej zalety: oddzielenie wydawcy od abonenta. Problem polega na tym, że określenie silniejszych właściwości, których aplikacja może potrzebować, może być trudne. Jako pierwszy przykład, wiele systemów pub / sub będzie próbowało dostarczać wiadomości przez chwilę, ale potem się poddaje. Jeśli aplikacja rzeczywiście potrzebuje silniejszej gwarancji dostarczenia wiadomości, takiej, że albo wiadomości będą zawsze dostarczane, albo, jeśli dostarczenie nie może zostać potwierdzone, wydawca zostanie poinformowany, że system pub / sub nie ma możliwości zaimplementowania takich właściwości. Inny przykład pojawia się, gdy wydawca „zakłada”, że subskrybent słucha. Załóżmy, że system pub / sub jest używany do rejestrowania problemów w fabryce: każda aplikacja, która wykryje błąd, publikuje odpowiedni komunikat, a komunikaty są wyświetlane na konsoli przez demona programu rejestrującego, który subskrybuje „temat” dotyczący błędów. Jeśli zdarzy się awaria rejestratora, wydawcy nie będą mieli żadnego sposobu, aby to zobaczyć, a wszystkie komunikaty o błędach znikną. W związku z tym zaobserwowano, że chociaż pub / sub skaluje się bardzo dobrze w przypadku małych instalacji, jednak technologia często nie daje się łatwo skalować w przypadku dużych systemów. W rezultacie problemy, takie jak niestabilność przepustowości (skoki obciążenia, po których następują długie okresy ciszy), spowolnienia, ponieważ coraz więcej aplikacji korzysta z systemu (nawet jeśli komunikują się na rozłączne tematy) i tak zwane burze rozgłoszeń IP (które mogą zamknięcie sieci lokalnej przez nasycenie jej komunikatami napowietrznymi, które blokują cały normalny ruch, nawet ruch niezwiązany z pub / sub), stają się wąskim gardłem dla tych systemów. Przeprowadzono szeroko zakrojone badania w tej dziedzinie i omówiono kilka rozszerzeń modelu pub / sub w kontekście sieci komórkowych i radzenia sobie z zawodnymi połączeniami. JMS zezwala na przechowywanie wiadomości w pamięci trwałej, dopóki wszyscy zarejestrowani subskrybenci nie połączą się i nie otrzymają ich lub do momentu osiągnięcia określonego limitu czasu i są one odrzucane. Zajmuje się rozłączeniami dzięki trwałym subskrypcjom, które są przechowywane i mogą być aktywowane przez ponowną subskrypcję. Zakresy ograniczają widoczność powiadomień publikowanych przez producenta i ograniczają te powiadomienia tylko do tych konsumentów, którzy są w określonym zakresie lub w tym samym zakresie, który zdefiniował wydawca. Ta sama koncepcja zakresu jest również stosowana do sieci czujników, jako ogólna abstrakcja dla grupy węzłów