中心数据交换平台建设方案

XX 省电子政务系统

数据交换平台

国际商业机器中国有限公司 2005.5

目 录：

1 概述

数据交换共享平台是协作式电子政务应用平台（包括政府职能部门之间的电子协作、政府与公众/企事业单位的服务管理等）的核心基础服务模块，负责实现跨系统的数据交换、流程控制和分布式数据存储服务。

数据交换平台的目的是实现每个合法用户将其所要传输的数据包安全可靠地传输到指定的地方。数据交换平台支持常见数据库类型、多种业务类型、多种数据传输方式和网络特性，是各类应用系统共享信息资源的公共渠道，是应用系统扩展的接口。

面向服务的体系架构

目前，大多数企业都有各种各样的系统、应用程序以及不同时期和技术的体系结构。集成来自多个厂商跨不同平台的产品和应用系统，一直是企业IT 部门的主要挑战。面向服务的体系结构为解决这一问题提供了良好的途径。

SOA 是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

以服务为导向、开放、松散耦合的总体目标架构，在应用系统的规划设计时，我们遵循如下业务集成参考架构。

图 IBM 基于SOA 的业务集成参考架构

SOA 的主要组件包括服务、动态发现和消息。

服务是能够通过网络访问的可调用例程。服务公开了一个接口契约，它定义了服务的行为以及接受和返回的消息。术语服务常与术语提供者互换使用，后者专门用于表示提供服务的实体。

接口通常在公共注册中心或者目录中发布，并在那里按照所提供的不同服务进行分类，

就像电话簿黄页中列出的企业和电话号码一样。客户（服务消费者）能够根据不同的分类特征通过动态查询服务来查找特定的服务。这个过程被称为服务的 动态发现。

服务消费者或者客户通过消息来消费服务。因为接口契约是独立于平台和语言的，消息通常用符合 XML 模式的 XML 文档来构造。

SOA 结构中，中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为随需应变业务，在随需应变业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。服务包括：

1) 用户交互服务。为用户在界面上提供一个统一的信息服务功能入口。通过将内部和

外部各种相对分散独立的信息组成一个统一的整体，保证了用户既能够从统一的渠道访问其所需的信息，也可以依据每一个人的要求来设置和提供个性化服务。

2) 应用服务。通过HUB 或总线架构，实现应用与应用之间的连接，完成相关的数据

路由与数据格式转换。

3) 信息集成服务。实现数据或整合，在异构的数据源之间实现数据层的直接整合。通

过建立统一的数据模型来实现不同系统间的信息转换。

4) 工作流程服务。实现业务流程管理，包括工作流管理、自动化流程两层面。它将不

同的应用系统连接在一起，进行协同工作，并提供商业流程管理的相关功能，包括流程设计、监控和规划，实现业务流程的实时管理。同时支持行业标准（如RossetNet 、ebXML 、EDI 、CIDX 、SWIFT 、FIX ）以适应企业集中、扁平、透明的管理机制，适应企业供应链、企业内部流程共享和流程优化。

5) B2B 集成服务。通过多种连接方式，接入第三方的系统，如ERP 等。

企业服务总线

每个企业在信息系统建设过程中必然涉及到多个应用系统（可能运行于不同的平台之上，采用不同的开发语言与模式进行开发）之间的相互集成需求（Information Connectivity&Integration或者大家熟知的EAI ），采用何种集成体系结构必须慎重考虑。当前大部分的企业采用的应用系统之间的集成是一种点对点的体系结构，具体请见下图：

图 基于点对点的集成架构

