Соглашения об именах объектов WebSphere MQ

это звучит как хорошая тема для новой Миссия: Обмен Сообщениями столбец, но я напишу здесь сокращенную версию. Я предварю свой ответ, отметив, что многие из моих рекомендаций противоречат тем, которые вы можете найти в другом месте. В некоторых случаях это происходит потому, что способ MQ обычно используется изменились с годами. В других случаях это происходит потому, что общепринятая мудрость никогда не работала хорошо с самого начала. (Кластерные каналы с именем TO.QMGR например.) В во всех случаях я предпочитаю условности, применимые к самому широкому числу ситуаций. Это означает, что обычно можно найти исключения из этих правил для конкретных случаев, но они тем не менее широко применимы.

общие правила
Следующее применимо ко всем типам объектов.

используйте символ точки . в качестве разделителя.
Правила авторизации анализируют имена, используя точечные символы в качестве разделителей. Например, имя очереди MY.EXAMPLE.QUEUE.NAME будет соответствовать правилам, как MY.*.*.* или MY.** а не MY.* потому что точки обозначают символы разделителя узлов имен. Сделайте себе одолжение и используйте точки, а не подчеркивания в качестве разделителей узлов именования последовательно.

использование машины-возможные имена.
Когда у вас есть 5 администраторов очередей и несколько сотен объектов, вы можете легко получить, выполнив все управление вручную с помощью WMQ Explorer или runmqsc. Однако, наступает момент, когда согласованность, надежность, повторяемость и эффективность требуют, чтобы вы написали сценарий некоторых своих рутинных операций или использовали инструментарий для реагирования на сетевые события. Больше всего это означает устранение двусмысленности в названиях.

например, если вы создаете соглашение об именах, что имена каналов должны выглядеть как SRCQMGR.DESTQMGR тогда для скрипта возможно прочитать RCVR или SDR имя канала и производные имена двух администраторов очередей, которые он соединяет. Однако, что делает ли скрипт с именем канала, как GA.PAYROLL.OPS? Это GA.PAYROLL администратор очередей подключается к OPS диспетчер очереди? Или это GA администратор очередей подключается к PAYROLL.OPS диспетчер очереди? Человек может мгновенно определить, основываясь на контексте, но сценарии известны тем, что делают то, что вы им говорите, а не то, что вы намеревались. Аналогичные ситуации возникают, когда имена очередей имеют квалификаторы, зависящие от позиции, как в начале, так и в конце имени и переменной число узлов.

придерживайтесь имен в верхнем регистре.
Это для совместимости на всех платформах, и в частности z/OS. Хотя верно, что больше магазинов z/OS используют смешанный регистр, также верно, что есть еще много систем, которые принимают только имена в верхнем регистре. Хотя легко сказать: "это не относится ко мне", я видел много случаев, когда у кого-то были проблемы с взаимодействием с новым деловым партнером из-за несовместимых имен. В конце концов, возможность интерфейса практически с любой платформой является одной из основных причин использования WMQ в первую очередь.

не включайте атрибуты объекта в название
В мире SOA очереди и темы являются различными типами назначения и часто взаимозаменяемы. Что-то, помещающее сообщения в то, что он считает очередью, не обязательно знает (или заботится!) если они действительно собираются в очередь или тему. Очередь, которая имеет прослушивание приложений на нем для сообщений может подаваться административной подпиской, которая фактически связывает публикации из одной или нескольких тем.

что нас действительно волнует, так это характер сообщений - какую функцию они выполняют, а не то, подключаемся ли мы к локальной очереди или очереди псевдонимов. Поэтому добавление квалификаторов, таких как .QA, .QL, .TPC (по теме) и так далее не имеет смысла. Аналогично, добавив .RCVR на имя канала всасывает 5 полезных символы, которые могли бы быть лучше использованы для описания имени QMgr. Хуже того, эти практики запекают топологию в имена объектов, делая систему менее гибкой и более хрупкой.

названия каналов

названия каналов точка-точка
Используйте такие имена, как SRCQMGR.DESTQMGR на RCVR, RQSTR, SDR и SVR каналы. Это смещено в сторону языков, которые читают слева направо, потому что намерение состоит в том, чтобы описать поток данных С а на "qmgr"to еще на "qmgr"

кластер каналы
Используйте такие имена, как CLUSNAME.QMNAME. Старая мудрость говорила, что нужно использовать такие имена, как TO.QMNAME но если вы когда-либо реализуете перекрывающиеся кластеры, это приводит к тому, что один и тот же канал используется для нескольких кластеров. Это плохо, потому что вы никогда не сможете выполнять обслуживание одного кластера, не влияя на другой. Используя CLUSNAME.QMNAME гарантирует, что каждый QMgr имеет выделенный CLUSRCVR канал для каждого кластера, в котором он участвует.

Клиентские Каналы
Исключение из "не включать атрибуты объекта в имя", возможно, является SVRCONN канал. Это связано с тем, что каналы очень сильно привязаны к физическому, а не к логическому слою сети. Таким образом, размещение имени QMgr в имени канала SVRCONN обычно нормально. Я не возражаю слишком сильно, если люди хотят добавить .SVRCONN в конце, любой.

