Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
NServiceBus - Message Broker vs Message Bus
Message Broker i Message Bus to dwa konkurencyjne wzorce architektoniczne związane z integracją systemów. Celem obu jest rozwiązanie problemu komunikacji między wieloma systemami (usługami) w taki sposób, aby zapobiec tzw. Spaghetti-Oriented Architecture, czyli komunikacji każdy-z-każdym.

Message Broker (znany także jako hub-and-spoke) zakłada istnienie jednago centralnego punktu, przez który przechodzą wszystkie komunikaty w danym systemie. Broker zajmuje się konwersją formatów oraz innymi kwestiami niefunkcjonalnymi (np. bezpieczeństwo). Oczywiście stwierdzenie "jeden centralny punkt" dotyczy architektury logicznej. Fizycznie Broker może być zrealizowany za pomocą klastra maszyn w celu zapewniania zwiększonej wydajności i/lub niezawodności.

Wzorzec Message Bus opiera się na braku wspomnianego centralnego punktu. Każdy system (usługa) biorąca udział w komunikacji stanowi węzeł abstrakcyjnej "szyny informacyjnej". Skoro brak jest centralnej koordynacji, to czym Message Bus różni się od tak znienawidzonego spaghetti? Już spieszę z odpowiedzią -- wspólnym mechanizmem komunikacji. Każdy węzeł szyny komunikuje się zegodnie ze wspólnym, uzgodnionym protokołem. Dzięki temu dodanie kolejnego systemu do układanki nie powoduje lawinowego wzrostu skomplikowania systemu.

Dlaczego o tym piszę? Otóż dlatego, że NServiceBus jest frameworkiem pozwalającym budować systemy (lub systemy systemów;-) zgdonie z wzorcem Message Bus. Często wyobrażamy sobie szynę informacji (nazywaną czasem ESB), jako ogromny kawał infrastruktury, który kupujemy za ciężkie pieniądze od IBM czy Oracle. Takie ESB stoi sobie na dedykowanych maszynach w dedykowanej serwerowni... Tylko czy w tym dzikim pędzie za kolejnymi ficzerami i trzyliterowymi skrótami nie zapominamy o samej idei Message Bus? Brak centralnych punktów, tak? Hmm...



NServiceBus pozwala zrealizować ten jeden, konkretny system, nad którym właśnie pracujesz tak, aby komunikacja odbywała się w topologii Message Bus. W NServiceBus każdy niezależny proces systemu to węzeł Szyny. Wszystko, czego potrzeba, aby wpiąć się w tę szynę, to dołączyć referencję do NSB i wystartować swoją instancję IBus.



Na powyższym obrazku klocki ze strzałkami reprezentują kolejki MSMQ. To one (i tylko one) budują szynę. To, czego obrazek nie oddaje to fakt, że kolejki te zlokalizowane są na tych samych fizycznych maszynach, na których systemy je wykorzystujące. Obrazki starają się oddać ważność elementów składowych rozwiązania w obu koncepcjach. Według klasycznej, ESB jest najważniejszym elementem architektury. Według tej, jaką można zrealizować za pomocą NServiceBus, najważniejsze są systemy biznesowe.

Opublikowane 20 listopada 2009 16:05 przez simon

Filed under:

Komentarze:

# re: NServiceBus - Message Broker vs Message Bus @ 20 listopada 2009 20:29

Wspomniana pod pierwszą notką regularność wychodzi ci całkiem imponująco:).

Prośba o rozwinięcie pewnej kwestii, materiału zbierze się pewnie na osobny post...

O szynach słyszy się głównie w kontekście integracji różnych systemów działających na róznych maszynach, w wielkim środowisku o skali "enterprise" - cokolwiek to tak naprawdę znaczy. Czy widzisz jakieś przeciwwskazania, aby NSB wykorzystać w aplikacji o dużo mniejszym stopniu skomplikowania? Udi pisał, ty pisałeś, ja pisałem o ApplicationEvents bądź DomainEvents. Ja rozumiem je jako "lokalną szynę". Czy dobrze to odbieram? Mógłbyś napisać coś o stosowaniu NSB w takim właśnie kontekście - jako mechanizm komunikacji pomiędzy "modułami" jednej aplikacji? Bez rozbijania na wiele maszyn, bez load balancingu, bez zwracania uwagi na bezpieczeństwo komunikacji... Po prostu jako zastąpienie ".NETowych zdarzeń" zrealizowanych w taki bądź inny sposób, w jednym fizycznym procesie. Czy ma to w ogóle sens? Jakieś wady/zalety takiego rozwiązania?...

Procent

Komentarze anonimowe wyłączone