Jakarta Messaging - Jakarta Messaging

В Jakarta Messaging API (ранее Служба сообщений Java или же JMS API) является Ява интерфейс прикладного программирования (API) для промежуточное ПО, ориентированное на сообщения. Он предоставляет общие модели обмена сообщениями, способные обрабатывать проблема производитель – потребитель, который можно использовать для облегчения отправки и получения сообщений между программные системы.[1] Jakarta Messaging является частью Джакарта EE и изначально определялся спецификацией, разработанной в Sun Microsystems, прежде чем руководствоваться Процесс сообщества Java.[2]

Общее представление об обмене сообщениями

Обмен сообщениями - это форма слабо связанный распределенная связь, где в этом контексте термин «коммуникация» можно понимать как обмен сообщениями между программными компонентами. Технологии, ориентированные на сообщения, пытаются расслабить тесно связаны общение (например, TCP сеть Розетки, CORBA или же RMI ) путем введения промежуточного компонента. Такой подход позволяет программным компонентам косвенно взаимодействовать друг с другом. Преимущества этого заключаются в том, что отправителям сообщений не нужно точно знать своих получателей.

К преимуществам обмена сообщениями относится возможность интеграции разнородных платформ, уменьшение количества узких мест в системе, повышение масштабируемости и более быстрое реагирование на изменения.[3]

История версий

  • JMS 1.0[4]
  • JMS 1.0.1 (5 октября 1998 г.)[4]
  • JMS 1.0.1a (30 октября 1998 г.)[5][6]
  • JMS 1.0.2 (17 декабря 1999 г.)[7]
  • JMS 1.0.2a (23 декабря 1999 г.)[8]
  • JMS 1.0.2b (27 августа 2001 г.)[9]
  • JMS 1.1 (12 апреля 2002 г.)[10]
  • JMS 2.0 (21 мая 2013 г.)[11][12]
  • JMS 2.0a (16 марта 2015 г.)[13][14]

JMS 2.0 в настоящее время поддерживается Процесс сообщества Java в качестве JSR 343.[15]

JMS 3.0 находится на ранней стадии разработки как часть Jakarta EE.[16]

Элементы

Ниже приведены элементы JMS:[17]

JMS провайдер
Реализация интерфейса JMS для промежуточного программного обеспечения, ориентированного на сообщения (MOM). Провайдеры реализуются либо как реализация Java JMS, либо как адаптер для MOM, отличного от Java.
Клиент JMS
Приложение или процесс, который создает и / или принимает сообщения.
Производитель / издатель JMS
Клиент JMS, который создает и отправляет сообщения.
Потребитель / подписчик JMS
Клиент JMS, получающий сообщения.
Сообщение JMS
Объект, содержащий данные, передаваемые между клиентами JMS.
Очередь JMS
Промежуточная область, содержащая сообщения, которые были отправлены и ожидают чтения (только одним потребителем). Как следует из очереди имен, сообщения доставляются в порядке отправки. Очередь JMS гарантирует, что каждое сообщение обрабатывается только один раз.
Тема JMS
Механизм распространения для публикации сообщений, которые доставляются нескольким подписчикам.

Модели

JMS API поддерживает две различные модели:

  • Точка-точка
  • Опубликовать и подписаться

Двухточечная модель

Под точка-точка В системе обмена сообщениями сообщения направляются отдельным потребителям, которые поддерживают очереди входящих сообщений. Этот тип обмена сообщениями основан на концепции очереди сообщений, отправители и получатели. Каждое сообщение направляется в определенную очередь, и принимающие клиенты извлекают сообщения из очередей, установленных для хранения своих сообщений. Хотя любое количество производителей может отправлять сообщения в очередь, каждое сообщение гарантированно будет доставлено и использовано одним потребителем. В очередях сохраняются все отправленные им сообщения до тех пор, пока сообщения не будут использованы или пока срок их действия не истечет. Если для получения сообщений не зарегистрированы потребители, очередь удерживает их до тех пор, пока потребитель не зарегистрируется для их использования.

Модель публикации и подписки

В публикация и подписка Модель поддерживает публикацию сообщений в определенной «теме» сообщения. Подписчики может проявить интерес к получению сообщений опубликовано по определенной теме сообщения. В этой модели ни издатель, ни подписчик не знают друг о друге. Хорошая аналогия - анонимная доска объявлений.

  • Сообщение получат ноль или более потребителей.
  • Между издателями и подписчиками существует временная зависимость. Издатель должен создать тему сообщения, чтобы клиенты могли подписаться. Подписчик должен оставаться активным для получения сообщений, если он не установил длительную подписку. В этом случае сообщения, опубликованные, пока подписчик не подключен, будут перераспределяться при повторном подключении.

