Черга повідомлень проти веб-служб? [зачинено]

За яких умов ви б прихиляли додатки, які спілкуються через чергу повідомлень, а не через веб-сервіси (я маю на увазі XML або JSON або YAML або що-небудь понад HTTP тут, а не якийсь конкретний тип)?

Мені потрібно поговорити між двома програмами в локальній мережі. Один буде веб-додатком, і потрібно запитувати команди в іншому додатку (працює на іншому обладнанні). Запити - такі речі, як створення користувачів, переміщення файлів і створення каталогів. За яких умов я б віддав перевагу веб-сервісам XML (або прямому TCP чи чомусь) перед чергою повідомлень?

Веб-додаток - це Ruby on Rails, але я думаю, що питання ширше, ніж це.

Під час використання веб-сервісу у вас є клієнт і сервер:

1. Якщо сервер не працює, клієнт повинен взяти на себе відповідальність за усунення помилки.
2. Коли сервер знову працює, клієнт несе відповідальність за його повторне надсилання.
3. Якщо сервер дає відповідь на дзвінок, а клієнт не працює, операція втрачається.
4. У вас немає суперечок, тобто якщо мільйон клієнтів зателефонують на один сервер на одному сервері за другий, швидше за все, ваш сервер знизиться.
5. Ви можете очікувати негайної відповіді від сервера, але ви також можете обробляти асинхронні дзвінки.

Коли ви використовуєте чергу повідомлень, наприклад RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo, ви очікуєте різних та більш відхилених від помилок результатів:

1. Якщо сервер виходить з ладу, черга зберігає повідомлення (необов'язково, навіть якщо машина вимикається).
2. Коли сервер знову працює, він отримує очікуване повідомлення.
3. Якщо сервер дає відповідь на дзвінок, а клієнт не працює, якщо клієнт не підтвердив відповідь, повідомлення зберігається.
4. У вас є суперечки, ви можете вирішити, скільки запитів обробляє сервер (замість цього називайте його працівником).
5. Ви не очікуєте негайної синхронної відповіді, але ви можете реалізовувати / моделювати синхронні дзвінки.

Черги повідомлень мають набагато більше функцій, але це певне правило, щоб вирішити, чи хочете ви самі обробляти умови помилок або залишити їх у черзі повідомлень.

Нещодавно було проведено багато досліджень щодо того, як дзвінки REST HTTP могли замінити концепцію черги повідомлень.

Якщо ви введете поняття процесу та завдання як ресурсу, потреба в середньому шарі обміну повідомленнями починає випаровуватися.

Наприклад:

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

Завдання може мати кілька кроків для ініціалізації, і процес може повернути статус при опитуванні або POST до URL-адреси зворотного виклику, коли завершено.

Це мертве просто, і стає досить потужним, коли ви розумієте, що тепер можете підписатися на канал rss / atom усіх запущених процесів і завдань без середнього шару. Будь-яка система черги вимагає будь-якого веб-передового кінця, і ця концепція вбудована без іншого шару спеціального коду.

Ваші ресурси існують, поки ви не видалите їх, а це означає, що ви можете переглядати історичну інформацію задовго після завершення процесу та завдання.

Ви створили службове відкриття навіть для завдання, яке має кілька кроків, без зайвих складних протоколів.

GET /task/name
    - returns form with required fields

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

Вашим службовим відкриттям є форма HTML - універсальний і читаний людиною формат.

Весь потік може використовуватися програмно або людиною, використовуючи загальновизнані інструменти. Це керований клієнтом і, отже, RESTful. Кожен інструмент, створений для Інтернету, може керувати вашими бізнес-процесами. У вас все ще є альтернативні канали повідомлень шляхом POSTing асинхронно окремого масиву серверів журналів.

Коли ви подумаєте про це деякий час, ви сідаєте назад і починаєте розуміти, що REST може просто усунути потребу в черзі обміну повідомленнями та ESB взагалі.

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

Черги на повідомлення ідеально підходять для запитів, обробка яких може зайняти тривалий час. Запити в черзі і їх можна обробити в автономному режимі, не блокуючи клієнта. Якщо клієнту потрібно повідомити про завершення, ви можете надати спосіб клієнту періодично перевіряти стан запиту.

Черги повідомлень також дозволяють краще масштабуватись із часом. Це покращує вашу здатність обробляти спалах великої активності, оскільки фактична обробка може бути розподілена за часом.

Зауважте, що черги повідомлень та веб-сервіси є ортогональними поняттями, тобто вони не є взаємовиключними. Наприклад, у вас може бути веб-служба на основі XML, яка виконує функції інтерфейсу до черги повідомлень. Я думаю, що відмінністю, яку ви шукаєте, є Черги повідомлень проти запиту / відповіді, остання - коли запит обробляється синхронно.

Черги з повідомленнями є асинхронними і можуть повторно спробувати кілька разів, якщо доставка не завершиться. Скористайтеся чергою повідомлень, якщо запитувачу не потрібно чекати відповіді.

Фраза "веб-сервіси" змушує мене думати про синхронні дзвінки до розподіленого компонента через HTTP. Використовуйте веб-сервіси, якщо запитувачу потрібен відповідь.

Я думаю, загалом, ви хочете, щоб веб-сервіс для завдання блокування (це завдання потрібно виконати, перш ніж ми виконаємо більше коду), і черга повідомлень для неблокуючого завдання (може зайняти досить багато часу, але ми цього не потрібно чекати).