点对点的应用系统集成结构的出发点很简单，当两个系统之间需要相互协作时，为这两个系统开发相应的连接组件(Adapter)将二者互联。这种由简单出发的结构存在着严重的隐患：随着应用系统个数的增加，连接组件(Adapter)的数目将快速增长（总数为n*(n-1)个连接组件，其中n 为应用系统的个数），而且在不同应用系统之间由于缺乏自动提交请求的机制，必须在相关的连接组件内部固化请求的提交功能，应用系统之间存在着高度的藕合性，这为系统的维护带来了巨大的复杂性，任何一个系统的升级或改动都将影响到其它与之相关的应用系统的修改；同时当一个新的应用系统需要纳入整个应用集成体系时整个工作变得非常复杂。

The Hub and Spoke提供克服传统点对点缺点和 Enterprise Service Bus (ESB)趋势的分配和模块架构。重要的是一个建立在 ESB 上的集成趋势，它提供一个普通的商业目标模式，它运作起来像数据隔离层，分隔特别应用数据和逻辑过程相关数据。另外，相比以前的趋势，连接器和接口数减少，整合努力减少了。继续上面的例子，只有5个连接器和10个接口需要建设。

图 基于Application Hub的集成架构

良好的EAI 体系结构应该保证不同应用系统之间的高度内聚，同时又保持各个应用系统的相对独立性，系统之间存在着松散的藕合关系。基于Application Hub 的EAI 结构能够满足复杂的企业应用集成需求和发展的需求。

与点对点的EAI 结构相比，在基于Application Hub的EAI 体系结构中，连接组件的数目很少（一个应用系统对应于一个针对Application Hub的连接组件，总数为n 个。n 为被集成的应用系统的个数）；而且各相互集成的应用系统之间不存在直接的关联，所有的集成工作通过中央Application Hub 进行，当某应用系统需要与其它的系统集成时该应用程序发请求（一般通过消息的方式）给Application Hub ，由Application Hub 自动地将该请求转发给相应的目标系统进行处理后将结果返回给请求者。在这种体系结构中，系统的维护非常简单，每一个应用系统的更新和修改都能够实时地实现，同时当新的应用系统出现时能够简便的纳入到整个IT 环境当中，与其它的应用系统相互协作，共同为用户提供服务。

企业服务总线（ESB ）和以服务为导向的应用架构体系（SOA ）紧密连接在一起，企业服务总线（ESB ）是以服务为导向的应用架构体系（SOA ）的核心组成部分。企业服务总线（ESB ）为以服务为导向的应用架构体系（SOA ）提供了连通性基础架构，它是SOA 架构下Application Hub 的具体体现。如上图所示，在SOA 架构上发布的业务服务是ESB 的“用户”，这些基于SOA 架构的业务系统所开放出来的服务通过ESB 进行交互。它们的交互请求被以事件的方式进行发布和订阅。IBM 的企业服务总线解决方案是WebSphere MQ 以及WebSphere Business Integration Message Broker。

2 数据交换系统采用中间件的必要性

中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，管理计算资源和网络通讯。它在计算机系统中是一个关键软件，它能实现应用的互连和互操作性，能保证系统的安全、可靠、高效的运行。

中间件的跨平台性可以屏蔽操作系统的差异，克服网络状况不理想的限制，另外，使用中间件可以缩短系统的开发周期，使集成商把更多的精力投入到各有价值的业务应用开发中。

目前中间件的种类很多，为实现安全、可靠的数据传输交换平台和应用整合方案，利用消息传输中间件(MOM)是最佳的选择。它简化了应用之间数据的传输，屏蔽底层异构平台，提供一致的通讯标准和应用开发，确保数据交换网络上可靠的、跨平台的信息传输和数据交换。它基于消息队列的存储-转发机制，并提供了特有的异步传输机制。优秀的消息中间件能够基于消息传输和异步事务处理实现应用整合与数据交换。

在XX 省电子政务数据交换项目中，使用中间件的必要性有以下几个方面：

数据传输量大

数据交换应用系统建成以后是一个覆盖各委办局的复杂的应用系统，并且在这些节点之间存在大量的数据需要传输，在如此众多的应用节点之间如果缺乏快速可靠的消息传输机制，将导致整个系统的故障率大幅上升，从而使整个系统陷于不可用状态。因此快速而可靠的消息传输机制将是企业内部统一数据交换系统取得成功的重要保证。

