MQ 的安全性实现

在实际生产系统上，安全性是一个重要的要求。除了在网络和操作系统上提供通用的保护外，在 WebSphere MQ 上，还需要提供一些安全性控制手段。首先 MQ 提供对 MQ 资源管理的安全性控制管理，确保 MQ 资源只能被合法的人定义和改动，其次 MQ 提供对 MQ 资源访问的安全性控制，确保本地 MQ 里的信息只能被合法的人使用，再次提供对 MQ 通道的安全性控制，确保只有合法的人才能够从外面向本地 MQ 传递信息。这样，通过这三个方面的保护，MQ 实现了一个安全可靠的信息处理系统。

MQ 资源管理权限

MQ 资源管理权限主要包括对以下操作的权限管理：

• 对 MQ 服务器发布管理命令
• 在 MQ 服务器上使用 WebSphere MQ Explorer
• 在 z/OS 上使用 MQ 控制面板
• 在 z/OS 上使用命令工具如 CSQUTIL 等
• 在 z/OS 上对 MQ 数据集的访问

把这几条路径管理好了，就能保证 MQ 系统资源配置的安全，从而不会发生恶意或意外的改变。当 MQ 部署在 z/OS 上时，它的安全认证是通过 external security manager (ESM) 实现的，在默认情况下，这个 ESM 是 RACF（Resource Access Control Facility，IBM的主机操作系统的安全管理产品），MQ 通过 RACF 里定义的 profiles 对用户访问权限进行验证。为达到目标，管理员要根据实际情况建立适当的 RACF profiles 并且为系统用户和组进行适当的授权。

客户可以根据需要对 MQ for z/OS 的安全管理选项进行打开和关闭。如果选项关闭，则 MQ 不会做任何安全检查动作。安全管理选项的打开和关闭可以在单个 MQ Server 的粒度上实施，也可以在 Queue Share Group 的粒度上实现，也可以采用混合模式，当在 Queue Share Group 的粒度上实现时所有 MQ Server 都用相同的 RACF profiles 进行安全检查，安全管理简单而且一致，这是一种比较常用的方式。

有关 MQ 资源管理安全的具体实现，请参考《WebSphere MQ for z/OS Version 6.0 System Setup Guide》的第 12 章：Using RACF classes and profiles。

MQ资源访问权限

MQ的资源访问权限主要保护如下的 MQ 资源：

• Queue managers
• Queues
• Processes
• Namelists

这些资源可以通过如下方式进行访问：

• 通过在应用程序中使用 MQI 应用接口进行访问；
• 通过 MQ 管理界面进行访问；
• 通过 Programmable Command Format (PCF) 命令进行访问；
• 可以通过 CSQUTIL、CSQUDLQH 等工具程序进行访问。

进行这些访问时，MQ 会进行访问权限的检查。为实现这些控制，需要在 RACF 里建立适当的 profiles 并为系统用户和组进行授权。

一些 MQI 的命令，如 MQOPEN 和 MQPUT1 允许使用 Alternate user authority。操作时使用指定的用户名进行操作，而不是程序自己的用户名。这时需要两个条件都满足才能成功：首先运行程序的用户有使用 Alternate user authority 的权限，其次指定的用户在操作对象上有所需的权限。

CHANNEL安全权限

除本地 MQ 访问以外，远程 MQ Server 可以通过远程队列的方式，通过 Channel 把消息放到一个 MQ Server 的队列中；同样写入远程队列的消息也会通过 Channel 传递给远程服务器，所以 Channel 上的安全性也是 MQ 整体安全的一个重要部分。

作为发送方通道，Channel 的用户需要有对 Transmission Queue 的访问权限，这样才能正常把消息发送到远程队列。可以通过设置通道的 MCAUSER 参数来改变 Channel 用户名，默认情况下，它将是 Channel-Initiator 的启动作业相关联的用户名。

