Відповіді:
JMS (ActiveMQ - реалізація брокера JMS) може використовуватися як механізм, що дозволяє асинхронну обробку запитів. Ви можете зробити це через те, що запит потребує тривалого часу, або через те, що фактичний запит може зацікавити декілька сторін. Ще одна причина його використання - це дозволити декільком клієнтам (потенційно написаним різними мовами) отримати доступ до інформації через JMS. ActiveMQ - хороший приклад тому, що ви можете використовувати протокол STOMP, щоб дозволити клієнт C # / Java / Ruby.
Приклад справжнього світу - веб-додаток, який використовується для замовлення конкретного замовника. У рамках розміщення цього замовлення (та зберігання його в базі даних), можливо, ви захочете виконати ряд додаткових завдань:
Для цього ваш код програми опублікує повідомлення у черзі JMS, що містить ідентифікатор замовлення. Одна частина вашої програми, яка прослуховує чергу, може відповісти на подію, взявши orderId, переглянувши замовлення в базі даних, а потім розмістіть замовлення в іншій сторонній системі. Інша частина вашої заявки може нести відповідальність за прийняття замовлення і відправлення підтвердження електронною поштою замовнику.
Використовуйте їх весь час для асинхронної обробки тривалих операцій. Користувач Інтернету не захоче чекати більше 5 секунд на обробку запиту. Якщо у вас є такий, який працює довше, одна конструкція полягає в тому, щоб подати запит у чергу та негайно відправити назад URL-адресу, яку користувач може перевірити, щоб побачити, коли робота закінчена.
Опублікувати / підписатись - ще одна хороша методика для роз'єднання відправників від багатьох приймачів. Це гнучка архітектура, тому що абоненти можуть приїжджати та виходити за потребою.
У мене було так багато дивовижних застосувань для JMS:
Веб-чат спілкування для обслуговування клієнтів.
Налагодження входу в сервер. Усі сервери додатків транслювали повідомлення про налагодження на різних рівнях. Потім клієнт JMS може бути запущений для спостереження за повідомленнями про налагодження. Звичайно, я міг би скористатися чимось на зразок syslog , але це дало мені всілякі способи фільтрації результатів на основі контекстної інформації (еквівалент за іменем сервера додатків, викликом api, рівнем журналу, користувальницьким типом, типом повідомлення тощо). Я також розфарбував вихід.
Налагодження реєстрації у файлі. Як і вище, лише окремі фрагменти витягувались за допомогою фільтрів та записувались у файл для загального ведення журналу.
Сповіщення Знову ж, подібне налаштування до вищевказаного журналу, спостереження за конкретними помилками та попередження людей за допомогою різних засобів (електронна пошта, текстове повідомлення, чат, спливаюче вікно Growl ...)
Динамічне налаштування та управління кластерними програмами. Кожен сервер додатків транслюватиме повідомлення "Налаштувати мене", а потім демон конфігурації, який би відповідав повідомленням, що містить усі види інформації про конфігурацію. Пізніше, якщо всі сервери додатків потребували відразу змінити їх конфігурації, це можна зробити з демона конфігурації.
І звичайне - транзакції в черзі для затримки діяльності, такі як виставлення рахунків, обробка замовлень, надання, створення електронної пошти ...
Це чудово, де ви хочете гарантувати доставку повідомлень асинхронно.
Розподілені (а) синхронні обчислення.
Справжнім прикладом світу може слугувати система сповіщень на основі додатків, яка надсилає електронні листи зацікавленим особам у різні моменти під час використання додатків. Таким чином, додаток буде виконувати функцію Producer
створення Message
об'єкта, розміщення його на певному Queue
і просування вперед.
Був би набір Consumer
s, який підписався б на Queue
питання, який би подбав про обробку Message
відправлених через. Зауважте, що в ході цієї транзакції, Producer
s відключаються від логіки того, як дана Message
обробка буде оброблятися.
Рамки обміну повідомленнями (ActiveMQ і подібні) виступають основою для полегшення таких Message
транзакцій, надаючи MessageBroker
s.
Я використовував його для передачі торгів між днями між різними системами управління фондами. Якщо ви хочете дізнатися більше про те, що таке чудова технологія обміну повідомленнями, я можу досконало рекомендувати книгу " Шаблони інтеграції підприємств ". Існує кілька прикладів JMS для таких речей, як запит / відповідь та публікація / підписка.
Повідомлення - чудовий інструмент для інтеграції.
Ми використовуємо його для ініціювання асинхронної обробки, яку ми не хочемо переривати або конфліктувати з існуючою транзакцією.
Наприклад, скажімо, що у вас є дорога і дуже важлива логіка, як-от "купуйте речі", важливою частиною матеріалів для покупки буде "сповіщення про магазин". Ми робимо виклик сповіщення асинхронним, так що будь-яка логіка / обробка, що бере участь у виклику сповіщення, не блокує і не суперечить ресурсам з логікою придбання бізнесу. Кінцевий результат, покупка завершується, користувач задоволений, ми отримуємо наші гроші, і оскільки черга гарантована доставка, магазин отримує повідомлення, як тільки він відкриється, або як тільки в черзі з’явиться новий товар.
Я використовував його для свого академічного проекту, який був веб-сайтом роздрібної торгівлі, схожим на Amazon. JMS використовувався для обробки наступних функцій:
У нас було декілька також реалізованих віддалених клієнтів, підключених до основного Сервера. Якщо з'єднання доступне, вони використовують для доступу до основної бази даних або не використовують власну базу даних. Для обробки узгодженості даних ми впровадили механізм 2PC. Для цього ми використовували JMS для обміну повідомленнями між цими системами, тобто один, який виконує функцію координатора, який ініціює процес, надсилаючи повідомлення по черзі, а інші відповідатимуть відповідним чином, знову відсилаючи повідомлення в черзі. Як уже згадували інші, це було схоже на модель pub / sub.
Я бачив JMS, що використовується в різних комерційних та академічних проектах. JMS може легко увійти у ваше зображення, коли ви хочете мати повністю роз'єднані розподілені системи. Взагалі кажучи, коли вам потрібно надіслати запит з одного вузла, а хтось у вашій мережі береться за нього без / з наданням відправника будь-якої інформації про приймача.
У моєму випадку я використовував JMS для розробки проміжного програмного забезпечення, орієнтованого на повідомлення (МОМ) у своїй дипломній роботі, де конкретні типи об'єктно-орієнтованих об'єктів генеруються в одну сторону як ваш запит та компілюються та виконуються з іншого боку як відповідь. .
Верблюд Apache, який використовується разом з ActiveMQ, - це чудовий спосіб зробити схеми інтеграції підприємств
Ми використовуємо JMS для зв'язку з системами у величезній кількості віддалених сайтів через ненадійні мережі. Нещільне з'єднання в поєднанні з надійними повідомленнями створює стабільний ландшафт системи: кожне повідомлення буде надіслане, як тільки це технічно можливо, більші проблеми в мережі не матимуть впливу на весь ландшафт системи ...