数据传输的安全性要求很高

信息的准确性和安全性直接影响客户满意度

系统维护和管理的任务和风险很大，某些单位的工作人员的IT 水平有限，需要采

用一种自动化的数据传输和管理手段，降低系统维护的成本

与其他单位的数据交换

在实现数据交换的同时，电子政务系统还存在与其它系统进行数据交换的需求。 各种应用系统的互通，在多个应用系统之间进行数据交换，而未来参与数据交换的

局委办应用系统数目更会不断的增加，如何应用维护的工作量最小。

在未来数据交换的进行过程中，对于用户需求的变化带来的用于应用系统之间交换

的数据格式、数据内容的改变，如何进行有效的管理和维护。

鉴于以上方面的考虑，我们建议在电子政务数据交换项目中采用适当的中间件技术来实现项目的建设和规划。

为了解决数据传输的问题，我们推荐IBM 公司的WebSphere MQ和Message Broker通讯中间件。WebSphere MQ 是IBM 公司为用户提供的消息服务中间件，以80%左右的全球市场占有率遥遥领先于其它所有的MOM(Message-Oriented Middleware) 中间件产品。WebSphere MQ采用异步的消息机制在不同的服务器节点之间保证可靠的信息传递服务，在此过程中WebSphere MQ能够自动屏蔽各种异常和故障而保证将数据信息传送到目的地，每种信息将至少被传递一次而且只被传递一次。在电子政务数据交换应用系统中，采用WebSphere MQ，相关信息（以及其它任何所需的信息）能够在各局委办之间实现灵活而可靠的消息传递，即使在传输过程中网络或任何软件、硬件系统出现故障，WebSphere MQ也能够保证将信息安全地传送到目的地。

它的特点：统一的接口，缩短开发周期；可跨多种平台；保证复杂环境下的可靠传输；适用于分布式处理；处理不依赖于时间的限制。

我们建议采用IBM 公司的应用整合中间件WBI Message Broker 作为一个信息/数据总线。它提供了基于Application Hub的通讯连接和应用整合方式，能够有效地提供数据路由、加工处理和格式转换等功能。

Message Broker位于电子政务数据交换平台的核心，连接各个委办局，起到一个交通和通讯枢纽的作用。它可以简化系统的配置，同时提供各种数据处理服务，如：数据的计算、过滤、数据库操作等；实现各种不同数据格式之间的转换，如：传统数据格式与XML 格式之间的转换；实现基于数据内容的智能路由，从而调用不同的字模块所提供的服务；对原有应用的修改减少到最低限度，并具有高可扩展性。

3 IBM 解决方案

3.1 方案描述

XX 电子政务数据交换平台是是基于成熟可靠的JMS 技术的数据交换、数据流管理和跨厅局协同工作功能的应用支撑平台系统。

信息交换系统是电子政务综合业务支撑平台所提供的关键服务。通过信息交换系统，实现电子政务系统跨平台、跨系统、跨应用、跨地区的互联互通和信息共享，为政府部门之间进行公文交换、网上审批等提供支持。

数据交换中心处于核心位置，通过配置在数据交换中心的数据交换服务器提供的标准化的适配器和接口为每个数据交换节点（需要进行数据交换的各个厅局）提供服务。每个数据交换节点只需要与数据交换中心通过数据适配器进行交互，并通过XML 进行数据转换。

在充分了解当前项目需求并考虑未来扩展的基础上，建议采用如下的系统架构来实现数据交换平台。

“数据交换平台”功能架构图

在上面的系统架构图中，主要由如下几个主要功能模块组成：

可靠的消息传输服务