作为接收通道，用户要具有对目的队列和死信队列的访问权限，通道定义语句里的 PUTAUT 参数指定哪个用户标识是用于这些检查的：可以指定使用运行 Channel 的用户名进行检验，也可以指定使用接收到消息的消息头里 UserIdentifier 字段里指定的用户名进行检验。

通信安全性 —SSL

在MQ的通道安全性机制之上，我们可以进一步使用安全套接字层（SSL）协议来对通信链路上的数据进行保护。安全套接字层协议提供业界标准通道安全性，具有确认通信对象、防窃听、防数据篡改的功能。通过 SSL 支持可以实现以下的安全性：

认证：启动支持 SSL 连接的队列管理器或客户机可确定它们正在连接的队列管理器的身份，正在接收连接的队列管理器可检查正在启动连接的队列管理器或客户机的身份。

消息加密：通过使用唯一的会话密钥，SSL 可加密通过连接进行交换的所有信息。如果信息受到未授权方拦截，这可以确保此信息无法查看。

消息完整性：数据不会在链路中被篡改。

使用SSL通道时，当队列管理器连接至另一个队列管理器，这两个队列管理器执行证书的标准 SSL 交换和验证检查。如果验证成功，则建立连接。要达到此目的，必须使用适当的证书设置来配置这两个队列管理器以及它们将使用的通道。当消息沿着通道从一个队列管理器发送至另一个队列管理器时，通常使用证书交换期间已建立的会话密钥来加密数据。要实现 SSL 配置，必须使用适当的证书和加密算法来配置将要使用的通道。具体配置过程，请参考《WebSphere MQ Version 6.0 Security》的“Part 3. Working with WebSphere MQ SSL support ”部分。

回页首

MQ 与传统 CICS 应用的连接

在使用 IBM 主机的大型企业里，一般采用 CICS 作为联机交易支持系统，经过长年 IT 的发展，CICS 系统里积累了大量的企业核心业务应用，MQ 作为应用集成的重要工具，是否能够方便灵活地与 CICS 中的程序进行连接，是个重要问题。

在主机上，MQ 与 CICS 有很好的应用集成，可以方便地从 CICS 中使用 MQ 资源，也可以容易地从 MQ 中调起 CICS 程序进行业务处理。MQ 提供两种主要的方式与 CICS 连接方式，一种称作 CICS adapter，通过 CICS adapter 的功能，CICS 应用程序可以访问 MQ 队列里的数据；另一种称作 CICS bridge，通过 CICS bridge 的功能，向某个 MQ 队列发送包含 COMMAREA 的消息，从而自动触发起 CICS 中处理程序运行，并自动把 CICS 程序返回的 COMMAREA 写到返回队列里去，这个 CICS 程序不必为 MQ 调用做任何改变。

CICS adapter

CICS adapter 把 CICS 与某个 MQ 队列管理器相连，使得 CICS 程序可以通过标准的 MQI应用接口访问 MQ 资源，CICS adapter 本身包括：

• 一组控制功能，用来管理 MQ 与 CICS 的连接。
• MQI stub，一组函数库，通过他们，CICS 程序可以调用 MQ 资源。

上面图 1 中的例子给出了一个使用 CICS adapter 程序的例子。它可以通过MQGET()、MQPUT() 等 MQI 调用接口来访问 MQ 资源。MQ 还会在 CICS 中安装一些交易程序，CKQC 交易用来管理 CICS/MQ 的连接和对 CICS adapter 自身进行管理。CKTI 交易是任务初始化程序，它用来监控 MQ 触发信息，如果某个 MQ 队列上定义的触发程序是 CICS 程序，触发条件符合时将由 CKTI 初始化运行 CICS 程序。

实际中，CICS adapter 的主要用法一般有两种，一种是由 CICS 程序主动发起，它读取队列信息进行处理，或者向某个队列发送响应/通知信息，比如 CICS 中的取款程序可以把帐户取款事件写入 MQ 队列，通过 MQ 传递到其它系统进行处理；另一种是 MQ 应用主动发起，向某个输入队列放入消息，这个队列上定义了触发器，指定将被触发的是某个 CICS 程序，当 MQ 的触发监控程序 CKTI 发现有消息到达，它会自动启动相应的 CICS 程序，这个 CICS 程序自己到队列里读取数据进行处理，最后把返回数据写到返回队列里去。

