有关队列管理器,队列(本地,远程,传输,死信队列......),渠道等的WebSphere MQ命名约定的建议指南是什么？我在IBM的developerWorks上找到了一个,但是想看看是否还有其他全面的内容.那里.谢谢.
T.R*_*Rob 11
对于新的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队列管理器的队列管理器？一个人可能能够根据上下文立即讲述,但是脚本因为你告诉他们而不是你的意图而臭名昭着.当队列名称在名称的开头和结尾以及可变数量的节点处具有位置相关的限定符时,会出现类似的情况.
坚持使用UPPERCASE名称.
这是为了兼容所有平台,特别是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),则该表中的唯一索引是通道名称.这意味着你不能在多个QMgrs上拥有相同的通道名称,仍然使用CCDT.由于CCDT是配置SSL/TLS通道细节的一种方式,因此在"让我们最终确保WMQ"项目出现之前,通常不会充分认识到这一点.通过SVRCONN从一开始就为通道使用唯一的通道名称,您可以面向未来的网络.通常这些名称看起来像APP.QMNAME或显而易见,你没有处理集群或点对点通道,APP.QMNAME.SVRCONN或类似的.
队列经理姓名
QMgr名称中没有点
先前规则的一个含义是集群和队列管理器名称必须只包含一个节点,因此不应包含.字符.这是因为通道名称通常来自群集和/或QMgr名称.因此,在上面的示例中,RCVR通道名称GA_PAYROLL.OPS会告诉人和脚本相关的通道连接一个名为GA_PAYROLLQMgr的QMgr OPS.
9个字符或更少字符的
名称可以只有20个字符.减去一个用于点分隔符,除以2并向下舍入为队列管理器最多9个字符.如果有,你可以设置不同的渠道为服务类(大VS小消息,例如,然后回落到8个字符或更少QMGR名称的可能性.这导致QM1.QM2.A,QM1.QM2.B等等.
QMgr名称反映了物理层
在面向服务的世界中,我们真正关心目标名称,如队列和主题.我们更关心队列管理器名称,因为这些只是对队列和主题的生命支持.客户端应用程序并不关心连接到哪个 QMgr,只要它们可以发送请求并接收回复即可.WMQ非常方便地在出站请求中填写对QMgr名称的回复,因此应用程序很少需要知道它.
另一方面,管理员需要了解QMgr名称.在早期,通常为主机服务器命名QMgrs.后来它成为了他们为他们托管的应用程序命名的时尚.现在在SOA世界中,消息传递是基础架构,通常与任何单个应用程序无关,因此钟摆已经摆回来.为QMgr提供对管理员有意义的唯一名称.
永远不要重复使用QMgr名称!
遗憾的是,将QMgr从一个地方"移动"到另一个地方或者具有相同名称的主要和灾难恢复QMgr是很常见的.这种做法通常意味着应用程序的某些部分依赖于QMgr名称,因此重用该名称"更容易".IBM引入了QMID这种方法来解决重用QMgr名称引入的一些问题.典型的用例是节点重建,一旦QMgr也从头开始重建.群集知道它是一个新的QMgr,因为它QMID已经改变,但用于路由和其他操作的名称保持不变.
尽管这在有限的用例中有所帮助,但它并没有解决同时具有相同名称的QMgrs在线时的问题.它也没有解决信誉良好的证书颁发机构不会发布具有相同专有名称的多个证书的问题,这些证书强制为多个QMgrs重用相同的证书.
请记住,QMgrs只是对队列和主题的生命支持,理想情况下对使用它们的应用程序是匿名的.选择一个命名约定,允许您根据需要使用数百或数千个唯一名称来启动新的QMgrs,这样您就不必重用QMgr名称.
其他对象
使用意图揭示名称
或者换句话说,将对象命名为它的作用而不是它的名称.例如,如果您习惯(尽可能多的人)包括.QL本地队列和.QA别名等限定符,那么拓扑中的任何更改都会影响使用这些队列的应用程序.而是为它们代表的函数命名队列.
从左到右,对大多数特定
对象名称最通用,特别是队列,应该从最通用的限定符开始按层次结构构建,然后进入最具体的限定符.例如,许多商店使用APP.FUNC.SUBFUNC.VER其中APP是所属的应用程序的ID,然后用功能和子功能的一个或多个节点.许多商店在最后添加版本限定符,以便新版本的服务可以在不同的计划上迁移其客户端,而不是更改现有队列上的服务并使所有客户端同时更改.
读取消息的东西拥有队列
如果我有一个由队列表示的服务端点,那么可能将服务调用到提供服务的东西之间存在多对一关系.队列与服务和提供该服务的东西相关联.客户或多或少都是匿名的.因此,如果可以说任何利益相关者应用程序"拥有"该队列,则服务提供者应用程序会从其中消费消息.
发布消息的东西拥有该主题.有点.
这种关系并不像主题那么简单.这是消息的消费者通常是匿名的.从这个意义上讲,如果主题名称反映任何应用程序,则很可能是发布者.然而,即使是出版商也可以是匿名的,或者至少可能有许多出版商,而不是所有出版商同时出版.对于主题,更有意义的是,主题树节点是针对它们所代表的数据或功能的层次结构而构建的.这些名称往往与发布应用程序的名称相匹配,因此有时发布者"拥有"该主题与其他任何内容一样多.
将位置限定符放在左侧
名称具有可变数量的限定符,将位置限定符放在左侧,脚本和自动化可以在其中解析它们.一些商店,其中开始和结束限定符都是位置处理,通过在名称的变量部分使用下划线分隔符APP.FUNC.SUBFUNC1_SUBFUNC2.VER.然后,脚本和授权总是会在名称中看到固定数量的节点,但如果有人忘记并使用额外的节点或两个节点创建名称,则此方法可能会很脆弱.
进一步阅读
这总结了大多数一般规则,但其背后的一些哲学已经在Mission:Messaging专栏中得到了体现.特别是:
| 归档时间： |
|
| 查看次数： |
6037 次 |
| 最近记录： |