可靠的消息传输服务是" 数据交换平台" 最重要的底层基础服务。利用消息中间件软件，通过业界流行的队列机制可以方便地实现跨越不同厅局、不同网络、不同操作系统的数据交换与共享，并可以透明地处理诸如宕机、网络堵塞、网络中断等各种复杂的通讯异常。 该基础模块提供了标准的数据封装接口，能够以多种协议为基础实现数据交换功能，屏蔽底层通讯机制，从而提供了可靠的数据传输保证。

消息代理服务

消息代理服务是" 数据交换平台" 的核心服务。消息代理服务运行在基础消息传输服务之

上，为数据交换平台提供了强大的信息格式转换与信息路由的功能。其高性能的消息处理引擎，灵活的系统扩展机制与负载均衡的架构设计，完全满足了" 数据交换平台" 未来的升级扩展。

人员交互、安全认证、管理监控、信息存储等辅助服务

相关平台辅助服务是" 数据交换平台" 不可或缺的功能，进一步简化并完善了平台的功能。

我们建议在省电子政务系统中心配置WebSphere Business Integration Message Broker, 在各局委办安装配置WebSphere MQ。

对于WebSphere MQ 来说，两个WebSphere MQ 系统要进行通讯，需要建立它们之间WebSphere MQ的逻辑连接——通道。因此在这里需要在每一节点上为需要进行通讯的相邻的节点定义配置WebSphere MQ通道。

采用这种点对点的通讯方式，如图：

系统将会是一个复杂的网状结构,n 个系统要建立n(n-1)个连接，系统的维护和管理将会比较复杂，重要的是局委办的数量很多，并且它们之间存在着互相通信的需求，在这种情况下，如果将这么多的节点两两相连，其配置将会比较复杂，最为重要的是，其管理和维护的成本会很高，所以这种方法显然是不可行的。

Message Broker的设计理念恰恰是要改变这一结构的弊端，将网状结构变为星型结构，它采用”hub and Spoke ”的设计思想。大大减少系统间的连接个数，从n(n-1)个减少到n 个，使系统的配置和管理大大简化。

随之而来的是，系统的可扩展性大大增强，每新增加一个局委办，不必建立它和其他局委办之间的两两连接，而只需连接到Message Broker 上，通过Message Broker 便可以实现与其余支局的连接和通讯。

这样，我们构造了一个WebSphere MQ通讯网络，作为各种应用系统的公共数据传输平台，使得纵向、横向的信息可以在系统内部顺畅地流动，而不会因为网络或系统故障造成信息的丢失或重复传递。对于各种应用程序来说，只需调用WebSphere MQ提供的编程接口来发送/接收消息即可, 大大提高了应用开发的效率和质量，并降低了系统维护的难度。

此外，在各应用系统通过中心数据交换平台进行数据交换时，如何根据数据内容的确定数据的路由选择也是一个较大的挑战。Message Broker的智能路由功能能够让用户根据消息的格式和内容定义消息转换和路由决策，规则的定义可以通过GUI 界面来实现，十分简单易行。如我们可以在数据中设定路由信息标志位，MQ 本身是无法解析数据报中内部的具体信息的，而Message Broker,可以解析和识别消息的具体内容，可以根据消息中设定的路由标志位进行数据的智能路由。如：从A 市将数据发给Message Broker，Message Broker可以智能地分析数据的目的地，并准确将数据转发出去。

通过智能化数据路由和转换功能，用于可以在应用程序之间实现消息流，同时满足业务过程的数据流要求；同时它可以随着业务要求的变化而变化，当业务需求变化时，仅需对Message Broker,做必要的更改，而无需改动原有的应用程序，使系统的可扩展性大大增强。

除了智能路由功能之外，Message Broker还具有以下更加丰富和完善的功能：

对数据的各种复杂的计算和处理功能。它用每一个Node 表示对消息的一种处理，如compute node 可以对消息进行各种计算操作，其他Process Node 有：input node, output node, filter node, check node 等；node 与node 相连，便组成了一个Message Flow，由各种“Processor Node ” 组成的Message Flow ，可对消息进行各种处理操作，在消息从数据中心经过时便可以被进行相应地计算，从而发往目的应用系统；