CICS bridge

WebSphere MQ-CICS bridge 提供了一种方便的手段，使 MQ 应用可以调用 CICS 程序并传递参数，这个 CICS 程序可以是现有的使用 COMMAREA 传递参数的任何程序，它里面不必做任何 MQ 调用。使用 MQ-CICS bridge 可以很容易地把现有的 CICS 传统 DPL 应用程序提供给 MQ 应用程序调用，不必对现有程序做任何改写和重新编译。对于传统的面向 3270 终端的 CICS 程序，也可以通过 3270 bridge 格式进行调用，而不必对应用进行修改。

如上图 2 所示，使用 MQ-CICS bridge 时要定义一个输入队列和一个输出队列，并对 MQ-CICS bridge 进行配置。MQ 应用程序向输入队列中放入一个包含需要传递给被调用的 CICS 程序的 COMMAREA 数据的消息，MQ 提供的 Bridge Monitor 程序会监控到有新消息到达，它会 START 一个 MQ 提供的 Bridge Task 处理程序，这个程序从队列中读取消息，取得应用所需的 COMMAREA，然后使用 LINK 命令去调用指定的 CICS 业务程序，这个业务程序处理完毕后，在 COMMAREA 里返回结果数据，Bridge Task 处理程序会把含有返回 COMMAREA 的消息写入返回队列，最后 MQ 应用从返回队列中取走数据进行显示或进一步处理。在这个过程中，对 MQ 应用来看，它把包含输入 COMMAREA 的数据写到一个队列，就可以到另一个队列去读取包含返回 COMMAREA 的结果数据；对 CICS 业务应用程序而言，它是从 COMMAREA 接收数据，从 COMMAREA 返回数据，与平常的运行一样，到底是被其他业务应用程序调用的还是被 MQ-CICS bridge 调用的，对它没有分别。

通过 MQ-CICS bridge 调用 CICS 程序，不但可以实现单个 CICS 程序的调用，还可以实现一次调用多个 CICS 程序，一次传递一个 COMMAREA 进入，一次得到多个 COMMAREA 的返回。

使用 MQ-CICS bridge 可以很方便地把现有 CICS 程序公布在网络上对外服务，而不必对CICS 程序进行任何修改。MQ-CICS bridge 为企业应用提供了一种快速方便的 MQ CICS 连接。

回页首

使用 MQ 实现 SOA 服务

SOA（Service Oriented Architecture）是目前最流行的设计模型，用来把一些软件服务用松耦合方式联系成分布式应用。这些松散耦合的软件服务是可互操作的，他们不依赖特定计算机技术，独立于实现服务的硬件平台、操作系统和编程语言，因而有很大的灵活性。一个 SOA 应用解决方案由一组业务服务（有时又称作应用组件）连接成一个业务工作流而形成的端到端的业务应用。

为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。从最基本的层次来看，使用 SOA 做基础架构，就要涉及到如何按 SERVICE 把应用进行包装和如何把服务请求传递给正确的服务提供者。SOA 不仅需要根据标准指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务，同时在服务的提供者和消费者之间进行传输数据格式的自动改变。这样的服务路由和格式转换是就是企业服务总线（ESB）的重要功能。ESB 构成了连接 SOA 框架下各种服务的骨干，企业范围内的各种服务，通过 ESB 连接起来，服务请求者通过 ESB 来调用服务提供者，完成业务处理。