JMS позволяет отделить приложение от транспортный уровень предоставления данных. Та же Ява классы может использоваться для связи с различными поставщиками JMS с помощью Интерфейс именования и каталогов Java (JNDI) информация для желаемого провайдера. Сначала классы используют фабрика подключений для подключения к очереди или теме, а затем используйте заполнить и отправить или опубликовать сообщения. На принимающей стороне клиенты затем получают сообщения или подписываются на них.

Схема URI

RFC 6167 определяет jms: Схема URI для службы сообщений Java.

Реализации провайдера

Чтобы использовать JMS, необходимо иметь поставщика JMS, который может управлять сеансами, очередями и темами. Начиная с Java EE версии 1.4, поставщик JMS должен содержаться в все Серверы приложений Java EE. Это может быть реализовано с помощью управления потоком сообщений Архитектура соединителя Java EE, который впервые был доступен в этой версии.

Ниже приводится список распространенных поставщиков JMS:

Смотрите также

Рекомендации

  1. ^ Карри, Эдвард. 2004 г. «По промежуточного слоя, ориентированного на сообщения». В промежуточном программном обеспечении для коммуникаций, изд. Кусай Х. Махмуд, 1-28. Чичестер, Англия: Джон Уайли и сыновья. Дои:10.1002 / 0470862084.ch1. ISBN  978-0-470-86206-3
  2. ^ "JSR 914: API службы сообщений Java (JMS)". Программа процесса сообщества Java. Получено 31 июля, 2018.
  3. ^ Ричардс и др., Страницы 3–5.
  4. ^ а б «Служба сообщений Java» (PDF). Sun Microsystems. 5 октября 1998 г. В архиве (PDF) из оригинала 1999-02-24. Получено 31 июля, 2018.
  5. ^ «Документация службы сообщений Java». Sun Microsystems. 30 октября 1998 г. В архиве из оригинала 1999-02-24. Получено 31 июля, 2018.
  6. ^ "Источник службы сообщений Java - версия 1.0.1a". Sun Microsystems. 29 октября 1998 г. Архивировано с оригинал (ZIP) 16 августа 2000 г.. Получено 31 июля, 2018.
  7. ^ «Служба сообщений Java» (PDF). Sun Microsystems (опубликовано 17 декабря 1999 г.). 9 ноября 1999 г. В архиве (PDF) из оригинала 23.08.2000. Получено 31 июля, 2018.
  8. ^ «Документация службы сообщений Java». Sun Microsystems. 23 декабря 1999 г. В архиве из оригинала от 29.02.2000. Получено 31 июля, 2018.
  9. ^ «Служба сообщений Java» (PDF). Sun Microsystems. 27 августа 2001 г.. Получено 31 июля, 2018.
  10. ^ «Служба сообщений Java» (PDF). Sun Microsystems. 12 апреля 2002 г.. Получено 31 июля, 2018.
  11. ^ «Служба сообщений Java» (PDF). Oracle. 20 марта 2013 г.. Получено 31 июля, 2018.
  12. ^ «Финальный выпуск JMS 2.0». Спецификация службы сообщений Java. 9 июня 2017 г.. Получено 31 июля, 2018.
  13. ^ «Служба сообщений Java» (PDF). Oracle. 10 марта 2015 г.. Получено 31 июля, 2018.
  14. ^ «Выпуск исправлений JMS 2.0 (Rev a)». Спецификация службы сообщений Java. 5 июля 2017 г.. Получено 31 июля, 2018.
  15. ^ "JSR 343: Служба сообщений Java 2.0". Программа процесса сообщества Java. Получено 31 июля, 2018.
  16. ^ Монсон-Хефель, Ричард (6 декабря 2018 г.). «JMS 3.0: примите участие!». Tomitribe. Получено 17 июля, 2020.
  17. ^ Служба сообщений Java (JMS)
  18. ^ «Apache Qpid ™: обмен сообщениями AMQP с открытым исходным кодом».
  19. ^ Уоллис, Грэм. «Выбор системы обмена сообщениями: WebSphere MQ и шина интеграции служб WebSphere Application Server». IBM developerWorks.

дальнейшее чтение

  • Ричардс, Марк; Ричард Монсон-Хефель; Дэвид А. Чаппелл (2009). Служба сообщений Java, второе издание. О'Рейли. ISBN  978-0-596-52204-9.

внешняя ссылка