（计算机软件与理论专业论文）web系统移植框架的研究及数据访问层辅助系统的实现.pdf

摘要 随着互联网的发展进步，对信息和资源交换与共享的需求，从数量、水准到 范围都在飞速发展。基于w e b 的i n t e r n e t i n t r a n e t 体系结构已经成为当今应用 的首选结构。与此同时，再工程时代已经到来，一大批运行于十几年、甚至几 十年的软件系统也纷纷进行w e b 化升级改造。这些都极大的推进了信息、资源共 享的步伐。然而飞速发展的软件技术，产生了大量的操作系统，数据库，软件体 系结构，这些异构平台的出现太大的阻碍了信息、资源共享化。这种必然的矛盾 必然引发_ | l r e b 系统移植需求的大量涌现。目前最受欢迎的w e b 系统移植方法多是 基本手工对原系统进行重构的，然而大量的手工操作必然出现项目的成本增加， 生产率下降，质量得不到很好的保证。建立良好的计算机辅助系统来辅助实现 w e b 系统移植将可以在很大程度上缓解手工移植作业产生的成本、生产率、质量 上的缺陷。 本文首先进行w e b 移植理论的研究：提出了面向模式思路解决数据访问层移 植问题，以集成的观点进行业务逻辑层移植的辅助，通过静态走查工具实现页面 表示层移植后的浏览器兼容性问题，进而提出了w e b 系统移植计算机辅助框架。 基于这个框架，在实践的基础上构建了一个w e b 系统移植辅助系统，重点进行了 数据访问层移植的设计与实现，并指出了设计实现过程中的关键点。本文在理论 和实现上重点阐述了数据库移植、数据访问层生成的计算机辅助支持。 关键词软件再工程；模式；w e b 系统移植；数据访问层；w s m a b s t r a c t a l o n gw 油i h ed e v e j o p m e 玎ta n dj m p m v e m e n to fi n t e m e t ，t h er e q u j r e m e n to fe x c h a n g ea n ds h a r e o fi n f 0 皿a t j o n 锄dr e s o u r c e sa r e q u i c k l yd e v e l o p m e n t 劬mq u a i 】右吼l e v e j t o s c o p e t h e i n t e r n e 们n t 啪e ta r c h i t e c t u r eb a s i n gw e bh a sa l r e a d yb e c o m ep r e f e r r e da r c h j t e c t u r e 访n o w a d a y s a p p | i c a t i o n s ”a tt 1 1 e s a m et i m e ，r e e n g i n e e r i n ga g e sh a s a l r e a d yc o m e ，al a r g eq u 叫i t yo f s o f h v a r es y s t e mw h i c hh a sb e e nm nf b rm o r et h a nt e ny e a r sa n de v e ns e v e r a ld e c a d e sc a n yo n w e br e e n g j n e e r i n gi ns u c c e s s j o n 耵l e s e 仃e m e n d o u sb o o s tt i l ee x c h a n g e 柚ds h a r e ds t e po f i n f o n m t i o na n dr e s o u r c e s h o w e v e r ，t h ed e v e l o p m e m a ls o f h v a r et e c h n o l o 斟p m d u c e sag r e a t d e a lo fo p e r a t es y s t e m ，d a t 曲a s ea n ds o f h v a r ea r c h i t e c t i l r e t h ee m e 唱e n c eo ft h e s ei s o m e r o u s p l a t f b 订n so b s t m c t st h ee x c h a n g ea i l ds h a r eo fi n f o r n l a t i o na n dr e s o u r c e s t h i sk i n do fi n e v j t a b l e c o n 妇i c tc o n s e q u e n t i a l j yc a u s e sag r e a td e a io fw e bs y s t e mm i g r a t i o nf e q u i f e m e n t n o w a d a y s ，t h e m o s tp o p u l a rw e bs y s t e mm i g r a t i o nm 吼h o d sm o s t l yb a s eh a n d i c m f tt oc a 兀yo nr e e n g i n e e r j n g f r o mo r i 舀n a ls y s t e m ，h a w e v e r ，ag r e a td e a lo fh 孤d i c r a no p e r a t i o ni n e v i t a b l ee m e g e n c et h ec o s t i n c r e m e n to fp r o j e c t ，也ed e s c e n d e n tr a 【eo f p r o d u c t i v “y ，t h eb a da s s u f a f l c eo f q u a l 时b u i i d i n gu p ag o o dc o m p u t e ra i d e ds y s t e mw h i c he x e c u t ea i d e do p e r a t et ow e bs y s t e mm i g r a t o nw i l lb ea b i e t oa l l e v i a t ed e f e c t so f c o s t ，p r o d u c t i v i t ya n dq u a l i t yi nt h eh a n d i c r a f tm i g r a t i o nh o m e w o r k t h ed i s s e n a t i o nc 删e so nt h er e s e a r c ho ft h ew e bs y s t e mm i g r a t i o nt h e o r j e s6 r s t ，p u t t i n g t l o n v a r dp a n e m o r i e n t e dd a t a b a s ea c c e s sl a y e rm i g r a t i o n ，w i t hi n t e 掣a i e ds l a n d p o i n tc 锄y i n g 佣 t h eb u s i n e s sl o g i c1 a y e rm g r a t j o n ，w i t hs t a t j cw a l kt l l r d u 曲t o o li m p m v i n gi h ec o m p a 石b i l i t yo f b m w s e ts e c o n d l y g i v ea c o m p u t e ra i d e df h m e w o r ko fw e bs y s t e m m i g r a t j o n ，b a s j n g t h e f r a r n e w o r ka n dp m c t j c e s ，d o j n gt h ed e s g na n dr e a l i z a t i o no fw e bs y s t e mm i g r a t i o na i d e ds y s t e m e s p e c i a l l y ；nd a t a b a s ea c c e s s1 8 y e rm i g r a t i o ns u p p o r t ，a n dp o i n t i n go u ik e yp o i n t s d u r i n gt h e r e s e a r c h t h i sd i s s e r t a t j o ne l a b o r a t e dt h ed a l a b a s ea c c e s sl a y e rm i g r a t i o ni nt h et h e o e sa n dt h e r e a l i z a t j o ne s p e c j a l l yi nd a t a b a s em j g r a t i o na n dd a t a b a s ea c c e s sj a y e rg e n e r a t i n g k e y w o r d ss o r w a r er e e “g i n e er i n g ；p a n e m ； w e bs y s t e mm i g r a t i o n ；d a i a b a s ea c c e s sl a y e r w s m 独创性声明 本人声州所呈交的论文是我个人在导师指导下进行的研究1 _ 作及取衙的研 究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中小包含其他 人已经发表或撰写过的研究成果，也4 i 包含为获得北京t 业大学或其邑教育机构 的学位或证书而使用过的材料。与我一同t 作的同志对本研究所做的任何贡献均 己在论文中作了明确的说明并表示了谢意。 签名日期 关于论文使用授权的说明 奉人完全了解北京t 业大学有关保留、使用学位论文的规定，即：学校订救 保留送交论文的复印件，允许论文被查阅和借阅；学校可以公布论文的全部或部 分内容，可以采用影印、缩印或其他复制手段保存论文。 ( 保密的论文在解密后麻遵守此规定) 虢巡：塑缉叫 幽 第l 章绪论 1 1 课题背景 1 1 1 平台多元化与信息资源共享 伴随着i n t e r n e l 时代的到来和快速发展，信息、资源共享化与平台多元化 之间的矛盾越来越显著，这也就直接导致w e b 系统移植需求的大量涌现。这种显 著矛盾的内在原因可归纳如下： ( i ) 互联网的互联互通特点必然导致信息、资源的共享需求增加。 i n t e r n e t i n t r a n o t 的发展打破了地域和时间的限制，使对信息和资源交换与共 享的需求，从数量、水准到范围都在飞速发展，局域网下的软硬件资源在广域网 范围内的互通有无、交换、互补和共享已成为必然的人方向，为社会各个领域带 来了不可估量的社会价值和商业价值。 ( 2 ) w 曲化再工程极大的推进了信息、资源共享的步伐。软件维护期的适 应性、完善性、预防- 阵维护都届再工程范畴。如图卜l 所示，2 0 世纪9 0 年代 以后，计算机领域发达国家的既存软件开发已占软件开发总量的8 0 以上，可 以说，软件工程已经进入了再工程时代。1 。在冉工程作业中，又有占绝对多数的 再工程作业是对原有系统进行w e b 化再i 程，从而极大的加速了局域网下的软硬 件资源在广域网范围内的互通有无、交换、互补和共享。基于w e b 的 i n t e r n e t i n t r a n e t 体系结构已经成为当今应用的首选结构” 嗨惭删鲥姚倒 ； 软卅 再 ，j，7f：j二辜。二二二：二： l 一一一一一 ； 一f l 9 8 0 年j 9 9 0 年2 0 0 0 年 图1 1 软件工程巾一次t 程和再t 程比例趋势 图1 1 软仲工程中一次t 程和再i | 程比例趋势 f i g u r e1 1t h ep m p o n j o nt r e n do f e n g m e e n g a r i dr c e n g j n e c r i n gi ns o r w a r ee n g i n e e n n g 北京 业大学l 学坎十字位论文 ( 3 ) 平台多元化阻碍了信息、资源的共享。在软、硬件技术一日千里的今 天，操作系统、数据库管理系统、软件体系结构等技术已经得到了前所未有的快 速发展，各大厂商在商业利益的推动下纷纷发展创新，占有、扩大自己的市场份 额，造就了多种平台共存、竞争的局面。各提供商的产品互有所长，使用户选择 的范围更宽更广，从而出现了大量异构平台上的应用系统。在许多时候，这些系 统间并不能很快的进行交互和信息、资源的共享。为了达到这种目的，不得不面 对不同平台厂商间巨大差异，而花费大量的时间、成本进行应用系统在不同平台 间的移植工作。 1 1 2 平台多元化下的w e b 系统移植 w e b 系统移植指既存系统向w e b 系统的重构开发，它是缓解日益显著的信息、 资源共享化与平台多元化之间矛盾的一个有效途径。 w e b 系统移植属于w e b 再工程范畴，它是使目标系统为了适应以w e b 为中心 的计算方式而将既存系统再工程升级为基于w e b 系统的开发过程，并且升级后的 w e b 系统与既存系统存在操作系统平台、数据库平台的变更。w e b 系统移植的既 存系统既可以是客户机服务器( 简称c s ) 系统也可是浏览器服务器( 简称b s ) 系统。 一般的w e b 系统移植有一个显著的特点，即可以维持绝大部分外部不变，通 过对既存系统的局部甚至整体各个层次进行重构移植，将局域网下的局部系统重 构为具有客户端一w e b 服务器一数据库服务的三层或者多层结构的w a n 系统“1 。 其结果可以实现局域网内的信息、资源在互联网上的最大共享。 1 1 3w e b 系统移植的着眼点 本课题的研究内容是构建一个计算机辅助系统辅助实现既存系统向具有很 强可移植性的w e b 系统的移植升级。此既存系统可以是局域网下的c s 结构的系 统，也可以是w e b 系统，它们可以有数据库的支持，也可以没有数据库的支持。 为了进行更为典型的研究，我们重点放在既存系统为局域网下的有数据库支持的 c s 系统。 在w e b 系统移植过程中，数据库移植是一个非常重要的环节，数据库的发展 已经经历了网状数据库、层次数据库、关系数据库和面向对象的数据库四大主要 阶段。目前最广泛使用的数据库是关系数据库，而网状数据库和层次数据库现在 已经很少使用，面向对象数据库刚刚兴起，没有达到理想的效果。我们这里研究 的重点是关系数据库，所有的数据库移植在关系数据库之间进行。在后面的文章 中，如果没有特殊说明，提到的数据库专指关系数据库。 1 2w e b 系统移植概念 1 2 1 w e b 系统体系结构 w e b 体系结构是指逻辑结构而言，它是在w e b 应用的大量普及下产生、发展 并越来越完善的。图卜2 描述了典型w e b 系统体系结构。 碍三 应用服务器 i 数据库服务器 业务逻辑层 数据访问层 图卜2 典犁w e b 系统体系结构 f i g u r el - 2t h ec l a s s i c a lw e bs y s i e ms t r u c t u r c ( 1 ) 数据访问层包括数据库服务器和数据库本身，用户的全部数据信息存 放在数据库上，数据库服务器只与应用题服务器打交道。 ( 2 ) 业务逻辑层应用服务器呈现为核心平台的角色，应用服务器主要存放 系统功能组件和应用程序，来完成用户对数据库的访问和复杂的业务处理。 ( 3 ) 页面表示层w e b 客户端应用程序负责为用户显示信息，处理数据库和 北京工业人学工学硕上学位论文 用户屏幕上的信息，显示报表并提供用户可中断的操作，任何发送给服务器组件 的操作应该不需要用户的干预就可完成。有些系统将w e b 服务器与应用服务器集 成在一起放在业务逻辑层。 1 2 2w e b 系统可移植性 w e b 系统的可移植性就是指w e b 系统的所有逻辑组件从一个平台移植到另一 个平台后，仍能继续工作的能力。根据w e b 系统的典型体系结构，它应该包括三 种情况：数据库平台( d b m s ) 上的可移植性、操作系统平台( 0 s ) 上的可移植性、 浏览器平台上( b r o w s e r ) 的可移植性。 ( 1 ) 数据库平台上的可移植性是指w e b 系统的数据访问层访问对象从一个 数据库平台移植到另一个数据库平台后，仍能继续工作的能力。它要求在w e b 系 统中的数据库访问层对于业务逻辑层是透明的，数据访问层内部的任何变动都不 会对业务逻辑层产生副作用并导致业务逻辑层的修改，这种数据访问层的变动包 括对后台数据库在不同操作系统下、不同数据库及其版本间的移植，也包括数据 访问层内的访问数据库的s q l 的变更。这就要求在新规和改造的w e b 系统中，其 数据访问层要有相当的独立性，可维护性，它对外要有一个统一不变且很灵活的 接口。 ( 2 ) 操作系统平台上的可移植性是指w e b 系统的业务逻辑层从一个操作系 统平台移植到另一个操作系统平台后，仍能继续工作的能力。它要求w e b 系统的 所有业务逻辑组件能摆脱平台的烙印，可以在新的操作系统中断续工作。 ( 3 ) 浏览器平台上的可移植性是指w e b 系统的页面表示层的客户端页面从 一个浏览器平台上移植到另一个浏览器平台上后，其页面仍能正常与用户交互的 能力。它要求页面表示层生成的向客户端发送的字节码可以在多种b r o w e r 上正 常显示和工作。 因此，如果一个w e b 系统它本身已经俱有很好的可移植性，那么些系统向其 它平台移植时可以在更小的时间，更少成本，以更高的质量完成移植，这种w e b 系统可以更容易的进行信息、资源的整合共享。 1 2 3w e b 系统移植作业组成 针对w e b 系统的层次结构以及w e b 系统的可移植性理论，通常的w e b 系统移 植是由三部分组成。即数据访问层移植，业务逻辑层移植和页面表示层移植。 ( 1 ) 数据访问层移植是指对既存系统的数据库和数据访问逻辑进行兼容 改造，使其成为目标w e b 系统的数据访问层。通常要涉及到数据库的移植和数据 访问层的生成。对于数据库移植，一般是指原来的数据库版本的升级或向其它数 据库的移植。它必须要保证原有数据库中数据的安全性和完整性，并具有较强的 数据库平台可移植性。本论文将从数据库移植和数据访问层生成两个方面对数据 访问层的移植进行重点研究。 ( 2 ) 业务逻辑层移植是指对既存系统的业务逻辑处理进行重构，将其统 一封装成w e b 系统的业务逻辑层。通常要将既存系统的业务逻辑进行整理重组， 保证原有的业务处理流程不变，业务处理结果不变。并且新的业务处理逻辑必须 很强的操作系统平台可移植性。本论文将对业务逻辑层移植进行一定的理论分析 和研究。 ( 3 ) 页面表示层移植是指按照既存系统的页面表示逻辑根据w e h 系统的 基本风格及客户的具体页面显示需求进行w e b 页面的设计。页面表示层移植的处 理大部分是进行新的w e b 页面设计并且保证其工作流程与既存系统页面的工作 处理流程一致。新的w e b 页面要保证其可以在尽可能多的浏览器中正常的显示， 具有很强的浏览器平台可移植性。本论文中将页面表示层浏览器兼容性作为研究 内容。 1 3本课题与既成成果的关系及创新性 1 3 1参考、继承既成成果 a s o s e p 是用2 年左右的时间在八年多研发成果之上，进一步构筑和完善适 应当今全球o u t s o u r c i n g 化时代的软件开发环境平台，这个平台具有支持软件 工程生产线和c m m l 5 级软件企业计算机辅助支援管理功能。 a so a l 是a s o s e p 上的软件组装生产线，a s e r e 是软件再工程辅助丌发系 北京工业丈学工学硕士学位论文 统，它在a s o a l 上的一个w e b 再工程生产线，本课题在此基础上进行w e b 系统 移植辅助系统的开发，其中借鉴许多a s e r e 的既成成果，研究结果将作为一个 新的软件开发生产线一w e b 系统移植生成线，对具有w e b 系统移植需求的项目进 行辅助支持。 1 3 2 本课题创新性 ( 1 ) 对w e b 系统移植进行了全面的整合研究，提供了w e b 系统移植过程中 的全方面计算机辅助支持，而不是仅局限于某一个局部的移植支持。 ( 2 ) 以面向模式的思路研究w e b 系统移植，将复杂问题简单化，通过积累， 抽象进而达到移植的一般化，最后得到所有解。 ( 3 ) w e b 系统移植辅助系统的核心思路不是为原有系统增加超平台性，而 是为低成本、高质量、快捷方便地构建低冗余、高维护性，高可移植性的新平台 系统提供计算机辅助支持。 1 4 全文组织结构 第1 章对w e b 系统移植的背景进行了阐述，指出进行w e b 系统移植研究的重 大意义，并介绍了w e b 系统移植理论，以及本课题的创新性。 第2 章主要详细描述了当前w e b 系统的研究现状。重点介绍了手工w e b 系统 移植方案下的研究现状，并分析了现存的一系列问题。 第3 章主要讲述了本课题对w e b 系统移植进行的理论研究，重点详细阐述了 面向模式思想进行w e b 系统数据访问层移植的基本研究理论，并对业务逻辑层和 页面表示层的移植方案进行简要的理论阐述。 ， 第4 章主要提出了w e b 系统计算机辅助移植的框架，详细叙述了数据库移植 和数据访问层生成的实现原理，简述了业务逻辑层移植的集成思路，并简要叙述 了提高页面表示层浏览器兼容性的实现方案。最后介绍了此框架与 a so s e p a s 一0 a l 之间的关系。 第5 章论述了w e b 系统移植辅助系统( w s m ) 的设计，主要进行了数据访问 层移植辅助支持的设计与实现，重点详述了设计实现中的三个关键点。 结论中展望w e b 系统移植辅助系统的发展和其存在的局限性。 第2 章w 曲系统移植的研究现状 2 1w 曲系统移植主要方案 随着i n t e r n e t 的快速发展，越来越多的公司和机构开始关注并进行w e b 系 统移植的研究，并且有许多产品已经进入了商业化。目前进行w e b 系统移植主要 有两大类方案：自动化半自动化移植和手工移植。 2 1 1自动化半自动化移植 自动化半自动化移植是指主要通过自动化工具进行w e b 系统移植作业，并 辅助以一定的手工修正，将既存系统移植到新平台上。这些自动化工具绝大多数 是由一些实力雄厚的开发环境提供商研究开发的。表2 一l 是几种典型开发环境 提供商的w e b 化移植方案，有相当高的自动化率，为在这些环境进行既存系统 w e b 化移植提高了生产率，节约了成本。 表2i 几种典型制造商的w e b 化移植方案” t a b l e2 1s e v e r a 】c l a s s i cw e bm j g r a t i o ns o l u 廿o n so f p r o d u c e r s 预算自动源语吉 源开发 r e l e a s e 制造商 w e b 化开发t 具 w e b 化移植解决方案转化率重用率 语言时间 ( 最高值)( 虽高值) s v b a s ep o we rp o w e r b u i 】d e r p p e o ns 0 1 u ti o n 2 0 0 29 0 9 0 b u i l d e r80 4 7 0 r 8p o w e r bu l l d e r90 部品化s o l u ti o n 2 0 0 3 31 0 6 0 b o r l a n dd e l d h jd e l o h i6d c 0 6 i c o ms 0 1 u t i o n2 0 0o 207 0 d e l o h i6w e b s n a ds 0 1 u t i o n 2 0 0 1 6 05 0 d e l d h j7i n t r a w e b s o 】u t i o n2 0 0 205 0 d e l d h i8d e l h i8ont h en e t2 0 0 2 87 0 7 0 f r a m e w o r ks o l u t i o n m i c r o s o f tv b 6v i s u a ld c o m c s o l u t i o n2 0 0 2 25 0 9 0 s t u d i on e t v is u a l a s p n e t v b n e t 2 0 0 2 25 0 4 0 j i s t u d i o n b ts o l u t i o n 但是这些方案的也存在着很多的不足之处： ( 1 ) 对移植前系统的限制过多，成功案例很少。它们都是为了挽救自己的 已有市场份额而进行了w 曲化移植方案。这些方案大部分都是在一些的苛刻条 件下进行的。比如a p p e o n 的限制是既存系统的规模不得超过5 0 m ，复杂度不能 超过1 0 层调用等等。它们的费用都是相当的高，对于非大型用户是基本承受不 起的，从而阻碍了这些方案的推行，在目前的并没有太多的成功案例。 ( 2 ) 移植后的w 曲系统多是运行于w i n d o w s 平台，具有较差的w 曲系统 可移植性。从表1 1 中可以看到，这些厂家基本上是跟随m i c r o s o r 的脚步，它 们进行的w 曲化移植后的系统多是采用n e tf r 锄e w o r k 的结构，并不具备到其它 操作系统上的可移植性。 ( 3 ) 转化率高的解决方案使移植后的w e b 系统页面与传统的w e b 页面有很 大的差异。如s y b a s e 的a p p e o n 方案，相当于将既存系统的页面镶在了浏览器上， 并且对浏览器的限制很大，只支持i e 5 o 及以上版本。 ( 4 ) 转化率低的解决方案( 如b o r l a l l d 、m i c r o s o f i ) 并没有实现既存系统 的w e b 化。这种方案只是实现了对其业务逻辑所用的开发语言的升级支持，然 后再用a s p n e t 进行了w e b 系统的开发。 2 1 2手工移植 手工移植指用另一种语言重构既存系统来实现w e b 系统的移植。这种方案是 目前最为广泛的w e b 系统移植方案之一，它没有太多的限制，只要对既存系统进 行详细的需求分析、设计、并最大限度的重用既存系统的资源就可以达到用户所 要求的结果，但是通常其自动化程度很低。这种方案更具有灵活性和普遍性，通 常采用具有很好可移植性的1 a v a 语言进行开发，下面我们将从数据库移植、数 据访问层生成、业务逻辑层移植、页面表示层浏览器兼容性四个方而更详细的介 绍其手工移植研究现状。 2 2数据库移植研究现状 2 2 1 s q l 标准 2 0 世纪7 0 年代、i b m 公司丌发了一种叫做s e q u e l 的产品，又称结构化英语 查询语言，它最终演变成为s q l ，即结构化查询语言( s t r u c t u r e dq u e r yl a n g u a g e ) 。为了在各个开发商间达到高度的一致a n s i ( a m e r i c a nn a t i o n a ls t a n d a r d s i n s t i t u t e ，美国国家标准委员会) 于1 9 8 6 年发布了它的s q l 标准的第一版本， 并又陆续推出s q l 9 2 ，s q l 9 9 。 各关系数据库开发商对s q l 9 9 进行了不同程度的支持，但都已达到其要求的 最低标准。同时，各开发商在支持s q l 9 9 标准的基础上根据自己数据库的具体情 况对s q l 进行了不同程度的扩展，产生了各自的方言。如：o r a c l e 的p l s q l 、 s q ls e r v e r 的t r a n s s q l 、d b 2 的d b 2s q ld i a l e c t 等，在一些情况下，不同数 据库提供商针对同一功能所提供的函数、方法名是完全不同的，或者是同一函数、 方法名在不同的数据库中的功能是大相径庭的。这都使得数据库间的移植产生了 很大的困难。 2 2 2关系数据库厂商的数据库移植工具 各大关系数据库厂商本身都提供了从其它数据库向自身数据库的移植一r ：具。 典型的数据库厂商如o r a c l e ，s q l s e r v e r ，s y b a s e ，d b 2 等1 如表2 2 所示。 表2 2 数据库厂商的数据库移植工具 t 曲1 e2 2t h ed a t a b a s em i g r a t i o nt 0 0 1 so fd a t a b a s es u p p o n e r 5 数据库t 具名 o r a c l eo f a c l em i g r a t i o nw o r k b e n c h s 0 1s e r v e r 数据转换服务( d t s ) s v b a s e s q lu p g r a d e d b 2i b md b 2m i g r a t i o n r o o l k i t 各关系数据库提供商提供的移植工具不是对所有数据库或已经支持的数据 库的所有版本都是有效的。以w i n d o w s x p 下的0 r a c l e 9 i 为例，它所吏持的数据 库移植工具o r a c l em i g r a t i o nw o r k b e n c h 的支持情况1 如表2 3 所示： 表2 3o m c l e 9 i 数据库移植工具支持一览 1 1 a b l e2 3t h e1 j s to f s u p p o r tc a s ef 岫mo r a c l em i g r a t i o nw b r k b e n c ho f o r a c l e 9 i 目标数据库 o r a c l e 8 o r a c l e 8 io r a c l e 9 i 、 源数据库 m i c r o s o rs o ls e r v e r6 5a n d7 0 d b 2 m i c r o s o na c c e s s2 o 9 5 ，9 7a n d2 0 0 0 s y b a s ea d a p t i v es e r v e rl l i n f o m l i xd y n a m i cs e r v e r7 3 m ys q l3 2 2a n d3 2 3 。 p o s t g r e s q l 2 2 3 非数据库提供商的数据库移植工具 由于数据库移植的需求比较大，出现了一些数据库移植的辅助工具。这些工 具通常是解决一些典型数据库问的移植，下面是家具有权威性研究和经营数据 库相关的公司a d v e n t n e t 提供的系列工具支持。如下表所示： 表2 4a d v e n t n e t 移植工具支持情况一览 t a b 【e2 - 4t h e1 i s to f s u p p o r tc a s eh md a t a b a s em i g r a t i o nt o o lo f a “e n t n e t 蛔标数据库 m j c r o s o n so f a c 】e p 0 s t g r e s v b a s e m y i n f o ri b md b 2 o l s e r v e r8 i 9 i 1 0s o la s e1s o l m x u d bf o rl i 2 0 0 02 x n u x u n i x a n dw i n d o w i s8 x 源数据库 m i c r o s o ns o ls e r v e r2 0 0 o o r a c l e 8 i 9 i 1 0 g i b md b 2u d bf b r l i n u ) 【，u n i x ， a n dw i n d o w s 8 x s v b a s ea s e 1 2 x i n f o r m i x m ys q l p o s t g r e s q l 2 2 4 现有数据库移植方案的不足之处 1 ) 数据库厂商移植方向都是单向的，即都是从其它的数据库向自身的数据 库提供移植的解决方案。 2 ) 非数据库提供商提供的移植工具主要是针对目前比较主流的一些数据库 的移植。对0 r a c l e ，s q l s e r v e r 的支持性相对较好，对于向d b 2 和s y b a s ea s e 的支持较差，对于许多应用也比较广+ 泛的关系数据库i n f o r m ix 、m ys q l 、 p o s t g r e s q l 等基本不支持。 3 ) 非数据库提供商提供的移植工具约有6 5 以上是在w i n d o w s 平台下的数 据库提供移植。对于在l i n u x 、u n i x 等其它操作系统下常用数据库m ys q l 、 p o s t g r e s q l 、z 0 p e 、s a p d b 、g d b m 、b e r k e l yd b 、m s q l 、f i r e b i r d 等( i 勺移植目肓i 不支持。据调查，目前德国政府和公司使用的信息系统中有4 0 以上使用的是 l i n u x 平台，我国正在丌展的电子政务也鼓励基本l i n u x 平台进行构建1 ，使得 支持l i n u x 下的数据库移植工具的重要性大大的提升。 4 ) 所有的移植工具支持数据库的版本也是很有限制的，并不是完全满足现 有数据库移植需求。如表2 4 中对s q l s e r v e r 只支持s q l s e r v e r 2 0 0 0 一个版本， 对于s y b a s e a s e 的支持也仅是1 2 x 版本，对于更早且用得的很广范的6 o ，7 o 等都不支持。 5 ) 数据库移植没有一个统一的移植方案，各移植方案之间是比较独立的， 在不同的移植工具间没有形成共同的接口，特别是对于专业从事w e b 化再工程开 发的企业来说，要进行相当多的重复劳动来解决同样或相似的问题，造成一种人 力，财力的浪费。 2 3数据访问层生成的研究现状 数据访问层的实现主要有两大类：传统全手工编码和计算机辅助编码。 2 3 1 传统全手工编码 既存系统向w e b 系统进行移植升级时，要将原来系统的所有数据访问逻辑进 行整理、归纳，在w e b 系统中进行统一包装，这样的数据访问层将具有更强独立 性。这样的工作一般是图2 一l 所示的流程进行的。 图2 1 传统全手j 二编码数据访问层生成过程 f i g u r e2 一lt h ep r o c e s so f t r a d i t i o n a ld a t a b a s ea c c e s si a y e r 传统全手工编码生成数据访问层有如下不足之处： 1 ) 编码任务繁重。存大的大量的重复劳动，如典型的数据库连接、参数匹 配处理等都是大量的相似或相同的代码，手工的拷贝虽然减少了一定的编码时 间，但却增加了测试时间。 2 ) 测试任务繁重。对于以数据为中心的大多数w e b 系统来说，数据访问层 的工作量几乎占整个编码的4 0 左右，这种开发方式中人为的因素很多，给测 试工作增加了很多的工作量，从而也增加了整个软件开发的成本和时间。 3 ) 移植后的w e b 系统的数据访问层并不具备很好的可移植性和维护性。由 于不是统一生成的代码，即使有开发规范的限制，人为因素的参与使得生成的数 据访问层仍不具有很好的可移植性和可维护性。 2 3 2计算机辅助编码 计算机辅助编码是通过辅助工具，按照一定的规范和代码模板对数据访问层 进行编码。现在已经出现了针对专门语言的数据访问层自动生成工具，它们的基 本工作原理是根据数据库中的库表结构自动生成数据访问层，并提供对外统一的 访问接口。不同开发语言的典型工具如表2 5 所示： 表2 5 数据访问层自动生成t 具一览 t a b l e2 5t h e1 l s to f d a t a b a s ea c c e s sl a y e rg e n e m t i n gt o o l s 框架语言工具名 n e tf r a m e w o r kc 拌 r a p t i e r n e tf r a m e w o r kv b n e tc o d e s m i t h j 2 e ej a v at 0 r o u e j 2 e ej a v ah i b e m a t e ( 1 ) 这些数据访问层生成工具的优点： 1 ) 数据访问层的生成过程很快，可以节省大量的时间和成本。利用工具生 成数据访问层的时间远比手工编码快的多。表2 6 是c o d e s m jt h 每次运行后自 动计算的结果。其前提是：美国最优秀程序员的生产率为6 0 行小时，公司支付 给员工的小时薪水6 0 美元小时。虽说结果有些夸张，但已经足以说明代码生成 工具所带来的经济价值。 表2 6c o d e s m i t h 运行结果报告 t a b l e2 _ 61 1 1 er e s u l tr e p o r to f c o d e s m i t h 工作方式规模生产率单价 时间 成本 ( 行)( 行川、时)( 美元，j 、时)( 小时)( 美元) 手上( 优秀)9 1 ，5 5 9 6 06 01 8 3 1 1 81 0 9 8 7 0 8 0 c o d e s m i t l l9 i 5 5 96 0 l 6 0 2 ) 数据访问层的测试工作大大的减少。这些工具本身已经提供对生成的数 据访问层的测试功能，减少了大量而繁重的测试工作。 3 ) 生成后的数据访问层有很好的可维护性和可扩展性。所有数据访问层生 成工具都是要首先进行数据库的连接，然后根据数据库的结构生成对应库表数据 访问逻辑。如果要对库表进行变动，只需要重新生成一次就可以完成任务，不需 要进行逻辑的手工修正，用户可以根据开发规范定制模板。这些都使得生成的数 据访问层具有很好的可维护性和可扩展性。 ( 2 ) 这些数据访问层生成工具的不足之处是： 1 ) 生成的数据访问层的数据访问类型是简单而有限的。仪是简单的对单表 的处理，如i n s e r t 、d e l e t e 、u p d a t e 操作。对于多表的处理和进行一些简单业 务逻辑的封装处理则不能支持。 2 ) 生成的数据访问层只能针对某一种语言，并不支持多种语言的转化生成， 使得生成的数据访问层并不具备很好的可移植性。 3 ) 生成的数据访问层代码具有较大的冗余性。由于数据访问逻辑是根据数 据库中的库表结构生成，并不是根据用户的具体数据访问需求生成的，必然会出 现冗余的访问逻辑出现，同时电不能解决用户的所有需求。 2 4业务逻辑层移植的研究现状 ( 1 ) j a v a 语言的出现已经使严格遵守其规范进行开发的w e b 系统平台无 关性得到了很好的解决”“。j a v a 引入了虚拟机的概念，这台虚拟的机器在任何 操作系统平台上都提能供给编译程序一个的共同的接口。编译程序只需要面向虚 拟机，生成虚拟机能够理解的代码，然后由解释器来将虚拟机代码转换为特定系 统的机器码执行。在j a v a 中，这种供虚拟机理解的代码叫做字节码( b y t e c o d e ) ， 它不面向任何特定的处理器，只面向虚拟机。每一种操作系统平台的解释器是不 同的，但是实现的虚拟机是相同的。j a v a 源程序经过编译器编译后变成字节码， 字节码由虚拟机解释执行，虚拟机将每一条要执行的字节码送给解释器，解释器 将其翻译成特定机器上的机器码，然后在特定的机器上运行。这样，j a v a 语言 就实现平台无关性。所以在w e b 系统移植开发中，j a v a 语言自然而然成为了首 选的语言。 ( 2 ) 中间件解决平台烙印逻辑。虽然j a v a 已经使w e b 系统的平台无关性解 决的很好。但这并不是说所有j a v a 程序能解决w e b 系统所有的跨操作系统平台 的特性，事实上，相当一部分的j a v a 程序是不能在别的操作系统上讵确运行的， 特别在很多情况下，必须使用非j a v a 编码。例如，我们有时要访问操作系统的 专用特性，与特殊的硬件设备打交道，或者要使用”对时间敏感”的代码段等等， 必须重复使用现有的非j a v a 接口。这些非j a v a 语言的业务逻辑全部是具有平台 烙印的逻辑，正是由于不同操作系统的a p i 有很大的不同，使得调用操作系统 a p i 的业务逻辑失去了w e b 系统本身提供的超平台特性。 目前，针对调用非j a v a 代码处理，不同的公司己经有了一些各自的解决方 案，如表2 7 所示： 袭2 7 调用非j “a 处理模块方案列表 t a b 】e2 - 71 飞e1 i s to fs 0 1 u t j o n sw h i c hc a l ln o n i a v ap r o c e s sm o d e l 公司方案 s u nj a v a 固有接口( j n i ) 网景j a v a 运行期接 ( j r i ) 微软j d i r e c t 、本源接口( r n i ) 、j a v “c o m 集成方案0 1 6 】 o m g通用对象请求代理结构( c o r b a ) i b mj a v a - c o m 桥( r j