数据格式转换和路由服务。Message Broker提供多种数据格式服务，其中包括：自定义格式，用户可以通过MRM(Message Repository Manager)来定制自己的消息格式；XML 格式；面向纪录的信息格式，如C 的头文件，COBOL records 等。对于这些消息格式，它提供

相应的剖析器进行解析，实现它们之间的格式转换。如对于用户的bit stream的输入信息可以输出为XML 的格式，反之亦然。

与数据库紧密集成。提供了与DB 操作相关的各种Node, 如INSERT,UPDATE,DELETE 等Node ，用户可以之间通过ESQL 进行和数据库的操作，如把数据存入数据库，从数据库中取数据等；这样，当数据通过Message Broker时，我们便可以将数据进行各种数据库操作，为今后的数据仓库做准备。

应用整合功能，Message Broker是IBM 的应用整合中间件。从电子政务系统的一个横截面来看，存在很多业务系统，在系统今后的发展过程中，必然需要进行应用整合，即实现各个子系统之间的数据交换和数据共享。

为了实现各应用系统间的数据交换和数据共享，我们更加建议星型Message Broker 解决方案——即位于同一层次上的各应用系统均通过它互相连接。

考虑到在各业务系统建立时都是以各业务部门为主进行，且各自的业务属性也有较大的不同，故各应用系统间在数据定义、数据格式上必然会存在着或多或少的差异性。这就为各应用系统间的数据交换带来了一定的困难。通过Message Broker，用户完全不需要专门开发接口和路由选择程序，只需要在中心的Message Broker上对每个业务系统的数据格式作相应定义，并定义相关的数据路由规则即可。这样一方面简化了其实现方法，另一方面大大提高了系统的可维护性。

3.2 方案设计中的核心要点：

1）采用业界成熟的产品：对于一个企业级的应用，这一点是非常必要的；

2）采用一个合理的架构：在通讯节点众多时，要避免采用复杂的网状架构，要采用先进的星型架构；

3）关于MQ Server和MQ Client的选择：

MQ Client为我们提供了一个MQ 应用程序的开发和运行环境，它是MQ API的Client 实现。在Client 环境下，没有队列管理器、队列等对象，它通过MQI 通道与Server 之间建立实时的通讯，并将消息从Client 端发往Server 端的队列，或从Server 端的队列中取得消息。

MQ Client提供下列好处：适合同步处理的工作模式；减少系统负担；减少系统管理开销；减少磁盘空间要求等。

MQ Client比较适合于网络条件较好或实时通讯的情况。它的劣势在于以下几方面： 它和服务器端是一个实时、同步的连接，失去了MQ Server产品所具有的异步、可靠传输的特点；

在大数据量传输时的效率问题，在进行大数据量传输时的问题，由于要进行拆包处理，这时为了保证数据的完整性，我们要对多个被拆的小包设置在同一个工作单元中，用Client 传输时，如果中间网络断了，所有的包都会被回退，然后被重传，降低了传输效率。

通讯方向问题：MQ Client和Server 之间的通信是单向的，Client 只能向Server 发数据，在取数据时，它只能主动地到Server 上取，这时就必须利用一个轮循程序，不断地到Server 上去取，在轮循的间隙，如果网络出现问题，该程序就会出现问题，被挂起，必须人工干预来将该程序重起。

其它方面的功能：MQ Client不具备其他一些Server 具有的重要功能，如：SSL 加密，群集负载均衡等。

MQ 产品分为Server 和Client 两种版本，与Client 不同，Server 的运行环境拥有队列管理器、队列、消息通道等对象，它提供全面的消息服务。通常在广域网环境下，以及在企业

与企业之间进行通讯的情况下，我们都建议配置MQ Server对Server 的通讯环境。

