Niniejsza notka została zamówiona przez Procenta za pomocą komentarza do poprzedniej notki. Chcesz zamówić notkę? Zostaw komentarz:)

Jak już napisałem, NServiceBus pozwala budować szyny informacyjne. Jest jednak (w przeciwieństwie do ciężkich rozwiązań ESB) zorientowany na wykorzystanie w pojedynczym systemie. Czym jest system, to już każdy może sobie odpowiedzieć. Może to być jedna mała aplikacja, może być także cały zestaw aplikacji CRM, ERP i innych stanowiących kompleksowy system informatyczny obsługujący np. internetowy sklep z warzywami.

Nie zrozumcie mnie źle, NServiceBus może być użyty do komunikacji z innym systemem nie wykorzystującym NSB, jednak jest to przypadek szczególny. Zdecydowanie lepiej biblioteka ta sprawdza się jako wewnętrzny mechanizm komunikacji dla luźno powiązanego systemu. W takim kontekście NSB może nam zaoferować możliwość osiągnięcia:

  • wysokiej przepustowości
  • wysokiej dostępności
  • lepszego modelowania procesów biznesowych

Jak to możliwe? Zaraz opowiem. Dla niecierpliwych tylko krótka informacja: wszystko to dzięki asynchronicznej komunikacji.

Wysoka przepustowość

Powiedzmy, że system składa się z trzech modułów A, B i C. Tylko moduł A udostępniany jest na zewnątrz, ale moduł ten musi wywołać usługę modułu B, aby wykonać swoją pracę. Moduł B wewnętrznie korzysta zaś z C — ot taki łańcuszek szczęścia. Możemy go zaimplementować dosyć za pomocą usług Web Service korzystając ze wsparcia WCF dla transakcji rozproszonych. Ma to jednak wiele negatywnych konsekwencji, o czym miałem okazję już mówić przy okazji spotkania KGD.NET. Najważniejszymi problemami, z punktu widzenia przepustowości, są:
  • blokowanie zasobów bazodanowych jednocześnie w 3 bazach danych przez transakcje rozproszoną
  • blokowanie wątków oczekujących na odpowiedź Web Service z usług B oraz C

Mając do dyspozycji narzędzia oferowane przez NServiceBus możemy tak zaprojektować system, że moduły A, B i C przesyłają sobie komunikaty zlecające zadania asynchronicznie. Jeśli moduł A do przetworzenia komunikatu żądania potrzebuje informacji X z modułu B, a moduł B produkuje informację X jako wynik swojego przetwarzania, to zwykły schemat request-response:

można zastąpić następującym:

Dzięki temu nikt na nikogo nie czeka. Zarówno zadania (strzałki czerwone), jak i stan (strzałki niebieskie) płyną od modułu do modułu. Jest to analogia taśmy produkcyjnej, podczas gdy rozwiązanie synchroniczne bardziej przypomina pracę rzemieślnika posiadającego dwóch pomocników.

Wysoka dostępność

Popatrzcie jeszcze raz na diagramy sekwencji dla przepustowości. Co się stanie, jeśli moduł C na jakiś czas zostanie wyłączony? Żadne żądanie klienta nie będzie mogło być obsłużone. Pozostałe dwa moduły są kompletnie bezradne i uzależnione od działania modułu C.

A teraz przypadek z NSB. Ponieważ informacje X i Y są przesyłane asynchronicznie do modułów ich potrzebujących i są tam przechowywane lokalnie, brak dostępności modułu C oznacza, że dane będą przez jakiś czas nieco nieaktualne. Taki stan rzeczy jest prawdopodobnie całkowicie akceptowalny. Kiedy tylko moduł C zostanie uruchomiony ponownie, przetworzy zaległe żądania i opublikuje nowe wartości danej Y. Klient niczego nie zauważy.

Lepsze modelowanie procesów biznesowych

Często zdarza się sytuacja, że w systemie wykonujemy na tych samych obiektach kolejno kilka zadań: A, B, C. Pomyślne zakończenie zadania A umożliwia wykonanie B i tak dalej. Często realizuje się to za pomocą kilku wątków, które okresowo odpytują bazę danych czy czasem nie istnieją jakieś obiekty w stanie do wykonania zadania X i jeśli istnieją, wykonują zadanie. Dla programistów takie podejście jest oczywiste. Dla ludzi biznesu nie koniecznie. W ich języku wymaganie to można zapisać jako: wykonanie zadania A powoduje rozpoczęcie zadania B. Stosując wspomniane rozwiązanie gubimy po drodze ten związek przyczynowo-skutkowy.

Po co nam tutaj NServiceBus? Otóż zamiast wyszukiwać obiekty w określonym “stanie” można, po pomyślnym wykonaniu zadania publikować na szynie NSB zdarzenie zadanie X wykonane pomyślnie. Co z tego, że jedynym subskrybentem zdarzenia będzie ten sam system, który je publikuje? W niczym to nie przeszkadza, a za to sprawia, że kod nareszcie przypomina biznes, który wspiera i automatyzuje.

VN:F [1.8.7_1070]
Rating: 0.0/5 (0 votes cast)