Posts tagged NServiceBus

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.

VN:F [1.9.13_1145]

Zakładam, że po przeczytaniu poprzedniej notki albo się z zgadzacie, ale przestaliście czytać tę serię. Dlatego pozwolę sobie przejść od razu do konkretów. Wiemy już co-nieco o tym czym jest NSB i jakie są jego główne założenia. Postaram się teraz opowiedzieć dokładniej o tym, co biblioteka ta oferuje programistom.

NServiceBus posiada warstwę abstrakcji oddzielającą rdzeń biblioteki od szczegółów implementacyjnych mechanizmu transportowego. Dzięki temu istnieje możliwość wyboru alternatywnego, w stosunku do MSMQ, sposobu komunikacji, np. opartego bezpośrednio na UDP lub (nowość!) na kolejkach Windows Azure. Niemniej jednak MSMQ pozostaje wciąż najbardziej popularnym rozwiązaniem, dlatego też ten tutorial będzie mocno zorientowany na ten transport.

W NServiceBus każdy węzeł szyny posiada 2 kolejki: kolejkę wejściową oraz kolejkę błędów. NSB w nieskończonej pętli odbiera i przetwarza komunikaty z kolejki wejściowej. Jedna instancja szyby może obsługiwać tylko jedną taką kolejkę. Komunikaty, których nie udało się przetworzyć pewną założoną ilość razy (domyślnie 5) trafiają do kolejki błędów (dead-letter queue), gdzie oczekują na manualne przetworzenie przez jakiegoś administratora.

Wysyłanie komunikatu w NServiceBus polega na wstawieniu go do kolejki wejściowej adresata. To bardzo ważne. Nie istnieje nic takiego jak kolejka wyjściowa. Zamiast tego komunikat od razu trafia na wejście kolejki docelowej. Jeśli kolejka ta znajduje się na innej maszynie, lokalna infrastruktura MSMQ automatycznie zajmuje się forwardowaniem komunikatu do docelowej instancji MSMQ.

Wysyłanie komunikatów w NSB udostępnione jest za pośrednictwem wszechobecnego interfejsu IBus. Dlaczego wszechobecnego? Dlatego, że IBus dostępny jest z każdego miejsca w kodzie (można go po zainicjowaniu na starcie aplikacji zachować w jakiejś statycznej zmiennej). IBus jest bezpieczny, jeśli chodzi o wywołania z wielu wątków i zachowuje się różnie w zależności od tego, jakim kontekście został użyty. Bardzo rzadko przyjdzie wam schodzić niżej, niż poziom tego mega-interfejsu. A wracając do tematu — IBus udostępnia szereg metod służących do wysyłania komunikatów. Można wśród nich wyróżnić dwie główne grupy: Send oraz Publish.

Metoda Send służy do wysłania komunikatu (lub zestawu komunikatów) do jednego konkretnego adresata. Adresat ten (w postaci nazwy kolejki) może być podany jako argument lub pobrany z konfiguracji. Preferowane jest rozwiązanie wykorzystujące konfigurację. W sekcji MsmqTransportConfig określamy mapowanie assembly lub typ -> kolejka docelowa.

Metoda Publish służy do wysłania komunikatu do wielu odbiorców jednocześnie. Odbiorcy ci muszą jednak wcześniej zgłosić zapotrzebowanie na dostarczanie komunikatów danego typu.

Zgłoszenie to określa się mianem subskrypcji. Subskrypcje są przechowywane wewnętrznie przez NSB. Aby zasubskrybować dany komunikat, klient wywołuje na swojej instancji IBus metodę Subscribe, której działanie polega na wysłaniu systemowego komunikatu subskrypcji na adres serwera. Oznacza do, że klient musi w swojej sekcji MsmqTransportConfig posiadać mapowanie typu subskrybowanego komunikatu na adres kolejki wejściowej serwera.

To be continued…

VN:F [1.9.13_1145]

W wielu moich dotychczasowych postach mieliście okazję poczytać o bibliotece NServiceBus. Jest nawet osobna kategoria o tej nazwie w chmurze tagów. Odnoszę jednak wrażenie, że nie poświęciłem wystarczająco dużo czasu, aby Wam przedstawić NSB. Dopiero teraz zdałem sobie sprawę, że nie jest to biblioteka powszechnego użytku, jak np. NUnit czy NHibernate.

NServiceBus jest produktem niszowym. Nie aspiruje do bycia kombajnem od wszystkiego. Ma swój jeden, bardzo dobrze zdefiniowany cel: jest frameworkiem do komunikacji asnychronicznej z obsługą publish/subscribe. Tylko tyle, a jednocześnie aż tyle. Samo nasuwa się porównanie do WCF: zakres odpowiedzialności NSB to niewielki ułamek tego, co robi WCF. Z drugiej strony, w ramach tego niewielkiego zakresu NServiceBus potrafi o wiele, wiele więcej niż WCF.

Aby wejść w świat NSB zmuszeni jesteśmy porzucić kilka wygodnych abstrakcji. Po pierwsze, komunikacja pomiędzy dwoma procesami/usługami/aplikacjami zawsze wiąże się z niebanalnym narzutem. Nie więc możemy udawać, że to tylko wywołanie metody. Komunikacja między dwoma procesami realizowana jest przez przesyłanie komunikatów, a nie wywołanie metod.

Zapomnijmy także o tym, że możemy bez konsekwencji wymienić warstwę transportową zmieniając wyłącznie binding. Każdy, kto zna lepiej WCF-a wie, że to tylko iluzja i że macki binding-ów (w postaci wielu subtelnych niuansów) sięgają daleko głębiej niż się z początku wydaje i zmiana transportu bez wcześniejszego przygotowania jest nierealna.

Na koniec zapomnijmy o czymś takim, jak transakcje typu ACID między różnymi procesami/aplikacjami. Transakcje rozproszone to kolejna z cieknących abstrakcji odziedziczonych po systemach komponentowych (CORBA?). Nie dowiemy się jednak tego wcześniej, niż przy pierwszym produkcyjnym wdrożeniu systemu, który masowo z nich korzysta. Problem z transakcjami między procesami jest taki, że tworzą one bardzo silne powiązanie (także czasowe) między zaangażowanymi stronami. Cierpi na tym zarówno dostępność (bo dostępność systemu z transakcjami rozproszonymi jest iloczynem dostępności jego elementów składowych), jak i wydajność (bo awaria jednego komponentu powoduje utratę rezultatów całej transakcji).

Czytelniku, jeśli dotarłeś aż tutaj stosując się do sugestii autora, jesteś gotów na rozpoczęcie przygody z NServiceBus. NSB wymaga bowiem (w odróżnieniu od WCF), aby zaakceptować rzeczywistość taką, jaka ona jest.

W następnych odcinkach postaram się pokazać, jak NServiceBus pozwala stworzyć system, który nie walczy z prawami fizyki, ale żyje z nimi w zgodzie i harmonii.

VN:F [1.9.13_1145]