Прежде чем обратиться к файлу .bindings, нам нужно немного отступить назад и взглянуть на JNDI - интерфейс именования и каталогов Java - и то, как он используется JMS. Очередь, тема и различные типы фабрики соединений - все это объекты JMS времени выполнения с методами и атрибутами. Но вы можете предварительно определить их и сохранить их в реестре, где приложение JMS может получить их с помощью поиска JNDI.
Это полезно, потому что объекты похожи на монеты в том смысле, что имеют сторону JMS и сторону поставщика. На стороне JMS любой администрируемый объект выглядит примерно одинаково. Независимо от основного транспортного поставщика, ConnectionFactory имеет одинаковые методы и атрибуты. Однако на стороне провайдера администрируемые объекты выглядят очень по-разному от одного провайдера к другому. Например, ConnectionFactory, используемый с транспортом WebSphere MQ, будет иметь атрибут для администратора очередей. Ни у одного другого транспортного провайдера нет «администратора очередей», поэтому этот атрибут действителен только в контексте WMQ.
Два аспекта администрируемых объектов - это «клей», который позволяет JMS работать независимо от поставщика транспорта. В вашем коде вам просто нужно найти ConnectionFactory и вы получите объект, подходящий для выполнения вызовов методов. Под прикрытием JMS-классы провайдера используют атрибуты объекта, специфичные для провайдера, для предоставления контекста для преобразования общих вызовов API JMS в вызовы, специфичные для провайдера. Таким образом, объект подключения, который вы создаете, приводит к вызову WMQ CONNECT, который задает имя QMgr, хост, порт, канал и множество других параметров.
ОК, я обещал добраться до файла .bindings. Ранее я говорил, что поиск JNDI был против «реестра», и это обычно означает LDAP или подобное. Но Sun спроектировал JNDI, такой как JMS, в котором есть API, который использует ваша программа, и интерфейс SPI или Service Provider, который используется реестром. Итак, хотя JNDI может быть реализован в LDAP, нет ничего, что говорит о том, что должно быть реализовано в LDAP. Одна из базовых реализаций, которую Sun предоставила прямо из коробки, заключалась в использовании локальной файловой системы в качестве реестра. В этой реализации корневой контекст является папкой файлов. Каждый контекст может хранить либо другой субконтекст (другую папку файлов), либо определения объектов. Обычно для корневого контекста существует одна папка, и все объекты определены на этом уровне. Файл, содержащий определения объектов, ... вы уже догадались ... файл .bindings.
Объекты в файле .bindings представлены в триплетах Имя / Тип / Значение. Таким образом, каждый файл .bindings обычно имеет много объектов. Каждый объект имеет много атрибутов. Каждый атрибут имеет имя, значение и тип переменной, которая содержит значение. Лучший способ получить дескриптор файла .bindings - это отсортировать его, чтобы собрать все объекты и их атрибуты вместе и сделать его более понятным для человека. Список возможных свойств см. В руководстве .
.
Конечно, файл .bindings должен быть скомпилированным артефактом и не предназначен для чтения человеком. IBM предоставляет инструмент JMSAdmin для генерации и чтения файла .bindings. Вы также можете использовать WMQ Explorer для управления администрируемыми объектами в файле .bindings. Они также обсуждаются в руководстве, связанном выше. Есть также (некоторые говорят) хорошее руководство в developerWorks здесь .