о клиентских каналах следует помнить, что если вы используете таблицу определения клиентского канала (CCDT), то уникальным индексом в этой таблице является имя канала. Это означает, что вы не можете иметь одно и то же имя канала на нескольких QMgrs и все еще использовать CCDT. Поскольку CCDT является одним из способов настройки деталей канала SSL/TLS, это часто не оценивается в полной мере, пока не появится проект "let's finally secure WMQ". Используя уникальные имена каналов для SVRCONN каналы с самого начала, вы можете в будущем сети. Обычно эти имена выглядят как APP.QMNAME или, чтобы было очевидно, что вы не имеете дело с кластером или каналом точка-точка,APP.QMNAME.SVRCONN или аналогичные.

имена администратора очередей

нет точек в именах QMgr
Одно из следствий предыдущих правил заключается в том, что имена кластера и администратора очередей должны содержать только один узел и поэтому никогда не должны содержать . символ. Этот это потому, что имена каналов обычно являются производными от имен кластера и/или QMgr. Так в приведенном выше примере RCVR название канала, как GA_PAYROLL.OPS сказал бы как людям, так и сценариям, что рассматриваемый канал соединяет qmgr с именем GA_PAYROLL на на "qmgr" имени OPS.

имена 9 символов или меньше
Имена каналов могут быть только 20 символов. Вычесть один для разделителя точек, разделить на два и округлить вниз получает вас до 9 символов максимум для администраторов очередей. Если есть возможность, что вы можете настроить разные каналы для классов обслуживания (например, для больших и малых сообщений, затем вернитесь к 8 символам или меньше для имен QMgr. Это приводит к QM1.QM2.A, QM1.QM2.B, etc.

имена QMgr отражают физический уровень
В сервис-ориентированном мире мы действительно заботимся об именах мест назначения, таких как очереди и темы. Мы гораздо меньше заботимся об именах администраторов очередей, потому что это просто поддержка жизни для очередей и тематическое направление. Клиентские приложения не заботятся так много о , который QMgr подключение, пока они могут отправлять запросы и получать ответы. WMQ очень удобно заполняет имя ответа на QMgr в исходящих запросах, поэтому редко приложение должно знать об этом.

С другой стороны, администраторы должны знать о имени QMgr. В первые дни было принято называть QMgrs для хост-сервера. Позже вошло в моду называть их приложения, которые они размещали. Теперь в мире SOA обмен сообщениями является инфраструктурой и обычно не связан с каким-либо одним приложением, поэтому маятник качнулся назад. Дайте QMgr уникальное имя, которое имеет значение для администратора.

никогда не используйте имена QMgr!
К сожалению, очень часто "перемещать" QMgr из одного места в другое или иметь первичный и аварийный qmgr с тем же именем. Эта практика обычно означает некоторую часть приложение зависит от имени QMgr, и поэтому его" легче " повторно использовать. IBM представила QMID как способ решения некоторых проблем, связанных с повторным использованием имен QMgr. Типичный случай использования заключается в том, что узел перестраивается, а QMgr после этого также перестраивается с нуля. Кластер знает, что это новый QMgr, потому что QMID изменилось, но имя, используемое для маршрутизации и других операций, остается прежним.

хотя это помогло в этом ограниченном использовании случай, он не решает проблемы, когда оба QMgrs с тем же именем находятся в сети одновременно. Он также не решает проблему, что авторитетный центр сертификации не будет выдавать несколько сертификатов с одним и тем же отличительным именем, что заставляет повторно использовать один и тот же сертификат для нескольких QMgrs.

помните, что QMgrs-это просто поддержка жизни для очередей и тем и в идеале будет анонимным для приложений, использующих их. Выберите соглашение об именах, которое позволяет создавать новые QMgrs с уникальными именами на сотни или тысячи, если это необходимо, так что вам не придется повторно использовать имена QMgr.

другие объекты

используйте имена, раскрывающие намерения
Или, другими словами, назовите объект тем, для чего он тут а не то, что это is. Например, если у вас была привычка (как и у многих людей) включать квалификаторы, такие как .QL для локальных очередей и .QA для псевдонимов, тогда любое изменение топологии повлияет на приложения, использующие эти очереди. Вместо этого назовите очереди для функций, которые они представляют.

перейти слева направо, наиболее общие для наиболее конкретных
Имена объектов, особенно очереди, должны строиться иерархически, начиная с самого общего классификатора и заканчивая самым конкретным классификатором. Например, многие магазины используют APP.FUNC.SUBFUNC.VER здесь APP - это идентификатор приложения-владельца, затем один или несколько узлы с функцией и подфункцией. Многие магазины добавляют квалификатор версии в конце, чтобы новые версии Службы могли переносить своих клиентов по отдельным расписаниям, а не изменять службу в существующей очереди и одновременно изменять всех клиентов.

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

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

поместите позиционные квалификаторы слева
Где имена имеют переменные номера квалификаторов, поместите позиционные слева, где скрипты и автоматизация могут их анализировать. Некоторые магазины, где оба начала и конечные квалификаторы являются позиционными с этим, используя подчеркивания для разделителей в разделе переменных имени, например APP.FUNC.SUBFUNC1_SUBFUNC2.VER. Скрипты и авторизации всегда видеть фиксированное количество узлов в имени, но этот подход может быть хрупким, если кто-то забывает и делает имя с дополнительным узлом или двумя.

более дальнеишее чтение
Это подводит итог большинству общих правил, но некоторые из философии за ними были захвачены в колонке миссия: обмен сообщениями. В частности:

• принятие культурных изменений в WebSphere MQ сообщество
• миграция, отработка отказа и масштабирование в кластере WebSphere MQ
• статьи планирование SSL в Сети WebSphere MQ обсуждает стандарты отличительных имен, как они применяются к WMQ