MQ Server是一个异步传输中间件，用于实现客户位于不同系统、不同平台下的数据交换。WebSphere MQ 具有强大的跨平台性，可以支持35种平台，它利用消息机制实现应用系统间数据的传输和通讯，无论出现何种异常故障（如网络断线、网络阻塞、系统当机等），都能确保应用程序数据在传递过程中不丢失、不重复，而当故障恢复时，WebSphere MQ 可以将未成功发送的信息自动发送至应用系统，而无需人工干预。

在大数据量传输上，在MQ 中有逻辑消息和物理消息的概念，利用逻辑消息和物理消息，我们可以将大消息进行分段处理，也可以将若干个本身完整的消息在应用逻辑上归为一组进行处理。对于分段消息的传输，MQ 用一阶段提交的方式来处理，即把所有segment 消息当成一个完整的事务，保证他们或者都被传输到接收方的应用程序，或者一个都不传输。

MQ Server之间可以通过自身的群集功能，实现负载均衡。

MQ Server 的队列管理器可以具有事务控制的功能，即它可以利用与数据库之间XA 的连接，实现数据库与MQ 队列操作的两阶段提交。

MQ Server支持触发、消息分发/订阅等功能。

在安全控制方面，MQ Server支持Server 之间通道的SSL 加密。

在可靠性上，MQ Server支持HA 。

从XX 电子政务的业务需求来看，各个局委办之间的数据传输，可以用异步的处理方式处理。要在网络条件畅通的前提下，及时发送到达。在这种需求下，建议采用MQ Server。 另外，针对XX 电子政务目前的网络状况、系统的规模以及可靠性、安全性的要求，我们认为使用MQ Server能更好地满足系统需求。

3.3 推荐配置

省中心：

软件：WBI Message Broker

硬件：IBM pServer 570, 操作系统：AIX V5.3

各局委办：

软件：WebSphere MQ Server

硬件：PC Server，操作系统: Linux

省中心各局委办

服务器服务器服务器服务器

4 IBM 解决方案的优势

WebSphere MQ和Message Broker在电子政务数据交换系统的优势主要表现在传输的可靠性、安全性、灵活性、应用集成和数据交换等诸多方面。

4.1 强健的数据传输系统，灵活的通讯方式

采用WebSphere MQ可以实现关键数据在任意网络环境中的安全、可靠传输。

采用消息中间件WebSphere MQ 的应用系统是三层次的结构，而由于将通讯逻辑的部分独立出来，使得系统的可移植性、可扩充性和可维护性都大大提高。中间件是随着计算机在社会生活的各个层次广泛应用近年来迅速发展、壮大起来的一个软件领域。在系统应用的层次结构中，中间件位于操作系统和用户应用之间。对应用程序来说，其主要作用是屏蔽操作系统和网络协议。应用开发人员编程时只需利用中间件产品提供的跨平台的、统一的接口，而不必考虑操作系统的差异。在提高应用程序的可移植性的同时也缩短了应用开发的周期。中间件的采用可以为我们节约大量的人力、物力和财力，使我们可以将更多的精力投入到真正有价值的业务应用的开发中。

4.1.1 全网通信能力，灵活的通讯方式

采用WebSphere MQ 作为电子政务数据交换系统的通讯平台不但可以使整个系统在较短的时间内建立起广域网上的可靠的数据交换系统，还能够为以后应用系统的扩充提供统一的通信接口。另外，WebSphere MQ 还支持与数据库协同工作（如IBM DB2，Oracle 等），并可连接办公自动化系统软件（如LotusNotes 等）、系统管理软件（如Tivoli 等）、企业资源规划系统（如SAPR/3）等。因此，从发展的角度看，选择WebSphere MQ不仅可以作为统一的通讯平台，还能够实现整个企业各个应用系统的业务整合，实现信息在最大程度上的共享。

