Matt Burton, jeden z deweloperów NServiceBus, zainspirował mnie wczoraj do napisania tej notki zadając pytanie, czy można określić NSB mianem application server. Matt miał problem prowadząc swoje szkolenie z NSB, ponieważ stwierdzenie, że NServiceBus to ESB nie trafiało do słuchaczy.

Nie wiem, jak Wam, ale mnie ESB kojarzy się od razu z wielkim i ciężkim kawałem infrastruktury, który jest centralnym punktem architektury SOA danej organizacji. Pisałem już nieco o tym tutaj, porównując wzorce Message Broker i Message Bus. NSB jest dokładnym przeciwieństwem ESB, jednak w praktyce służy do tego samego. To trochę mylące, więc spróbujmy znaleźć jakąś lepszą analogię.

Niestety stwierdzenie, że NServiceBus to szyna komunikatów (bez odwoływania się do magicznego skrótu ESB) zdaje się nie trafiać do ludzi. Dlaczego? Pewnie dlatego, że w coś takiego jak szyna ciężko sobie wyobrazić w oderwaniu od kontekstu konkretnego wdrożenia. Jeśli widzimy serwerownię z 10 serwerami, na każdym z nich inny system i wszystkie te systemy wykorzystują do komunikacji NSB — to tak, wtedy możemy sobie wyobrazić NServiceBus jako szynę. Ale patrząc w kontekście pojedynczego systemu? Czym jest NSB dla mojego systemu?

I tu dochodzimy do tego, co zaproponował Matt, czyli application server. Serwer aplikacyjny jest platformą, na której działa aplikacja. Musi ona być, oczywiście, napisana w pewien specyficzny sposób — zgodnie z założeniami twórców serwera. W zamian za dochowanie wierności tym założeniom, serwer aplikacyjny oferuje wiele udogodnień, takich jak:

  • wymuszenie spójności architektonicznej (poprzez nałożenie niezbędnych ograniczeń)
  • gotowy do użycia mechanizm komunikacji, pozwalający udostępnić funkcje systemu na zewnątrz
  • gotowe rozwiązania dla problemów związanych z aspektami niefunkcjonalnymi systemu: wydajnością, bezpieczeństwem itp.

Powyższa definicja jest oczywiście moją osobistą. Zgodnie z nią, serwerami aplikacyjnymi są np. (niespodzianka!) dowolny serwer aplikacyjny J2EE, tandem IIS/WCF oraz właśnie NSB.

Serwer J2EE służy do budowania aplikacji będącej kolekcją tzw. beanów. Na zewnątrz mogą być udostępniane session beans (komunikacja synchroniczna) oraz message-driven beans (komunikacja asynchroniczna – JMS).

IIS/WCF pozwala budować systemy jako kolekcję usług Web Service udostępnianych na zewnątrz dowolnym kanałem (WAS).

NServiceBus natomiast zakłada, że aplikacja jest zbiorem tzw. message handlerów — obiektów obsługujących rozmaite komunikaty. Obiekty te są bardzo podobne do message-driven beans, zapewne dlatego, że służą do tego samego celu — obsługi komunikatów pochodzących z kolejki.

To oczywiście bardzo duże uproszczenie. Każda z wymienionych trzech technologii posiada dużo więcej dodatkowych możliwości. Nie o możliwości tu jednak chodzi, ale o charakter, o model, którego dany serwer aplikacyjny używa do reprezentacji hostowanej aplikacji. Dlaczego model jest tak ważny? Spróbujcie hostować za pomocą WCF coś, co nie jest usługą Web Service, np. proces uruchamiany co 5 minut. Coś takiego nie ma reprezentacji w modelu WCF, trzeba więc zrobić jakieś obejścia tu i tam. Podobnie w NServiceBus, gdzie tego typu zadania można zrealizować wysyłając komunikat do tzw. timer service, ale rozwiązaniu takiemu daleko do elegancji. W takim wypadku być może powinniśmy użyć Quartz.NET, jako serwera aplikacji? No i mamy zadanie dla architekta…:-)

VN:F [1.8.7_1070]
Rating: 5.0/5 (2 votes cast)
Czym jest NServiceBus?5.052