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

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
NServiceBus w kontekście zwykłej aplikacji - notka sponsorowana
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.

Opublikowane 21 listopada 2009 12:30 przez simon

Filed under:

Komentarze:

# re: NServiceBus w kontekście zwykłej aplikacji - notka sponsorowana @ 21 listopada 2009 17:44

To się nazywa obsługa - dzięki:).

W takim razie zdecydowanie przyjrzę się NSB nieco bliżej.

Procent

# Re: NHibernateStarter... @ 1 grudnia 2009 09:05

Czyli nawiązanie do świetnego posta Procent-a na temat jego sposobu budowy aplikacji. Poniżej zamieszczam

Simon says...

# Re: NHibernateStarter... @ 1 grudnia 2009 09:13

Czyli nawiązanie do świetnego posta Procent-a na temat jego sposobu budowy aplikacji. Poniżej zamieszczam

Simon says...

# re: NServiceBus w kontekście zwykłej aplikacji - notka sponsorowana @ 8 grudnia 2009 10:41

Witam,

Możesz podać jakieś przykłady komunikacji asynchronicznej w mniejszych systemach (np. w opisanym crm warzywniaka). Trudno mi znaleźć jakikolwiek przykład w mniejszych systemach. Nawet proste zamówienie wymaga weryfikacji natychmiast (braki stanow magazynowych itd).  

k1

# re: NServiceBus w kontekście zwykłej aplikacji - notka sponsorowana @ 8 grudnia 2009 11:11

Natychmiast oznacza, ze klient od razu musi widziec wynik

k1

# re: NServiceBus w kontekście zwykłej aplikacji - notka sponsorowana @ 9 grudnia 2009 09:55

W wypadku kompleksowego systemu dla warzywniaka możemy np. mieć następujące osobne aplikacje:

* Sprzedaż (front-end)

* Marketing (zarządzanie cenami)

* Magazyn

* Obsługa klienta (CRM) (upusty, promocje itp.)

Aplikacje te mogą komunikować się asynchronicznie za pomocą schematu pub/sub, np. w sposób następujący:

* Magazyn publikuje informacje o zmianie stanu, aby front-end mógł zawsze wyświetlać klientowi, czy i ile produktu jest dostępne

* Sprzedaż publikuje informacje o zmianie cen, aby front-end mógł wyświetlić klientowi cenę

* CRM publikuje informacje typu "klient otrzymał upust", aby usługa billingu mogła ten upust uwzględnić

Wiem, że to ekstremalny przykład i dla warzywniaka wszystkie te usługi mogą być częściami jednej aplikacji i niczego nie trzeba rozpraszać, jednak w przypadku "enterprise" takie rozproszenie z wykorzystaniem asynchronicznej komunikacji pub/sub jest możliwe.

simon

# re: NServiceBus w kontekście zwykłej aplikacji - notka sponsorowana @ 9 grudnia 2009 11:00

Zastanawia mnie tylko jedno / jak powiadomic klienta o nieudanej operacji, w koncu w momencie zmiany stanu produktu, inna koncowka moze tez go zmienic i ostatecznie w momencie aktualizacji repozytorium (DB) moze dojsc do bledu.  

k1

# re: NServiceBus w kontekście zwykłej aplikacji - notka sponsorowana @ 10 grudnia 2009 08:28

Jeśli dobrze rozumiem chodzi Ci o przykład, w którym stan magazynu wynosi 1, a dwóch klientów prawie równocześnie wysyła zamówienie. W takim wypadku problem zostanie wykryty dopiero na etapie realizacji zamówienia (brak w magazynie) i powinien być rozwiązany na poziomie biznesowym, np.:

* sprawdzenie, czy nie da się danego towaru sprowadzić ekspresowo

* powiadomienie klienta o problemie (np. telefonicznie) i zapytanie, czy nie woli poczekać, czy też zwrot pieniędzy

* anulowanie innego zamówienia, które jeszcze nie zostało wysłane (ale zostało zaakceptowane!), którego zamawiający ma mniejszy priorytet (np. nie jest klientem strategicznym)

simon

# re: NServiceBus w kontekście zwykłej aplikacji - notka sponsorowana @ 10 grudnia 2009 14:00

OK dzieki za wyjesnienie / wg mnie nservice bus to jednak rozwiazanie do wiekszych systemow. Przy malych moze sprawdzi sie przy wysylaniu maila lub przy zlecaniu zadan co do ktorych mamy pewnosc ze problemy z ich wykonananiem moga lezec tylko po stronie aplikacji (sa niezalezne od decyzji klienta, ktora moglby podjac w momencie wyslania zadania).

Kontynuuj serie .. samo rozwiazanie jest swietne.

k1

# re: NServiceBus w kontekście zwykłej aplikacji - notka sponsorowana @ 11 grudnia 2009 09:10

Masz racje, prawdopodobnie nie zastosowałbym NSB w systemie o budżecie 2 osobotygodni:) Na pewno zanim zastosujemy NSB należy się upewnić, że "zwykłe" sposoby rozwiązywania problemów się w danym wypadku nie sprawdzają.

Jeśli chodzi o NSB w _naprawdę_ małych systemach, to przychodzi mi do głowy zastosowanie w wysokowydajnych systemach transakcyjnych zbudowanych w modelu CQRS, gdzie NSB mogłoby być użyte do komunikacji między podsystemem realizacji komend, a podsystemem zapytań.

simon

Komentarze anonimowe wyłączone