【发布时间】：2012-03-17 03:03:26
【问题描述】：
对于队列管理器、队列（本地、远程、传输、死信队列...）、通道等的 WebSphere MQ 命名约定的推荐指南是什么。我在 IBM 的 developerWorks 找到了一个，但想看看是否有还有其他全面的东西吗？谢谢。
【问题讨论】：
标签： ibm-mq
【发布时间】：2012-03-17 03:03:26
【问题描述】：
这听起来像是一个新的Mission:Messaging 专栏的好主题，但我会在这里写出精简版。我将首先指出我的许多建议与您在其他地方可能找到的建议相反。在某些情况下，这是因为多年来常用 MQ 的方式发生了变化。在其他情况下，这是因为传统智慧从一开始就没有奏效。 （例如名为TO.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)，那么该表的唯一索引就是渠道名称。这意味着您不能在多个 QMgrs 上拥有相同的通道名称，并且仍然使用 CCDT。由于 CCDT 是配置 SSL/TLS 通道详细信息的一种方式，因此在“让我们最终保护 WMQ”项目出现之前，通常不会充分认识到这一点。通过从一开始就为SVRCONN 频道使用唯一的频道名称，您可以让网络适应未来的发展。通常这些名称看起来像APP.QMNAME，或者为了表明您不是在处理集群或点对点通道，APP.QMNAME.SVRCONN 或类似名称。
队列管理器名称
QMgr 名称中没有点
上述规则的一个含义是集群和队列管理器名称必须仅包含一个节点，因此不应包含. 字符。这是因为通道名称通常源自集群和/或 QMgr 名称。所以在上面的例子中，像GA_PAYROLL.OPS 这样的RCVR 频道名称会告诉人类和脚本，有问题的频道将一个名为GA_PAYROLL 的QMgr 连接到一个名为OPS 的QMgr。
9 个字符或更少字符的名称
频道名称只能是 20 个字符。为点分隔符减去 1，除以 2 并向下取整，队列管理器最多可显示 9 个字符。如果您有可能为服务类别设置不同的通道（例如，对于大消息和小消息，然后将 QMgr 名称回退到 8 个字符或更少。这会导致 QM1.QM2.A、QM1.QM2.B 等。
QMgr 名称反映物理层
在面向服务的世界中，我们非常关心队列和主题等目的地名称。我们不太关心队列管理器的名称，因为它们只是队列和主题的生命支持。客户端应用程序不太关心哪个 QMgr 连接到，只要它们可以发送请求和接收回复。 WMQ 非常方便地填写出站请求的回复 QMgr 名称，因此应用程序很少需要知道它。
另一方面，管理员需要了解 QMgr 名称。在早期，通常将 QMgrs 命名为主机服务器。后来，为它们托管的应用程序命名它们成为一种时尚。现在在 SOA 世界中，消息传递是基础设施，通常不与任何单个应用程序相关联，因此钟摆已经摆回。为 QMgr 指定一个对管理员有意义的唯一名称。
切勿重复使用 QMgr 名称！
不幸的是，将 QMgr 从一个地方“移动”到另一个地方或拥有一个同名的主 QMgr 和灾难恢复 QMgr 是很常见的。这种做法通常意味着应用程序的某些部分依赖于 QMgr 名称，因此重用该名称“更容易”。 IBM 引入了QMID 来解决由于重用 QMgr 名称而引入的一些问题。典型的用例是一个节点被重新构建，并且一旦存在 QMgr 也从头开始重新构建。集群知道它是一个新的 QMgr，因为 QMID 已更改，但用于路由和其他操作的名称保持不变。
虽然这在有限的用例中有所帮助，但它并不能解决同名的两个 QMgrs 同时在线时的问题。它也没有解决信誉良好的证书颁发机构不会颁发具有相同专有名称的多个证书的问题，这会迫使多个 QMgrs 重复使用相同的证书。
请记住，QMgrs 只是队列和主题的生命支持，理想情况下对使用它们的应用程序是匿名的。选择一个命名约定，允许您根据需要以数百或数千个唯一名称启动新的 QMgr，这样您就不必重复使用 QMgr 名称。
其他对象
使用能透露意图的名字
或者换一种说法，将对象命名为 做什么 而不是 是什么。例如，如果您习惯（和许多人一样）包含限定符，例如用于本地队列的 .QL 和用于别名的 .QA，那么拓扑的任何更改都会影响使用这些队列的应用程序。相反，为它们所代表的功能命名队列。
从左到右，从最通用到最具体
对象名称，尤其是队列，应该从最通用的限定符开始分层构造，然后到最具体的限定符。例如，许多商店使用APP.FUNC.SUBFUNC.VER，其中APP 是拥有应用程序的ID，然后是一个或多个具有功能和子功能的节点。许多商店在末尾添加版本限定符，以便服务的新版本可以按单独的时间表迁移其客户端，而不是更改现有队列中的服务并让所有客户端同时更改。
读取消息的对象拥有队列
如果我有一个由队列表示的服务端点，那么可能调用服务的事物与提供服务的事物之间存在多对一的关系。队列与服务和提供该服务的事物相关联。客户或多或少是匿名的。因此，如果可以说任何利益相关者应用程序“拥有”队列，那么从它消费消息的就是服务提供者应用程序。
发布消息的事物拥有主题。有点。
与主题的关系并不那么简单。在这里，消息的消费者通常是匿名的。从这个意义上说，如果主题名称反映了任何应用程序，则很可能是发布者。然而，即使是出版商也可以是匿名的，或者至少可能有许多出版商，而不是所有出版商同时出版。对于主题，主题树节点是针对它们所代表的数据或功能的层次结构而构建的，这更有意义。这些名称往往与发布应用程序的名称相匹配，因此有时发布商“拥有”该主题与其他任何事情一样出于巧合。
将位置限定符放在左边
如果名称具有可变数量的限定符，则将位置限定符放在脚本和自动化可以解析它们的左侧。一些开始 和 结束限定符都是位置的商店通过在名称的变量部分使用下划线作为分隔符来处理这个问题，例如APP.FUNC.SUBFUNC1_SUBFUNC2.VER。脚本和授权总是会在名称中看到固定数量的节点，但如果有人忘记并用一个或两个额外的节点命名，这种方法可能会很脆弱。
进一步阅读
这总结了大多数一般规则，但它们背后的一些理念已在 Mission:Messaging 专栏中得到体现。特别是：
【讨论】：
-
谢谢 Rob，像往常一样，它是学术性的。我必须再读一遍，如果有的话，我会在这里发布问题和澄清。再次感谢。
-
感谢@Shashi 和@arrehman！让我知道是否有任何我没有涵盖的重要内容或需要澄清的内容。有一些主题会间接影响对象名称，我在这里没有尝试介绍。例如，如果您想知道安全性如何影响对象名称，那么这本身就值得提出一个问题（答案也差不多），我可以将这两个帖子链接起来。
-
对听众名字有什么建议吗？我通常给它起一个名字并在脚本中启动它。
-
我使用像
TCP.1414这样的名称，其中名称包括协议和端口。您有什么理由不将听众置于 QMgr 控制之下？然后当 QMgr 关闭时它们会停止，因此当 QMgr 恢复时不必清除信号量和共享内存。 -
说吧，这个VER的名字应该是什么样子的？你有这方面的经验吗？用版本号命名第一个 Q 或 Alias 是一个好习惯吗？或者也许开始没有它并添加另一个版本？