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.