WebSphere MQ提供了基于消息队列的通讯机制，而利用这种通讯机制提供给应用程序极为灵活的通讯方式：一对一、一对多、多对一、多对多的关系；实时的、批量的数据传输；同步的、异步的通讯模式。

从电子政务数据交换系统的数据传输实时性上来看，数据的传输可以分为实时数据传输和集中数据传输两类。从传输方式来看，可以分为点对点传输和单点对多点的分发式传输。显然采用WebSphere MQ可以很好地满足上述多种传输方式。

4.1.2 路由

利用WebSphere MQ，可以方便地实现关键数据在各局委办之间的传输。整个网络的任何两个节点之间通讯，不需要建立直接的物理连接，而可以通过MQ 的通讯网络来实现。

4.1.3 可靠性

WebSphere MQ由于采用了先进的程序设计思想以及内部工作机制，保证消息的可靠传递，即只传一次，不丢失、不重复，可以克服一些地区网络线路质量差的现状。

同时WebSphere MQ支持永久性的(Persistent)消息和队列，永久性的消息保存在硬盘上，

并提供独立的日志(log)系统，当关机和系统掉电消息仍完好地保存在队列中，即使存放消息的硬盘发生介质故障，我们仍然可以从日志中将消息恢复出来。相应地，WebSphere MQ提供了一整套消息的备份和恢复手段。

因此，采用WebSphere MQ可以在最大程度上保证信息的可靠传输，而且利用WebSphere MQ 的先进的传输机制，应用程序只需运行一次，将信息放入MQ 的队列中，MQ 将负责将其传送到目的系统的队列中，而不再需要人工的干预。

利用WebSphere MQ不但可以支持数据的断点续传，而且如果在传输过程中，通信线路出现故障或远端的主机发生故障，本地的应用程序都不会受到影响，可以继续发送数据，而无需等待网络故障恢复或远端主机正常后再重新运行。

同时MQ 确保信息只传输唯一的一次，而不会发生数据重复的问题。MQ 的这些特点可以帮助我们极大的提高数据传输的可靠性和效率。

4.1.4 安全性

WebSphere MQ可以实现安全的数据传输，支持SSL 加密。

MQ 为我们提供了全方位、多层次的安全管理。确保队列管理者所拥有的资源不被非法存取，防止消息泄漏。MQ 提供了OAM(Object Authority Manager)机制实现资源级和应用级的安全控制，OAM 维护了各种资源的Access Control List(控制列表) ；在消息级别上，还设置了Message Context 标识。这些机制从以下几个方面保证了系统内部的安全性：用户应用与队列管理者的连接；用户对MQ 资源，如队列、通道、过程的操作；队列管理器的管理命令；对消息的存取等。

MQ 为用户提供了多种途径确保网络传输过程的数据安全。

安全出口：主要用于两个MQ Series系统之间通道启动时的双方的身份认证；

发送和接收出口：可以用来进行数据的加密/解密以及数据的压缩/解压缩；

消息出口：可以用来在消息级实现用户的特定功能，如数据转换，加密/解密等。 此外，MQ Series在TCP/IP上还支持防火墙。

4.1.5 系统架构的可扩展性

可以随着业务规模的扩大或项目的进行，随时增加新的城市，能够与现有系统无缝整合，又能随时增加新的应用，大大减少系统间接口开发的个数。

4.2 统一的应用开发接口，简化开发

WebSphere MQ 支持35种不同的软硬件平台，在所有这些平台上WebSphere MQ 均提供相同的应用编程接口，便于应用程序在不同的平台之间进行移植。WebSphere MQ 提供的API 函数共有13个，开发简单迅速，可大大提高软件开发的效率。

4.3 跨平台性和异构系统连接能力，屏蔽网络和系统异构性

