通过互联网访问WebSphere MQ消息队列（即100毫秒延迟）和组织边界的推荐架构是什么？
我们正在考虑的两种方法是直接从我们的客户端访问其他组织的队列管理器，另一种方法是在本地拥有一个队列管理器，它将从远程队列中抽取消息，然后本地客户端将访问它。我认为两者都有价值，但我不确定这两种架构之间的权衡。
我们必须处理的卷是每秒600，消息大小约为50字节。另一个组织的队列管理器是不可更改的（它是WebSphere MQ）。必须按顺序处理消息。也许它们可以在不同的队列之间拆分，然后每个队列由不同的客户端处理，但在每个队列中，顺序仍然非常重要。通常会有一个事务处理客户端。可能有一个额外的商业智能客户端将处理该消息的副本。
是否有人拥有MQSeries到MQSeries队列管理器吞吐量的任何性能指标以及WebSphere MQ队列管理器与客户端吞吐量的比较？
答案 0 :(得分：2)
从安全角度来看，建议的答案是其他组织应该要求您使用完整的QMgr而不是客户端。来自外部QMgr的频道连接只会发出CONNECT，INQUIRE和PUT命令。客户端连接可以访问整个WMQ API，并且可以对任何对象执行任何API调用。例如，如果另一方在其队列名称（例如帐号）中使用结构化数据，则客户端应用程序可以遍历所有可能的名称以枚举所有帐号。如果调用返回2035，则该对象存在但授权失败。如果调用返回2085，则该对象不存在。除了允许各种类型的枚举之外，陷入连接循环的客户端可以在QMgr上每秒抛出数百次重新连接尝试，这将完全占用一个监听器。因此，客户本质上更容易接受来自第三方的QMgr和客户的连接，甚至更多。但是，客户端是免费的，并且成本通常超过风险，特别是当应用程序没有移动高价值交易或敏感数据时。如果我被指控连接到供应商的QMgr，他们允许选择客户端连接或QMgr连接，并且应用程序具有高可见性或关键任务，我会选择一个完整的QMgr。
要考虑的另一个方面是QMgr-to-QMgr通道对网络连接问题更具弹性。这是因为两个QMgrs跟踪消息序列号，在同步点下保持批量直到确认，并且能够自动协商信道恢复，而不会丢失或复制任何持久性消息。因为客户端通道为您提供了开发人员对API的完全访问权限，包括编写牺牲性能可靠性的程序的自由，所以可以编写丢失或复制消息的客户端应用程序。事实上，网络上异步消息的一个固有问题是会话恢复问题可能会产生导致重复消息的模糊结果。这不是特定于WebSphere MQ的，事实上，JMS规范讨论了这个问题，并指出应用程序负责正确计算由于会话恢复而产生的“功能重复”消息。您可以通过始终使用事务处理会话消除消息丢失的可能性，但消除发送重复消息的可能性需要一些工作。两个QMgrs谈话使用一种消除任何这种歧义的协议。
至于效果指标，请查看适用于您平台的效果报告。这些都可以从SupportPacs landing page获得。查找名称为MP**的SupportPac，例如适用于Windows的SupportPac MP71或适用于Linux的SupportPac MPL5。
答案 1 :(得分：0)
我不清楚有重要的细节。
您希望每个本地客户端都能获得整个邮件队列吗？如果是这样，那么http://code.google.com/p/pubsubhubbub/可能会有用。
或者您是否希望队列中的邮件在您的客户端之间划分？如果是这样的话，我会有一个本地队列管理器，以便您的客户往返时间获取下一条消息完全在您的网络内部，而不必经历可能较慢的互联网连接。