（电气工程专业论文）intranet网络信息平台应用研究.pdf

a b s t r a c t t h et h e s i si sb a s e do nt h es t u d yo ft h ep r a c t i c a lp r o b l e m sa r i s i n gf r o mt h ec o n s t r u c t i o n o f aw a n d e v e l o p e db y t h ei n f o r m a t i o nc e n t e r o f s h e n g l i o i l f i e l d c l i e n t s e r v e r c o m p u t i n ga r c h i t e c t u r e ，h a s b e e n p r e v a i l i n g s i n c e1 9 8 0 s t h i s a r c h i t e c t u r es e p a r a t e su s e ri n t e r f a c ea n db u s i n e s sp r o c e s s i n gf r o md a t a b a s e 剖c c e s sa n d d a t a p r o c e s s i n g 。b r i n g st h eh e a v y d a t a b a s eo p e r a t i o nt ot h eb a c k g r o u n dd a t a b a s es e i v e r v i ar e m o t ed a t a b a s ea c c e s s ，a n do v e r c o m e st h e s h o r t c o m i n g so f c e n t r a l i z e dc o m p u t a t i o n b u t n o w a d a y s t h i sa r c h i t e c t u r ei sf a c i n g c h a l l e n g e s i nt h ea r e ao f p e r f o r m a n c ea n dc o s t i nt h i sp a p e r , t h el i m i t a t i o n so fc l i e n t s e v e ra r c i i t e c m r eb a s e da p p l i c a t i o ns y s t e mi s a n a l y z e da n dt h ew a y st h a tm a ye l e v a t et h el i m i t a t i o n sw e r es t u d i e d b ya d o p t i n g c o m p o n e n t - b a s e dd e s i g nm e t h o d , t h e3 - l a y e rs e r v i c em o d e lp u tf o r w a r db yf b r e i 伊 s c h o l a r si st r a n s f e r r e dt ot h ep l a t f o r mo fi n t r a n c t ，m a k i n gt h ei n t r a n e tt h ep h y s i c a l i m p l e m e n t a t i o no f t h e3 - 1 a y e rc sm o d e l t h em e t h o dt oa c a ：e s sb a c k g r o u n dd b m si st h ek e y p r o b l e mo fb u i l d i n gp r a c t i c a l a p p l i c a t i o ns y s t e mo ni n t r a n e tp l a t f o r m b yc o m p a r i s o no f3d i f f e r e n ta p p r o a c h e s ，t h e t h e s i s p u t sf o r w a r d 缸a p p r o a c hw i t hg o o dp e r f o r m a n c ea n dc o n v e r t si ti n t or e a l a p p l i c a t i o n k e y w o r d s ：i n t r a n e t ，3 一l a y e r s e r v i c e m o d e l ，c l i e n t s e r v e r a r c h i t e c t u r e ，m i s 合肥工业大学 本论文经答辩委员会全体委员审查，确定符合合肥工业大 学硕士学位论文质量要求。 答辩委员会签名： 主席( 工作单位、职称) ： 弓协晖 委员：癞潞 警置 ? 小扔 仓屺z - 暾誊h 哦 乜包巴；些芝亏 导师：既幸穗 叫侈。触：岳驰j ( 弓i 南擂 含孵2 埘髓 s 柏l 睁叼 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作 及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地方 外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为 获得合肥工业大学或其它教育机构的学位或证书而使用过的材料。与 我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的 说明并表示谢意。 学位论文作者签名勰毋v 签字日期：阳口j 年1 1 月fb v 学位论文版权使用授权书 本学位论文作者完全了解合肥工业大学有关保留、使用学位论文 的规定，有权保留并向国家有关部门或结构送交论文的复印件和磁盘， 允许论文被查阅和借阅。本人授权合肥工业大学可以将学位论文的全 部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描 等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书1 学位论文作者签名刁，坍f _导师签名 学位论文作者签名叱坍“、 导师签名 签字同期：渺j 年月1 日签字日期：州年，月r 学位论文作者毕业后去向 工作单位 通讯地址 电话 邮编 致谢 本论文是在合肥工大老师的指导下完成的，老师严谨的学风、工大优秀的校 风，使学生深受感动。该文是学生长期从事工作的认识及研究的结果本文概念 性地提出了三层“服务模型”。阐述了三层服务模型概念应用于i n t r a n e t 网络信息 平台的实际应用系统设计。学生谨愿在以后的工作学习中，继续得到老师与学校 的指导、激励、鞭策。 王政明 2 0 0 3 9 1 6 第一章绪论 1 1 问题的提出 八十年代兴起的两层客户机服务器( c l i e n t s e r v e r ) 结构应用，是伴随着网络 数据库和图形交互窗口应用及开发技术发展而逐渐形成的。它将一个复杂的网络 应用的用户交互界面和业务应用处理与数据库访问以及处理相分离，将大量数据 库的操作通过远程数据库访问的方式交给了后台数据库服务器去完成，提高了用 户交互反应的速度，降低客户端对c p u 处理能力的要求，应用开发简单且具有较 多的功能强大的开发工具。这样似乎对客户端的要求不高，但实际上，由于c s 结构将应用逻辑放到了客户端，很难达到所谓“瘦客户机”的要求，对客户端的 要求越来越高，安装的软件越来越庞大，机器配置越来越高；同时基于传统c s 结构的应用系统，界面不一致，应用彼此不兼容，用户需要很多的培训，潜在的 费用很高。目前传统的两层c l i e n t s e r v e r 结构存在如下缺陷： 1 由于应用处理留在c l i e n t 端，使得应用程序在处理复杂应用时，客户端应 用程序适应性差，限制了其对业务处理逻辑变化适应和扩展的能力，当访问数据 量增大和业务处理复杂时，客户端往往会成为瓶颈。 ， 2 随着应用业务逻辑的变化，必须修改客户端应用程序，并需在每一个工作 站上重新安装配置。 3 当采用远程数据库访问数据库时，客户端与后台数据库服务器数据交换频 繁，且数据量大，当大量用户访问时，易造成网络瓶颈。 4 当复杂应用需要同时访问多种异构服务器时，应用开发或安装配置工作量 会明显加大。 从客户机方面考虑，如何能够降低对客户端的配置要求，但其所能完成的应 用却可以不断得到升级和扩展，即达到所谓的“瘦客户机”的要求呢? 另一方面从 应用系统方面考虑，就是如何使应用系统能适应业务处理逻辑的变化、具备良好 的伸缩性且易使用、易维护呢? 进一步说，如何构筑这样的一个实际应用系统? 这些 是本文要著力研究解决的问题。 1 2 选题背景 本题目是针对胜利石油管理局信息中心的实际需要而提出的。 现代社会激烈的竞争促进了企业组织从原来的垂直结构向平面化方向发展， 这样能减少中间管理层，加快决策的过程，提高工作效率，以便更快地根据外界 情况和需要做出更快的反映和更有效地提供服务。许多组织正经历着这样一个过 程。在垂直结构部门中，每个部门需要和一个上级部门和若干个下级部门点对点 的联系，而在平面化的结构中，各部门除要和上、下级打交道外，还要和许多相 关的兄弟部门进行错综复杂的横向联系。作为信息处理基本工具的计算技术相应 地从以主机为中心的集中计算模式经历了随着微机的发展与普及而兴起的分散 计算模式，正开始步入以网络为中心的分布式计算模式。有人称这是计算机发展 的中的第三次浪潮，即进入网络时代。它正好适应了社会组织结构平面化重整的 需要。 胜利石油管理局作为全国特大型企业也已经建立了信息网络系统，目前，s l n e t 一期工程已经完成，促进了油田内部信息资源的共享，提高了企业整体管理水平， 为油田的勘探开发和生产提供了基础。s l n e t 是一个多层次的广域网。其中互连局 域网4 0 多个，网上路由器约6 0 台，入网节点超过6 0 0 0 个。胜利石油综合信息网 的建设，推动和促进了二级单位的局域网建设的步伐，9 6 年包括主要生产、科研 单位在内的2 8 个二级单位，已实施各自局域网建设。到9 7 年底已有4 0 家二级单 位的网络投入运行，油田内、外部已形成一个纵横交错的信息网络。 随着油田综合信息网的建成，应用面拓宽和应用深度加大，给综合信息网的 管理增加了难度。主要难点体现在以下几方面： 1 综合信息网规模大。计算机主机设备、网络设备等网上资源，种类多，数 量大，安装场点分散，难以实现集中管理。 2 由于各二级单位一般不设专职人员，网络管理人员的流动对各二级单位的 网络建设往往会产生不利影响。 3 各种基础数据查询不便，提供的辅助决策信息不及时，难以充分掌握现有 资源的使用状况，为今后资源配置提供科学、准确的决策依据。 4 广域网资源管理信息量大、管理繁琐、事务性强。缺乏管理的有效手段， 管理效率低。 5 各单位现有计算机资源数据不规范、不全面，难以动态更新和维护，不能 准确及时体现各单位计算机应用状况和深入细致的全面管理。 6 难以对网络运行维护过程中出现的各种情况做出全面、准确的统计分析， 为今后网络设备的扩充升级提供依据。 针对目前情况开发一套实用的系统以实现广域网资源管理的标准化、现代化 这在眉睫。在设计新的应用系统时，要着力克服以前c s 应用系统的诸多限制， 使应用系统的设计能为解决同类型问题提供新的思路。 1 3 选题目的和意义 本课题主要目的就是针对基于国际上广泛流行的t c p i p 协议构筑的企业内 部互联网- - i n t r a f i e t ，从系统分析和设计的角度对i n t r a n e t 信息管理和交换平台进 行研究，重点研究如何将i n t e m e t 技术和数据库技术楣结合，建设对业务处理逻辑 2 变化适应能力强，系统具备良好的可伸缩性，且易维护的企业管理信息系统。并 以胜利油田广域网管理信息系统的建设为契机，研究和开发实际的应用系统。 当今世界经济的发展已日趋国际化，对信息的有效获取和利用日益重要，经 济实力的竞争首先表现为信息实力的竞争。我国企业的信息化，经过了单项技术 运用，如为节能降耗进行的对老设备的改造，在生产流程中采用智能仪表和计算 机以提高质量、增加产量，对财务和物资进行计算机管理，加工模具和简单产品 的设计采用c a d 技术等，向综合化、系统应用化发展的过程。本课题对企业信息 化建设中的应用技术进行研究和尝试，为加快企业信息化的建设将起到积极的作 用。 第二章系统设计的理论分析 2 1 三层客户机服务器模型的确立 2 1 1 客户机服务器计算模式 客户机服务器计算模式是从最早的集中式计算模式基础上发展起来的。在集 中式计算模式中，所有的应用程序和数据均存储在大型机上，用户利用“哑”终 端与大型主机连接。所有的应用都是基于具有较为高级的计算功能的大型主机。 集中式计算模式的缺点是用户和机器之间缺乏交互，终端只是主机的一个程 序窗口。系统的扩充性受主机计算能力的限制，当希望增加一些较为高级的图形 用户界面时，网络带宽将成为一个严重的瓶颈。为解决这些问题，客户机服务 器计算模式产生了。 客户机服务器计算模式是伴随着个人电脑、工作站性能的飞速提高，网络 技术的迅速发展而逐步完善的。它将一个复杂的网络应用的用户交互界面及业务 应用处理与数据库访问及处理相分离开来，将大量数据库的操作通过远程数据库 访问的方式交给了后台数据库服务器去完成，从而提高了用户交互反应的速度， 降低了客户端对c p u 处理能力的要求，其应用开发简单且具有较多的功能强的开 发工具。 相对于集中式的计算模式，这种计算模式克服了集中式模式的不足。客户机 服务器模式把一个全部由主机完成的计算任务分解成了两部分：主机接收客户 机发出的对数据库进行操作的命令，完成有关数据库的操作，将操作结果返回给 客户机；客户机负责同用户进行界面交互，完成业务应用处理。通过对计算任务 的分解，达到了主机和客户机整体性能的提高，灵活性增强。 2 1 2 三层c s 计算模式的确立 传统的客户机服务器计算模式在性能提高的同时，也不可避免地会遇到本 文开始所提到的问题：应用程序对业务处理逻辑的变化适应能力差；将应用程序 图形界面、处理程序与数据源绑在一起，会消耗客户机的主要系统资源。这对客 户机来说是个沉重的负担，会导致系统性能的降低，为了系统整体性能的提高， 客户端需不断对系统的软硬件资源升级。通过对集中式计算模式到客户机服务 器计算模式变迁的过程，自然想到：既然客户机的计算能力不堪重负，可以把客 户机的计算任务进一步分解，将一部分计算任务由其他主机来完成。这一思想正 是本文解决提出的问题的途径。 两层客户机服务器计算模式的计算任务包括：提供一个复杂网络应用的用 户交互界面和业务应用处理。由于业务应用处理也集中在客户端，当应用系统的 业务处理逻辑发生变化时，无论这个变化多小，对多客户机的应用系统，都将不 4 得不重新在每一台客户机上，加以修改或重新安装新的应用系统。问题的解决关 键在于将客户端的计算任务简化，客户端只提供复杂网络应用的交互界面；应用 系统的业务应用处理不再由客户端完成。应用系统的业务应用处理可以由其他主 机去处理。 上述思想对一个c s 的计算任务加以分解，实际上就是对应用系统的应用程 序进行分割，可将代码划分为不同的逻辑组件。“服务模型”( s e r v i c em o d e l ) 是划 分不同逻辑组件的一种逻辑方式。服务模型基于这样一个概念：每个组件都是一 系列的服务的集合，这些服务由组件提供给其他对象。服务模型将客户机服务 器系统中各种各样的组件划分为三“层”服务，它们共同组成一个应用程序，通 过三层服务模型的划分，产生了基于服务模型的三层客户机服务器计算模式。 这三层服务包括： 1 用户服务：提供信息和功能、浏览定位、保证用户界面的一致性和完整性。 用户服务提供了一个可视化的接口，用来表示信息和收集数据。它们确保业务服 务能够提供所需的业参- 处理能力，并且使甩户与应用程序紧密结合起来，以处理 某项业务。用户服务通常表现为用户界面，而且通常位于最终用户工作站上的一 个可执行程序中，当然有时候几个服务可能位于几个分离的组件之中。 2 业务服务：共享的业务处理逻辑，从数据中生成业务信息，保证业务的一 致性。业务服务是联系用户服务和数据服务的“桥梁”，它们响应用户f 或其他的业 务服务) 发来的请求，执行某种业务任务。为了完成这些任务，它们对相应的数据 运用形式化的过程和业务规则。如果所需的数据驻留在数据库服务器上，通过它 们可以获得所需的数据服务，或运用所需要的业务规则。用户不能直接与数据库 打交道。 业务任务是由应用程序的需求定义的一种操作，例如添加一个定货单或打印 机列表。业务规则是控制业务工作流程的策略。例如，在生成客户发票的时候， 需要在库存价值的基础上进行一定幅度的上调，这就是业务规则。与任务相比， 业务规则更容易发生改变。所以在实现时最好将业务规则封装在单独的组件中， 与应用程序的逻辑分隔开。例如，某个应用程序需要“获得销售价格”这项服务 可以被封装在中央网络服务器上的一个组件中，应用程序可以访问它。如果计算 过程发生了改变，仅需在个地方进行修改就可以了，应用程序本身是不需要修 改的。一旦业务改变了，所有的“获得销售价格”的请求都将使用己修改的业务 服务得到新的计算结果。 某些中间层服务严格讲不能被视为业务服务。例如，登录屏幕用来提示用户 输入密码以获得网络访问权，它实际上是与中央数据库服务器连接的自动组件。 作为应用程序支持服务的图形处理、纯粹的数字计算以及安全服务等，通常既不 属于用户服务和数掘服务，也不是严格的业务服务。 3 数据服务：数据的定义，永久数据的存储和检索。数据一致性的保证。数 据服务包括数据的定义、维护、访问和更新，以及管理并口l 应业务服务的数据请 求。与其他种类的服务相比，这种类型的服务已经研究了很长时间，所以好理解 得多。它们的物理实现可以在某种数据库管理系统上，也可以是一个异种数据库 的集合，这些数据库可能驻留在多种平台上，运行在服务器和大型计算机上。 将数据服务与应用程序的其他组件分离开，在维护、修改甚至重构数据结构 及访问机制时，可以丝毫不影响业务服务和用户服务。 这些“层”并不一定与网络上的具体物理位置相对应，它们只是概念上的层， 借助这些概念可以开发出适应性强、基于组件的应用程序。使用这种方法设计应 用程序，开发人员在网络上部署进程及数据时可以有相当大的灵活性，从而有利 于实现最佳的性能、更好的安全性以及更方便的维护。 除了定义应用程序中每一种服务的功能之外，上面的分类还为进行结构化开 发的开发小组和开发过程提供了一种组织线索。各种服务通过网络联系在一起并 且互相合作，从而支持一个或多个业务进程。在这种模型下，应用程序是用户、 业务以及满足一定需求的数据服务集合体。服务总是被设计成通用的，并且遵守 公共的接口标准，所以它们可以被重用，并能被多个应用程序所共享。 服务模型有助于如何将应用程序逻辑划分给物理组件，但一般不能用它安排 软件组件实际的物理配置方案。它可以决定应将哪些应用程序逻辑地集中到一个 组件里配置，以及将组件放置于哪一个层。 服务是逻辑意义上的而非物理意义上的。服务模型描述了应用程序的概念 结构，它强调的是逻辑意义而不是物理意义、它说明如何设计应用程序，而不是 如何具体部署。服务模型允许服务在物理上驻留在任何地方。 2 2 三层c s 模型的网络实现 三层服务模型从逻辑意义上对应用程序进行了划分，但在具体的物理实现上还 需要具体的部署。随着i n t e m e t 技术不断发展，尤其是随着w e b ( h t m l 、h t f p ) 幽2 一i 浏览器? 服务器结构幽 技术的发展，人们已不再满足于简单的信息发布，丌始将w e b 与数据库技术相结 合，形成了基于w e b 的计算模型，并将这种计算模型应用到企业网i n t r a n e t 中，最 终使i n t r a n e t 成为三层客户机服务器模型实际的物理实现。 i m r a n e t 实际上是一种三层结构的客户机服务器模式，i n t r a n e t 把传统的客户 机服务器模式中的服务器分解成一个w e b 服务器和一个或多个数据库服务器。 如图2 一l 所示： 第一层，浏览器是表示层，主要完成用户接口的功能，即：在客户端，向由 u r l ( u n i f o r m r e s o u r c el o c a t o r ，统一资源定位符) 所指定的w e b 服务器，提出服务 申请，w e b 服务器用h t t p 协议把所需的文件资料传送给用户，客户端只是接收文 件资料，并显示在w w w 浏览器上。 第二层，具有c g i 或o d b c 接口的w c b 服务器是功能层，主要利用服务器完 成客户的应用功能，即；w e b 服务器接受客户申请，首先需要执行c g i 或其他服 务程序，与数据库连接，进行申请处理，而后将处理结果返回w e b 服务器，再由 w e b 服务器传至客户端。 第三层，数据库服务器是数据层。数据库服务器应客户请求独立地进行各种 处理。由于处理完全交给了数据层完成，功能层发生变化不会影响到数据层的改 变，因此，i n t r a n e t 的三层结构在软硬件环境发生变化时的适应能力比c s 模式 的两层结构更强，即具有更强的可伸缩性。 以w e b 计算模型为核心的i n t r a n e t 有下列优点： 1 资料格式统一且多媒体化。企业公司内部的文件、资料都以h t m l 格式展 现，资料格式统一，而且包含文字、图形、声音等。 2 文件共享，信息提供及更新快速。由于h t m l 简单而且容易使用，故企业 内各单位通过浏览器存取，文件容易共享，且信息的促供及更新速度可加快。 3 简单易用，教育训练负担轻。由于浏览器容易使用，所以信息部门对于系 统建置后所负担的教育训练等责任减轻许多。 4 以信息发布为主要功能的系统，建立容易，成本低。 5 跨平台，容易整合。使用i n t e m e t 相关技术，其优势是标准化，容易集成 各信息系统，对于l a n a v a n 的结合障碍低。 i n t r a n e t 的迅速崛起除技术成熟、简单易用等条件外，最重要的一点是浏览器 己成为通用客户程序( u n i v e r s a lc l i e n t ) 的事实，以往的信息系统，不论是大、中型 专属系统，或是个人电脑局域网络、工作站等，不同的硬件及不同的系统，沟通 并不容易，现在由于w w w 的盛行，浏览器己成为跨平台沟通的基础，是企业对 内、外信息存取的必须工具，对企业组织内部集成、与上下游合作伙伴合作，进 而加强客户联络服务有很大的帮助。 第三章应用系统数据库访问方式的选择 i n t r a n e t 网络信息平台为三层服务模型提供了一种物理实现。但是w e b 技术并 没有直接提供应用系统对后端数据库的访问，因此必须解决应用系统对后端数据 库的访问，这是构造i n t r a n e t 上应用系统的关键性问题。 一个应用系统，无论在理论上是怎样的理想，实际需求分析是如何周到细致， 但一旦涉及到具体实现，必然要考虑到具体实施的方案，并由此方案而产生的应 用系统性能、功能和实际需求是否完全相符。如果具体实施的方案在实践中已经 证明是可行的，设计者考虑的主要问题是在现有方案下应用系统设计的优化，系 统性能、功能的完善。如果具体实施的方案不成熟，没有充分的应用经验可循， 设计者考虑的首要问题是在可能实施的方案中，确定一个能满足实际需求，且在 性能和功能上比其他方案更完善的方案。然后才考虑在该方案下，应用系统的设 计、优化等具体问题，在这种情况下，方案的选择对于整个系统的开发是非常重 要的，采用好的方案，应用系统性能、功能大大提高，开发比较有信心，可咀少 走弯路，少浪费人力、物力，最后为相同特点的应用系统开发提供可以借鉴的经 验。由于要进行方案的选择、对比，工作量大大增加。本课题所涉及的i n t r a n e t 应 用研究还是一个较新的领域，需要研究者在自己的前期工作中，掌握各种方案在 性能、功能上同实际需求的差距，以及对各方案的优缺点进行比较，最终确定切 实可行的方案并进行具体的实施和开发。 在应用系统具体开发过程中，通过文献查阅和调研的情况，本课题确定了三 种主要的应用系统对后端数据库访问方案，分别与实际情况进行简单结合，进行 试开发实验，根据实验结果，确定了一个较完善的方案，并加以细化、最后完成 应用系统。下面对这三种方案进行说明。 3 1 应用b o r i a n d 的i n t r a b u ii d e r 的方案1 把b o f l a n d 公司的i n t r a b u i l d e r 这一辅助开发工具作为首选的方案，是借助于 两层c s 系统开发中的实践，好的开发工具可以使系统的开发大大加快，例如 p b 、v b 这一类高性能的可视化的开发工具。在三层c s 应用系统设计中，首先 使用i n t r a b u i l d e r 作为开发工具，因为i n t r a b u i l d e r 是当时仅有的可以在三层应用系 统开发中，可以被使用的可视化开发工具，支持可视化的继承和控件的重用；支 持面向对象的程序设计；支持对控件的方法进行用户的自定义和扩展；自动的专 家系统，可以完成常用的任务，如：建立交互式表单( f o r m ) ，定制报表( r e p o r t ) 等， 能够大大提高开发的效率是该工具的特色。浚方案实现的原理图和过程如下： i n t r a b u i l d e r 图3 - 1i n t r a b u i l d e r 的实现原理 1 用户单击浏览器上的u r l 后，将对+ f r m 页面和对该页面进行解释执行的 应用程序名i n t r a s r v i s v ，一起作为请求提交给w e b 服务器。 2 w 曲服务器对该请求进行解读后，调用该应用程序对f r m 页面进行处理， 首先执行该页面中需在服务器端运行的j a v a s c r i p t 内容，具体执行是在系统进程内 产生一个代理管理( b r o k e r ) ，由它调度具体在哪一个代理( a g e i l t ) 上完成，a g e n t 主要具体完成与后端数据库的交互。 3 w e b 服务器将a g e n t 完成的结果，同用户界面的控件捆绑一起发送给用户， 用户通过界面中的控件属性值，可以从数据库中得到数据的内容，进一步，用户 还可以通过使用界面中代表对数据库进行不同操作的按钮，触发新的请求，服务 器进行下一步的处理。 在具体实验过程中，做了以下工作： 1 配置b o f l a n d 数据库引擎使其能够远程访问o r a c l e 数据库。首先安装基于 w i n d o w sn t 的s o ln e t v 3 2 ，使安装w e b 服务器的n t 主机，做为后端o r a c l e 数据库的客户与o r a c l e 数据库进行通信，在s q l n e t v 3 2 中配置供本地应用程 序访问的o r a c l e 数据源的名称，主机口地址，使用的通信协议等。利用s q ln e t v 3 2 提供的测试工具，测试n t 服务器与0 r s c l e 数据库是否连通，连通后，在 b o r l a n d 数据库引擎配置程序中配置有关o r a c l e 数据库驱动程序的内容。具体如表 3 一i ： 9 i v e r s i o n3 0 t y p e s e r v e r d l l s q l d o r a d l l d 1 1 3 2 s q l o r a 3 2 d l l w i n d o wi n i tc ：o r a n t 】3 i n x o r a 7 2 d l l s c r v e rn a l n e o r a 7 2 u s e fn a m ey j k ，y j k n e tp r o t o c o lt c p ，口 o p e n m o d e r e a d ，r j t e l a n g d r i v e r p a r a d o xc h i n a9 3 6 表3 - 1 b d e 中有关o r a c l e 驱动程序的配置 2 利用i n l r a b u i l d e r 提供的自动专家系统，设计通过w e b 远程数据查询和更新 为主要内容应用系统。首先选定o r a c l e 数据库中有关的表文件，以及需对表中进 行操作的具体字段，然后通过专家系统自动将数据同应用界面中的控件绑定在一 起，增加以记录( r o w ) 为操作对象的方法，如增加，删除，更新，针对某一字段的 条件查询，记录的浏览，应该说，包含了所有对单条记录进行操作的所有功能。 但它将数据同控件的绑定，只是将数据同文本框控件联系，用户需对每一字段都 要详细输入，显得很烦琐。在应用中，有些字段可以提供缺省项，以便用户通过 简单的选择挟速输入。具体做了如下的尝试：将原文本框控件，改为下拉列表框 控件，对新控件可以赋多个选择项，供用户使用。重写了新控件的o ns e r v e r l o a d 方法，及对记录对象进行操作的方法。编程语言采用服务器端j a v a s c r i p t 脚本语言。 + 给下拉列表框赋单位名称，单位名称来自数据库中单位代码表，q u e r y l 与游标一样，代表一个记录集“s e l e c t + f r o md w d m b ”对象，此处定义了一个单位 名称数组，先将已录集中所有的数据赋给数组中的每一个元素，再将数组作为一 个整体赋给下拉列表框控件s e l e c t l 的o p t i o n s 属性。 f u n c t i o ns e l e c t io n s e r v e r l o a d 0 f f o r m d w m c a r r a y = n e wa r r a y ( ) ； f o r m q u e r y l r o w s e t f i r s t ( ) ； w h i l e ( ! f o r m q u e r y l r o w s e t e n d o f s e t ) f f o r m ，d w m c a r r a y ，a d d ( f o r m q u e r y l r o w s e t f i e l d s ”d w m c ” v a l u e ) ； f o r m q u e r y l r o w s e t n e x t ( ) ； ) f o r m ，d w m c a r r a ys o n ( ) ； o f o r m s e l e c t l o p t i o n s a r r a yf o r m d w m c a r r a y ； b u t t o n l 对象将录入界面定位到上网节点表中的第一条记录由于上网节点 表中存放的是单位代码、设备代码、楼房代码，在给用户显示时，必须将相应的 代码转换成有实际意义的名称。下面就是完成这三个代码的转换，改写了b u t t o n l 原有的o n s e r v e r c l i c k 方法，原方法仅有最后一行 f u n c t i o nb u t t o n l _ o n s e r v e r c l i c k 0 f o r m q u e r y l r o w s e t f i r s t ( ) ； w h i l e ( ! f o r m q u e r y l 1 - o w s e t e n d o f s e t ) i f ( f o r m q u e r y l r o w s e t f i e l d s ”d w d m ”】v a l u e = f o r m t e x t l v a l u e ) f o r m s e l e c f l v a l u e = f o r m q u e r y l r o w s e t f i e l d s “d w m c ” v a l u e ； f o r m q u e r y l t o w s e t n e x t ( ) ； ) f o r m q u e r y 2 r o w s e t f i r s t ( ) ； w h i l e ( ! f o r m q u e r y 2 r o w s e t c n d o f s e t ) i f ( f o r m q u e r y 2 r o w s e t f i e l d s ”s b d m ” v a l u e - - f o r m t e x t 3 v a l u e ) f o r m s e l e c t 2 v a l u e = f o r m q u e r y 2 r o w s e t f i e l d s ”s b m c ”】v a l u e ； f o r m q u e r y 2 r o w s c t n e x t ( ) ； ) f o r m q u e r y 3 r o w s e t f t r s t o ； w h i l e ( ! f o r m q u e r y 3 r o w s e t e n d o r s e r ) ( i f ( f o r m q u e r y 3 r o w s e t f i e l d s ”l f d r n 】v a l u e - - f o r m t e x t 2 0 v a l a c ) f o r m s e l e c 3 v a l u e = f o r m q u e r y 3 r o w s e t f i e l d s ”l i l a c ” v a l u e ； f o r m q u e r y 3 r o w s e t n e x t ( ) ； f o r m s e l e c t 4 v a l u e = f o r m t e x t l 9 v a l u e ； f o r m s e l e c t 5 v a l u e = f o i t s t c x t 2 2 v a l u e ； f o r m s e l e c t 6 v a l u e = f o i t n t e x t 9 v a l u e ； f o r m y j k _ s w j d b l r o w s e t f w s t 0 ； 3 在使用i n t r a b u i l d e r 的过程中，发现对o r a c l e 数据库中已有的汉字数据不能 正常显示，存入的新数据，在调出显示时也不正确，在检查了b d e 配置程序中关 于对中文支持部分的配置，发现无误后，使用s q lp l u s 调用o r a c l e 数掘库中已 有的内容时，也显示不正确，由此可以判断是s q l n e t 中有关民族语言支持的字 符集部分的配景，与o r a c l e 数掘库使用的字符集不相符，需要更改s q ln e t 在 n t 上的配置文件，一般须更改o r a c l e i n i 文件中的n l sl a n g 参数，但在n t 上找不到该文件。后来查阅有关w i n 9 5 n t 资料，发现应用程序的配置文件集中 存放在r e g e d i t 程序中，经过搜索，找到有关n l sl a n g 参数部分，发现确实有 问题，将原参数更改后，系统显示汉字正常。 在使用i n t r a b u i l d e r 开发应用系统过程中，发现该方案存在以下问题； 1 最明显的问题是系统在用户端浏览器上进行测试时，对o r a c l e 数据库访问 的速度非常慢，完成一次简单的数据交互，须耗时将近两分钟。考虑其原因一是 b o r l a n d 的i n t r a b u i l d e r 服务器处理能力比较低，不太适合多用户的并发访问，二是 o r a c l e 数据库在大型关系数据库中性能也并不是最优的。两个不同厂商的产品兼容 2 系统的设计与浏览器的显示不完全兼容。在i n t r a b u i l d e r 中设计的功能页面， 在任何一个浏览器中无法原样再现，需要重新调整，大大降低了可视化开发工县 的所见即所得的特性，降低了开发的效率。 3 系统设计不够灵活。很难满足用户多角度对数据的查调访问，提供查询的 专家开发系统比较呆板。查询速度慢。难以甄别不同用户而将不同的数据与控件 动态绑定。 由于存在以上问题，从系统的整体性能考虑，这不是一个理想的方案。 3 2 应用o r a c i e 的w e bs e r v e r 的方案2 鉴于方案1 中的缺点本课题转而考虑系统兼容性好的方案，方案2 是使用能 访问o r a c l e 数据库厂商自己产品的专用w e b 服务器0 r a c l e 的w e bs e r v e r 。 o r a c l e 的w e bs e r v e r 使用的是w r b ( w e br e q u e s tb r o k e r ，w r b 请求代理) 技术。 w r b 是个高性能、多线索和多进程的h t t p 服务器。o r a c l ew e b 服务器直接通 过w r b 提供动态的h t m l 页面。通过将客户机的请求直接分布到o r a c l e 数据库 服务器而不是编写烦琐的c g i 程序( 一种在i n t e r n e t 上动态内容发布的技术) ，w r b 能够获得很高的性能。w r b 将所有的服务器扩展都作为一个单独的进程执行。 o r a c l ew e bs e r v e r 2 0 基本原理示意如图3 2 ： 1 在w e b 浏览器上，用户单击包含后台应用的u r l ( 统一资源定位) 。 2 w e b 侦听器f w e l ) l i s t e n e r ) 接收用户请求，分析用户的请求，如果只是一般 静态页面( 请求的文件是h t m ) 请求，则调用简单转接器( s i m p l yd i s p a t c h e r ) ，进一 步通过服务器的文件系统将所需页面返回给用户。如果是需调用w e b 请求代理 ( w p , b ) 的统一资源定位符( 一般是在o w a 目录下的文件) ，它将请求的执行送给 w e b 请求代理转接器( w r bd i s p a t c h e r ) 处理。 3 转接器负责和叫做w r b 执行引擎( w r b x s - - w r be x e c u t a b l ee n g i n e s ) 的进 程池通讯。转接器会找一个空闲的、配置成运行所需要的w r b 服务执行引擎，同 时把执行权交给该引擎。结果是侦听器能接收并确认请求的统资源定位有效 而每一个请求被传递到在后台执行陔请求的进程。+ 4 每一个w r b 执行引擎使用w r t 3 应用编程接口和每一个w 西请求代理组件 ( w r bc a r t r i d g e ) 接口。w e b 请求代理组件可以是p l s q l 代理组件( a g e n t c a r t r i d g e ) 、j a v a 解释器、l i v e h t m l 解释器及第三方厂商开发的扩展组件。 p l s q l 代理( p l s q la g e n t ) 该组件执行存储在数据库中p l s q l 命令。它比j a v a 组件更优化了对数据库 的访问，但它不具有j a v a 的全部功能。 馐) j a v a 解释器 j a v a 解释器这个组件允许在服务器上执行j a v a 来产生动态的w e b 页面。使 用它可以从j a v a 中执行p l s q l 命令。 l i v e h t m l 解释器 该组件是o r a c l e 在工业标准服务器端内置( s s 卜一s e n ，e rs i d e i n c l u d e s ) 功 能的实施和扩展。l i v e h t m l 可以将用户操作系统能运行的任何程序的输出结果包 含在用户的w e b 页面之中。 5 利用p l s q l 代理组件执行存储在数据库中的p l s q l 包，将输出的数 据库操作结果返回给测览器用户。 图3 - 2o r a c l ew e bs e r v e r 原理 基于o r a c l e w e b s e r v e r 的应用程序的设计是围绕着不同的数据库访问组件展丌 的。 在实际应用中，本课题尝试开发了基于p l s q l 组件的应用。主要有： 1 配置数据库连接描述文件( d a t a b a s e c o n n e c t i o nd e s c r i p t o r ) 。一个统一资源 定位( u r l ) 在请求p l s q l 代理时必须在其中指明相应的和数据库连接的描述文 件，这个文件是一个由w e bs e v e r 维护的系统文件，该文件提供建立数据库连接的 用户名，口令，数据库名，还有其他一些访问数据库所需要的信息。该描述文件 决定了p l s q l 代理在执行该请求时，能访问哪一个数据库以及能访问数据库中 的哪一部分。在统一资源定位中给出该文件名，p l s q l 代理就按该文件提供的 内容进行配置。例如，配置的d c d 文件名是“x x g l