I'm trying to understand how common is the usage of MQ Topics in the industry. And MQ with SSL?
Thanks, Guy
I'm trying to understand how common is the usage of MQ Topics in the industry. And MQ with SSL?
Thanks, Guy
Pub/Sub
在 WMQ v7 之前,Pub/Sub 既可以作为 WMQ 的单独组件使用,也可以作为 WebSphere Message Broker 功能的一部分使用。现在在 v7 中,pub/sub 是 WMQ 不可或缺的一部分,并允许主题级别的安全性。有一定数量的 pub/sub 采用正在发生,因为它现在作为本机功能融入 WMQ。
另一个影响 WMQ 发布/订阅的因素是更多的人通过 WMQ 文件传输版接触到它。WMQ FTE 将文件传输状态作为出版物提供,许多使用此产品的人正在编写监视这些主题的应用程序,以提供各种自定义功能。一旦他们开始使用 pub/sub,许多这些商店开始看到它的其他用途。
Pub/Sub 还解决了一些与消息传递有关的常见问题,例如当前写入队列的应用程序,并且出现了将该消息的副本提供给另一个消费者的新要求。在 v7 之前,将应用程序从写入队列切换到写入主题有点侵入性,并且需要更改 JMS 应用程序的配置或更改其他类型代码的代码。解决该问题的最简单方法是使用将副本写入两个或更多队列的应用程序或出口来拦截消息。从 v7 开始,可以为为队列编写的应用程序提供主题的别名。生产者仍然认为它正在写入队列,但 WMQ 正在将消息发布到主题。然后,消费者可以直接订阅,或者在需要队列的遗留代码的情况下,管理订阅可以导致主题上的消息被传递到队列。我看到很多关于 pub/sub 的吸收来解决这些类型的要求。
在某些情况下,pub/sub 是适当的解决方案,并且仅出于这个原因使用它。过去,对单独组件、管理技能或 WMB 许可证的要求是采用的障碍,导致部分发布/订阅应用程序被重新设计为点对点。使用 WMQ 中内置的 pub/sub,这些障碍被消除或至少显着减少,这导致更多的采用,因为它是解决手头问题的正确架构。
一般来说,我会说 WMQ pub/sub 已经成为 v7 的主流。由于 v6 已于 2011 年 9 月宣布终止使用,因此今年将大规模迁移到 v7,随后将更多地采用 pub/sub。
SSL/TLS
至于 SSL,WMQ 安全正在接近主流。我不会说 SSL 是标准 - 只是现在 - 但在过去的两三年里,我在 IMPACT 和欧洲 WebSphere 技术会议上的WMQ 动手安全实验室会议的需求已经足够多。我最近写...
创造了“受信任的内部网络”一词来区分位于防火墙外部的内部网络部分。但是在这种情况下使用的术语“受信任”是相对的。它不应该表明内部网络是隐式信任的,只是它比防火墙外的东西更受信任。不幸的是,该术语有时被完全按字面解释。我有客户非常认真地告诉我,根据定义,我们信任“受信任的内部网络”上的所有内容,这就是我们称之为的原因。当然,这夸大了事实,因为即使是最坚定相信内部网络的人,仍然会强制使用基于密码的方式登录服务器、数据库和应用程序。所以内部网络是可信的,
尽管 SSL(实际上是 TLS)通道会加密,但它们也会进行身份验证。随着越来越多的人意识到他们需要在“受信任的”内部网络上对 WMQ 连接进行身份验证,SSL 已成为实现此目的的常用方法。当然,对于内部和外部连接的 WMQ 通道上的隐私(加密)和完整性服务的要求也越来越高,这也推动了 WMQ SSL 通道的采用。
现在 SSL 更加普遍,当人们不完全了解 WMQ 安全性时,会出现许多次要挑战。事实上,这些现在是WMQ listserve和MQSeries.net上的常见主题证明 SSL 的采用水平。其中一些次要问题是在 QMgr 的密钥库中包含未使用的证书颁发机构根证书,或者缺少 QMgr 通道设置,如 SSLPEER(按可分辨名称过滤连接)或 MCAUSER(将授权映射到特定用户帐户)。人们经常启用 SSL,但忽略了这些其他设置中的一个或多个,并且没有达到他们预期的安全级别。由于您必须启用 SSL 才能让这些东西出现问题,所以正如我的一个朋友所说的“奢侈问题”。接受 SSLPEER 设置的挑战总比完全不应用 SSL 要好得多。
总之......
所以我想这两个问题的简短答案是在 WMQ 中使用 pub/sub 和 SSL 是很常见的。现在两者都处于急剧上升的趋势,如果我正在编写新的应用程序,我肯定会使用 SSL,并且会毫不犹豫地在需要的地方使用 WMQ pub/sub。