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

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
NServiceBus
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.

Opublikowane 18 listopada 2009 17:42 przez simon

Filed under:

Komentarze:

# re: NServiceBus @ 18 listopada 2009 18:17

I bardzo dobrze, byle duzo, szczegolowo i regularnie - czekam:)

Procent

# re: NServiceBus @ 18 listopada 2009 18:49

@%

Oj z tą regularnością to mogą być problemy... U mnie zawsze są. Zwykle przypominam sobie, że już _powinienem_ coś napisać, kiedy widzę u Ciebie drugą z kolei notkę;)

simon

# Simon says... : NServiceBus @ 18 listopada 2009 18:56

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

dotnetomaniak.pl

# re: NServiceBus @ 18 listopada 2009 18:56

Ja bym się tak nie cieszył z braku transakcji rozproszonych bo prawdopodobnie NServiceBus ich nie wyeliminuje... Wystarczy ze NServiceBus 'chodzi' na MSMQ, bazę danych aplikacji masz w SQL Server no a transakcja polega na aktualizacji bazy danych i wysłaniu paru komunikatów NServiceBusem - to już wystarczy żeby system użył transakcji rozproszonej. A to bardzo typowy przypadek. Możesz tego uniknąć tylko rezygnując z transakcyjności, ale to z kolei powoduje inne problemy.

rafal_g

# re: NServiceBus @ 18 listopada 2009 19:11

@Rafał

Transakcje rozproszone -- jak najbardziej, ale w granicach jednego serwisu/procesu (nazwij, jak wolisz). Generalnie, transakcja między MSMQ a bazą danych jest OK, dlatego, że całością zarządza jeden kawałek softu.

Transakcje rozproszone są wg mnie złe, kiedy dotyczą więcej niż jednej usługi/aplikacji.

Problem wydajnościowy związany z transakcjami rozproszonymi nie wynika z tego, że są wolne same z siebie (owszem, są _nieco_ wolniejsze niż transakcje natywne SQL lub MSMQ), ale z tego, że architektura, w której wiele usług/aplikacji partycypuje w jednej transakcji jest wrażliwa na awarie.

simon

# re: NServiceBus @ 18 listopada 2009 21:47

A dasz radę z tym tematem w pełni do połowy przyszłego tygodnia, bo muszę naskrobać projekcik i NBS pasuje jak ulał? ;)

dario-g

# re: NServiceBus @ 19 listopada 2009 06:57

@Dario

Do przyszłego tygodnia to chyba nie dam rady, ale w Sieci jest wiele materiałów. Jest grupa mejlingowa działająca dosyć prężnie -- raczej nie zostają pytania bez odpowiedzi.

Jeśli tylko Ci pasuje NSB, nie wahaj się. I polecam wersję 2.0. Jest w tym momencie beta 2, ale raczej stabilna, release już niedługo, a wiele rzeczy jest bardziej intuicyjnych niż w 1.9.

simon

Komentarze anonimowe wyłączone