ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 重新配置 WebSphere Message Broker V6.1 中的消息流

重新配置 WebSphere Message Broker V6.1 中的消息流

原创 Linux操作系统 作者:CloudSpace 时间:2009-01-15 14:20:21 0 删除 编辑
在繁忙的生产环境中部署消息流可能很成问题,但是 WebSphere Message Broker V6.1 中的新功能减少了在应用次要配置更改时对编辑和重新部署消息流的需要。本文将描述这些功能并介绍如何最好地使用它们。

引言

IBM® WebSphere® Message Broker(以下称为 Message Broker)执行的应用程序集成逻辑由用户生成的称为消息流的资产所定义,消息流由代理运行时上称为执行组的系统进程解释。为了开始在某个执行组上运行此逻辑,需要编译消息流并将其与任何相关文件一起组合到称为代理存档(broker archive,BAR)文件的压缩包中。部署过程包括通过名为 Configuration Manager 的控制组件将 BAR 文件从工具发送到执行组。接收到新的消息流时,执行组解析新的配置,然后立即更新其执行逻辑。

在现有的代理域上,执行部署是非常简单的。从 Message Broker Toolkit 中,通过将 BAR 文件拖到目标执行组的表示形式上即可开始部署。或者,您可以使用命令行输入单个命令,其中指定 BAR 文件和目标 Configuration Manager、代理以及执行组。虽然部署非常简单,但是务必认识到将逻辑发布到任何正在提供业务服务的活动系统(其中包括 Message Broker)所具有的相关风险。消息流与源代码类似,因为它们包含您希望系统执行的功能的完整逻辑描述,因此错误会阻止代理按您预期的那样工作。

足够的消息流测试和严格的更改管理流程可以帮助缓解这些风险。但是直到最近,由于大多数配置信息都是在消息流和 BAR 文件结构中静态地设置的,即使次要的配置更改也需要重新部署受影响的消息流。

Message Broker 中的若干功能使您无需重新编译和重新部署消息流即可应用次要的配置更改。其中有些功能(例如部署描述符)自从 V5 以来就已经存在于产品中了。然而,Message Broker V6.1 引入了新功能,可进一步减少需要重新部署的场景。虽然更改管理始终是明智的,但是对于使管理员能够在对代理(从而对业务)产生最小风险的情况下应用配置更改这个目标来说,V6.1 标志着迈向该目标的重要第一步。

本文描述 Message Broker 中的一些支持此目标的功能,从一些已在产品中存在了一段时间的管理功能开始,然后介绍 V6.1 中的一些新功能。本文面向 WebSphere Message Broker 的应用程序开发人员和管理员。虽然本文主要集中于 Message Broker V6.1 中引入的功能,但是正在考虑升级到 V6.1 的早期版本的用户也应该会对本文感兴趣。

部署描述符

部署描述符自从 V5 以来就已经在 Message Broker 中使用了,并且是描述对存储在已编译的消息流中的配置参数覆盖的文件。例如,在某个已编译的消息流可能包含对名为 MY.QUEUE 的队列的引用的情况下,管理员可以提供部署描述符将此参数覆盖为 NEW.QUEUE。这意味着可以将已编译的消息流文件与某些节点和配置节点的消息流参数分离。

部署描述符覆盖存储在 BAR 文件中,并在部署时由 Configuration Manager 应用于消息流,因此对部署描述符的任何更改需要重新部署受影响的消息流。但是,部署描述符的优点在于,它们消除了重新编译消息流以便在不同环境中运行的需要。例如,在将已编译的消息流从测试域移动到包含不同队列和数据源名称的生产域的时候,可以使用相同的已编译消息流。跳过编译步骤是有利的,因为这有助于确保升级到生产环境的消息流除了某些不同的覆盖之外,将与所测试的已编译消息流确切相同。

部署描述符通常在 Message Broker Toolkit 中在 BAR 文件内进行编辑,不过 V6.0 还通过 mqsireadbar 和 mqsiapplybaroverride 命令在命令行提供了此功能。V6.1 改进了这些命令,并使它们同时在运行时和 Message Broker Toolkit 安装中可用;后者以 Eclipse Headless 模式运行,但是命令在其他方面是完全相同的。所调用的命令的变体显示在输出的第一行。

mqsireadbar 命令显示指定的 BAR 文件的内容。在 V6.1 中,产生的信息包括已嵌入文件中的任何版本信息,还有关于任何部署描述符覆盖(已应用的覆盖和可在 BAR 文件中应用的覆盖)的信息。例如:

