Kolejka wiadomości a usługi sieciowe? [Zamknięte]

Pod jakimi warunkami preferowane byłyby aplikacje rozmawiające za pośrednictwem kolejki wiadomości zamiast usług internetowych (mam na myśli tylko XML, JSON lub YAML lub cokolwiek innego przez HTTP, a nie żaden konkretny typ)?

Muszę rozmawiać między dwiema aplikacjami w sieci lokalnej. Jedna będzie aplikacją internetową i będzie wymagała poleceń w innej aplikacji (działającej na innym sprzęcie). Żądania obejmują tworzenie użytkowników, przenoszenie plików i tworzenie katalogów. W jakich warunkach wolałbym XML Web Services (lub zwykły TCP lub coś takiego) niż używanie kolejki komunikatów?

Aplikacja internetowa to Ruby on Rails, ale myślę, że pytanie jest szersze.

Kiedy korzystasz z usługi internetowej, masz klienta i serwer:

1. Jeśli serwer ulegnie awarii, klient musi wziąć odpowiedzialność za obsługę błędu.
2. Gdy serwer ponownie działa, klient jest odpowiedzialny za jego ponowne wysłanie.
3. Jeśli serwer udzieli odpowiedzi na wezwanie, a klient się nie powiedzie, operacja zostanie utracona.
4. Nie masz sporu, to znaczy: jeśli milion klientów wywoła usługę internetową na jednym serwerze w ciągu sekundy, najprawdopodobniej twój serwer przestanie działać.
5. Możesz oczekiwać natychmiastowej odpowiedzi od serwera, ale możesz również obsługiwać połączenia asynchroniczne.

Korzystając z kolejki komunikatów, takiej jak RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo, oczekujesz różnych i bardziej odpornych na błędy wyników:

1. Jeśli serwer ulegnie awarii, kolejka utrzymuje komunikat (opcjonalnie, nawet jeśli urządzenie zostanie zamknięte).
2. Gdy serwer znów działa, odbiera oczekującą wiadomość.
3. Jeśli serwer udzieli odpowiedzi na połączenie, a klient nie powiedzie się, jeśli klient nie potwierdzi odpowiedzi, komunikat będzie trwał.
4. Masz spór, możesz zdecydować, ile żądań jest obsługiwanych przez serwer (zamiast tego nazywaj go pracownikiem).
5. Nie oczekujesz natychmiastowej odpowiedzi synchronicznej, ale możesz implementować / symulować połączenia synchroniczne.

Kolejki wiadomości mają o wiele więcej funkcji, ale jest to pewna ogólna reguła, aby zdecydować, czy chcesz samodzielnie poradzić sobie z błędami, czy pozostawić je w kolejce wiadomości.

Niedawno przeprowadzono wiele badań nad tym, w jaki sposób wywołania REST HTTP mogłyby zastąpić koncepcję kolejki komunikatów.

Jeśli jako zasób wprowadzisz koncepcję procesu i zadania, potrzeba środkowej warstwy wiadomości zacznie wyparowywać.

Dawny:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Zadanie może składać się z wielu etapów inicjowania, a proces może zwrócić status po odpytywaniu lub POST na adres URL wywołania zwrotnego po zakończeniu.

Jest to bardzo proste i staje się dość potężne, gdy zdasz sobie sprawę, że możesz teraz subskrybować kanał rss / atom wszystkich działających procesów i zadań bez żadnej warstwy środkowej. Każdy system kolejkowania i tak będzie wymagał jakiegoś interfejsu WWW, a ta koncepcja ma go wbudowaną bez kolejnej warstwy niestandardowego kodu.

Twoje zasoby istnieją, dopóki ich nie usuniesz, co oznacza, że ​​możesz wyświetlić informacje historyczne długo po zakończeniu procesu i zadania.

Wbudowano funkcję wykrywania usług, nawet dla zadania składającego się z wielu kroków, bez żadnych dodatkowych skomplikowanych protokołów.

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

Twoje odkrycie usługi jest formą HTML - uniwersalnym i czytelnym dla człowieka formatem.

Cały przepływ może być używany programowo lub przez człowieka, przy użyciu powszechnie akceptowanych narzędzi. Jest sterowany przez klienta, a zatem RESTful. Każde narzędzie utworzone dla Internetu może sterować procesami biznesowymi. Nadal masz alternatywne kanały komunikatów przez asynchroniczne testowanie POST do osobnej tablicy serwerów dziennika.

Po zastanowieniu się przez chwilę usiądź i zaczniesz zdawać sobie sprawę, że REST może po prostu wyeliminować potrzebę kolejki przesyłania wiadomości i ESB.

http://www.infoq.com/presentations/BPM-with-REST

Kolejki wiadomości są idealne dla żądań, których przetworzenie może zająć dużo czasu. Żądania są umieszczane w kolejce i mogą być przetwarzane w trybie offline bez blokowania klienta. Jeśli klient musi zostać powiadomiony o zakończeniu, możesz zapewnić mu okresowe sprawdzanie statusu żądania.

Kolejki wiadomości pozwalają także lepiej skalować w czasie. Poprawia to zdolność do radzenia sobie z gwałtownymi ruchami, ponieważ faktyczne przetwarzanie może być rozłożone w czasie.

Zauważ, że kolejki wiadomości i usługi sieciowe są pojęciami ortogonalnymi, tzn. Nie wykluczają się wzajemnie. Np. Możesz mieć serwis internetowy oparty na XML, który działa jako interfejs do kolejki komunikatów. Myślę, że rozróżnienie, którego szukasz, to kolejki wiadomości w porównaniu z żądaniem / odpowiedzią, ta ostatnia ma miejsce, gdy żądanie jest przetwarzane synchronicznie.

Kolejki komunikatów są asynchroniczne i mogą ponawiać kilka razy, jeśli dostarczanie się nie powiedzie. Użyj kolejki komunikatów, jeśli requester nie musi czekać na odpowiedź.

Wyrażenie „usługi sieciowe” przywodzi mi na myśl synchroniczne wywołania rozproszonego komponentu przez HTTP. Skorzystaj z usług internetowych, jeśli requester potrzebuje odpowiedzi z powrotem.

Myślę, że ogólnie rzecz biorąc, potrzebujesz usługi sieci Web dla zadania blokującego (zadania te muszą zostać zakończone, zanim wykonamy więcej kodu) oraz kolejki komunikatów dla zadania nieblokującego (może to zająć trochę czasu, ale nie trzeba na to czekać).