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

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
NServiceBus - możliwości 2
Oto dalszy ciąg opowieści o możliwościach biblioteki NServiceBus. W poprzedniej części mogliście przeczytać głównie o wysyłaniu komunikatów. Tym razem postaram się opowiedzieć więcej o odbieraniu komunikatów oraz o ...

Odbieranie komunikatów

NServiceBus nie oferuje bezpośrednio żadnego API służącego do odbierania komunikatów. Odbieranie (a zaraz po nim – przetwarzanie) odbywa się automatycznie na podstawie zarejestrowanych w danej instancji szyny obiektów obsługi komunikatów, tzw. message handler-ów. Aby umożliwić przetwarzanie danego typu wiadomości wystarczy zaimplementować generyczny interfejs IHandleMessages<T> i zapewnić, że assembly zawierające handler-a znajdzie się w ścieżce poszukiwania DLLek aplikacji hostującej szynę.

Zwróćcie uwagę na niecodzienną nazwę interfejsu. Jest to konwencja proponowana przez Udiego Dahana – aby nazwa interesu była zdaniem oznajmującym informującym o jego roli. Osobiście jestem raczej sceptycznie do tego pomysłu nastawiony, ale fakt jest taki, że w NServiceBus konwencja ta stosowana jest coraz szerzej.

Może równolegle istnieć wiele klas obsługujących pojedynczy typ komunikatu. Każda z nich może być np. zainteresowana jedynie podzbiorem przesyłanych danych. W takim wypadku, jeśli szyna pracuje w trybie transakcyjnym, transakcja obejmuje wykonanie wszystkich handler-ów danego komunikatu. W przypadku niepowodzenia jednego z nich, przetwarzanie jest przerywane, a transakcja – wycofywana.

Kolejka komunikatów zatrutych

To bardzo niewybitne tłumaczenie poison message queue. Idea jest prosta: ponieważ komunikaty w kolejce są przetwarzane w trybie FIFO, a komunikat, którego przetworzenie zakończy się błędem jest zwracany do kolejki, jedna "zatruta" wiadomość mogłaby skutecznie zablokować całe przetwarzanie – serwer próbowałby ją obsłużyć do końca świata (do 2012-go?).

Odpowiedzią na ten problem jest specjalna kolejka, do której trafiają komunikaty, których nie uda się przetworzyć określoną ilość razy. Sensowną wartością ilości ponowień jest 5. Pozwala to zminimalizować prawdopodobieństwo, że komunikat wyląduje w kolejce błędów na skutek nieprzewidywalnych zdarzeń losowych, typu chwilowa utrata połączenia z bazą danych.

NServiceBus wymaga, aby dla instancji szyny określić nazwę kolejki komunikatów zatrutych oraz liczbę ponowień przetwarzania. Parametry te znajdują się w dedykowanej sekcji  konfiguracyjnej.

To be continued...

Opublikowane 27 listopada 2009 15:44 przez simon

Filed under:

Komentarze:

# re: NServiceBus - możliwości 2 @ 28 listopada 2009 23:37

Konwencja nazewnicza działa bo nazwy interfejsów zaczyna sie od 'I'. Ale gdybyś programował po polsku to musiał byś swój interfejs nazywać JaObsługujęKomunikat<Jakiśtam>. W sumie fajnie.

nightwatch

Komentarze anonimowe wyłączone