ESB 本身是不依赖于具体产品的解决方案，它的实现有很多具体的方式。我们可以通过选择成熟的中间件来实现服务的集成与互操作性。这样做的好处是由于成熟的商品中间件已经足够稳定且有丰富的工具支持，应用开发、部署、运行过程会很顺畅。目前实现 ESB 的主流方法有两种：基于 WebService 的实现和基于 MessageQueue 的实现。WebService 与 J2EE 紧密融合而且有大量工具的支持，因此在 WINDOWS 平台和 UNIX 平台上有比较多的应用。在交易量巨大的大型企业中，依托于 MQ 实施的 ESB 具有更高的效率和处理能力，而且可以十分方便地与运行核心系统的 CICS 系统进行集成，是大型企业实现 ESB 的首选方式。

通过 MQ 作为 ESB 的基础架构来实现 SOA，就要使用 MQ 在整个企业内建立各种不同软硬件平台、不同通信协议、不同编程语言的应用系统的连接，对企业的业务 Service 进行划分和定义，把每个 Service 功能以在某个特定队列守侯的服务程序方式实现，这样整个 MQ 通信覆盖的范围之内，任何应用只要向这个队列发送一个服务请求消息，就能够调用这个业务服务，达到业务重用和快速实施的效果。一旦某种业务以服务方式公布出来，未来的任何应用系统中，都可以十分方便地通过调用实现这种业务功能，只要这个系统里部署了 MQ。

在以 MQ 作为基础架构的企业服务总线之上，还可以使用 WebSphere Message Broker for z/OS来为 ESB 提供更加丰富的功能。通过 Message Broker 可以更方便地实现客户端程序以独立于所涉及的服务位置和通信协议的方式来调用服务，同时在服务的提供者和消费者之间进行传输数据格式的自动转换，例如在 C structure、COBOL copybook、XML、SOAP 等格式间自动的转换。

回页首

MQ 应用监控

作为重要的企业核心应用中间件产品，我们不但要求它能够提供丰富的功能和高超的效率，而且必须要有有效的监控手段，以使得我们能够了解 MQ 生产系统的运行状况，预防和解决系统发生的问题并对系统进行优化调整提供信息支持。

IBM 的 Tivoli OMEGAMON XE for Messaging 是一个能对 WebSphere MQ 提供全面监测和管理功能的软件产品，通过它可以：

• 监控 MQ queue manager 的一般整体状态：QM 的版本，运行平台，当前状态；MQ listener 监听的端口，当前状态；当前的应用连接，连接的状态等。
• 通过监控软件进行 QM/Channel 的启动，停止。
• Dead letter queue(死信队列)消息的监控，并可对死信进行转发/删除。
• Application queues (应用程序队列)的监控：队列满，队列的深度，队列深度过高/过低，队列不可操作，投入/取出队列消息的速率，正在操作队列的程序的状态，队列 message 内容的检视等。
• 针对队列深度，通道性能等不同对象设定阀值或组合的策略设置，策略违反时进行报警，进行预定义的操作如增加队列的深度，清除队列的消息，重启QM 或通知管理人员。
• MQ Channels 的状态，性能的监控；Transmission queues (传输对列)的监控。
• 队列、Channel（传输通道）等对象的短期/长期历史趋势报告。如队列深度，队列 get/put 消息的速率随时间的变化曲线；Channel 性能随时间的变化。
• 查看、监控 MQ 的 Error Log。
• 各种 QM 事件如通道停止、QM 起停的监控（需要 MQ 开启相应的事件通知）。
• QM 内部统计信息，连接 MQ 的应用的记账/统计信息的监控(需要 MQ 开启记账/统计功能)。
• QM 的配置，各种 queue、channel 对象配置的监视。

通过 Tivoli OMEGAMON XE for Messaging 对生产 MQ 系统的监控，我们可以有效地预防和解决问题，评估和调整系统性能。

回页首

总结：

本文是本系列的第2 部分，分别为大家介绍了 MQ 的安全性实现，MQ 与传统 CICS 应用的连接，使用 MQ 实现 SOA 服务和 MQ 应用监控等课题。这些内容构成了企业级 MQ 系统设计的主要内容，涵盖了需要考虑的主要方面。在下一部分里，作者将为您介绍 MQ 应用程序设计方面需要考虑的主要内容。