WebSphere MQ支持35种系统平台，包括IBM 和非IBM 。应用开发人员编程时只需利用中间件产品提供的跨平台的、统一的接口，而不必考虑操作系统的差异。利用WebSphere MQ 可以简单有效地实现跨平台，跨系统，跨网络协议的消息通讯和应用整合。将企业复杂

的信息孤岛联接成为共享的信息资源。

4.4 分布式系统上的数据一致性

WebSphere MQ对交易处理的支持分为三个层次：

首先，WebSphere MQ 内部一系列队列的存取操作可以构成一个工作单元，同时进行提交或回退。

其次，支持XA 标准，可以在多种交易处理软件的参与下实现WebSphere MQ队列操作与数据库操作的同步，完成两阶段提交；

其三，WebSphere MQ 在作为资源管理者的同时，可作为资源协调者，具备部分交易处理管理器的功能，可以在没有交易处理软件参与下，通过XA 标准控制WebSphere MQ与数据库的协同工作，实现了与数据库更为密切的结合。

WebSphere MQ如此全面的对交易处理的支持，是任何同类产品都无法比拟的。

在电子政务数据交换需求中，涉及到MQ 与数据库的协同工作，利用MQ 的优越特性，可以保证数据的一致性和交易完整性。

4.5 可维护性

MQ 为用户提供了良好的管理界面，方便用户对中间件系统的配置和管理工作，通过管理界面，用户可以定义、修改、删除中间件的各种资源、对象，察看各种对象的属性，监控各种对象的运行状态；在各个平台上使用的系统管理命令是相同的，在一个有若干平台共存的系统中大大地方便和简化了系统管理的工作。

MQ 提供了远程管理机制，在互相联接的系统中的任意一个节点都可以进行对其他所有节点的配置和管理，在NT/2000平台上还提供了图形界面的管理工具。可以把一个节点设成管理机，利用管理机可以监控和配置网络中的任一节点，监测和显示整个网络中任何一个节点上的服务器及其各种对象的状态和运行情况，从而实现对中间件的集中管理和监控。 MQ 不仅自身提供了GUI 和文本化监控工具来监测和显示对象的状态, 并且能够利用各类网管软件对整个网络运行状况实施监控；如Tivoli Manager for MQ就是一个功能强大的综合管理工具：它为控制消息和应用程序框架提供了一个集中管理平台。它捕获和显示MQ 的事件，并能发现新的队列管理员以及相应的对象，这些对象可以通过中央控制台进行定义和配置。除此之外，许多第三方厂家也提供有类似的管理工具。

4.6 数据交换机制

通过在中心采用Message Broker的解决方案来实现各业务系统之间的数据交换和路由，这样各系统间不必为与其它系统的数据交换分别开发系统接口，而只需要将其信息定义格式以及与其它业务系统的数据交换规则（如信息格式转换方式、额外的信息处理工作以及信息的路由规则等）预先在综合信息中心的Message Broker上进行定义即可。

以上数据交换机制的优势主要在于：

首先，通过建立数据交换中心能够大大降低建立各业务系统间数据交换机制的复杂度和工作量。

其次，便于统一集中管理各业务系统间的数据交换，避免无序混乱的数据交换。

最后，这种集中式的数据交换机制具有极大的灵活性，既有利于以后新的业务系统与原

有系统的整合的连接，并且当原有业务系统发生变更时，其相应数据交换方式的修改也非常简单。

4.7 不同应用系统的整合

如果对于局委办有许多不同时期、不同厂家开发的应用程序，这些应用程序位于不同的系统，使用不同的编程语言和不同的通讯方法。消息队列技术可以在这些差异之间架起桥梁。

消息队列是非常强大的技术，只需在每一应用程序中进行简单的编程就可以实现一对

一、一对多、多对一、多对多的连接。通过消息队列技术，可以简单地交叉连接应用程序，而新增的功能使之可以将系统的优势扩展到整个网络。采用Message Broker还能够实现诸如自动数据格式转换、动态路由以及企业应用整合等高级业务整合功能。