NServiceBus – możliwości
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.
Komunikacja kolejkowa
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.
Publikacja polega na wstawieniu komunikatu do wejściowej kolejki odbiorców.
Własna kolejka wejściowa jest pomijana
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.
Publikacja polega na wstawieniu komunikatu do wejściowej kolejki odbiorców.
Własna kolejka wejściowa jest pomijana
Wysyłanie komunikatów
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.
Proces subskrypcji: 1) wysłanie komunikatu,
2) zapisanie informacji o subskrypcji w bazie danych
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.
Proces subskrypcji: 1) wysłanie komunikatu,
2) zapisanie informacji o subskrypcji w bazie danych
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…
