（计算机应用技术专业论文）基于mvc结构的管理信息系统的研发.pdf

摘要 m v c ( 模型视图一控制器) 结构由三部分组成：模型、视图和控制器。模型代表 数据层：视图代表信息的表示层；控制器接受用户提出的请求，并决定由哪个业务逻 辑负责处理。基于m v c 结构开发的系统的优点是具有可靠的稳定性、更高的可重用型、 适应性、更低的丌发费用、更快的部署和更好的可维护性。 s t r u t s 是基于m v c 设计模式的服务器方的j a v a 实施工具，为w e b 开发提供了一 种玎放的源代码架构，利用这种架构能很容易得将表示层和数据层分离。 i b a t i s 对数据层进行了更高一层的封装，在j a v a 应用程序的开发中利用i b a t i s 有助于我们对数据层的设计和实现。在i b a t is 中有两个主要的组件：s q lm a p s 和 d a o ( 数据库访问对象) 。 在本论文中，讨论了为天津某信托公司设计的管理信息系统，该系统是基于m v ( ： 发汁模式的，在5 2 e e 平台上丌发的w e b 应用系统，充分利用了以上讨论的两项新技 术，并且开发了自己的标签库，经简单配置，可移植到其它系统。实现了系统较高稳 定性，较强适应性，和更好的可移植性。 关键词：模型一视图控制器，s t r u t s ，i b a t i s ，s o lm a p s ，数据访问对象 长羔t r 考、导师同殛 勿垒文公布 a b s t r a c t m v c d e s i g np a t t e r n ，w h i c hc o n s i s t so ft h r e ep a r t so fc o m p o n e n t s ：am o d e l ，a v i e w ，a n dac o n t r o l l e r t h em o d e lr e p r e s e n t st h ed a t ao b j e c t s ；t h ev i e ws e r v e sa s t h es c r e e nr e p r e s e n t a t i o no ft h em o d e l ；t h ec o n t r o l l e rd e f i n e st h ew a yt h eu s e r i n t e r f a c er e a c t st ot h eu s e r si n p u t ；t h ec o n t r o l l e rc o m p o n e n ti st h eo b j e c tt h a t m a n i p u l a t e st h em o d e l s o m eo ft h em a j o rb e n e f i t so fu s i n gm v ci n c l u d e ：r e l i a b i l i t y h i g hr e u s e ，a d a p t a b i l i t y ，v e r yl o wd e v e l o p m e n tc o s t s ，r a p i dd e p l o y m e n t ，a n d m a i n t a i n a b i l i t y ， t h es t r u t sp r o j e c ti sas e r v e r s i d ej a v ai m p l e m e n t a t i o no fm v cd e s i g np a t t e r n ， w h i c hi s d e s i g n e dw i t ht h ei n t e n t i o no fp r o v i d i n ga n o p e ns o u r c ef r a m e w o r kf o r c r e a t i n gw e ba p p l i c a t i o n st h a te a s i l ys e p a r a t et h ep r e s e n t a t i o nl a y e ra n da l l o wi t t ob ea b s t r a c t e df r o md a t al a y e r i b a t i si st h ed a t a b a s el a y e r t h i sf r a m e w o r kh e l p su sd e s i g na n di m p l e m e n t b e t t e rp e r s i s t e n c el a y e r sf o rj a v aa p p l i c a t i o n t h e r ea r et w om a i nc o m p o n e n t st o t h ef r a m e w o r k ，w h i c ha r es q lm a p sa n dd a t aa c c e s so b j e c t s i nt h ep a p e r ，an e wm a n a g e m e n ti n f o r m a t i o ns y s t e mb a s e do nt h es t r u c t u r eo f m v ci sp u tf o r w a r dt od e v e l o pt h em a n a g e m e n ti n f o r m a t i o ns y s t e md e s i g n e df o ra f i n a n c i a lc o m p a n yo ft i a n j i n ，w h i c ht a k e sf u l lu s eo ft h es t r u t sa n di b a t i s ，h a sm o r e r e l i a b i l i t y a d a p t a b i l i t y ，a n dv e r yl o wd e v e l o p m e n tc o s t s k e y w o r d s ：m v c ，s t r u t s i b a t i s s q lm a p s ，d a o 独创性声明 y6 2 7 3 7 2 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作和取得的研究 成果，除了文中特别加以标注和致谫 之处外，论文中不包含其他人已经发表或撰写过 的研究成果，也不包含为获得丞洼王些盔堂或其他教育机构的学位或证书而使用过 的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说 明并表示了谢意。 学位论文作者签名：7 霞毖红i 签字目期：d 牛年月日 学位论文版权使用授权书 本学位论文作者完全了解丞洼工些太堂有关保留、使用学位论文的规定。特 授权丞洼王些盍堂可以将学位论文的全部或部分内容编入有关数据库进行检索， 并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学校向国家 有关部门或机构送交论文的复印件和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 学位论文作者签名： 动冼钮 导师签名 签字日期： 蚪年月，日签字日期：少，驴年厂月厂日 定， 处矿 第章绪论 1 1 计算机应用结构发展概述 第一章绪论 计算机的应用结构经历了集中式结构、文件服务器结构、客户机服务器m 络结 构、分布式客户机服务器结构和w e b 网络结构等几个发展阶段。 集中式计算模式分为两个阶段，第一阶段是基于主机或大型机的计算，第二阶段 是基于p c l a n 的计算。在纂于主机或大型机的环境中，几乎所有的处理都发生在中 央主机上，应用程序和数据集巾并唯一存在于主机中，应用程序丌发和维护电都集中 化，以提供重要的控制和安全措施，系统管理也都集巾处理。进入8 0 年代，传统的大 中型计算机系统受到以p c 机为主体的微机系统的挑战，一方面由于主机系统固有的 缺陷无法在信息急剧增长的企业范围内提供一个灵活的解决方案，另一方面，微处理 器的高速发展使得微机4 i 再是简单的个人系统，基于文件服务器的l a n 能很好的处理 绝大多数办公自动化任务，如文字处理、文件存储、共亨打印设备和中央o a 应用程 序维护等。 在文t b j j l i 务器应用模式中，应用程序是在客户端工作站卜运行的，文件服务器只 提供了资源的集中管理和访问途径。只要求客户端的计算机必须有足够的能力来执 j 需要的任何程序，以便能完成必要的任务。l 比时，网络上传送大量的文件，形成嘲络 访问的瓶颈。 9 0 年代，分布式系统的c s 体系结构得到了异乎寻常的发展，它能集中大型主 机系统的文件服务器系统的优j _ ，并且具有更好的系统开放性和易扩展性。c s 系统 的特点是客户机只执行当前端应用，而将数据库的操作交i - i 务器完成；服务器f j , j i j r 务列客户机是透明的，即客户机可以完全不知道服务器的硬件，软件配置，为达到分 枷式事务处理的分布式计算提供了良好的机制：c s 结构具有：可扩充性，客户机端 及其功能的添加和更新不会刈整个系统产生影响；分布式特性，客户机端和服务器端 执行= = f i 同性质的任务，从而可分和于不i 刊的计算机：提高事务处理能力，任务的分解 可充分利q 各种汁算机资源，减少了各种事务处理列服务器性能的要求，减轻了服务 器的负担，提高了事务处理能力。 分确j 式计算应用模式下，由于客户端的沉重负担，造成了大量维护费用的升级。 从而引进了一种改进的客户机服务器配置方案，即三层客户机服务器方案。加入- f 1 问层，而向商业规则或企业舰则，通过这种划分可以将程序代码划分成不同的逻辑组 件。 在w e b 剐络应用模式下，随着w w w 服务缸：全球的推广，其数据源的数量电在迅速 第一章绪论 增长。在传统的w w w 服务中，文本和其它信息都是以文件的形式进行存储和管理的， 随着应用领域的不断拓展，静态的w e b 页面不能满足对信息服务的动态性、实时性和 交互性的要求。在b s ( b r o w s e r s e r v e r ) 结构或b s d 结构中，实现对w e b 数据库 访问的最常用的方法是在w e b 服务器端提供中间件来连接w e b 服务器和数据库服务 器。在b s 结构巾，企业信息网络以w e b 为中心，采用t c i ，【p 技术，以l i t t p 为传输 协议，客户端通过b r o w s e r 访问w e b 以及与w e b 相连的后台d a t a b a s e 。在b s 结构 中客户端无需专用的软件，减轻了系统维护和升级的成奉与工作量。由于b s 模式采 用了标准的t c p i p 技术，h 1 、t p 协议，因而可以与企业现有网络很好的结合，同时可 直接与i n t e r n e t 介入，具有良好的扩展性。 1 2 w e b 数据库访问技术剖析 随着w w w 技术的迅速发展，i n t e r n el 正以惊人的速度改变着人们的生活、学习 和工作方式。i n t e r n e t 已经成为一个全球性的巨人的信息库，连接着数以万汁的运 行于各种平台下的数据库。为了实现信息的实用性、动态性、交互性，进行网上数据 的高效存耿，对数据库的操作就成为所有于w e b 有关的技术中最为关键的领域。 w e b 数据库技术目前己广泛应用于in t e r n e t i n t r a n c t 开发中，w e b 技术与数据 库管理系统( d b m s ) 相互融合领域的研究已成为热点，数据库厂家和w e b 公司也纷纷 推出各自的产品和巾间件支持w e b 技术和d b m s 的融合，将两者取长补短，发挥各自 的优势，使用户可以在w e b 浏览器上方便的检索数掘库的内容。其关键技术是w e b 服务器与应用程序扩展之间的接口编程问题和应用程序扩展与网络数据库的连接问 题。 网络管理足控制一个复杂的计算机网络使其具有最高的效率和生产力的过程。在 网络管理平台中，数据库子系统位于中间层，用于其上层应用管理层和下层数据采集 层高效可靠的存取数据。数据库子系统定义管理子系统所要求的各个数据库，并定义 与上下层子系统相关的数据接口，为上层的管理子系统和下层的数据处理子系统访问 数据库提供支持。由_ r | 计算机网络的复杂性和异构性，使网络管理模式由传统的高度 集中转为层次化的网络管理模式，进而出现了分布式网络管理体系结构和基于w e b 的网络管理。基于w e b 的网络管理将是网络管理的发展方向，这就提出了如何基于 w e b 高效的存取管理信息库中的信息。 访问w e b 数据库的关键是如何实现应用服务程序，常见的几种方法是： ( 1 ) c g i ( c o m m o ng a t e w a yi n t e r f a c e ) 通用网关接口c g i 是w e b 服务器凋用外部程序的接口规范协议，也是w e b 最早提 供的具有较完善交互功能的手段。按照这种标准编写的c g l 应用服务程序能够扩展 w e b 服务器的功能( 访问数据库时重要的任务之一) 从而在w e b 服务器于数据库之间 第一章绪论 架起一道桥梁。最典型的三层客户机服务器模型是公共网关接口c 6 i 。c ( ；t 是传统的 w e b 数据库连接技术，是一个位于服务器和外部应用程序之问的通信协议。w e bs e f v e r 于远程数据库问没有任何独立的中间层，c g i 程序可以与w e b 浏览器进行交互，并町 以通过数据库的调用接口于数据库服务器进行通信。 c g l 程序作为独立的外部应用程序来执行，与w e b 服务器上的其他进程竞争处理 器资源，因此导致运行速度缓慢。 如图卜1 所示，其典型的工作流程如下： 客户根据需要查询的内容填写浏览器提供的表格，并通过嵌入在| t t m l 中的 “a c t i o n ”来激活一个c g i 程序；， 浏览器将填写内容嵌入u r l 的c o i 串，作为程序变量上传给w e b 服务器，由 后者交给c g i 进程； c g i 进程处理数据，访问制定的数据库并将结果返回给w e b 服务器； w e b 服务器动态产生一个w e b 页，以l i t m l 文件形式f 传给浏览器； 浏览器解释h t m l ，显示查询结果。 几乎所有的w e b 服务器均支持c g i ，冈此c g i 对w e b 服务器通用性好。但c g i 程 序存在固有的缺点： 运行速度慢：因为c g 【作为w e b 服务器外部程序，它和w e b 服务器之间的通 信属于进程叫通信，每当客，1 t 产生一次 t t p 请求，都要在服务器中肩动一个c g i 进 程，分配新资源。当用户流量增加时，w e b 服务器性能急剧下降； 访问数据库效率低： _ _ 】于每次访问数据库首先建立连接，用完后立即拆除连 接，即使w e b 服务器在此之前曾多次访问过这个数据库； 可移植性差：必须针对不同数据库丌发不同的c g i 程序，编程难度大，任务 重。 i 数据库服务器 f 鲞询 i 毒： 强l 诸求 l 用程序l 粜 变量赋值， 1 舍结果豹砒页面 1 w e b 服务器 围卜lc g i 访问数据库流程图 ( 2 ) w e b 服务器应用程序接口( w e ba p i ) 为了克服c 6 i 运行缓慢尤其是访问数据库效率低下的缺陷，w e b 服务器厂商椎f i w e ba p 【。w e ba p i 通常以动态连接库( i ) i 。i ) 的形式提供。m 主要有m i c r o s o f t 的 第一章绪论 i s a p 和n e t s c a p e 的n s a p i 等。w e b 访问数据库的流程图如图卜2 所示。 古= 芋r x s l p i 的盯t p i 寿求 舍有结果的i t l l l 页面 i 数据库服务器i 壹淘 r结粜 葛e b p 工 葛e 硼甚彗器 固卜2w “a p i 访问数据库琉程图 其： 作原理是：客户浏览器发出h t m l 请求，w e b 服务器将w e b 应用程序部分交 给统进程中的w e b 服务器，然后由w e b 服务器将结果通过i i t m l 显示在客户浏览器 中。w e b 浏览器的优点是： a p 程序执行效率高：由于w e ba p i 常驻w e b 服务器，于w e b 服务器同处内 存统段地址空间，两者属于同一进程，a p i 在w e b 服务器运行期问始终处于激活状 态，而不像c g i 那样每次访问都要重新启动新进程。另外，通过w e ba p i 可以直接访 问运行在w e b 服务器上的专门应用程序，解决不同w e b 应用的特殊要求； 访问数据库效率高：w e ba p i 仅在第一次操作数据库时建立连接，以后访问 不须再次连接，大大降低了访问数据库的开销。a p i 结构存在的最大问题是它们的互 不通用。各科ta p i 之间的兼容性差，缺乏统一的工业标准。 ( 3 ) 数据库服务厂商提供的接口 除了w e b 服务器厂商提供的w e ba p i 外，数据库服务厂商也提供相应的功能接口。 如o r a c l e 使用标准的w e b 公共网关接口，将其p l s q l 开发环境与w e b 连接在一起。 使用o r a c l ew e bs e r v e r ，通过w e b 客户机可直接调用o r a c l e 的存储过程来生成动态 的w e b 文档。 ( 4 ) j a v a 数据库接口j d b c j d b c ( j a v ad a t a b a s ec o n n e c t jv j t y ) 技术是j a v a s o f t 公司设计的j a v a 语言的数 据库访问a p i ，在功能上与o d b c 相同，都是基于x o p e n 的s q l 命令层接11 ( c l i ) ， 定义了友好的j a v a 界面来与x o p e n 的s o l 调用级接口中定义的基本抽象层和基本概 念层进行连接。 j d b c 的数据库独立性是一组由驱动程序实现的j a v a 接口。驱动程序负责标准 j d b c 调用向支持的数据库所要的具体调用转变。图卜3 显示了常见的j d b c 躯动程序。 第一市绪沦 主要有四种，分别是： 区面 j d b c 壤鬻d l “8 ” 甲甲蹴序 l厂i 8 瓢序 围卜3j d b c b 暖自程序的类型 j d b c o d b cb r i d g e ：包含在s u n 公司提供的j d b c 软件包中，是在o d b c 的基 础上实现了j d b c 的功能。必须在系统中配置o d b c 。 n a t i v ea p id a r t l y - j a v ad r i v e r ：引对某种数据库产品的驱动程序，它是 在这利；数据库产品原有驱动程序的基础上实现的。使用时，须在系统安装该数据库驱 动程序。 j d b c n e tp u r ej a v ad r i v e r ：该驱动程序将在j d b c 调用翻译成于数据库无 关的网络协议，然后在服务器端将网络咖议翻译成某种数据库l 办议。使用这种驱动程 序刁：需要在客户端安装其它软件，并且能访问多种数据库。这种驱动程序与平台无关， 并且与用户访问的数据库无关，适合在多层结构应用软件体系结构中使用。 n a t i v e p r o t o c o lp u r ej a v ad r i v e r ：该驱动程序将j d b c 调用翻译成某种 数据库协议。不同的数据库厂商开发不同的驱动程序，以便用户能够使用这种驱动程 序快速的访问自己的数据库产品。该驱动程序于平台无关，但与数据库有关。 j d b c 接口包括两部分：j d b ca f ) i 和j d b cd r i v e ra p 。 d b ca p i 提供了应用程 序到j d b cd r i v e rm a n a g e r 的通信功能，为j a v a 语言定义的一个s q l 调用( c l i ) 接口，它的应用程序可以对某个数据库打开连接，执行s q l 语句并处理结果；j d b c d r v e ra p l 支持j d b cd r i v e rm a n a g e r 于数据库驱动程序的通信。 1 3 课题的任务和取得的结果 水课题是为某信托公司玎发的管理系统，课题拟实现的日标是： ( 1 ) 面向客户 为了提高管理的有效性，更好地为客户提供服务，系统在会计事项处理上 以经营管理为中心，同时兼顾刺客户的服务和客户信息的管理。 第一章绪论 以客户信息为基础，在新系统中构造客户信息管理子系统，其目标是： 综合反映客户在信托公司各项委托业务信息，为公司的经营管理与决策 服务。 建立客户风险管理体系，为降低信托公司风险提供基础数据。 以客户信息系统为基础，构造、! k 务系统、账务系统，为客户提供安全、 方便的服务。 客j 、信息处理系统应具有如下功能： 对客户基本信息的管理。 对客户所有账户信息的管理。 对客户所有合同信息的管理。 对大客户和重要客户的特殊信息管理和服务提供接口。 实现客户信息的集中化管理。 支持建立客户之间的联系，如个人与公司之问的联系、母公司与 子公司之间的关系等。 ( 2 ) 面向合同 作为信托公司，合同协议是客户与信托公司的一个纽带，每一笔信托业务 自始至终都是围绕合同进行，合同从签订、变更、到最终消亡的轨迹真实的描 述了一笔信托业务的来龙去脉。合同管理子系统奠定了整个系统的基础。 建立合同管理子系统的目标是： 合同成为客户与业务人员、会计人员进行业务处理的纽带。 为会计系统提供基础数据，比如委托资金的进入、退出，贷款的发放与 归还应受合同信息的控制。 通过建立全面的合同信息，简化会计核算手续。 提高业务人员的工作效率、使业务人员在任一时间都能清晰的掌握自己 负责的每个合同执行状况。 为各种考核提供原始数据。 客户与信托公司业务往来，其账务核算应以合同为依据、通过账户记录 反映合同执行情况。也就是对于信托客户来讲，客户只需知道合同号就可 以办理各种业务。同时信托公司科目体系的变动也不会影响到客户。 合同管理子系统应具有如下功能： 对合同种类的管理( 合同种类信息、合同模版) 对合同基本信息的管理； 第一章绪论 对合同变更的管理( 挂失、逾期、展期、撤销) ； 对来源合同与运用合同对应关系的管理； 从长远目标来看，本系统的开发和应用，应达到以下目的： 建立完整、详细的基础数据库，实现数据共享、最终实现公司的全面信息化管 理。 建立公司业务经营、会计核算、管理控制、行政办公一体的信息化系统。 软件系统结构采用b s 方式，支持多种数据库、多种操作系统。 按照公司管理制度要求，建立严格的权限控制系统，分级操作，保证数据安全。 系统支持公司业务流程设计与组织架构重组，便于未来新业务的系统迁入，满 足公司向规模化经营和现代化企业制度过渡的需要。 整个系统运行于现有的网络及硬件设备环境，保护公司现有投资。 首期系统要求： 完成系统总体目标设计。 构建公司会计系统、业务系统。 处理业务时要保证多途径的“资金来源”与多领域运作市场的“资产运用”及 收益分配对象的合理对应关系。 区分公刮自有资产与客户信托资产，分别记账、独立核算。 会计核算应包括本、外币业务；外币、i k 务实行分账核算。 信托业务必须体现委托人财产单独设账、单独核算的封闭性特点。 第二章j 2 e e 技术1 r 台 第二章j 2 e e 技术平台 企业应用系统的开发一直面临着重大挑战：一方面，企业应用系统面对的是一个 异构的分析i 式环境，它必须支持与已有系统的集成性和与其他系统的互操作性；另一 方面，作为客户、合作伙伴和企业内部的信息服务甲台，企业系统还必须具有高可用 性、安全性、可靠性和可伸缩性。这些要求再加上复杂多变的用户需求和不断伸缩的 交付时间，使得企业系统的开发越来越困难。j a v a 技术的出现，尤其是j 2 e e ( j a v a2 p l a t f o | me n t e r p r i s ee d i t i o n ) 平台的推出使得企业系统的开发由此变得快速和方 便。j 2 e e 本身是个标准，它为彳i 同一。商创建平台产品提供了标准，使不同j 2 e e 平 台产品之间的交互成为可能。 2 1 n 层体系结构 n 层体系结构是在两层体系结构的基础上增加了一层或者更多层。在n 层软件部 署中，表示层、商务逻辑层和数据层被物理的分割成不同的层。在多层体系结构中， 甚至可以将每个逻辑层更进一步的进行物理上的分割，让其更加独立的完成功能。 表示层在由一个或多个w e b 服务器构成的空m 里运行，山j a v as e r v l e t 定制 显示界面的脚本( 如a s p 、j s p 等) 和流程逻辑控制模块组成。 商务逻辑层在由一个或多个应用程序服务器构件的空间里运行。应用程序服务 器是必不可少的，它们为商务逻辑层组什提供了运行的容器环境。应用程序服务器还 为这些组件提供可靠的和必要的支持，而且还能够管理这些组件。例如：应用程序服 务器可以为商务逻辑层提供数据库访问的底层环境，通过这些底层环境，商务逻辑层 可以向数据层中写入数据或者提取数据。应用程序服务器在必要的时候实例化组件对 象。 数据层由一个或多个数据库系统组成，其中可能包括由存储过程组成的和数据 存取相关的逻辑模块。 在n 层体系结构中： 部署开销低数据库驱动程序被安装和配置在服务器端。在服务器端部署和配置 系统的丌销远低于在数千台客户终端上部署和配置系统。 更改数据库开销低n 层体系结构中，用户不直接访问数据库，而是通过中剐层 来访问数据。这样，即使重新定义数据结构，更改数据库驱动程序，甚至更改存储方 式，也不会影响到客户端。 商务逻辑层修改开销低n 层体系结构中，修改商务逻辑层不会对客户端产生任 第二章j 2 e e 技术甲台 何影响，不需要重新编译和部署客户端软件。 可以在n 层体系结构中直接安装防火墙来增强安全性在基于w e b 的系统中，如 果彳i 希望外部用户i 方问自己的商务逻辑层，表示层也不希望被任意访。解决此问题 的办法就是在表示层和商务逻辑层安装防火墙。如图2 - 1 所示。 一生三囊鞍 旷i ：簪： 层边界 c 1 ，一，、 口+ l 一、羔： 固2 - ! 三层结构中解决系统安全方案 舟 ， 安生区域 u 资源可以被有效的共享和重新利用在n 层体系结构中，与外界资源建立的连接 可以被有效的管理起来。在一个系统中，数据库所能提供的连接通常少于系统中发出 数据库请求组件的总数量。在n 层体系结构中系统将这些资源的连接收集起来，用来 不断响应不同用户应用的请求，而不是让客户端的应用去获得或释放对象数据库的资 源连接，从而避免了系统资源的浪费，同时增加了系统的整体可拓展性。此外，由于 资源的连接不需要不断的被创建和释放，所以，也提高了系统整体性能。资源共享如 图2 2 所示。 第= 章j 2 e e 技术1 i j 台 固2 21 层体系结构中资强利用 每个层面互相独立互不影响剥数据库结构进行修改时，不需要对表示层进行大 的修改。 使性能下降局部化如果某个层的应用出现过载的情况，其它层的应用也能够正 常的工作。在基于w e b 的系统中，即使应用服务器已经严重超载，用户依然能浏览系 统主页。 使故障局部化如果出现严重故障，n 层体系结构能够确保这个故障被限定在一 个层而中，不继续扩散。 增加网络的负荷由于n 层体系结构物理卜区分了各个层面，这些层面中的应用 要通过各种层而叫的界限。 2 2b s 运行模式 i n t e r n e t 的发展给传统应用软件的丌发带米了深刻的影响。基于i n t e r n e t 和w e b 的软件和应用系统需要更为丌放和灵活的体系结构。随着越来越多的商业系统被搬上 i n t e r n e t ，一种新的、更具生命力的体系结构被广泛采用，这就是为我们所知的“三 层多层计算”。 ( 1 ) 客户层( c l i e n tt ie r ) 用户接口和用户请求的发出地，典型应用是网络浏览器 和胖客户( 如j a v a 程序) 。 ( 2 ) 服务器层( s e r v e rt i e r ) 典型应用是w e b 服务器和运行业务代码的应用程序服 鹅二章j 2 e e 技术t 台 务器。 ( 3 ) 数据层( d a t at i e r ) 典型应用是关系型数据库和其它后端( b a c k e n d ) 数据资 源如o r a c le 。 三层体系结构中，客户( 请求信息) 、程序( 处理请求) 和数据( 被操作) 被物 理地隔离。三层结构是个更灵活的体系结构，它把显示逻辑从业务逻辑中分离出来， 实现业务代码的独立性，使其可以不关心怎样显示和在哪单显示。业务逻辑层处于中 间层，不需要关心由哪种类型的客户来显示数据，也可以与后端系统保持相对独立性， 有利于系统扩展。三层结构具有更好的移植性，可以跨不同类型的平台工作，允许用 户请求在多个服务器间进行负载平衡。三层结构中安全性也更易于实现，因为应用程 序已同客户隔离。 2 33 2 e e 技术概述 j a v a2e n t e r p r i s ee d i t i o n ( j 2 e e ) 规范提供了实现高度可伸缩、可靠和可用 的分布式基于服务的体系结构。通常，j 2 e e 应用体系结构与模型一视图一控制器( m v c ) 框架相对应一资源库外部系统资源支持域模型( 模型) ，j s p s e r v l e t 管理显示 ( 视图) ，而e j b 处理商业逻辑( 控制器) 。 j 2 e e 本身是一个标准，而4 i 是一个现成的产品，由以下儿个部分组成： 2 3 1 组件一容器搭建体系架构 j 2 e e 规范定义了一个基于组件的多层企业应用系统开发平台，其逻辑结构如图 2 3 所示。图中的椭圆形表示组件，大矩形表示容器，包含向下文字的小矩形表示 a p i ，箭头表示访问，箭头线l ：的文宁表示相应的协议。 第二章j 2 e e 技术平台 固2 3j 2 e e 平台 j 2 e e 是一个基于组件容器模型的系统平台，其核心概念是容器。容器是指为特 定组件提供服务的一个标准化的运行时环境，j a v a 虚拟机就是个典型的容器。组 件是一个可以部署的程序单元，它以某种方式运行在容器r r 【，容器封装了j 2 e e 底层 的a p i ，为组件提供事务处理、数据访刈、安全性、持久性等服务。在j 2 e e 中组件 和组件之问并不直接访问，而是通过容器提供的1 办议和方法来相互调用。组件和容器 间的关系通过“协议”来定义。容器的底层是j 2 e e 服务器，它为容器提供j 2 e e 巾定 义的各种服务和a p i 。一个j 2 e e 服务器( 也叫j 2 e e 应用服务器) 可以支持一种或多 种容器。每个容器的服务包括两部分：j 2 5 e ( j a v a2p l a t f o r ms t a n d a r de d i t io n ) 和一组扩展的服务。容器在j 2 s e 之上再根据需要提供一些扩展的服务，如目录服务、 事务管理、数据访问、消息机制、安全性等。 2 3 2 平台标准服务 服务是纽件和容器之间，以及容器和j 2 e e 服务器之间的接口，在实现层面上是 一系列a p i 和队议。j 2 e e 平台定义了一组标准的服务。 ( 1 ) = ；_ f 录服务j n d i ( j a v an a m ea n dd i r e c t o l l y ) a p i 为应用程序提供了一个 统一的接口来完成标准的目录操作，由于j n d i 是独立于目录协议的，应用程序i 叮以 用它c ；j ：问各种目录服务，如i g a p 、n d s 、d n s 等。 第一章j 2 e e 技术t l 台 ( 2 ) 数据i 方问j d b c ( j a v ad a t a b a s ec o n n e c t i v i t y ) a p i 为访问不同类型的数 据库提供了统一的途径，屏蔽了不同数据库的细节，具有平台无关性。支持行集、连 接池和分布式的事务处理。 ( 3 ) 事务处理j t a ( j a v at r a n s a c t i o na r c h i t e c t u r e ) 定义了一组标准的接l _ 】， 为应用系统提供可靠的事务处理支持。j t s ( j a v at r a n s a c t i o ns e r v i c e ) 是c o r b ao t s 事务监控的j a v a 实现。j t s 规定了事务管理器的实现方式，该事务管理器在高层支 持j t a 标准，在底层实现了o m go t s 规范的j a v a 映射。 ( 4 ) 消息服务j m s ( j a v am e s s a g es e r v i c e ) 是一组用于和面向消息的中间件 相互通信的a p i 。 ， ( 5 ) c o r b a 兼容接口 r m i ( 远程方法调用) 是在分布式对象问通信的j a v a 本地 方法，它使应用程序调用远程方法像凋用本地方法一样，不需要考虑所调用剥象的位 置。r m i i i o p 是r m i 的扩展，是符合c o r b a 标准的剥象通信协议，也是j 2 e e 默认的 组件通信协议。j a v ai d l 允许j 2 e e 应用组件通过i i o p 协议访问外部的c o r b a 对象。 ( 6 ) 安全服务j a a s ( j a v aa u t h e r t t ic a t i o na n da u t h o r i z a t i o ns e r v i c e ) 用 两个步骤实现安全性：认证，即由用户提供认证信息( 如用户名和密码) 来获得系统 认证，这一过程又称之为登录；授权，在被确认为合法用户后，系统根据用户的角色 授予其相应的权限。j 2 e e 的授权是基于安全角色的概念，一个安全角色是一个拥有 相同权限的逻辑组。 ( 7 ) w e b 服务支持。 2 4 应用服务器 应用程序服务器的定义如卜| ：采用具有分布式计算能力的集成结构、支持瘦客户 机的软件服务器产品。应用程序服务器的基本用途包括：管理客户会话、管理业务逻 辑、管理与后端计算资源( 包括数据、事务和内容) 的连接。 随着w e b 应用范围的扩大，需要w e b 服务器端提供复杂的和灵活的应用丌发支持。 j a v a s c r i p t 、v b s c r i p t 等技术的运用，w e b 中对象和组件的应用使基于w e b 的商业程 序开发得以迅速发展。但这种应用通常只适用于构建规模不大的商业系统，当商业系 统进一步扩大时，其扩展性就会受到限制。 应用程序服务器( a p p l i c a t i o ns e r v e r ) 的产生正是为了突破这一瓶颈，应用程 序服务器完全不同于w e b 服务器，是专门为基于大负荷高端处理的w e b 应用而设计的 全新的运行环境，该环境能提供很高的可靠性，健壮的程序逻辑处理能力。 第= 章j 2 e e 技术甲台 2 4 1 应用服务器功能 应用程序服务器是位于企业数据和访问企业数掘的客，之间的中间件，它提供了 业务代码的存放和运行的环境。从物理上把业务逻辑( b u s i b e s s1 0 9 i c ) 同客户端和 数据资源分离开来。应用程序服务器使一个商业系统得以快速简便的开发和部署，也 可以适应商业系统的用户增加而无需重构系统，这切都是因为它处丁一个相对独立 的结构层。在实际应用中，一个企业系统可以由多个应用程序服务器、多个w e b 服务 器和多个数据库服务器组成，应用程序代码可以分布在这多个应用程序服务器上。 所有应用程序服务器有其共有的基本特性，包括连接管理，状态和会话管理，业 务逻辑集中和数据库连接等。应用程序服务器支持允许客户连接的有关协议，有验证 用户的安全机制。服务器进程的主要工作是管理客户连接，以及将到来的客户请求重 定向到不同的后端资源。 安全服务( s e c u r i t ys e r v i c e s ) 为了获得资源访问权，客户必须通过服务器的 认证，因此服务器必须要有验证用户的安全设施。大多数应用程序服务器提供增加用 户用户组的机制和对组件的访问控制。一旦用户身份被验证，服务器将允许或禁止 它对组件的访问和所管理的数据连接。 状态和会话管理( s t a t ea n ds e s s i o nm a n a g e m e n t ) 服务器必须在同一用户会 话过程中多次请求之间维护有关的状态数据。从扩展性方面考虑，运行在服务器上的 组什应避免使用实例变量。在应用程序服务器环境中，服务器必须通过会话列象来保 持用户数据。会话埘象( s e s s i o no b j e c t ) 的唯一功能就是保存服务器端的数据，从 而简化复杂应用程序的开发，因为可以不必在程序中编写有关使用c o o k i e s 和隐藏字 段来回传递状态的代码。同时也使存在安全风险的数据远离浏览器端，增加系统安全 性保证。一般情况下，在浏览器和服务器问来回传递的唯一信息只是会话i d 。 负载平衡和失败恢复( l o a db a l a n c i n ga n df a i l - o v e r ) 所有的应用程序服务 器都提供某种类型的负载平衡和失败恢复机制。负载平衡意味着一绀服务器可以被集 。| | 成为一个服务器集群( c l u s t e r f a r m ) 。发往服务器的请求被一个分配器 ( d is p a t c h e r ) 处理以便将请求发给虽空闲的服务器，此后客户将直接与那台服务器 通信。负载平衡机制为系统提供了很好的扩展性，随着用，o 负载的增加，更多的服务 器主机可以被加入到服务器集群。p 。 业务和处理逻辑( b u s i n e s sa n dp r o c e s s i n gl o g i c ) 在应用程序服务器的核心 部分集中容纳了业务逻辑( 叩访问，生成数据和执行处理的代码) 。与应用程序相关 的业务逻辑可以山可重用组件组成。一旦组件被创建，就可以被载入到应用程序服务 第二章j 2 e e 技术甲台 器中，分配适当的安全设定，然后运行。火多数应用程序服务器提供机制用于指定组 件的持久性，事务处理设定和线程设定等。 数据访问应用程序服务器提供机制，用j 二增加和管理与火系型数据库( 如 o r a c l e ，d b 2 ) 的连接。 事务管理( t r a n s a c t i o nm a n a g e m e n t ) 在应用程序服务器环境中，事务是由服 务器唯一管理的。如果调用序列中任何组件执行失败，服务器将执行回滚；否则服务 器执行确认。 连接池( c o n n e c t i o np o o l i n g ) 应用程序服务器不为每一个用户保持单独连接。 它维护了一个连接池，供所有服务器端组件共享。如果_ 用户需要更新数据，相应组件 就会请求服务器从连接池中分配一个可用连接，当所有的更新被完成后，组件负责通 知服务器是否所有操作都成功。当一个事务结束后，连接被立刻释放。 线程池和实例池( t h r e a dp o o l i n ga n di n s t a n c ep o o l i n g ) 高端的应用程序服 务器还提供线程池和实例池。 2 5 e j b 技术剖析 e j b 是j 2 e e 平台的核心，叫b 的核心思想是将商业逻辑与底层的系统逻辑分丌， 使丌发者只需关心商业逻辑，而由e j b 容器实现目录服务、事务处理、持久性、安全 性等底层系统逻辑。 2 5 1e j b 组件的构成 个可部署的e j b 组件包含3 个部分，如图2 4 所示。 第二章j 2 e e 技术平台 ( 1 ) r e m o t e 接口r e m o t e 接口定义剀b 组件中提供的可供用户调用的方法，即实现 商业逻辑的函数或过程，以供远程客户端调用。在e j b 组件部署到容器的时候，容器 会自动生成r e m ol e 接口相应的实例，即b j b 对象，它负责代理用户的调用请求。 ( 2 ) h o m e 接口h o m e 接口定义一组方法来创建新的e j b 对象，查找、定位和清除 已有的e j b 对象。在e j b 组件部署时容器也会自动生成相应的h o m e 对象，该对象负 责查找, u g , j 建e j b 对象，返回e j b 对象的引用给客户；用j 、利用该引用调用e j b 组件 的方法，得到结果；最后h o m e 对象清除e j b 对象。 ( 3 ) e n t e r p r i s eb e a n s 类e n t e r p r i s eb e a n s 类是商业逻辑的具体实现类。其可 供用户调用的方法在r e m o t e 接口中定义。根据功能不同，e j b2 o 规范中定义了三 种e n t e r p r i s eb e a n s ：会话b e a n s ( s e s s i o nb e a n s ) 、实体b e a n s ( e n t i t yb e a n s ) 和消息驱动b e a n s ( m e s s a g e d r i v er t 1 e a n s ) 。 2 5 2e j b 的运行结构 e n t e r p r i s eb e a n 驻留在c o n t a i n e r 中，通过e j bc o n t a i n e r 对e j b 进行管理。 e j bj ；! i l 范定义了两者之f u j 的接口。整个f 。i bb e a n 被压缩在一个j a r 包内，j a r 包中 的拙述文件( 对应每个e j bb e a n ) 记录了b e a n 的本地接口名字，客户端应用程序通 过h o