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.
