Ibm mq WebSphere MQ对象命名约定

对于队列管理器、队列（本地、远程、传输、死信队列…）和通道等的WebSphere MQ命名约定，推荐的指导原则是什么。我在IBM找到了一个，但希望看看是否还有其他全面的指导原则。谢谢。

对于一个新专栏来说，这听起来是一个不错的主题，但我会在这里写下浓缩版。在回答之前，我要指出，我的许多建议与你在别处可能找到的建议相反。在某些情况下，这是因为MQ的常用方式多年来发生了变化。在其他情况下，这是因为传统智慧从一开始就不起作用。（例如，将频道命名为

到.QMGR

）在所有情况下，我更喜欢适用于最广泛情况的约定。这意味着通常可以在特定情况下找到这些规则的例外情况，但它们仍然广泛适用

一些一般规则
以下内容适用于所有对象类型

使用点字符

作为分隔符。
授权规则使用点字符作为分隔符来解析名称。例如，队列名称

MY.example.queue.name

将匹配规则，如

MY.*

或

MY.*

，但不匹配

MY.*

，因为点表示名称节点分隔符字符。帮自己一个忙，使用点而不是下划线作为命名节点分隔符

使用机器可解析名称。
当您有5个队列管理器和几百个对象时，您可以通过使用WMQ Explorer或runmqsc手动执行所有管理来轻松获得。然而，一致性、可靠性、可重复性和效率要求您编写一些日常操作的脚本，或者使用仪器来响应网络事件。最重要的是，这意味着消除名称上的歧义

例如，如果您创建一个命名约定，即通道名称必须类似于

SRCQMGR.DESTQMGR

，则脚本可以读取

RCVR

或

SDR

通道名称，并派生它连接的两个队列管理器的名称。但是，脚本如何处理频道名称，如

GA.PAYROLL.OPS

？是连接到

OPS

队列管理器的

GA.PAYROLL

队列管理器吗？或者是连接到

PAYROLL.OPS

队列管理器的

GA

队列管理器？一个人可能能够根据上下文立即说出，但脚本却因为做了你告诉他们的而不是你想做的而臭名昭著。当队列名称的开头和结尾都有位置相关的限定符，并且节点数量可变时，也会出现类似的情况

坚持使用大写名称。
这是为了实现跨所有平台的兼容性，特别是z/OS。虽然确实有更多的z/OS商店使用混合大小写，但也确实有很多系统只接受大写名称。虽然说“这不适用于我”很容易，但我见过很多情况，其中有人因为名字不兼容而在与新的业务合作伙伴进行接口时遇到问题。毕竟，能够与任何平台进行接口是首先使用WMQ的主要原因之一

不要在名称中包含对象的属性
在SOA世界中，队列和主题是不同类型的目的地，通常可以互换。将消息放入它认为是队列的东西不一定知道（或关心！）它们是否真的要进入队列或主题。有应用程序监听消息的队列可能由管理订阅提供，管理订阅实际上是从一个或多个主题引入发布

我们真正关心的是消息的性质—它们执行什么功能—而不是连接到本地队列还是别名队列。因此，添加诸如

.QA

、

.QL

、

.TPC

（用于主题）等限定符是没有意义的。类似地，将

.RCVR

添加到频道名称中会吸收5个有用的字符，这些字符本可以更好地用于描述QMgr名称。更糟糕的是，这些实践将拓扑烘焙到对象名称中，使系统变得更不灵活，更脆弱

频道名称

点对点通道名称
对于

RCVR

、

RQSTR

、

SDR

和

SVR

频道，使用

SRCQMGR.DESTQMGR

等名称。这偏向于从左向右读取的语言，因为其目的是描述从一个QMgr到另一个QMgr的数据流

群集通道
使用像

CLUSNAME.QMNAME

这样的名称。古老的智慧说使用像

to.QMNAME

这样的名称，但是如果您实现了重叠的集群，这将导致相同的通道用于多个集群。这很糟糕，因为这样一来，您就永远无法在一个集群上执行维护而不影响另一个集群。使用

CLUSNAME.QMNAME

可确保每个QMgr为其参与的每个集群都有一个专用的

CLUSRCVR

通道

客户端频道
“名称中不包含对象的属性”的例外情况可以说是

SVRCONN

通道。这是因为通道与网络的物理层而非逻辑层紧密相连。因此，将QMgr名称放在SVRCONN通道名称中通常是可以的。如果人们想在末尾添加

.SVRCONN

，我也不会太强烈地反对

关于客户机通道需要记住的是，如果使用客户机通道定义表（CCDT），那么该表中唯一的索引就是通道名称。这意味着您不能在多个QMGR上使用相同的通道名称，而仍然使用CCDT。因为CCDT是配置