Kolejka komunikatów a Usługi internetowe? [zamknięte]

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

Jeśli wprowadzasz pojęcie procesu i zadania jako zasobu, potrzeba średniej warstwy wiadomości zaczyna wyparowywać.

Ex:

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 mieć wiele kroków inicjalizacji, a proces może zwracać status, gdy zostanie zapytany lub wysłany do adresu zwrotnego po zakończeniu.

Twoje zasoby istnieją do momentu ich usunięcia, co oznacza, że możesz przeglądać informacje historyczne długo po zakończeniu procesu i zadania.

Wbudowano funkcję service discovery, nawet dla zadania, które ma wiele kroki, bez dodatkowych skomplikowanych protokołów.

GET /task/name
    - returns form with required fields

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

Your service discovery to formularz HTML-uniwersalny i czytelny dla człowieka format.

Cały przepływ może być używany programowo lub przez człowieka, przy użyciu powszechnie akceptowanych narzędzi. To klient napędzany, a więc spokojny. Każde narzędzie stworzone dla sieci Web może napędzać twoje procesy biznesowe. Nadal masz alternatywne kanały wiadomości, wysyłając asynchronicznie do oddzielnej tablicy serwerów dziennika.

Po tobie zastanów się przez chwilę, usiądź wygodnie i zacznij zdawać sobie sprawę, że odpoczynek może całkowicie wyeliminować potrzebę kolejki wiadomości i ESB.

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

Kolejki komunikatów są idealne dla żądań, które mogą zająć dużo czasu. Żądania są kolejkowane i mogą być przetwarzane w trybie offline bez blokowania klienta. Jeśli klient musi zostać powiadomiony o zakończeniu, możesz zapewnić klientowi sposób okresowego sprawdzania statusu żądania.

Kolejki komunikatów umożliwiają również lepsze skalowanie w czasie. Poprawia zdolność radzenia sobie z wybuchami ciężkiej aktywności, ponieważ rzeczywiste przetwarzanie może być rozłożone na czas.

Zauważ, że kolejki komunikatów i usługi internetowe są pojęciami ortogonalnymi, tzn. nie wykluczają się wzajemnie. Na przykład możesz mieć usługę internetową opartą na XML, która 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 jest wtedy, gdy żądanie jest przetwarzane synchronicznie.

Kolejki wiadomości są asynchroniczne i mogą ponowić kilka razy, jeśli dostawa nie powiedzie się. Użyj kolejki komunikatów, jeśli żądający nie musi czekać na odpowiedź.

Fraza "web services" sprawia, że myślę o synchronicznych wywołaniach do rozproszonego komponentu przez HTTP. Użyj usług internetowych, jeśli żądający potrzebuje odpowiedzi.

Myślę, że ogólnie rzecz biorąc, przydałaby się Usługa sieciowa dla zadania blokującego (zadanie to musi zostać wykonane zanim wykonamy więcej kodu), oraz kolejka komunikatów dla zadania nie blokującego(może to zająć trochę czasu, ale nie musimy na to czekać).