Dzisiaj technicznie-architektonicznie. Dwudziesty drugi odcinek DevTalka pod znakiem WIADOMOŚCI i KOMUNIKACJI stoi. Reflektor w te mgliste pojęcia kieruje Szymon Pobiega: programista/architekt, blogger, prelegent. Pracuje w Particular Software, gdzie klepie NServiceBusa dla Udiego Dahana (pamiętacie DevTalk#14 – CQRS with Udi Dahan?). Zatem: zdecydowanie wie o czym mówi!
Z rozmowy dowiecie się czym tak naprawdę jest komunikacja i dlaczego warto sobie zawracać głowę jakimiś “wiadomościami” czy “kolejkami”. Dlaczego jest to lepsze niż RPC (Remote Procedure Calls). Jakie mamy systemy kolejek, czym się między sobą różnią, oraz… po co na kolejki nakładać jeszcze service bus, czyli szynę wiadomości?
Enjoy!
Montaż odcinka: Krzysztof Śmigiel.Ważne adresy:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Linki
- blog Szymona (http://simon-says-architecture.com)
- prezentacja Szymona “Wiadomości są wszędzie” (http://kenis.pl/wiadomosci-sa-wszedzie,10428)
- MSMQ (https://msdn.microsoft.com/en-us/library/ms711472(v=vs.85).aspx)
- RabbitMQ (https://www.rabbitmq.com)
- ZeroMQ (http://zeromq.org)
- NServiceBus (http://particular.net/nservicebus)
- MassTransit (http://masstransit-project.com)
- książka “Enterprise Integration Patterns” (http://www.amazon.com/dp/0321200683)
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
22 – O wiadomościach z Szymonem Pobiegą | DevTalk
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl
1) W przypadku RabbitMQ jestem przekonany, że centralizacja nie jest aż tak wielką wadą. Zauważmy, że podczas przesyłania komunikatu do serwera, jeżeli wystąpi błąd, to program działający na kliencie natychmiast dostaje informację o nim (np. błąd połączenia). Taka sytuacja może wystąpić również dla usługi kolejkowania działającej na lokalnej maszynie, więc i tak klient musi obsłużyć te błędy.
2) W przypadku polecenia które kasuje rekord z bazy danych i zwraca jego zawartość, obawiam się że użycie go do przetwarzania komunikatów może powodować problem utraty danych. Po usunięciu z bazy komunikatu, “żyje” on w pamięci operacyjnej. Jeżeli padnie zasilanie, między operacją skasuj-odczytaj a dostarczeniem komunikatu do odbiorcy, to komunikat zostanie bezpowrotnie utracony. Potrzebny tu jest jakiś protokół, przykładowo dopiero po portwierdzeniu odebrania komunikatu przez odbiorcę, rekord powinien zostać usunięty z bazy.
Updated: DevTalk – Programistyczny głos w Twoim domu
http://groopmark.com/link/details/181/devtalk-programistyczny-glos-w-twoim-domu?cid=11
Ciekawy odcinek.
Po przesluchaniu calosc, mysle ze zabraklo przykladu bardziej przyziemnego jak wykorzystac kolejki. Np. prosty program do wysylania duzej ilosci maili moglby byc takim przykladem. Kilka programow wysylka do systemu mailowego prosbe o wyslanie maila a system mailowy kolejkuje sobie to lokalnie i wysyla swoim tempem.
Warto jeszcze wspomniec, ze na Windows mozna uzyc ESB Toolkit jako szyny danych, ktory to jest dodatkiem do BizTalka
U nas w bardzo dużym projekcie korzystamy z NServiceBus’a opierającego się o bazę MSSQL. Działa to bardzo dobrze i daje dużą swobodę manipulowania message’mi. Poza tym łatwo pisać własne narzędzia operujące na wiadomościach NSB. Te domyślne nie do końca spełniały nasze oczekiwania, więc stworzyliśmy trochę swoich.
Oczywiście nie jest to system, w którym jak message przetworzy się sekunde później to coś się wielkiego wydarzy, więc przepustowość bazy nam w zupełności wystarcza.
Nawiązując do tematu wymiany komunikatów poprzez bazę danych to czy koś używał do tego SQL Server Service Broker?
Do “dnf “: używam Service Brokera. działa na produkcji, ale teraz wiem, że gdybym miał wybór, to bym nie szedł tą drogą. Kosztowało to nas dużo pracy, SB jest chyba napisany przez adminów db dla adminów db.
@Piotr S
1. Przerwaga MSMQ nad Rabbit w kontekście dostępności polega na tym, że MSMQ, jako usługa lokalna, ma o wiele większe szanse działania. Odapada cały zestaw problemów związanych z niedziałającą siecią. Oczywiście Rabbit ma dużo zalet w obszarach, gdzie MSMQ ma tyły. Choose your poison, jak to mawiają
2. Destrukcyjny odczyt wykonywany jest w ramach transakcji, która jest commit-owana po przetworzeniu wiadomości, więc nie istnieje niebezpieczeństwo utraty danych w przypadku wyjęcia wtyczki
[…] devtalk – programistyczny głos w twoim domu programowanie […]
[…] O wiadomościach z Szymonem Pobiegą (http://devtalk.pl/2015/09/22-o-wiadomosciach-z-szymonem-pobiega/) […]
[…] O wiadomościach z Szymonem Pobiegą (http://devtalk.pl/2015/09/22-o-wiadomosciach-z-szymonem-pobiega/) […]