基于面向消息中间件的SOA系统集成技术探索
一种基于SOA的中间件技术
［ １ ］ 王 大 勇，李伟 ， 刘立 力． 原 油动 态计 量 交接 流量 计 系数 方 法
应 用研 究 ［ Ｊ ］ ． 油 气储运 ，２ ０ ０ ９（ １ ０）： ５ ４ — ５ ６ ．
［ ２ 】 黄兴 汉 ，王建 华 ，宦 芳，等 ． 管输 原 油流 量计 系数 交接 计 量
方法 与误差 ［ Ｊ 】 ． 油气储 运 ，２ ０ １ ０ ，２ ９（ Ｏ １ １ ）： ８ ５ ５ — ８ ５ ７ ．
是正 常 的 。但 是 相对 采 用事 后 交 接 法 ，即将事 后 的高估 或者 低 估 量补 上 ，目前我 方 的总流 量 的高 估 了 ０ ． ０ ８ ３ ％ ，即在 ２ ０ １ ０年 １ 月到 ２ ０ １ ２年 １ 月１ Ｏ目之 间共 有 约 ２ ４ ０ ０万吨 油被 多 算 了 。但 这
及 ｋ系 数 大 的波 动造 成 。 由图 １ 可 以看 出前 期 随 流 量 计使 用 ， ｋ系 数 缓慢 的 下 降 ， 由于 每 次 在 正 常 范 围 ， 不 需 对 流量 计 做 过 多维 护 ，当持续 时 间 较长 （ 输 送 油量 自然 较多 ） ，自然会 产 生较 大正 偏 差 。 当下 降 到一 定 范 围后 会 对 流 量计 做 大 的校 准 ， 使 得 流量 计 短 时 间 回 到 １ ０ ０ ０ ０附近 ， 这 期 间会 产 生 负偏 差 ， 但 是 是 在较 短 的 时 间完 成 ， 这样 前 期 造 成 正 偏差 就 不会 被 后 面 短期 的 负偏 差 所 抵 消 。虽 然偏 差 是在 标 准 范 围 ， 但 我 方 因此 会 在 累计
一
［ ３ 】 宋景尧． 流量计 系数法的现状与思考 ［ Ｊ 】 ． 油气田地面工程，
面向服务架构的系统集成研究
面向服务架构的系统集成研究一、引言随着信息技术的快速发展，企业信息化建设已经成为了企业生产力和核心竞争力的重要组成部分。
而系统集成则成为实现信息化建设的重要手段之一。
随着面向服务架构(SOA)的兴起，系统集成的方式也发生着巨大的变化。
本文将从SOA角度出发，探讨面向服务架构的系统集成研究。
二、面向服务架构1. SOA 概述SOA是一种面向服务的架构模式，是一种将企业内部和与之交互的外部系统、服务组件等构建为基于服务的应用程序的软件架构。
其核心思想是将业务分解为独立的可重用的服务，通过服务间的协调组合构建一个完整的应用系统。
SOA实现重点在于服务的发布、查找、绑定、协议转换、消息处理和传输等。
2. SOA 主要特点SOA的三个重要特点是松散耦合、服务稳定化和服务重用。
（1）松散耦合：服务提供者、服务消费者之间通过约定的可寻址接口进行信息交换，实现了服务之间的松散耦合。
（2）服务稳定化：如果一个服务提供者发生了变化，但是其公开的服务接口不变，服务消费者不需要进行任何改变便可继续使用该服务。
（3）服务重用：SOA的服务可被多个应用程序复用，大大提高了系统整体的开发效率。
三、面向服务架构的系统集成传统的系统集成较为复杂，主要存在以下几个问题：1）软件环境差异造成的集成难度；2）异构系统接口的兼容性难题；3）当多个系统集成时，因为每个系统都有自己的开发语言、数据格式等差异，导致实现统一管理和去中心化管理困难。
SOA可以有效的解决以上问题。
1. 面向服务架构的系统集成的优势（1）松散耦合的服务可以降低整个系统的复杂度;（2）将业务系统中的功能模块分离成各种服务，便于对应不同的业务需求，强调服务的独立性，提高系统的可用性和灵活性；（3）提高了系统集成的效率，不同的服务之间可以采取异步通信，从而避免服务操作阻塞等问题，提高了服务的并发性和整体的响应速度；（4）面向服务的系统集成可以为企业提供更好的数据安全性，在集成过程中隔离各个系统之间的信息流，便于数据备份和恢复。
通用SOA中间件平台日志消息检索技术与实现
以Ｓ Ａ Ｐ Ｐ Ｉ 集 成 中间件为例 ，克服传统Ｅ Ｓ Ｂ中间件消息检 索功能 的不足 ，结合客制化开发方法 ，提 出了一套有效
的Ｓ Ｏ Ａ中间件平 台消息检索实现方案 。
统集成应用往往采用定期批量 同步 的方式在服务器负载 较小 的时间进行消息同步 ，如每天晚上将Ｅ Ｒ Ｐ 系统 中当 天所有的新增或变更的供应商数据 同步到ｓ Ｒ Ｍ系统 中，
随着企业信息化建设 的深入 ，会逐 步引入各类业务 信息 系统 ，￣ Ｉ Ｅ Ｒ Ｐ 企业 资源计划 系统 、Ｓ Ｒ Ｍ供应商关系 管 理系统 、Ｃ Ｒ Ｍ客户关 系管理 系统等 。为 了能够 实现 业务 流程 的跨系统流转 ，需要将 这些 系统进行集成 ，使 系统 间能够共享数据 。由于各个 系统 的开发厂商不同 ，
实施 时间不 同，系统架构和开发语 言也多种多样 ，为了
部分 ，由于通过Ｅ Ｓ Ｂ 转发的消息应用场景各异 ，不同的 接 口交换 的数据结构不 同 ，Ｅ Ｓ Ｂ 无法使用单一结构的数 据表对消息进行结构化存储 。因此 ，Ｅ ｓ Ｂ 一般采用使用 簇表 （ Ｃ ｌ ｕ ｓ ｔ ｅ ｒ Ｔ ａ ｂ ｌ ｅ ）的方式压缩存储消息 的Ｐ ａ ｙ ｌ ｏ ａ ｄ 部 分 。与传统数 据表 每个 字段存 储特定 内容不 同 ，簇表
是把一组数据按一定规则 以序列形式存放在某一个特定
能够实现业务流程 的跨系统流转 ，一般会采用Ｓ Ｏ Ａ（ 面
向服务的架构 ）的中间件平台进行集成 。
Ｓ Ｏ Ａ 是一种系统集成架构 ，是一种粗粒度 、松耦合 的体系思想 ，由服务和后端应用实现构成 ，通过运 行于
后端基础设施之上 的服务实现功能需求 。Ｅ Ｓ Ｂ（ 企业服
基于消息通信的SOA系统的设计与实现的开题报告
基于消息通信的SOA系统的设计与实现的开题报告1. 研究背景和意义随着信息技术的不断发展和应用，越来越多的企业开始了解和实践面向服务的体系结构（Service Oriented Architecture，SOA）的设计和开发。
SOA是一种基于服务的系统设计方法，将每一个应用组件作为服务来对待，这些服务可以从多个应用程序中进行构建和组合。
采用SOA的方法可以帮助企业快速地构建和组合应用组件，提高应用程序整体的可扩展性、可重用性和可维护性。
在当今的信息时代，由于企业规模的扩大和业务复杂性的增加，SOA已经被广泛应用于各个领域。
然而，对于分布式SOA系统来说，服务间的通信是其关键问题之一。
采用基于消息通信的方式实现SOA系统，可以帮助企业更好地管理和调度分布式服务，增强系统的可靠性和可扩展性。
2. 研究内容和目标本文将研究基于消息通信的SOA系统的设计和实现。
研究内容包括以下三个部分：（1）分析消息通信模型的特点和优势，研究基于消息通信的SOA系统架构和实现方式；（2）研究SOA系统服务的注册、发现、调用和管理方法，设计基于消息通信的服务注册中心和统一管理平台；（3）实现一个基于消息通信的SOA系统原型，测试其性能和可用性，分析系统的优缺点。
本文的研究目标是：（1）掌握基于消息通信的SOA系统的设计和实现方法；（2）设计并实现一个基于消息通信的SOA系统原型，并对其进行性能和可用性测试；（3）评估基于消息通信的SOA系统的优劣势，并对其进行讨论和总结。
3. 研究方法和步骤本文将采用以下研究方法和步骤：（1）文献调研：通过查阅相关文献，了解相关领域的发展趋势和研究进展；（2）需求分析和系统设计：分析用户需求，设计系统架构和接口，确定系统功能和服务模块；（3）开发实现：开发系统原型，实现基于消息通信的服务注册中心和统一管理平台，验证系统的正确性和可用性；（4）性能测试和评估：测试系统性能，对系统的性能和可用性进行评估，并比较基于消息通信的SOA系统与基于其它通信方式的SOA系统的差异；（5）总结和展望：总结研究成果，分析系统设计和实现中存在的问题和不足，并提出进一步研究的方向和展望。
基于SOA架构的空管信息系统集成方案初探
蒜缱 １
１ Ｔ基 础环 境集 成 ． Ｉ
（） １ 数据 中心 。 据 中心可 以实 现企 业异 构数据 环 境无 法支 数 持 的有效 的数据 交换 ，全面 、集 中、主 动并 有效地 管理 和优 化 Ｉ Ｔ 基础 架构 ，实现 信息 系统 的 高可 管理性 和 高可用 性 。它通 过 实现 统 一 的数 据 定义 与命 名规 范 、集 中的数 据环 境 ，从而 达 到数据 共 享 与利用 的 目标 。一 个典 型 的数据 中心 常 常跨 多个供 应 商和 多个 产 品组件 ，这些 组件 需要 放在 一起 ，确 保 它们 能作 为一个 整 体运 图 ３ Ｅ Ｂ 式多 系统 交互 Ｓ方 行 。同时 为 了数 据 的安 全性 ， 必须 建设 异地 远程 容灾备 份系 统 。 还 如果没有 Ｅ Ｂ， 么假设 空管 内有 ｎ个 系统在协作 ， Ｓ 那 那么 系统 （ ） 务器 设 备间 。服务 器设 备 间是安 置业 务应 用 、 理监 ２ 服 管 间 的交互数量 将会 有 １２ … （．）个 ，如 图 ２ 示 。而 当增 加一 控 等服 务器 设备 的工 作 区 。由于 服务 器工 作 间的设备 多 、噪 音大 ＋ ＋ ＋ ｎ１ 所 个新 业务模 块或系 统时 ，新增系 统交互 最多可达 ｎ ，即新系 统需 及 发热 量 高，在 规划 设计 时应 该 注意 满足 良好 的通风 、散热 和隔 个 要分 别和 以前 的每 个老系 统交互 ，同时也导致 老系统 需要做修 改来 绝 噪音 条件 。 和新 系统交 互 。而有 了 Ｅ Ｂ， 么 ｎ 系统就 只会有 ｎ个交互 ，即 Ｓ 那 个 （） ３ 网络 主干 设备 问 。网络主干 设备 间中经 常安 置的设 备包 每个 系统和 Ｅ Ｂ 间的交互 ，如 图 ３所示 。当新增一 个系统 时，新 括 网络 核心 交换 机 、路 由器 、防火 墙设 备 、Ｖ Ｎ 安全 管理 设备 、 Ｓ Ｐ 增 的交互 也只是 １ ， 系统也 不需做 任何修 改，新 老系统 的交互 通 信线 缆光 电信 号转 换 设备 、局 域 网骨干 光纤 配线 架 、机房 网络 个 老 通过 Ｅ Ｂ来 统一管 理 ，基本 上对 系统本 身不产 生影响 。 Ｓ 配 线架 、 电话 拨号服 务接 入 设备 、Ｉ Ｐ电话 网关 设备等 。 （ ） 业智 能 （ Ｉ。 ３商 Ｂ ） 商业 智 能 （ Ｉ “ ｕｉ ｓ Ｉｔｌ ｅｃ ” Ｂ ） Ｂ ｓ ｅｓｎｅ ｉ ｎｅ ， ｎ ｌｇ （ ）监控 室 。监控 室是 对所 有设 备集 中监 控和 管理 的房 间 。 ４ 是 一种 运用 了数据 仓库 、在 线 分析 和数 据挖 掘等 技术 来 处理和 分 般包 括 大屏幕 集 中显示 系 统 、监 控 终端 、运维 呼 叫中心 等 。 析 数据 的技 术 ， 目的是 为空 管 决策者 提供 决策 分 析和风 险 分析 。 ２监控 集成 ． 空 中交通 管理 的 “ 行业 经 验 ”并不 是靠 短 期 内就能 累积起 来 （ ）设 备监控 ： 数 据存 储设 备、网络 设备 、服 务器 设备 等 １ 对 的 ，唯有通 过 业务 不 断发展 和 变革 才 能历练 出来 。随着 信息 技术 进行 实时 的综 合性 的监控 与 管理 。 的进步 ，传 统 业务 已经 实现 了信息 化 ，每一 次 业务 数据 都记 录在 （ ）应用 服务 监控 ：对操 作 系统运 行状 况 ，各种 应用 支持 软 ２ 数 据库 中，斗 转星 移 ，累积 了 以 Ｔ 为计量 单位 的业 务 数据 记录 。 Ｂ 件如 数据 库 、 间件 、 件 以及各 种通 用或特 定服 务 如邮件 系 统、 中 群 Ｂ 从 大量 的数 据 中钻取 信 息与 知识 ， 行业 内多年 的 “ Ｉ 把 行业 经验 ” Ｄ 、Ｗｅ 等 的监控 与管 理 。 ＮＳ ｂ 整 合和 展 示 出来 ，这些 “ 业 经验 ”具 有不 可估 量 的价 值 。 行 （ ） 务系 统监 控 ： ３业 对企 业 自身核 心业 务系 统运 行情 况 的监 ２数据 集 成 ． 控与 管理 。 （ ） 业数 据 总线 （ ＤＢ 。 １企 Ｅ ） 企业 数据 总线 （ Ｄ “ ｎｅ ｒ ｅ Ｅ Ｂ） Ｅ ｔ ｐｉ ｒ ｓ （ ）数据 监控 ： 系统和 业 务数据 进 行统 一存储 、 份和 恢 ４ 对 备 Ｓ ｒｉ ｕ” Ｓ Ａ 的数 据集 成基 础 ， 可在应 用之 上 聚合 数据 ， ｅｖ ｅ ｓ 是 Ｏ ｃＢ 它 复 的监控 与管 理 。 直 接 作用 于生 产数 据 ，是对 现 有系 统影 响最 小 的方 式 。它允 许虚 （ ）信 息安 全监 控 ：对机 房人 员进 出 ，机房 设备 操作 ，系统 ５ 拟 化 企业 数据 存取 ，解 决 了众 多独 立信 息系 统 导致 数据 源分 散 、 访 问接入 等安 全 因素 的监控 与管 理 。 异 构数 据 库难 以访 问、数据 接 口复杂 、存储 形 式多 样 、数据 质量 四 、结语 较 低等 问题 。企业 数据 总 线可 以分 为两 大类 方 法 ，即企 业信 息集 空 中交通 管理 是 一个 即要求 高度 信 息化 又要 求绝对 安全 生产 成 （ Ｉ “ ｎｅ ｒ ｅｎｏｍａ ｏ ｔｇａｏ ” ＥＩ Ｅ ｔｐｉ ｆｒ ｔ ｎ ｅｒ ｉ 和数 据抽 取 “ ｘ ａｔ、 的行 业 。在信 息化 的 不断推 进 发展 中 ，不 同种类 的操 作系 统 ，应 ） ｒ ｓＩ ｉ Ｉ ｎ ｔｎ Ｅ ｔ ｃ” ｒ 转 换 “ ｒ ｓ ｒ 、装载 “ ｏｄ Ｅ Ｌ 。 Ｔａ ｆ ｍ” ｎｏ Ｌ ａ ”（ Ｔ ） 用软 件 ，系 统软件 ，数据库 ，应用 基础 结构 相互 交错 ；网络设 备 ， ＥＩ Ｉ利用 元数 据创 建 一个虚 拟 的数 据库 ， 该数据 库 能为存 储 于 应用 服务 器 ，存储 设 备 ，安全 管理 设备 等不 断更 新换 代 。因此 ， 不 同数据 源 中的各 种 数据 提供 一个 单 一 的视 图，它 能让 用户 像访 不可 能重 新建 立起 一个 新 的基础 环境 。 根据 新疆 空管 局现 有基 础 ， 问存 储在 本地 的 某个 单一 数据 库 一样 来访 问数 据视 图，而 实际 上 结合 信 息技术 发 展现状 ， 这里 提 出 了一 种基 于 Ｓ Ａ架 构 的空 管信 Ｏ 这些 数据 可 能来 自多个 不 同数 据源 。通 过 ＥＩ 术 ，实现 了实 时 息系 统集 成方 案 ，提 供一 个可 支持 有机 业务 的架 构 ，可按 照模 块 Ｉ技 全局 信 息的 可视 化 ，为 空管建 立 了一 个统 一 的数据 平 台 ，提 升 了 化 的方 式更 新或 新增 服务 ，解 决 了传统 的软 件 开发模 式和 系统 集 决策 支 持和 对外 服 务。 成方 法造 成 的空 管系 统 “ 信息 孤 岛 ”局 面 ，将会 极大 地促 进 空管 Ｅ Ｌ是构建数 据仓库 的重要技术环 节 。用户 从数据源抽 取 出所 信 息化集 成 与管 理水 平 的提升 。 Ｔ
MOM的思考
基于MOM-面向消息中间件的SOA系统集成技术一、什么是MOM？MOM是Message-Oriented Middleware（面向消息的中间件）的缩写，MOM 的作用就是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成，通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。
目前流行的MOM产品有IBM的WebSphere MQ和基于JMS标准的系列中间件等。
二、MOM特点MOM是一个基础架构，在基于MOM的通信环境中，通常是异步地发送和接受消息，它将应用抽象地划分为发送者和接收者，它们之间无需彼此了解，MOM最重要的作用就是将消息转发到它们的目的地。
下图就是MOM的简单模型图:从上图可以看出，为了支持消息传递的异步模型，MOM位于客户端和服务器之间，使用消息队列临时存储调用，并允许客户端和服务器分别在不同的时候运行，消息的目标端也不需要立即处理消息，并且客户端和服务器的程序之间不需要彼此知道对方的存在，它们之间不需要考虑它们之间的网络通讯复杂性。
MOM不同于普通的通讯系统的地方在于，通讯的接收和发送两端必须同时运行，并且消息必须即时处理。
三、MOM原理MOM要实现高效可靠的消息传递机制，必须实现以下三大功能：●实现消息的异步发送和接收，实现发布/订阅模式●实现消息的持久化，保证消息可靠性传输●优化网络传输，支持断点续传要实现以上三大功能，需要实现消息队列，消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合的方式，队列是消息的安全存放的位置，队列存储消息直到它被应用程序处理，这样的工作机制，能够保证在各种网络环境下能够可靠的传递。
在消息队列的应用上，各个不同的MOM产品应用上有所不同，例如，JMS 标准的MOM和IBM Websphere MQ实现上就有所区别。
从上图，可以看出IBM WebSphere MQ的结构和JMS结构在队列的应用上略有不同，IBM WebSphere MQ在客户机上存在有传输队列，而JMS在客户机方面不存在任何队列，所以说JMS相对于MQ而言，只是规范了消息的存取，而没有规范消息数据的传输，因为JMS客户机并不拥有存放数据的队列，所以所有发送的操作都要由应用程序来控制，JMS服务器本身不代理传输，也不保证数据在远程队列间的传输可靠性。
基于面向服务架构消息中间件的业务流程系统集成方法研究
【关键词】面对服务架构消息中间件，业务流程系统的集成方法
【中图分类号】 G2 9
【文献标识码】A
【文章编号】 1672-5158(2013)07-0480-01
一、前言 依据企业信息化发展的阶段模式理论来说，企业在信息化的发展共 有四个阶段。其中，引入阶段中，企业会运用一定的信息技术使得在企业内 部的一些职能的部门能够将业务的流程实现自动化，当今很多的企业都已 完成了这一阶段。集成阶段中，企业会在内部的职能部门间进行系统集成 框架的建立和数据管理系统的统一，同时，也需要将计算机的软件系统实 现在内部中的集成及综合的利用。这个阶段中，中间件的技术也产生了。在 这种技术中最为重要的中间件是消息中间件，它具备跨平台，扩展性好及 负载平衡的优点。消息中间件和面向服务架构之间的融合成为中间件技术 的一种发展趋势。这样企业就可以及时并方便的对业务进行调整，对流程 进行重组。流程的变革阶段中，企业与供应商和分销商这些工作伙伴通过 信息和网络的技术使得资源和数据得到共享和整合。现在对于信息技术的 运用较为成熟的企业有的完成了流程变革的阶段有的正处于这一阶段，在 此之后将会进入战略变革的阶段。 二、 面向服务构架消息中间件 1996年，面向服务架构的概念被提出。它是一种在对象构件的计算 模型的基础之上，把不同功能的单元用之前定义好的接口、契约联系起 来，从而实现程序和服务上的重复利用的新型体系架构。面向服务架构 包括三方面。其中，服务提供者是在根据网络导址这一实体来接受并且 执行服务的使用者的要求。服务提供者从根本上来说是一种应用程序或 者是软件快，它通过接口和契约来运行。服务注册中心是在服务中发现 并支持，它来使得服务提供者找到服务使用者的接口。当下最为普遍的 面向服务架构的技术叫做Web Service，这种技术的服务注册中心是通 过描述并发现、集成来保存服务的注册的信息，利用简单对象的访问协 议消息来达到服务的绑定及调用。中间件系统可以在不同的平台之间实 现通信，从而达到在分布式的系统间可靠并且高效率的跨平台的数据传 输工作。并且具有屏蔽在各种平台及协议间的性质，从而达到各种应用 程序间的协同。现在，最为普遍的消息中间件是由消息服务器和数据的 储存库及命名和目录的文档等等组合而成的，同时，采用了客户端和消 息服务器这两层架构。其中，消息的服务器可以接收消息和发送消息，它 根据查询命名和目录文档来获取每个消息服务器和消息对列等等的信 息，这时数据的存储库将会用来保存通信中重要的数据。消息中间件的 用户会使用应用程序接口技术来通过消息服务器进行发送消息和接收 消息，达到企业的数据集成。近些年来，消息中间件技术发展非常迅速， 它的研究的热点及关键的技术包括了系统的架构、负载平衡的技术及计 算机的集群技术。在标准及规范上并没有得到统一，因此这种应用是不 可以移植的。不同的消息中间件技术也是不能进行相互的操作。当下，消 息中间件技术在中间件技术中依然是研究的热点。消息中间件最传统的 采用的为客户及消息服务器上网架构，但是通过一系列的设计得到了一 种客户、客户端和消息服务器的具有三层架构的消息中间件。其中，消息
基于SOA的数据服务中间件的研究与实现
梁， 数据服务 提供 者 向它 注册 服务 ， 而数据 服务请 求者 通过 它查 询所 需服务 接 口信息 ， 以访 问 。 用
３ 基 于 Ｓ 的数 据 服 务 中 间件 ＤＳ ＯＡ Ｍ
第 ２ 卷第 ５ ５ 期
２１ ０ ０年 １ Ｏ月
成
都
信
Hale Waihona Puke 息工程学
院
学
报
Ｖｌ ． ． ０ ２５Ｎｏ ５ １
Ｊ ＵＲ Ｌ ＨＥ Ｄ ＵＮＩ Ｒ Ｉ ＯＦ Ｉ ＯＲ Ａ ＯＮ Ｃ Ｏ ＮＡ ＯＦ Ｃ ＮＧ Ｕ ＶＥ Ｓ ＴＹ ＮＦ Ｍ ＴＩ ＴＥ ＨＮＯ Ｋ Ｌ ￣Ｙ
Ｏｃ ．２ １ ｔ ＯＯ
Ｇ ＲＳ数据 服务 ３类 。 Ｐ
２ Ｓ 架构 ＯＡ
Ｓ Ａ， Ｏ 即面 向服务 的体 系结 构 ， 是一 个 组件模 型 ， 将应 用 程序 的不 同功能 单元 通 过这 些 服 务 间 定 义 良好 的 它 接 口和契约联 系起来 。接 口是采 用 中立 的 方式 进行 定 义 的 ， 独 立 于 实现 服务 的硬件 平 台 、 作 系统 和 编程 语 应 操 言。使得构建在系统中的服务以统一和通用的方式进行交Ｎ ４ ｌ Ｊ ，。 ５ Ｄ Ｍ 采用 Ｓ Ｓ ＯＡ核心 思 想 ， 过 制 定 统 一 的标 准 和 规 范 ， 数 据 以 通 将 服务 的形 式 由数据 提供 者 注册 提 供 ， 着 又 以服 务 的形 式 由数 据 使 用 接 者使 用 ， 而达 到数据 共 享 。ＤＳ 数据 共享 主要 涉及 ３种核 心 角色 ： 从 Ｍ 数 据服务 提供 者 、 据 服 务 请 求 者 和数 据 服 务 代 理 。３者 关 系 如 图 １所 数
收 稿 日期 ：０ ００ ０ 修 订 日期 ：０ ００ —５ ２ １ ９１ ； ２ １．９２ 基金项 目： 国家科技支撑计划资助项 目（０ ９ Ａ Ａ１ ０ ２ ０ Ｂ Ｄ Ｂ０ ）
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
基于MOM-面向消息中间件的SOA系统集成技术探索一、什么是MOM？MOM是Message-Oriented Middleware（面向消息的中间件）的缩写，MOM 的作用就是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成，通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。
目前流行的MOM产品有IBM的WebSphere MQ和基于JMS标准的系列中间件等。
二、MOM特点MOM是一个基础架构，在基于MOM的通信环境中，通常是异步地发送和接受消息，它将应用抽象地划分为发送者和接收者，它们之间无需彼此了解，MOM最重要的作用就是将消息转发到它们的目的地。
下图就是MOM的简单模型图:从上图可以看出，为了支持消息传递的异步模型，MOM位于客户端和服务器之间，使用消息队列临时存储调用，并允许客户端和服务器分别在不同的时候运行，消息的目标端也不需要立即处理消息，并且客户端和服务器的程序之间不需要彼此知道对方的存在，它们之间不需要考虑它们之间的网络通讯复杂性。
MOM不同于普通的通讯系统的地方在于，通讯的接收和发送两端必须同时运行，并且消息必须即时处理。
三、MOM原理MOM要实现高效可靠的消息传递机制，必须实现以下三大功能：●实现消息的异步发送和接收，实现发布/订阅模式●实现消息的持久化，保证消息可靠性传输●优化网络传输，支持断点续传要实现以上三大功能，需要实现消息队列，消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合的方式，队列是消息的安全存放的位置，队列存储消息直到它被应用程序处理，这样的工作机制，能够保证在各种网络环境下能够可靠的传递。
在消息队列的应用上，各个不同的MOM产品应用上有所不同，例如，JMS 标准的MOM和IBM Websphere MQ实现上就有所区别。
从上图，可以看出IBM WebSphere MQ的结构和JMS结构在队列的应用上略有不同，IBM WebSphere MQ在客户机上存在有传输队列，而JMS在客户机方面不存在任何队列，所以说JMS相对于MQ而言，只是规范了消息的存取，而没有规范消息数据的传输，因为JMS客户机并不拥有存放数据的队列，所以所有发送的操作都要由应用程序来控制，JMS服务器本身不代理传输，也不保证数据在远程队列间的传输可靠性。
IBM MQ通过通道与传输队列和远程队列来保证队列间的传输可靠性，IBM MQ支持客户端的断网续传，而客户端的应用程序不用做任何工作，但是，这种方式需要客户端本地安装MQ的客户端。
四、MOM通讯模式MOM主要存在3工作模式：点对点模式、发布/订阅模式以及消息队列模式，其中，点对点模式和发布/订阅模式统称为消息传递模式。
点对点模式（Point-to-Point）点对点模式用于消息生产者和消息消费者之间点到点的通信，是一种程序到程序的直接通信模式。
消息生产者将消息发送到由某个名字标识的特定消费者，点对点消息允许客户端通过队列这个虚拟通道来同步和异步发送、接收消息，传统上，点对点模型是一个基于拉取（Pull）或基于轮询（Polling）的消息传递模式，这种模型从队列中请求消息，而不是自动地将消息推送到客户端。
点对点消息传送模型的一个突出特点就是：发送到队列的消息被一个而且仅仅一个接收者所接收，即使可能有多个接收者在一个队列中侦听同一消息时，也是如此。
●发布订阅模式（Publish-and-Subscribe）在发布/订阅模型中，消息会被发布到一个名为主题（topic）的虚拟通道中。
消息生产者称为发布者（publisher），而消息消费者则称为订阅者（subscriber）。
与点对点模型不同，使用发布/订阅模型发布到一个主题的消息，能够由多个订阅者所接收。
有时候，也称这项技术为广播（broadcasting）消息。
每个订阅者都会接收到每条消息的一个副本。
总地来说，发布/订阅消息传送模型基本上是一个基于推送（push）的模型，其中消息自动地向消费者广播，它们无须请求或轮询主题来获得新消息。
如上图所示，在发布/订阅模式下，没有传统意义上的客户端和服务器，而是在网络中进行消息发布的应用程序和接收某个特定主题消息的应用程序，发布消息的客户端将消息传递给消息代理，有消息代理负责路由消息给相应的订阅消息的客户端，由消息代理实现消息的动态路由，发布者和订阅者在空间上是松耦合的，客户端和服务器不需要知道对方的地址和具体的数量，简化了配置，更容易重用。
这种模式也是目前应用最广泛的模式。
●消息队列模式消息队列模式是一种程序之间的无连接的通信模式，它允许程序通过消息队列进行通信，它将消息放入队列（通常基于内存和硬盘）直接或者按顺序传送，这种方式允许程序按照不同的速度独立运行，而不需要双方之间建立一条逻辑连接。
这种模式需要系统中包含有队列管理器，用于处理本地队列，保证消息传送到存在于本机或者网络中某个位置的目的地。
队列管理器与其他节点上的队列器合作控制网络路由机制。
支持不同Qos（服务质量），包括：●Qos 0至多一次消息会丢失或重复，但是只发送一次●Qos 1 至少一次确保消息到达，但消息重复可能会发生。
●Qos 2 只有一次确保消息到达一次消息队列可以是永久性或者非永久性的，永久性的消息存放在硬盘上，非永久性的消息存放在内存中，当队列管理器出现故障时，非永久性队列的消息会全部丢失，而永久性的消息会自动恢复。
消息队列支持触发，当请求消息和应答消息到达本地队列，但是应用程序未处于活动状态时，自动启动这个应用程序。
这种方式只有在工作需要完成时，处于活动状态，从而避免不必要的资源浪费。
目前，IBM MQ主要采用就是这种消息队列模式。
五、MOM消息传递模式比较●点对点模型在点对点模式下，每个消息都被发送到特定的队列，接收者从队列中获取消息，队列保留着消息，直到它们被消费或者超时。
每个消息只有一个消费者(Consumer)（即一旦被消费，消息就不再在消息队列中）发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列。
接收者在成功接收消息之后需向队列应答成功这种模式保证发送的每条消息都被消费者成功接收。
●发布/订阅模型在发布/订阅模型中，客户端将消息发送到主题。
多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。
每个消息可以有多个消费者发布者和订阅者之间有时间上的依赖性。
针对某个主题(Topic)的订阅者，它必须创建一个订阅之后，才能消费发布者的消息，而且，为了消费消息，订阅者必须保持运行的状态。
当然，为了缓和这种严格的时间相关性，有些MOM系统，例如利用了JMS 的MOM系统,允许订阅者创建一个可持久化的订阅。
这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。
在JMS中，持久化订阅者可以定义为durable（持久化的），持久化的订阅者注册一个带有JMS保持的唯一标识的持久化订阅，带有相同标识的后续订阅者会再续前一个订阅者的订阅状态，如果持久化订阅没有活动的订阅者，JMS会保持订阅消息，知道消息被订阅接收或者过期。
如果希望发送的消息可以不被做任何处理、或者被一个消费者处理、或者可以被多个消费者处理的话，那么可以采用发布/订阅模型。
六、系统业务集成的目标信息系统业务集成的目标是构建一个开放、松散耦合的系统集成环境，就目前公司开发的各个产品而言，存在多平台、多开发语言的特点，比如ZLHIS基于VB6+Windows平台、ZLBH基于.net +Windows平台、移动临床基于Java+Android 和Object C+IOS两种平台、社区一部分产品基于B/S架构运行于浏览器，而且在具体实施时还面临第三方厂商业务集成的需要。
由于各系统采用的技术路线不统一，进行业务集成是，需要开发新的接口或者采用其他集成方法，最终导致业务集成成本提高，增加了现有系统的复杂程度，而且随着各个应用系统上的业务交叉点越来越广，传统的数据集成已经不能满足现实的需求，需要一种支持业务流程编排重组的业务流程集成方式才能解决。
SOA是一种软件系统架构和软件设计模式，而WebService是就目前而言最适合实现SOA架构的核心技术，WebService基于XML、SOAP、WSDL和UDDI协议形成了实现SOA的一系列技术的集合。
企业服务总线（Enterprise Service Bus，ESB）为SOA系统的实现提供了一个核心架构，是一种分布式的集成框架，ESB 相当于一个WebService的组装平台，它支持各个异构系统间通过Webservice实现面向服务的交互，ESB智能的在企业系统间路由数据流，配合和转换各个系统需要的数据信息，为SOA提供一种连通性基础架构，用以连接SOA中的各个服务。
这种模式有助于减少应用接口的数据量和复杂性。
七、MOM在ESB中的应用ESB概念的四个支柱-MOM、WebService、数据变换和路由智能，其中MOM 是ESB实现消息和事件驱动的核心技术，对于ESB而言，可靠的传输是ESB的基础，比如IBM Message Broker就是建立于IBM MQ基础之上的（这里从名字也可以看得出来），Oracle Service Bus是基于JMS基础之上的。
例如，上图中可靠、异步、安全的消息传递机制就是依赖于JMS方式。
这里再举一个例子：上图简单示意了，出院程序如何通过ESB调用重庆医保的Webservice接口和ZLHIS出院结算接口，完成出院结算消息提醒，并通知到ZLHIS和ZLBH客户端以及IOS/android设备客户端。
1、出院程序首先调用ESB上公布的出院WebService，传入病人住院号；2、ESB通过传入的病人住院号调用数据库存储过程，通过病人住院号查询到病人的医保号和身份证号信息以及住院费用信息；3、ESB通过服务编排传入医保号和住院费用信息，调用重庆医保接口获得病人该次住院的医保结算报销费用；4、将出院报销费用和总费用传给zlhis出院结算WebService，检查该病人住院预缴金额是否充足，并将欠费金额组织成格式消息发送到消息代理上，消息代理转发消息至指定病区的护士工作站和移动护士工作站。
5、护士通过订阅消息获得病人出院信息，并作相应处理。
在这里，ESB通过服务组织调用不同的WebService或内置业务逻辑进行消息路由后，获得最终结果消息发送到消息代理，由消息代理将消息可靠的、异步的传输到工作站程序上。
因为目前ZLHIS运行环境的复杂性，消息的传递必须具备以下几个条件1、消息的通知必须是异步的，因为类似于移动设备可能因为移动网络原因和省电的原因，不可能一直保持连接；2、消息的通知必须能够通过推送的方式送达；3、消息接收的客户端要是能够跨平台的；如果要达到以上几点要求，ESB的消息传递就必须使用MOM，而目前厂商的ESB产品内置了MOM的功能。