Понимание Серийных файлов привязки MQ

Прежде чем обращаться к файлу .bindings, нам нужно немного отступить и взглянуть на JNDI - интерфейс именования и каталогов Java - и то, как он используется JMS. Очередь, тема и различные типы фабрики соединений - все это объекты 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 или интерфейс поставщика услуг, который используется реестром. Таким образом, хотя JNDI может быть реализован в LDAP, нет ничего, что говорит, что он должен быть реализован в LDAP.Одна из базовых реализаций, которые Sun предоставила прямо из коробки, заключалась в использовании локальной файловой системы в качестве реестра. В этой реализации корневой контекст - это файловая папка. Каждый контекст может хранить либо другой подконтекст (другую папку с файлами), либо определения объектов. Обычно существует одна папка для корневого контекста, и все объекты определяются на этом уровне. Файл, содержащий определения объектов, - это ... как вы уже догадались ... файл .bindings.

Объекты в файле .bindings представлены в тройках «Имя / Тип / Значение». Таким образом, каждый файл .bindings обычно имеет много объектов. У каждого объекта много атрибутов. У каждого атрибута есть имя, значение и тип переменной, которая содержит значение. Лучший способ получить доступ к файлу .bindings - это отсортировать его, чтобы объединить все объекты и их атрибуты и сделать его более удобочитаемым. Список возможных свойств см. В руководстве .

Конечно, файл .bindings должен быть скомпилированным артефактом и не предназначен для чтения человеком. IBM предоставляет инструмент JMSAdmin для создания и чтения файла .bindings. Вы также можете использовать WMQ Explorer для управления администрируемыми объектами в файле .bindings. Они также обсуждаются в руководстве по ссылке выше. Есть также (как говорят некоторые) хорошее руководство на developerWorks здесь .