毕业设计（论文）-基于中间件技术的异构数据库互访.pdf

基于中间件技术的异构数据库互访基于中间件技术的异构数据库互访 摘摘 要要 目前随着计算机技术特别是计算机网络技术的发展，传统的数据集成技术(如多库方 法)已无法满足人们获取更多更新地理位置不同，系统平台各异，数据存储模式相异的数 据的需要。同时对于企业来说，随着企业规模的扩大，不同时期构建的业务系统可能基于 不同操作系统和数据库平台， 也存在着需要解决数据交流效果较差， 实现对异构数据的透 明性访问的问题。如何解决透明性互访问题，整合信息资源，实现跨系统跨行业甚至跨地 区的信息共享和交换， 从而高效地利用现有的信息资源， 已经成为下一步信息化建设的重 要课题。 中间件技术所具有的强大通信功能和良好的可扩展性， 可以很好的解决互访所要求的 轻量快速部署的目标，达到系统快速适应数据源改变和低投入的效果。同时 java 技术的 飞速发展，其可移植性和跨平台性的特点，使得以 java 实现的中间件很容易实现平台无 关性。而平台无关、易于扩展、交互性好、语义性强等特点的 xml 技术的出现，使 java 技术与 xml 的结合可以达成一个相同的目的:提供一个完整、平台无关、internet 导向的 运算环境。基于此，通过采用 xml 作为数据集成的公共数据模型，采用 xml 文档集合 作为数据交换的中转站，并且使用以 java 实现的中间件来利用统一的 xml 视图集成离 散的异构数据库，达到实现透明性互访的目标，同时实现系统的可移植性和跨平台性，利 于部署的要求是一种较优的异构数据库互访方案。 关键字：关键字：扩展标记语言, 中间件,异构数据库, 数据集成 i abstract with current computer technology, especially computer network technology development, the traditional data integration technologies (such as multi-database approach) was unable to meet different people obtain more updated location, platform differences, the data storage model different data needs. at the same time the enterprises, with the expansion of the scale enterprises, a business system may be different periods for different operating systems and database platforms, and also the existence of the need to address effects of poor data exchange, the achievement of isomerization unit data transparency visit. how to address transparency visits, the integration of information resources, the realization of cross-system cross-sectoral information sharing and even trans-regional exchange, and thus efficient use of existing information resources has become an important topic in the next step of informationization construction. middleware technology with the powerful communications functions and the expansion of good will, could very well have been resolved by the light of the rapid deployment of the required objectives to achieve rapid system data sources change and the effects of low-input. at the same time rapid development of java technology, the portability and cross-platform nature features java enabled to achieve the middleware platform to easily achieve. and platform independent, easy to expand, the world is good, meaning the characteristics of the strong emergence of xml technology to enable the integration of xml with java technology can achieve the same purpose : to provide a complete, platform independent, internet-oriented processing environment. because of this, through the use of xml as a data integration of public data model, using xml files together as a data interchange, and using java middleware to achieve reunification use integrated xml type of isomerization unit separated databases to achieve transparency between the goals, while achieving system portability and cross-platform nature, requirements for the deployment of the isomerization unit is a better database visits programme. key words: xml ,middleware ,heterogeneous database, data integration ii 目录目录 摘摘 要要 . i abstract .ii 1 绪言绪言 1.1 本文研究背景本文研究背景1 1.2 问题问题 1 1.3 本文研究内容本文研究内容.2 1.4 论文章节安排论文章节安排2 2 异构数据库异构数据库 2.1 数据的异构性数据的异构性.4 2.2 异构数据库互访的目标异构数据库互访的目标.4 2.3 异构数据库的互访方式异构数据库的互访方式.5 3 技术可行性分析技术可行性分析 3.1 中间件技术中间件技术.7 3.2 xml 技术技术.7 3.3 java 开发语言开发语言 8 3.4 soap 技术研究技术研究9 3.5 jdom 技术技术.10 4 中间件模型中间件模型 4.1 中间件模型的体系结构中间件模型的体系结构.13 4.2 中间件运行流程图中间件运行流程图.16 4.3 中间件模型的视图定义中间件模型的视图定义.18 4.4 中间件模式映射中间件模式映射.20 4.5 中间件数据转换规则中间件数据转换规则.28 5 原型设计与实现原型设计与实现 5.1.需求分析需求分析 .33 5.2.开发环境开发环境 .33 5.3 具体实现具体实现 .33 5.4.运行示例运行示例 .38 6 总结与展望总结与展望40 致谢致谢 .41 参考文献参考文献 .41 iii 1 绪言绪言 1.1 本文研究背景本文研究背景 今天，越来越多的的应用需要访问各种异构数据库。对于企业应用来说，这既是企业 内部发展的需要也是企业适应外部环境的需要。 企业在发展过程中积累了大量数据，并为存储和管理这些数据不断投资。然而，由于 实施数据管理系统的阶段性、 技术性以及其它经济和人为因素的影响， 以至即使在一个单 独企业，采用的数据管理系统也大不相同，从简单的文件数据库到复杂的网络数据库，它 们构成了企业的异构数据源。 尽管这些数据管理系统能够满足数据存储和管理要求， 但是 在许多情况下， 为完成一项工作， 企业应用可能需要访问分布在网络不同位置上的多个数 据管理系统中的数据。 不仅如此，随着生存环境的不断变化，企业在把握机遇的同时也面临着许多挑战。网 络的发展使企业逐渐从一个孤立节点发展成为不断与网络交换信息和进行商务事务的实 体， 企业数据集成也从企业内部集成走向了企业间集成。 现在的企业比以往任何时候都需 要将内部数据进行发布和交换，这必然导致越来越多的企业应用需要访问各种异构数据 源，并且这些数据源可能分布在网络上任何地方。为了满足这种需求，必须有一种系统能 够支持异构数据库的数据互访。 所以， 无论是从企业自身发展角度还是从企业间的角度来看， 越来越多的企业应用需 要一种异构数据库互访系统作为访问异构数据源的支撑，那么，在当前的情况下，建立异 构数据库的互访系统必须解决哪些问题呢？ 1.2 问题问题 作者认为实现异构数据库的互访存在下面几方面的问题： a.异构性 异构性是实现异构数据库的互访必须面临的首要问题，其主要表现在两方面： (1)系统异构， 数据源所依赖的应用系统、 数据库管理系统乃至操作系统之的不同构成 了系统异构。 (2)模式异构， 数据源在存储模式上的不同。 一般的存储模式包括关系模式、 对象模式、 对象关系模式和文档嵌套模式等几种，其中关系模式为主流存储模式。需要注意的是，即 便是同一类存储模式，它们的模式结构可能也存在着差异。例如 oracle 所采用的数据类 型与 sql server 所采用的数据类型并不是完全一致的。 b.性能 网络时代的应用对传统数据库互访方法提出了挑战，提出了更高的标准。一般说来， 当前负责集成的应用必须满足： 轻量快速部署， 即系统可以快速适应数据源改变和低投入 1 的特性。 c.语义冲突 信息资源之间存在着语义上的区别。这些语义上的不同可能引起各种矛盾，从简单的 名字语义冲突(不同的名字代表相同的概念)， 到复杂的结构语义冲突(不同的模型表达同样 的信息)。语义冲突会带来数据集成结果的冗余，干扰数据处理、发布和交换。所以如何 尽量减少语义冲突也是数据集成的一个研究热点。 d.权限瓶颈 由于数据库资源可能归属不同的单位， 所以如何在访问异构数据源数据基础上保障原 有数据库的权限不被侵犯， 实现对原有数据源访问权限的隔离和控制， 就成为连接异构数 据资源库必须解决的问题。作者将该问题定义为权限瓶颈问题。 针对以上所介绍的四个方面的问题， 作者提出了基于 xml 的异构数据库互访中间件 解决方案，并基于此方案对集成的主要问题深入研究。 1.3 本文研究内容本文研究内容 本文依据 xml 具有自描述性，xml 数据模型的内容具有独立性，xml 能描述不同 复杂度的数据，同时还具有可扩展性的特点，建立了一个基于 xml 的异构数据库互访中 间件的模型。在此模型中，xml 用来描述各异构数据库的数据。首先从理论性和实用性 两方面深入研究了异构数据库互访技术的一些国内外最新学术成果和应用成果， 并剖析了 其中存在的问题;然后分别从中间件方面以及 xml 在数据模型角度和数据交换规范角度 论述了基于xml构建数据集成中间件的可行性:最后在此基础上给出了一个基于xml的 数据集成中间件模型， 并且着重阐述了在此中间件模型中如何基于 xml 实现异构数据库 互访方法,同时给出互访中间件模型。 1.4 论文章节安排论文章节安排 本文的章节安排如下： 第一章为绪言。主要介绍了本论文的研究背景和研究的主要内容。 第二章主要讨论了异构数据库互访的相关理论。 第三章本中间件模型的技术可行性分析。 第四章分别从数据集成中公共数据模型的建立以及数据转换的角度进行了阐述。 然后 围绕 xml 在数据集成方面的优势详细讨论了 xml 技术，以证明 x.ml 数据模型的实用 性，给出了基于 xml 的数据集成中间件的模型，描述了该中间件模型的体系结构以及功 能特性。 第五章为原型实现。编程环境:windows 2000，mysql，sql server2000，jdk5.0， jccreator。 预计实现的功能：mysql 与 sql server2000 之间的数据交换，并实现以下功能： 2 (l)根据源数据库信息生成 xml 文件并能查询并显示所需要的信息; (2)将指定 xml 文件写入到目标数据库中。 第六章总结了本论文的研究工作，并给出了进一步的展望。 3 2 异构数据库异构数据库 2.1 数据的异构性数据的异构性 数据的异构性导致了对于不同数据库的互访需求。那么何谓异构数据?异构数据是一 个含义丰富的概念， 它是指涉及同一类型但在处理方法上存在各种差异的数据， 在内容上， 不仅可以指不同的数据库系统之间的数据是异构的， 而且可以指不同结构的数据之间的异 构，(如结构化的 sql server 数据库数据和半结构化的 xml 数据)1。 总的来说，数据的异构性可以包括以下三个方面:系统异构、数据模型异构和逻辑异 构。 系统异构是指硬件平台、操作系统、并发控制、访问方式和通信能力等的不同，具体 细分如下: 1、计算机体系结构的不同，即数据可以分别存在于大型机、小型机、工作站、pc 或嵌入式系统中。 2、操作系统的不同，即数据的操作系统可以是 microsoft windows，windowsnt、各 种版本的 unix、ibm 0s/2、macintosh 等。 3、开发语言的不同，比如 c、c+、java、delphi 等。 4、网络平台的不同，比如 ethernet、fddi、afm、tcp/ip、ipxspx 等。 而数据模型异构则是指 dmbs 本身的不同。比如数据集成系统可以采用同为关系数 据库系统的 oracle、sql server 等作为数据模型，也可以采用不同类型的数据库系统关 系、层次、网络、面向对象或函数型数据库等。 逻辑异构则包括命名异构、值异构、语义异构和模式异构等。比如语义的异构具体表 现在相同的数据形式表示不同的语义，或者同一语义由不同形式的数据表示。 以上这些构成了数据的异构性， 数据的异构给行业、 单位和部门等的信息化管理以及 决策分析带来了极大的不便。于是数据集成技术应运而生了。 2.2 异构数据库互访的目标异构数据库互访的目标 为此对数据库访问和互用数据要解决下列几个主要问题： (1)计算机机种，操作系统和网络的透明性。要对依赖于机种，操作系统，网络的不 同数据的存储格式，浮点表示，字节排列，编码字符集，网络拓扑结构和通信协议等加以 屏蔽，使这些差别对用户透明。 (2)数据模型的转换。对存在与不同数据库系统中的不同数据模型进行转换，使用户 能采用与本地数据库一致的方式，访问具有不同数据模型的远程数据库中的数据。 (3)模式转换。每个本地数据库都有自身数据结构的本地模式。面向用户的数据结构 有用户模式来描述。各个本地模式要构成“全局模式” ，以便跨越数据库系统进行数据操 4 作。由于不同数据库中的本地模式，全局模式和用户模式可能个不相同，故应经模式，将 本地模式转换和集成为统一的全局模式，并能构造出各自不同的用户模式. (4)位置透明性。用户不必知道数据库中数据的具体存放位置。只要指明数据的逻辑 名，系统就能自动把逻辑名映射到存放数据的物理地址上，并能直接访问它。 (5)操作语言的透明性。用户使用一种公共语言就能访问不同数据库的数据。 2.3 异构数据库的互访方式异构数据库的互访方式 实现异构数据库数据互访的方式有以下四种： (1)多对一转换方法 这种方法比较简单， 它将异构的数据库转换为同一种格式的数据库， 实现了数据格式 的统一，从而解决了异构的问题.目前市场上有比较多的数据格式转换软件，用户可编程 实现这一点，如在 deiphi 中利用 odbc 技术，通过 thactcblmove 控件就能很好地快速 实现不同数据之间的数据格式转换.其他开发工具如 vb，vc，c+ builder 等也能够比较 容易地实现.但这种方法难免会出现数据不唯一、数据类型不一致、数据截断和数据不完 整等错误，而且工作量也非常大2。 (2)数据仓库方法 这种方法是将分布式的数据通过中间件提取到中心数据仓库中。 这种方法的一个显著 的特点就是数据仓库对于各个分布数据的高度控制权。 在这种方式中， 数据仓库将来自各 个分布场地的数据集成起来， 客户端直接访问数据仓库中的数据。 这个数据仓库并不需要 是特定的，它可能就是一个 dbms 来担任。这种方法所需转化模块少，仅需 n 个数据转 换中间件。每增添一种数据库，只需增加一个中间件，故其可扩展性强，缺点是实现难度 大，转换精度受影响，转换时间长，更重要的是采用数据仓库的成本是一般高校所难以承 受的，尽管大型数据库厂商都提供这样的解决方案，如 oracle、ibm、sybase、sql serve 等3。 (3)双向中间件方法 根据两种数据库系统数据语言的语法，中间件把用数据语言 a 编写的事务翻译成数 据语言 b 的等效事务，然后把每个等效事务放入数据库系统 b 中进行处理。一旦等效事 务在数据库系统 b 中被执行，其执行结果即以数据库系统 b 的数据模型的格式来表示， 并将结果传送到中间件。 在前面创建的数据库模式的基础上， 中间件再把数据结果转换成 数据库系统 a 的数据格式，最后把数据送到用户。若有 n 个异构数据库，则需要个 n2 中间件，这种方法开销很大。由以上分析可以看出，传统的异构数据库数据交换繁琐、费 时，涉及到很多手工编码，对数据资源的重用和移植都很差;灵活性不足。在当今科学技 术高速发展的信息时代，必然会造成信息交流不畅、资源严重浪费3。 (4)利用标准中间件方案。中间件具有标准的程序接口和协议，可以实现不同硬件和 操作系统平台上的数据共享和应用互操作。中间件其实是一类软件，而非一种软件；中间 5 件不仅仅实现互连，还要实现应用之间的互操作。在具体实现上，中间件是一个用 api 定义的分布式软件管理框架， 具有强大的通信能力和良好的可扩展性。 标准化中间件解决 方案针对传统解决方案的不足并借鉴其的优点， 将多个异构数据库互访的过程转化为通过 标准中间件的统一接口-为系统提供统一的公共模式来实现。此时，实现 n 个异构数据库 的互访只需要 2n 种转化模式,交互复杂度为 o(n)。如果在系统中增加一个新的异构数据 库，只需要增加 2 种转化模式3，见图 2.1。统一接口后面(中间件)的具体实现对用户来说 是透明的。这种方案大大降低了交互的复杂度，也为系统的扩展提供了方便。 图 2.1 采用标准中间件方案 6 3 技术可行性分析技术可行性分析 3.1 中间件技术中间件技术 中间件对分布式应用的底层支持， 决定了中间件必须负责实现分布式事务处理、 保证 安全、进行网络负载平衡和交易控制等工作。这一特点，使得目前的中间件主流技术都是 基于分布式对象技术。ejb, com+和 corba 组件是最新一代中间件反射(reflection)中 间件的代表技术。反射中间件是为适应一些新的应用领域，诸如多媒体、实时系统、cscw 和移动应用而提出的。ejb, com+和 corba 组件都是 ctm(组件事务监控器)4服务器端组 件，属于分布式组件体系结构范畴。从技术角度来看，这二种技术既竞争一又互相促进， 在一般情况下，不能说哪一种技术更强，只能说互有优势，适用的领域也不尽相同，并且 这种区别正在不断的消失。作为 ctm 服务器端组件，com+与 mts 兼容很好，是三种技术中 使用最成熟的一种， 但作为一种开发标准， com+只能在微软平台上使用， 为了达到高效率， com 不支持持久性， 是一种无状态组件;omg 的 corba 组件不仅实现了跨平台还实现了跨语 言实现，但是由于 corba 标准比较庞大，所以其发展缓慢，掌握也很困难，并且，由于各 corba 提供商提供了不同的解决方案，使集成不同 corba 产品变得很困难。另外，虽然在 1998 年 12 月 2 日 omg 的一些成员提出 corba components (corba 组件)草案， 但直到 2001 年的 4 月 2 日的 corba3 中才正式确定了 corba 的组件标准;ejb 也是一种跨平台的组件标 准， 它是 suv 推出的组件标准， 与 corba 和 com 十相比， ejb 是实现无关的， 也就是说 ejb 可以在任意支持 ejb 的 ctm 上部署，而不需要任何改动，这就克服了 corba 标准的缺点。 ejb 同时支持持久性和非持久性，所以可以更好地支持业务逻辑的实现，ejb 是事务型商 务逻辑的出色平台。为了兼容，ejb 标准和 corba 标准实现了相互支持4。 通过比较，可以说 ejb 技术在某些方面，特别是使用前景上，优于 com+和 corba。但 正如前面所提到的，我们并不能说某种技术更有优势，选用那种技术，应视具体环境和要 求而定。例如，要在微软平台上实现分布式应用，显然，com+应该是更合适的方案。 3.2 xml 技术技术 狭义的 xml 仅仅指一种语言和采用该语言所描述的 xml 文档，广义的 xml 包括 xml 语言、xml 文档以及所有与 xml 相关的工具和技术，例如，xml 解析器及解析技术，xml 转换技术(xsl, xsml)等。广义的 xml 与 dbms 大致具有相似的作用，xml 以文件系统为 手段提供数据存储。提供对数据的直接存取访问，不需要用户关心数据的物理结构。 提供数据的模式描述:xml 采用 dtd( document type definition，文档类型定义)或 xml schema (xml 规范)来描述数据的逻辑结构。提供应用逻辑接口:xml 采用 sax (simple api for xml)和 dom (document object model)定义应用编程接口，使应用程序能够访问 7 和更新 xml 文档的样式、结构和内容5。 xml 另一重要作用是，随着 web 技术的不断发展，信息共享和数据交换的范围不断扩 大，它能克服第一，传统的关系数据库，各数据库管理系统之间的异构性及其所依赖操作 系统的异构性，严重限制了信息共享和数据交换范围的弊病。第二，利用数据交换和信息 共享都是基于语义进行， 克服数据库技术的语义描述能力差， 很难实现数据语义的持久性 和传递性的弊病. xml 技术在数据应用方面具有很多优点。第一，跨平台，xml 文件为纯文本文件，不 受操作系统、软件平台的限制:第二，易表义，xml 具有基于 schema 自描述语义的功能， 容易描述数据的语义，这种描述能为计算机理解和自动处理。第三，xml 不仅可以描述结 构化数据，更可以有效描述半结构化、甚至非结构化数据。另一方面，xml 技术在数据管 理方面存在缺点。 首先， xml 技术采用的是基于文件的管理机制、 文件管理存在着容量大、 管理困难的缺点;第二， 目前 xml 的检索是基于节点的检索， 存放大量甚至海量数据的 xml 文件造成检索速度极低:第三，解析手段有缺陷，xml 具有两种解析机制，sax 方式是基于 文件的解析，速度慢，dom 方式是基于内存的方式，资源消耗极大，第四，修改效率低， 目前 xml 的修改是基于节点的;最后，xml 的安全性及并发操作机制也是需要解决的问题 之一5。 一个简单的 xml 例子 unix color 从上述分析不难得出， 在数据应用方面， 尤其是在 web 信息共享及异构应用数据交换 方面，xml 又具有其它技术无法比拟的优点。同时 xml 异构中间件系统的代码采用 java 语言实现，以满足系统的可移植性和跨平台特性的需要。 3.3 java 开发语言开发语言 java 实现了程序的跨平台性，而 xml 实现了数据的跨平台性。 xml 是在因特网时代与 java, corba 等量齐观的一个概念。 java 解决了语言实施的同 一，corba 解决了通讯协议的同一，而 xml 解决了信息表示、关联的同一，00 面向对象是 这三者的共同理论基础。xml 是信息的高层封装与运输的标准。据此 xml 也是不同应用系 统之间的数据接口标准， 是所有信息的中间层表示是中间层应用服务器(as)的通用数据接 口。甚至可以用于数据仓库技术的数据迁移过程、数据库报告格式中6。 整个 internet 的网络应用开发商现在纷纷采用 java 技术以作为可移植程序设计平 台、使用扩展标记语言(extensible markup language, xml)作为可移植数据平台，并为 8 结合两者所获的重大成就而雀跃不已。 这两种技术以开放标准为基础， 结合成为强大的应 用程序设计平台，能够在今日的服务导向网路中提供 web 服务。xml 提供了可移植、可重 用的数据;而 java 技术提供了可移植、维护的应用程序。 java 技术与 xml 在分布式系统中显示了价值。在分布式系统中，人们只会在乎两件 事:首先，人们需要与系统无关的封装元件，java 技术在进行该项工作方面表现卓越。其 次是数据本身，这点在所有系统都互相联网后便会显示出其重要性。 “数据无所不在，但 格式各异。 ”有跨越路由器的位元串流、有来自 oracle 数据库的数据，以及主机的历史数 据等等。我们要如何将数据统一？我们要如何提供顾客完成“采购、出售”交易所需的全 部信息？当我们需要将该数据以单一数据格式呈现时，没有其他工具可以与 xml 相提并 论，xml 可以对数据应付自如7。 同时，java 技术与 xml 结合可以达成平台无关性。各地的电子商务顾客都想要在一 个快速的异质环境中， 建立具有互通性的商务应用程式。 作为供应商无关运算的互补基础， java 技术与 xml 都可以达成一个相同的目的:平台无关性。这两种技术互相合作，以提供 一个完整、平台无关、internet 导向的运算环境。因此，java 平台与 xml 将能够提供一 个开放、标准导向的技术，以在未来确保互通性7。 在本次开发的异构数据库互访中间件系统中， 采用了 java servlet 作为与 http 协议 的连接点。所谓 java servlet，就是服务器方的 java 软件模块，它能够运行在任何实现 java servlet api 的 web 服务器上，之所以称它为软件模块，是因为它不能单独运行。 正如 applet 扩展了浏览器的功能一样，java servlet 扩充了 web 服务器的功能。从动态 创建 html 页到处理各种数据库业务，java servlet 几乎无所不能。更为重要的是，使用 java servlet 可以很容易地实现管理多线程、处理客户请求以及提供安全保障等功能， 从而使用户将主要精力放在完成特定的服务上。 另一方面， 与实现同样功能的 cgi (common gateway interface)相比，java servlet 对每个用户请求，只占用系统的一个线程，而 且 java servlet 一旦被装载，则一直处于激活状态，除非系统管理员将之终止。这些都 保证 java servlet 比 cgi 更高效，占用的系统资源更少。目前，java servlet 技术不但 正被越来越多的 web 服务器所支持，而且正被越来越多的应用服务器中间件开发商所采 用。 3.4 soap 技术研究技术研究 soap 提供了一个简单的轻量级机制，使得在一个松散的、分布的环境中可以使用 xml 对等地交换结构化的和类型化的信息。soap 本身并不定义任何应用语义，如编程 模型或特定语义实现， 它只是定义了一种简单的机制， 通过一个模块化的包装模型和对模 块中特定格式编码的数据重编码机制来表示应用语义。 soap 的这项能力使得它可被很多 类型的系统用于从消息系统到 rpc 的延伸8。 soap 规范主要由三部分组成： 9 soap 信封(envelop)。它构造定义了一个整体的 soap 消息表示框架，可用于表示消 息中的内容是什么，是谁发送的，谁应当接收并处理它，以及这些处理操作是可选的还是 必须的等； soap 编码规则(encoding rules)。它定义了一个数据的编码机制，通过这样一个编 码机制来定义应用程序中需要使用的数据类型， 并可用于交换由这些应用程序定义的数据 类型所衍生的实例。例如可能应订单服务的需要，使用 soap 编码规则定义订单的数据 类型，并可以在订单生成的客户端与订单服务之间交换订单实例； soap rpc (rpc representation)定义了一个用于表示远端过程调用和响应的约定， 例 如如何使用 http 或 smtp 协议与 soap 协议绑定，如何传输过程调用，在具体传输协 议的哪个部分传输过程响应， 如我们可以在 http 响应的时候传递过程响应; 虽然这三部 分是作为 soap 的不同部分作为一个整体定义的，但他们在功能上是正交的、彼此独立 的8。特别的，信封和编码规则是被定义在不同的 xml 命名空间(xmlnamespace)中，这 样有利于通过模块化获得定义和实现的简明性。 在本模型中， soap 协议是基于 http 的， soap 把请求和响应参数编码， 并用 http 协议进行传输。一个 soap 方法可以简单地看作遵循 soap 编码规则的 http 请求和响 应， 并且它是一个 http post 请求。 异构数据库互访中间件接收符合 soap 规范的 http 数据报， 然后启动相应的模块进行处理。 在异构数据库互访中间件向外界发送信息时也使 用 soap 信息。 异构数据库互访中间件把将要发送的 xml 数据构造为符合 soap 规范的 http 数据报，通过 www 服务器发送给远端主机。异构数据库互访中间件系统中所有 关键的访问信息都在 soap 的 body 中，异构数据库互访中间件系统收到这样的请求后， 根据请求体的内容进行下一步的处理工作。 3.5 jdom技术技术 我们知道，读取和操纵 xml 文件的标准方法是 dom (document object model，文档 对象模型)。 dom 是一种通过编程对 xml 文档中的数据及结构进行访问的标准， xml 将数据 组织为一颗树， dom 就是对这颗树的一个对象描述。 也就是说， 通过解析 xml 文档， 为 xml 文档在逻辑上建立一个树模型， 树的节点是一个个对象。 我们通过存取这些对象就能够存 取 xml 文档的内容。但是遗憾的是，这种方法需要读取整个文件并将它存储到树结构中， 因而效率不高， 速度缓慢， 并且会过度使用系统资源。 在我们开发的 xmlcon/oltp 系统中， 由于有大量的 xml 文档需要处理，所以必须寻找另外一种方法，这种方法就是 sax。sax 允许正在读取文档时处理该文档， 这避免了在采取操作之前需要等待存储文档的所有内容 9。 sax (simple api for xml, xml 的简单应用程序接口)提供了一种对 xml 文档进行顺 序访问的模式， 这是一种快速读写 xml 数据的方式。 当使用 sax 分析器对 xml 文档进行分 析时，会触发一系列事件，并激活相应的事件处理函数，从而完成对 xml 文档的访问，所 10 以 sax 接口也称为事件驱动接口10。 sax 的基本原理是由使用接口的用户提供符合定义的 处理器，xml 分析遇到特定的事件，就去调用处理器中特定事件的处理函数。之所以叫做 “简单”应用程序接口，是因为这个接口确实非常简单，绝大多数事情分析器都没有做， 需要应用程序自己去实现，所以相对而言程序员需要完成比使用 dom 接口时更多的工作， 其回报是更紧凑的代码，是值得努力的。 jdom(java document object model)是基于树操作的纯 java api，用于快速开发 xml 应用程序。它是明确针对 java 程序员设计的，包含了 java 语言的语法乃至语义。 jdom的内部逻辑结构基本上与dom的相同， 比如具有document、 element、 comment 等文档节点类型，其中每一个 jdom 文档必须有一个 document 节点，并且为节点树的根 节点。该根节点可以有子节点或者叶子节点如 comment、text 等。jdom 文档中的每一 个节点类型均对应格式良好的 xml 文当中的每一个元素11。 这也就为我们利用 jdom 转 换数据库到 xml 文档提供了可操作的依据。 相对于 dom 和 sax，jdom 具有以下的优点： jdom 是用 java 开发并为 java 提供服务的，它为 java 程序员提供了一个简单、 轻量的 xml 文档操作方法， 符合一般 java 程序员的习惯与希望。 jdom 不要求程序员一 板一眼地操作树状结构，而是直接操作某 element。jdom 使用标准的 java 编码模式，沿 用了 java 代码的规范和类库。只要可能，它会使用 java new 操作符而不会采用复杂的工 厂化模式，这样就使得对象操作即便对于初学用户也很容易12。 jdom 的出现使 java 程序员不必精通 xml 技术，而只需掌握少量的 xml 知识就 能使用 jdom 的 api， 程序员再也不用因为迁就 api 而烦恼了， 而 xml 也因此可能会得 到更多应用的支持。 jdom api 比 dom 所提供的方法更为直观，同时简化了与 xml 的交互。jdom 处理 xml 的方式比 dom 容易的多，也比使用 dom 更快，并且它的功能比使用 sax 更 加强大。 从上述的比较可以看出 jdom 是中优秀的解析方式， 能够完全胜任系统功能的要求， 并且本文用到了 java 作为开发语言，在这种情况下使用 jdom 技术来处理 xml 文档是 顺理成章的！ 综上， 本文提出的基于 xml 的异构数据库互访中间件， 是解决异构数据库集成问题的 一种较优的技术解决方案。 可见，本中间件所采用的技术如下图 3.1 所示: 11 图 3.1 技术路线图 12 4 中间件模型 中间件模型 通过第三章的可行性分析， 针对目前异构数据库互访技术存在的不足， 本文给出了一 个基于 xml 的异构数据库互访中间件的模型。该中间件模型采用 xml 作为数据集成的 公共数据模型，并且使用间件模型可以利用统一的 xml 视图来集成离散的异构数据库。 xml 异构互访中间件构建在数据库系统之上，目的是集成异构数据源的信息，为数据共 享、发布和应用对集成信息的访问提供支持，并负责异构数据源的数据访问、查询和协调 数据源之间的信息。采用 xml 文档集合作为数据交换的中转站，通过中间件技术实现数 据在传统数据格式和 xml 文档格式之间的转换。中间件系统的代码采用 java 语言实现， 以满足系统的可移植性和跨平台特性的需要，利于部署。该系统被建立在某种 internet 服 务器之上，被当作一种组件由 internet 服务器来调用执行。这种设计使得异构互访中间件 系统可以充分利用 internet 服务器的现有功能，专注于商务逻辑和其它方面的设计，并且 借助于 internet 服务器的帮助，系统被自然的扩展到了 internet 环境。 下面将详细介绍该中间件的实现技术： 4.1 中间件模型的体系结构中间件模型的体系结构 该中间件模型的体系结构可以用图 4.1 描述如下: 图 4.1 中间件模型的体系结构图 该中间件模型采用了 xml 作为数据集成的公共数据模型。 由于 xml 具有前述的诸 多优点，所以此模型可以支持来自各种数据源的数据，包括数据库系统中的数据、文件系 统中的数据、多媒体数据、www 上 html 文件中的数据，这就使得该中间件模型的可 扩展性得到了充分的保证。 13 由上图可知，该中间件模型主要由 xui 用户界面、通信模块、决策模块以及包装模 块这四个功能组件构成。 4.1.1xui 界面界面 xui 用户界面是一个可视化的用户界面，此界面用于管理此中间件模型(启动和停止 连接) ,性能监视。xml 异构互访中间件作为一个企业级中间件需要和许多其它服务器进 行通信，由于其通信的形式非常复杂，并且随着时间的推移，系统的原有配置可能需要加 以改进以满足系统最新的需求， 所有这些都要求存在一个性能监视工具， 对其通信状况进 行监视以利于系统性能分析。为此，本系统设计了一个辅助工具:系统监视工具，它用来 实时地监视本中间件通信处理模块的工作状况， 通过它系统管理员可以查看当前系统的负 荷以及通信逻辑处理模块和各个远程节点的通信信息， 从而评估当前系统的性能和找出系 统性能瓶颈等等信息，并进而改善当前系统的配置来提高其性能。也就是说，系统监视工 具是一个诊断工具， 它描述了系统的当前运行状况。 为了使用户能够监视整个中间件系统， 作为监视部件的系统监视工具部件必须采集各种各样的信息，这些信息分为全局信息和 rmt 信息，全局信息包括系统采样时间、区间 cpu 使用时间、session 总数、区间最大 使用中的session 数/区f7最小使用中的 session 数、 thread总数、 区间最大使用中的thread 数/区间最小使用中的 thread 数等等信息。rmt 信息包括远程主机名、总的 connection 数、 区间最大使用中的 connection 数/区间最小使用中的 connection 数、 上行数据字节数、 下行数据字节数等等信息。 我们把这些采集的信息存放到文件中去， 这样用户就可以通过 查看这些文件来了解当前系统的状态并进而分析当前系统的整体状况， 同时我们开发了一 种图形模式， 把这些信息通过一种图表的方式直观的反映在系统管理员的面前， 这两种信 息都可以通过网页的形式在远端客户机上被查看， 这样系统管理员就可以通过系统监视工 具远程维护本统。 4.1.2 通信模块通信模块 通信处理模块完成异构数据库的交互功能，系统初始化，以及文件关联机制的功能， 下面详细介绍之。 通信处理模块是整个中间件对外的接口， 负责从 interne 上接收用户的请求信息和把 响应返回给用户， 提供数据访问的透明性和位置透明性。 同时的系统初始化功能设计主要 基于如下考虑： ： 第一点是为了提高系统的处理速度， 在系统初始化过程中， 将把系统中所有的规则转 换信息即编辑指示文件读入内存，建立 hash 表，这些在以后的格式转换处理过程中，只 要根据关键字简单地取出即可利用，加快了系统的处理速度； 第二点是为了保持和通信逻辑处理模块的独立性问题，在初始化通信逻辑处理模块 时，只是简单地调用了它的接口，而不把初始化它的代码放入其它处理模块中。系统初始 化模块将通过接口初始化通信逻辑处理模块， 同时它将调用决策模块。 系统初始化模块在 14 每一次用户请求到来时，重新检查系统是否正常，如果系统发生异常，则由系统初始化模 块完成系统的自修复工作。 以下是系统初始化模块程序框架： public class xbilconwebserver extends httpservlet implements/*一些接口*/ public void init(servletconfig config) throws servletexception super. init(config)； 初始化中间件系统； 写日志信息； public void dapost(httpservletrequest http_req. httpservletresponse http_resp) throws servletexception, ioexception if(系统异常) 系统自修复工作; 调用请求服务模块完成用户请求服务任务: return； 文件关联机制： 对于同一次事务的请求信息和响应信息的关联问题。 由于对于同一种 事务请求，有多种类型的系统响应，所以必须设计一种机制，使得这些相关信息可以被有 效的联系在一起，方便系统的查找。这种文件是 xml 信息，并且还涉及到一个消息定义文 件， 该消息定义文件正是为了关联同一次事务中上下行编辑指示文件而设计的， 它也是一 种 xml 信息， 其中除了记录每一项服务的上下行编辑指示文件关联信息之外， 还记录了每 一项服务的配置信息。 消息定义文件被设计用来记录整个中间件系统向外提供的所有服务 的配置信息， 包括每一项服务的 serviceid, oltpname, transactionid,formatid、 以及 rulepath。 其中的 serviceid 是用来唯一确定一项服务的关键字，oltpname 是用来标识远程的主机， transactionid 是用来标识某主机之上某项事务，formatid 是用来标识处理事务的格式， rulepath 记录了上下行编辑指示文件的路径信息。该设计使得系统所有服务的配置信息都 在同一个文件中，系统对外提供的服务信息可以一目了然，这种设计方便了系统的处理， 有利于系统的维护，当然随着该系统所提供服务数目的增多，该文件将变得越来越大，所 以在设计该文件时必须考虑处理的速度问题， 基于前面同样的原因， 该文件的设计采用了 xml 文件形式，实现配置信息的动态扩展。一个完整的消息定义文件如下所示： 15 可以有多个 response 元素 4.1.3 决策模块决策模块 决策模块是 xml 异构集成中间件的逻辑组织核心，负责与通信层的交互，根据系统 传递的不同消息调用包装模块所提供的服务， 生成对应的中间件全局数据模式和数据转换 请求。决策模块与其他模块的分离，实现了较好的灵活性和可扩展性，并利于事务控制和 容错控制。 4.1.4 包装模块包装模块 数据转化是 xml 异构互访中间件的核心和最终实现的关键， 这一功能是由包装模块 实现的。对于异构数据库资源来讲，包装模块就是关系模式的翻译器。通常，包装器是负 责提取数据源元组的一段程序，为了适应 xml 异构互访中间件的需要，