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