Введение

Интерфейс программирования приложений Java (API) Jakarta Messaging (ранее Java Message Service или JMS API) — это интерфейс программирования приложений Java (API) для промежуточного программного обеспечения, ориентированного на обмен сообщениями. Он предоставляет универсальные модели обмена сообщениями, способные решать проблему «производитель-потребитель», которые можно использовать для упрощения отправки и получения сообщений между программными системами. Jakarta Messaging является частью Jakarta EE и изначально был определен спецификацией, разработанной в Sun Microsystems, а затем развивался под руководством Java Community Process.

Общая идея обмена сообщениями

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

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

JMS 1.0
JMS 1.0.1a (30 октября 1998 года)
JMS 1.0.2 (17 декабря 1999 года)
JMS 1.0.2a (23 декабря 1999 года)
JMS 1.0.2b (27 августа 2001 года)
JMS 1.1 (12 апреля 2002 года)
JMS 2.0 (21 мая 2013 года)
JMS 2.0a (16 марта 2015 года)

В настоящее время JMS 2.0 поддерживается в рамках Java Community Process как JSR 343. Разработка JMS 3.0 находится на начальной стадии в рамках Jakarta EE.

Модель "точка к точке"

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

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

Модель "издатель-подписчик" поддерживает публикацию сообщений в определенную "тему" сообщений. Подписчики могут выразить заинтересованность в получении сообщений, опубликованных по определенной теме. В этой модели издатель и подписчик не знают друг о друге. Хорошая аналогия – анонимная доска объявлений. Сообщение может получить ноль или более потребителей. Существует временная зависимость между издателями и подписчиками. Издатель должен создать тему сообщений, чтобы клиенты могли на нее подписаться. Подписчик должен оставаться постоянно активным для получения сообщений, если только не установлена постоянная подписка. В этом случае сообщения, опубликованные во время отсутствия подключения подписчика, будут повторно доставлены при его повторном подключении. JMS обеспечивает отделение приложения от транспортного уровня передачи данных. Одни и те же Java-классы могут использоваться для взаимодействия с различными провайдерами JMS, используя информацию Java Naming and Directory Interface (JNDI) для нужного провайдера. Классы сначала используют фабрику соединений для подключения к очереди или теме, а затем заполняют и отправляют или публикуют сообщения. На стороне получателя клиенты получают или подписываются на сообщения.

Схема URI

RFC 6167 определяет схему URI jms: для Java Message Service.