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