C:\>mqsireadbar -b SimpleFlow.bar
BIP1052I: Reading Bar file using runtime mqsireadbar...
SimpleFlow.bar:
myflow.cmf (08/08/07 09:53):
Author = Matt
VERSION = v1.2
Deployment descriptor:
myflow#additionalInstances
myflow#commitCount
myflow#commitInterval
myflow#coordinatedTransaction
myflow#MyMQInput.queueName = NEW_QUEUE_NAME
myflow#MyMQInput.validateMaster
myflow#MyMQInput.serializationToken
myflow#MyMQInput.topicProperty
BIP8071I: Successful command completion.

此输出告诉了我们许多有关 SimpleFlow.bar 的事情。首先,其中包括一个名为 myflow 的已编译消息流,该消息流包含这里显示的一些嵌入的版本信息(作者和版本),以及最后修改日期。它还告诉我们,myflow 消息流有一个部署描述符和一些可覆盖的属性。其中一个属性——MyMQInput 节点的队列名称——已覆盖为 NEW_QUEUE_NAME。

您可以使用 mqsiapplybaroverride 命令对部署描述符做出更改。通过指定要覆盖的属性名称(例如,myFlow#additionalInstances),或者通过查找和替换方法(例如,将出现的所有 OLD_QUEUE 更改为 NEW_QUEUE),您可以指定一个或多个要更改的属性。或者,您可以使用该命令来指定用整个新的部署描述符替换现有的部署描述符。

BAR 文件和部署描述符操作也可以通过基于 Java 的 Configuration Manager Proxy API 进行,该 API 现在包括一组用于操作 BAR 文件中的资产的类和方法。

用户定义的属性

部署描述符在 Message Broker V6.0 中得到了增强,以使它们可以包含可由管理员在部署时设置的附加属性。配置这些属性后,然后就可以从基于 JavaCompute 或 ESQL 的节点中访问这些属性,例如 Compute 节点。这些属性称为用户定义的属性(user-defined property,UDP),并在消息流编辑器中进行定义:


图 1. 使用消息流编辑器定义新的 UDP
图 1

图 2. 使用 BAR 编辑器在部署时覆盖 UDP
图 2

如果将 UDP 添加到消息流,它们的值可在部署时由管理员使用 BAR 文件编辑器(下面的图 2)进行覆盖,并且随后可在 JavaCompute 节点中使用如下形式的方法进行检索: String s = getUserDefinedAttribute("ServiceName");

还可以从 Compute 节点中使用的 ESQL 中访问这些值: DECLARE ServiceName EXTERNAL CHARACTER default

在 Message Broker V6.1 中,只能在 BAR 文件编辑器中操作这些属性,因此与部署描述符中管理的其他覆盖一样,仍然需要重新部署消息流才能更改这些属性的值。然而,这里提到 UDP 的原因在于,您可以使用它们来最小化需要嵌入在消息流逻辑中的环境信息。换句话说,它们进一步增强了对管理员可用的操作灵活性。

动态节点属性

Message Broker V6.1 包括比任何早期版本更多的新节点,这些节点展示了指定配置属性的新模式,以及改进的应用配置更改的灵活性。

新节点上的某些属性可以从消息树中的某个位置动态地取得其值,而不是需要在消息流编辑器中静态地设置其值。例如,考虑可在 FileOutput 节点上指定目标目录的方式。正如有经验的 Message Broker 开发人员所预期的那样,Basic 选项卡上有一个属性允许静态指定此位置的值:


图 3. FileOutput 节点的 Basic 属性
图 3

然而,您还可以使用该节点的 Request 选项卡,以 XPath 或 ESQL 语法的形式,指定消息树中可找到此值的覆盖的元素位置(请参见下面的图 4)。如果在某个消息流中调用该节点,并且这里指定的树位置处存在某个值,则此元素的值将用作目录位置,而不是使用 Basic 选项卡上静态定义的值。使用标准消息流操作逻辑,该树位置处的值可以静态地定义、根据消息内容计算得出,或者从外部来源得出。


图 4. FileOutput 节点的 Request 属性
图 4

Message Broker V6.1 中的若干属性遵循此模式——有关更多信息,请参见 WebSphere Message Broker 信息中心。在开发消息流时,这些属性为您提供了更多的灵活性,并允许 Message Broker 管理员动态修改消息流行为而无需重新部署消息流。

可配置的服务

新节点的另一种新兴模式是能够独立于使用资源的节点为消息流中使用的外部资源配置资源定义。此功能是在 V6.0 中引入的,以允许动态配置与代理关联的 JMS 提供程序。V6.1 使用同样的技术来配置对许多其他外部资源服务(包括 FTP、JDBC 提供者、SMTP 和 LDAP 服务器)的访问,以及对 Tivoli Federated Identity Manager (TFIM) 的访问。作为示例,请参见 EmailOutput 节点的 Basic 选项卡上的 SMTP Server and Port 参数(下面的图 5)。此属性用于指定代理将用于发送电子邮件的 SMTP 服务器的主机名称:


图 5. EmailOutput 节点的 Basic 属性
图 5

在最简单的形式下,此属性的值是 DNS 中定义的主机名称或 IP 地址,如果未使用缺省 SMTP 端口 25,则还包括可选的端口。但是,此属性的值也可以取而代之为某个别名,该别名引用代理上定义的某个可配置的服务。为了支持这一点,代理管理员可以在代理计算机上运行一组类似如下的命令:

mqsicreateconfigurableservice BROKER -c SMTP -o MYSERVER
mqsichangeproperties BROKER -c SMTP -o MYSERVER -n serverName -v smtp.hursley.ibm.com:25

这样,如果将 SMTP Server and Port 属性设置为已定义的别名(在此例中为 MYSERVER),则管理员覆盖的任何值(在命令行上将 smtp.hursley.ibm.com:25 设置为服务器名称)将优先于任何静态定义的值或 LocalEnvironment 中的覆盖而被使用。

用于选择值的优先顺序如下:

  1. 如果存在 SMTP Server and Port 设置中所提供的名称的别名,则选择 Configurable Service 中指定的值。
  2. LocalEnvironment 中指定的服务器名称。
  3. 节点上指定的 SMTP Server and Port 属性的值。

还可以使用类似的命令删除任何别名,并且节点将恢复为将主机名称解析为 IP 地址。虽然大多数可配置的服务属性都是使用 mqsichangeproperties 设置的,但是安全标识(用户 ID 和密码)则通常是使用 mqsisetdbparms 命令设置的,并在单独的 SecurityIdentity 属性中引用,例如:

mqsisetdbparms -n smtp::MyIdentity -u userName -p password
mqsichangeproperties BROKER -c SMTP -o MYSERVER -n securityIdentity -v MyIdentity

使用可配置的服务来配置对外部资源的访问的优点在于,它允许消息流开发人员独立于目标运行时环境工作,而且还使得消息流能够适应周围基础结构的更改。它还意味着,任何敏感信息(例如,用于访问这些服务的密码)未包含在已编译的消息流或部署描述符中,而是仅在本地代理计算机上输入和存储。

代理属性

上述示例中使用的 mqsichangeproperties 命令用于配置的属性远不只是与可配置的服务相关联的属性。虽然此命令在早期版本的 Message Broker 中用于设置各种代理间、多播和 JVM 属性,但是 Message Broker V6.1 中的许多组件也使用了此机制,例如新的运行时安全模型。

此命令对于所有种类的配置调整都非常有用,包括设置操作参数(例如要使用的附加线程实例级别),如果采用其他方式,则需要重新部署受影响的消息流才能设置操作参数。但是,虽然以这种方式更改的许多属性会立即生效,但是某些属性仅在执行组启动时才被读取,因此有时需要重新启动代理(或使用 mqsireload 命令)才能使更改后的属性生效。

还在 Message Broker V6.1 中引入的一个新功能是由授权用户通过 Configuration Manager Proxy 应用程序远程设置和获取这些配置属性。该 API 提供了相关方法,用于返回可用属性的列表,以及设置和获取代理、执行组和消息流的这些属性值。

Configuration Manager Proxy API Exerciser 示例是实现此目的的便利方法。下面的图 6 显示了执行组对象上可用的属性的一小部分及其当前分配的值。右键单击相关对象即可设置这些值:


图 6. 说明执行组上可用的某些运行时属性的 Configuration Manager Proxy API Exerciser 示例
图 6

虽然现在可以同时通过 Configuration Manager Proxy 和 mqsichangeproperties 命令设置代理属性,但是务必牢记几个有关同步的要点:

  • 如果使用 Configuration Manager Proxy 应用程序配置某一组属性,您必须调用相关方法来设置属性,然后请求 Configuration Manager 使用 BrokerProxy.deploy() 方法将任何更改的属性发送到代理。这不是传统意义上的部署(因为此调用未影响消息流逻辑),而是请求 Configuration Manager 将任何更改的配置发送到代理上。为了最小化 Configuration Manager 与代理之间的通信,您应该设置所有需要更改的属性的值,然后在结束时通过单个调用将其传输到代理。

  • 如果使用 mqsichangeproperties 命令更改属性,Configuration Manager 将不会立即发现属性的新值。在以下情况下才会发现新值:
    1. 在第一次成功部署到代理以后
    2. 当 Configuration Manager 启动时
    3. 定期使用 ConfigManagerProxy.setAutoDiscoveryIntervalMins() 定义的间隔(缺省为一小时)
    4. 调用 BrokerProxy.discoverConfiguration() 方法来手动地发现

    在完成此发现之前,如果使用 Configuration Manager Proxy 应用程序检查使用 mqsichangeproperties 来更改的属性,则仍然会显示旧的值。

  • 新的属性值始终替换任何已设置的现有值。如果使用 mqsichangeproperties 和 Configuration Manager Proxy 来同时设置某个属性,那么即使代理与 Configuration Manager 之间尚未进行同步,最后应用于代理的更改将是持久的更改。该更改可能是通过 Configuration Manager Proxy 或 mqsichangeproperties 命令做出的。

    因而,如果您仅在代理计算机上本地设置和获取这些代理配置属性,则使用 mqsichangeproperties 是完成此任务的方便快捷的方法。但是,如果要从远程计算机设置或获取这些属性,则最好仅通过 Configuration Manager Proxy 应用程序对其进行设置,因为您不需要等待 Configuration Manager 与代理之间的同步。无论您更喜欢哪种设置属性的方法,保持一致都是有帮助的——尽量使用一种技术或另一种技术,但是不要同时使用两种技术。

跟踪节点

Message Broker V6.1 中通过 Configuration Manager Proxy 和 mqsichangetrace 命令公开的另一个新的运行时属性是启用和禁用消息流或执行组中的跟踪节点的切换开关。此功能非常有用,因为跟踪节点通常在消息流开发过程中用作调试辅助手段。但是在生产系统中发布跟踪节点并非始终适宜,因为使用此类节点具有性能影响。过去,您必须删除任何跟踪节点并相应地重新连接消息流,这是一个手动过程,具有意外修改消息流逻辑并影响其操作的风险。

从操作上禁用跟踪节点的能力意味着,在将包含此类节点的消息流移动到生产系统时,不需要对其进行修改,从而消除了改动流程中的逻辑的风险。此功能的另一个优点在于,如果在将消息流发布到生产系统以后发现问题,可以重新启用跟踪节点并潜在地获得有用的诊断信息。

动态服务选择

动态服务选择是基于操作上定义的标准来调用服务的能力。除了其他用处以外,此功能在需要将消息流部署保持在最低限度的环境中非常有用。此功能由 Message Broker V6.1 中的两个新节点提供支持,这两个节点允许与 WebSphere Service Registry and Repository(以下称为 Registry and Repository)的实例进行交互。

通过结合使用 Registry and Repository 和 Message Broker,您可以定义消息流从 Registry and Repository 中查找服务定义,然后调用所返回的 Web 服务。然后通过手工操作 Registry and Repository 的内容,您可以动态地修改所返回的服务,从而影响代理执行的逻辑。下面的图 7 显示了连接在一起的两个节点如何能够支持此行为。EndpointLookup 节点用于从 Registry and Repository 查找某个文档,并配置代理的消息树中的服务请求信息以使其引用所返回的服务,这意味着然后可以将其直接连接到 HTTPRequest 或 SOAPRequest 节点中,从而调用所返回的服务。


图 7. 使用 EndpointLookup 节点调用 Registry and Repository 中定义的 Web 服务
图 7

您还可以调用非基于 Web 服务的文档。可以使用 RegistryLookup 节点从 Registry and Repository 返回任意文档,其中可能包含任何外部服务的寻址细节。对返回的文档进行解析,并使用 Compute 节点(举例而言)设置调用标准以输入请求类型的节点,然后调用该节点。

此类用法的常见模式是使用动态计算得出的样式表进行 XML 消息转换。如果使用 Registry and Repository 存储 XSL 样式表并使用 RegistryLookup 节点检索它们,则可以将返回的样式表嵌入在消息的 XML 正文内,然后使用 XSLTransform. 节点进行转换。

结束语

本文概括了 Message Broker V6.1 的一些旨在最小化消息流测试和重新部署需要的功能。然而要记住,部署是不可避免的事情。相反,定期的部署是更新应用程序集成基础结构并使其更灵敏地响应业务需要的方法。定期的部署还有助于使系统保持可管理,并让环境保持清洁、可再现的状态。在某些安装中,管理员是如此地讨厌重新部署消息流,以致基础结构变得陈旧落后,到需要重新部署的时候,该过程对管理员来说已变得如此陌生,代理的内容变得如此混乱(并且在某些情况下是未知的),以致该过程不必要地变得非常困难。

优秀的管理员应该在部署和操作调整之间寻求平衡。有了常识、有效的发布流程和本文中的信息,应该不难实现这种平衡。



参考资料



关于作者


Matt Lucas 是位于英国的 IBM Hursley Software Lab 的 WebSphere Message Broker 开发团队的一名软件开发人员。他于 1997 年加入 IBM,自从 WebSphere MQ V2.1 于 2001 年发布以后,他一直担任 WebSphere Message Broker 的开发团队负责人。他以前负责 WebSphere Message Broker Configuration Manager Proxy API 的开发,现在负责管理体系结构。他在空余时间喜欢上剧院、弹钢琴,并玩许许多多的视频游戏。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14789789/viewspace-539714/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-07-08

  • 博文量
    355
  • 访问量
    863691