队列管理器，队列（本地，远程，传输，死信队列...），通道等的WebSphere MQ命名约定的推荐准则是什么。我在IBM的developerWorks中找到了一个，但希望查看是否还有其他内容综合在那里。谢谢。
最佳答案
对于新的Mission:Messaging列，这听起来像是一个不错的主题，但是我将在此处编写精简版本。在开始我的回答之前，请注意我的许多建议与您在其他地方可能发现的建议相反。在某些情况下，这是因为多年来使用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到另一个QMgr的数据流。
集群渠道
使用诸如CLUSNAME.QMNAME之类的名称。古老的说法是使用TO.QMNAME之类的名称，但是如果您实现了重叠的群集，则会导致同一通道用于多个群集。这很糟糕，因为您将永远无法在不影响另一个群集的情况下对一个群集执行维护。使用CLUSNAME.QMNAME确保每个QMgr为其参与的每个群集都有专用的CLUSRCVR通道。
客户渠道SVRCONN通道可以说是“不在名称中包含对象的属性”的例外。这是因为通道非常依赖于网络的物理层而不是逻辑层。因此，将QMgr名称放在SVRCONN通道名称中通常是可以的。如果人们想在末尾添加.SVRCONN，我也不反对。
关于客户端通道，要记住的一点是，如果使用客户端通道定义表（CCDT），则该表中的唯一索引就是通道名称。这意味着您不能在多个QMgr上使用相同的频道名称，而仍使用CCDT。由于CCDT是配置SSL / TLS通道详细信息的一种方法，因此，在“让我们最终安全的WMQ”项目出现之前，通常无法完全理解它。通过从一开始就为SVRCONN通道使用唯一的通道名称，就可以对网络进行过时的验证。通常，这些名称看起来像APP.QMNAME，或者为了使您清楚地知道它们与集群或点对点通道，APP.QMNAME.SVRCONN或类似名称无关。
队列管理器名称
QMgr名称中没有点
先前规则的一个含义是，集群和队列管理器名称必须仅包含一个节点，因此绝不能包含.字符。这是因为通道名称通常是从群集和/或QMgr名称派生的。因此，在上面的示例中，像RCVR这样的GA_PAYROLL.OPS通道名称会告诉人类和脚本，该通道将名为GA_PAYROLL的QMgr连接到名为OPS的QMgr。
少于9个字符的名称
频道名称只能为20个字符。减去一个点分隔符，除以2并四舍五入可以使队列管理器的字符数最多达到9个。如果您可能为服务类别设置了不同的渠道（例如，对于大型邮件还是小型邮件，请为QMgr名称降到8个字符或更少。这导致QM1.QM2.A，QM1.QM2.B等）。
QMgr名称反映了物理层
在面向服务的世界中，我们确实关心目的地名称，例如队列和主题。我们不太关心队列管理器名称，因为它们只是队列和主题的生命支持。客户端应用程序并不关心连接到哪个QMgr，只要它们可以发送请求和接收回复即可。 WMQ非常方便地在出站请求中填写对QMgr的答复名称，因此应用程序很少需要知道它。
另一方面，管理员需要了解QMgr名称。在早期，为主机服务器命名QMgrs是很常见的。后来，根据托管的应用程序来命名它们成为一种时尚。现在，在SOA世界中，消息传递是基础结构，通常不与任何单个应用程序相关联，因此钟摆已经倒退了。为QMgr指定一个对管理员有意义的唯一名称。
切勿重用QMgr名称！
不幸的是，将QMgr从一个地方“移动”到另一个地方或具有相同名称的主灾难恢复QMgr是非常普遍的。这种做法通常意味着应用程序的某些部分依赖于QMgr名称，因此重用该名称“更加容易”。 IBM引入了QMID作为解决因重用QMgr名称而引入的一些问题的方法。典型的用例是重建节点，并且一旦从头开始重建QMgr。集群知道它是新的QMgr，因为QMID已更改，但是用于路由和其他操作的名称保持不变。
尽管这在有限的用例中有所帮助，但是当两个同名QMgr同时在线时，它不能解决问题。它也没有解决信誉良好的证书颁发机构不会颁发具有相同可分辨名称的多个证书的问题，这将迫使同一证书重复用于多个QMgr。
请记住，QMgr只是队列和主题的终生支持，理想情况下，QMgr对使用它们的应用程序是匿名的。选择一个命名约定，如果需要的话，它可以让您使用成百上千的唯一名称来启动具有新名称的新QMgr，这样您就不必重用QMgr名称。
其他物件
使用透露意图的名字
或者换种说法，为对象的功能而不是名称命名。例如，如果您习惯于（像很多人一样）包括限定符，例如.QL用于本地队列，而.QA用于别名，则拓扑中的任何更改都将影响使用这些队列的应用程序。而是为队列代表的功能命名。
从左到右，最通用到最具体
对象名称，尤其是队列，应从最通用的限定词开始，到最具体的限定词进行分层构造。例如，许多商店使用APP.FUNC.SUBFUNC.VER，其中APP是拥有应用程序的ID，然后是一个或多个具有功能和子功能的节点。许多商店最后都添加了一个版本限定符，以便新版本的服务可以按单独的时间表迁移其客户端，而不用更改现有队列中的服务并使所有客户端同时更改。
读取消息的事物拥有队列
如果我有一个由队列表示的服务端点，那么可能将服务调用的事物与提供服务的事物之间存在多对一的关系。队列与服务以及提供该服务的事物相关联。客户或多或少是匿名的。因此，如果可以说任何利益相关者应用程序“拥有”队列，那么服务提供商应用程序将消耗队列中的消息。
发布消息的事物拥有主题。有点。
与主题的关系并不那么直接。在这里，通常是匿名的消息的使用者。从这个意义上讲，如果主题名称反映了任何应用程序，则它很可能是发布者。但是，即使发布者也可以是匿名的，或者至少可能有许多发布者，而不是同时发布所有发布者。对于主题而言，主题树节点是按照它们所代表的数据或功能的层次结构进行结构设计的。这些名称往往与发布应用程序的名称相匹配，因此有时发布者“拥有”主题的可能性与其他任何事物一样都是出于巧合。
将位置限定词放在左侧
如果名称具有不同数量的限定词，请将位置的限定词放在脚本和自动化可以解析它们的位置的左侧。有些商店的开头和结尾限定词都在位置上，通过在名称的可变部分（例如APP.FUNC.SUBFUNC1_SUBFUNC2.VER）中使用下划线作为分隔符来解决此问题。脚本和授权然后总是在名称中看到固定数量的节点，但是如果有人忘记并使用一个或两个以上的节点来创建名称，则此方法可能会很脆弱。
进一步阅读
这总结了大多数一般规则，但其背后的一些理念已在“任务：消息传递”专栏中获取。特别是：
Embracing cultural change in the WebSphere MQ community
Migration, failover, and scaling in a WebSphere MQ cluster
文章Planning for SSL on the WebSphere MQ network讨论了适用于WMQ的专有名称标准
关于ibm-mq - WebSphere MQ对象命名约定，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/9468431/