JNDI - это способ, которым вы пишете свое приложение JMS для соединения, не зависящего от брокера. Клиентские классы JNDI являются частью Java SE. Как Spring, так и не Spring Java SE приложения используют JNDI для такого рода интеграции.
Любая реализация JMS также должна предоставлять реализацию JNDI, которую можно подключить к вашему приложению. Обычно это делается путем помещения файла с именем jndi.properties в ваш путь к классам и установки правильной конфигурации для любой реализации JNDI, которую вы используете в этот файл. Когда вы создаете пустой InitialContext файл jndi.properties на вашем пути к классам читается автоматически. Пары ключ = значение в jndi.properties помещаются в InitialContext, поэтому при выполнении поиска все работает с выбранной реализацией. Вы также можете настроить это программно, если хотите, предоставив подробные сведения о реализации в InitialContext через конструктор .
Используя API-интерфейсы JMS и JNDI в приложении Java SE и выводя сведения о подключении для конкретного брокера в файл jndi.properties, вы можете эффективно изолировать свои приложения от кода конкретного брокера, чтобы вы могли развернуть свое приложение и работать с различными брокеры с несколькими простыми изменениями в файле свойств.
Реализация клиента JNDI будет исходить от того, кто предоставляет реализацию JMS. JNDI-клиент, по сути, поставляется в форме javax.naming.spi.InitialContextFactory реализации, упакованной в jar, и обычно есть документация, описывающая доступные свойства.
Вот несколько примеров:
- Брокер ActiveMQ 5.x предоставляет
org.apache.activemq.jndi.ActiveMQInitialContextFactory, доступный в их activemq-client-<version>.jar. Документация доступна здесь .
- Брокер ActiveMQ Artemis предоставляет
org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory, доступный в их artemis-jms-client-<version>.jar. Документация доступна здесь .
Для ясности, спецификация JMS не требует использования JNDI для поиска объектов администратора, но устанавливает соглашение и ожидание что провайдеры JMS сделают так. Раздел 4.2 спецификации JMS 1.1 гласит:
Хотя интерфейсы для управляемых объектов явно не зависят от JNDI, JMS устанавливает соглашение, согласно которому клиенты JMS находят их, просматривая их в пространстве имен с использованием JNDI.
и позже он говорит:
Ожидается, что провайдеры JMS предоставят инструменты, необходимые администратору для создания и настройки административных объектов в пространстве имен JNDI. JMS
Реализации провайдера администрируемых объектов должны быть javax.naming.Referenceable и java.io.Serializable, чтобы их можно было хранить во всех контекстах именования JNDI.
По моему опыту, провайдеры JMS обычно стремятся предоставить реализацию JNDI, потому что они не будут столь же конкурентоспособны без нее, поскольку любое альтернативное решение не будет соответствовать стандартам и заставит пользователей внедрять непереносимый код.
Если вы столкнетесь с провайдером, который не предоставляет реализацию JNDI, вы можете реализовать свой собственный, следуя тому же шаблону, что и ActiveMQ 5.x , ActiveMQ Artemis и Qpid JMS . Эти 3 реализации предназначены только для клиентской стороны и просто создают экземпляры административных объектов на основе конфигурации, предоставленной для InitialContext. Большая часть кода - это котельная плита, а что не очень прямолинейно.