（计算机软件与理论专业论文）轻量级j2ee架构的研究与应用.pdf

摘要 摘要 随着j 2 e e 技术的发展，j 2 e e 在企业级软件开发中占的地位也日益重要，但是 作为传统的基于e j b 的j 2 e e 架构开始越来越不能满足一些企业对应用开发新的要 求。传统的基于e j b 的j 2 e e 架构其优势在于高级j 2 e e 特性和分布式应用，但是 很多项目对这些高级特性和分布式特性要求并没有要求，而且，这些高级特性和 分布式应用较为复杂的开发和配置大大降低了企业的开发速度，也增加了企业的 开发成本。本文针对这一问题，提出了一种基于开源框架的轻量级j 2 e e 开发架构 的解决方案。 本论文所做的工作如下： 首先，研究了j 2 e e 发展的现状，归纳传统的基于e j b 的j 2 e e 架构所带来的 开发问题，分析造成这些问题的原因。针对造成这些问题的原因，研究了现在流 行的轻量级j 2 e e 框架，考察了这样的轻量级框架可以在什么层面上对原来的“重 量级”架构进行替代，比较了轻量级架构和重量级架构各自的优势所在。 其次，结合本文的目标和现在流行的轻量级j 2 e e 框架的作用、优缺点进行技 术选型，选择s t u r t s 作为w e b 层框架，s p r i n g 作为业务逻辑层框架，i - h b e r n a t e 作 为数据持久层框架。深入探讨了几个框架所采用的技术、特性以及开发方法，同 时也对准备在本架构中采用的其他重要组件进行了研究分析。 再次，在前文的研究基础上，对本文要实现的轻量级j 2 e e 开发架构进行了模 型建立和模型分析，模型改进。根据建立的模型，对s t r u t s ，s p r i n g ，h i b e r n a t e 和 其他组件进行了整合，并在整合的基础上，设计和实现了异常处理机制，数据封 装，架构安全，为通用业务提供的模板接口和实现类等。 最后，通过一个开发实例，测试该开发架构的可用性，实用性，易用性及其他 特性。 本文提出的轻量级j 2 e e 开发架构提供了w e b 开发需要的服务，摒弃了不需要 的j 2 e e 高级特性和分布式应用，可以让企业的开发变得简单和快速，特别适合企 业的小规模w e b 业务开发。 关键字：j 2 e e 架构，轻量级开发，开源软件框架 a b s t r a c t w i t ht h ed e v e l o p m e n to ft h ej 2 e et e c h n o l o g y , j 2 e ei sb e c o m i n gm o r ea n dm o r e i m p o r t a n ti ne n t e r p r i s e sd e v e l o p m e n t , h o w e v e rt h et r a d i t i o n a lj 2 e ef r a m e w o r kw h i c h i sb a s e do nt h ee j ba r c h i t e c t u r ei sb e c o m i n gm o r ca n dm o r e 啪n o ts a t i s f yt h en e w r e q u e s t sf r o me n t e r p r i s e s m a n yp r o j e c t sd o n tn e e da d v a n c e dj 2 e e c h a r a c t e r i s t i c sa n d d i s t r i b u t e da p p l i c a t i o nw h i c ha r et h ea d v a n t a g eo ft h et r a d i t i o n a lj 2 e ef r a m e w o r k , s o t h ec o m p l e xd e v e l o p m e n t , c o n f i g u r a t i o n , d e p l o yo fa d v a n c e dj 2 e ec h a r a c t e r i s t i c sa n d d i s t r i b u t e d a p p l i c a t i o nd e p r e s s t h e d e v e l o p m e n ts p e e dg r e a t l y i t i n c r e a s c st h e e n t e r p r i s e sc o s ta l s o t h i sp a p e rf o c u so nt h ep r o b l e m s ，g i v e sah g h t - w e i g h tj 2 e e d e v e l o pf r a m e w o r ks o l u t i o np r o j e c tb a s e do no p e n - s o u r c e m yw o r ki ss h o w n a sf o l l o w si nt h ep a p e r ： a tf i r s t ，t h i sp a p e rh a sr e s e a r c h e dt h es t a t u sq u oo fj 2 e ed e v e l o p m e n t , c o n c l u d e d t h ed e v e l o pp r o b l e m sb r i n g sb yt h et r a d i t i o n a lj 2 e ef r a m e w o r ka n da n a l y z e dt h e c a u s a t i o n so ft h ep r o b l e m s f o c u so nt h e s ep r o b l e m s ，t h i sp a p e rh a v er e s e a r c h e dt h e f i g h t - w e i g h tj 2 e ef r a m e w o r kw h i c hi sp o p u l a rn o w , c h c c k a dw h a tl e v e l c a l lt h e l i g h t - w e i g h tf r a m e w o r ki n s t e a do f t h eh e a v y - w e i g h tf r a m e w o r ki n , f o u n da d v a n t a g ea n d d i s a d v a n t a g eo ft h et w o s e c o n d l y , t h i sp a p e rh a sc l a s s i f i e dt h ep o p u l a rl i g h t - w e i g h tj 2 e e f r a m e w o r k si n t o3 k i n d s , a n a l y z ef e wm o s ti m p o r t a n tf r a m e w o r k si n t o3k i n d s c o n s i d e r i n gt h ea i mo f t h i s p a p e r , t h ef u n c t i o n sa n da d v a n t a g e so ft h e s ef r a m e w o r k s , w ec h o o s e s t r u t sa s f r a m e w o r ko fw e bl e v e l ，s p r i n g 醛f r a m e w o r k 鹤b u s i n e s sl o g i cl e v e l ，h i b e r n a t e 勰 f r a m e w o r ko fp e r s i s t e n c el e v e l w ed i s c u st h e s et h r e ef r a m e w o r kd e e p l yi nt h i sp a p e r a n dd oi tt os o m eo t h e ri m p o r t a n ts u b a s s e m b f i 髂a l s o t h i r d l y , b a s e do nt h er e s e a r c hb e f o r e , t h i sp a p 盱h a sc o n s t r u c t e dam o d e lf o rt h e l i g h t - w e i g h tj 2 e ed e v e l o pf r a m e w o r ka n da n a l y z ei t , i m p r o v ei t a c c o r d i n gt o t h e m o d e l ，w ea s s e m b l e ds t r u t s ，s p r i n g , h i b e r n a t ea n do t h e rs u b a s s e m b f i e s i na d d i t i o n a l , w ed e s i g n e da n dr e a l i z e de x c e p t i o np r o c e s sm e c h a n i s m , d a t ae n c a p s u l a t i o n ，f r a m e w o r k s e c u r i t y , t e m p l a t ei n t e r f a c ea n dc l a s sf o rt h eb a s i cb u s i n e s sa n d s oo i l a tl a s t ，w eg a v ead e v e l o pi n s t a n c et ot e s tt h i sd e v e l o pf x a m e w o r k su s a b i l i t y , p r a c t i c a b i l i t ya n do t h e rc h a r a c t e r i s t i c s t h e l i g h t - w e i g h t j 2 e ed e v e l o pf r a m e w o r kg i v a l m o s ts e r v i c e st h a tw e b d e v e l o p m e n tn e e d , d i s c a r d ss o m ej 2 e ea d v a n c e dc h a r a c t e r i s t i c sa n dd i s t r i b u t e d a p p l i c a t i o n i tc a nm a k ee n t e r p r s e sd e v e l o p m e n tt ob es i m p l ea n df a s t , s oi t sa d a p tt o t h es m a l l - s c a l ew e bb u s i n e s sd e v e l o p m e n t k e y w o r d s ：j 2 e e6 狮e w o r l ll i g h t - w e i g h td e v e l o p m e n t , o p e n s o u r c 蛤s o f t w a r e f r a m e w o r k m 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工 作及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地 方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含 为获得电子科技大学或其它教育机构的学位或证书而使用过的材料。 与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明 确的说明并表示谢意。 堋年5 月1 日 关于论文使用授权的说明 本学位论文作者完全了解电子科技大学有关保留、使用学位论文 的规定，有权保留并向国家有关部门或机构送交论文的复印件和磁 盘，允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文 的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或 扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后应遵守此规定) 签名： 第一章引言 1 1 研究背景 第一章引言 j 2 e e 是s u no n e 的重量级产品，作为一种企业级w e b 应用程序开发技术，j 2 e e 是目前在市场上得到了广泛应用的技术体系。j 2 e e 以j a v a 为核心技术，更接近或 者更满足互联网在智能化w e b 服务上对分布性、开放性和平台无关性的要求，同 时它在安全性、健壮性、组件化等方面也更为成熟稳定，获得了众多r r 厂商如 m m 、o r a c l e 、b e a 等共同制定标准并提供技术支持，因此具有强大的功能，是电 子商务、远程教育等开发的首选平台。 目前，j 2 e e 已经成为许多企业应用程序开发的标准，其中的s e r v l e t j s p ，e j b 框架等技术已经被广大客户接受并使用。但是j 2 e e 也存在着许多的不足。 j 2 e e 使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组 件根据他们所在的层分布在不同的机器上。传统的j 2 e e 多层企业级应用模型将两 层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的服务提供一 个独立的层。其中，运行在j 2 e e 服务器上的e j b 容器可以认为是此结构的核心。 e j b 容器管理着所有e j b 的生命周期，e j b 的执行，并为它们提供系统级的服务。 在容器中的e j b 组件则负责接受和处理w e b 容器的客户请求，以及负责连接为整 个企业提供数据的e i s 层。这样一个架构，可被认为是j 2 e e 一个经典的架构。 此经典架构中，所有的数据访问都要通过e n t i t yb e a n ，业务对象都是带远程接 口的无状态s e s s i o n b e a n ，运行在f _ j b 容器中。e j b 中包含了各种服务( 比如声明 式的事务管理) ，而且提供了一个共享的中间层，可支持各种类型的j 2 e e 客户端。 但此结构中应用性能和开发开销的负担很重，一些负载来自于f _ j b ，而很大还是与 分布式架构的特性有关。此外，为了分布式的特性，牺牲了o o 原则，并且难以 测试，因为业务逻辑通常编写在e j b 的实现类中，而这些类完全依赖于e j b 容器 的。 此“经典”架构的一种改进，便是把远程e j b 替换为本地e j b ，实现了架构的 重用，解决了分布化的种种问题。但架构还是相当的复杂。e j b 的很多负担还是存 在，从e j b 中获得益处反而不多。 电子科技大学硕士论文 所以随着企业级应用开发的不断复杂，对架构设计的要求也会提出新的要求， 如：架构简单，但功能强大：架构可以通过配置w e b 容器集群来达到横向扩展； 在不同的应用服务器之间具有高移植性；便于在应用服务器之外进行业务对象的 单元测试，而且，一些集成测试甚至可以让一些轻量级容器( 如j u n i t ) 来完成。 为解决传统j 2 e e 架构中的不足和满足企业级开发新的要求，提出了轻量级 j 2 e e 架构。 一个典型的轻量级j 2 e e 架构，它的j a v a 类都运行在同一个j v m 中。业务对 象是用p o j o 实现的，并在一个控制反转的容器中运行。所有对象需要部署在i o c 容器中运行，但它们并不依赖于容器。开发者可以在应用服务器之外，用普通的 j u n i t 测试用例来测试它们。所有的调用都是针对业务接口，而不是针对业务对象 的实现类，以确保高度的接插性。借助a o p ，可以为p o j o 业务对象提供声明性 事务管理和其他横切性的企业级服务。事务的划分将由业务逻辑层或者更为合理 的容器基础设施负责。业务对象是无状态的，大多数时候，p o j o 业务对象是多线 程的无状态服务对象。w e b 层是业务逻辑层之上的一个薄层，只负责处理用户输 入，并将业务处理的结果展示给用户。数据访问层使用轻量级的o r 映射层，提 供透明的持久化。 使用这种轻量级架构，开发过程提高了代码复用度，更好的执行了o o 原则， 提高了代码的开发效率和可测试性。尤其重要的是，让企业有了传统j 2 e e 架构之 外的选择，而这样的选择允许企业可以轻松的缩放规模，而不必修改应用代码， 同时降低了开发复杂度，毕竟不是每个企业都需要分布式的，业务逻辑相当复杂 的系统。因此，相对于复杂的，基于e j b 的j 2 e e 架构，这种轻量级的j 2 e e 架构 会更受那种需要快速开发简单系统的企业的青睐。 综上所述，j 2 e e 开发的正经历着一次变革，e j b ( 2 x ) 编程模型已经过时， 轻量级容器慢慢成为j 2 e e 开发的主流，各种各样的开源软件对j 2 e e 开发提供 着强大的支持，a o p 作为一种新的编程模型逐渐兴起。整个j 2 e e 开发正在向更 加简单、易用的方向发展。 1 2 本课题的主要研究工作 本课题旨在建立一个满足j 2 e e 规范的轻量级开发架构，主要应用于对j 2 e e 高级特性和分布式特性要求不高的w e b 开发。相对于传统的j 2 e e 框架，本架构具 有较低的开发复杂度和较高的代码复用度，可以大大加快开发的速度。同时，由 2 第一章引言 于本架构是面向企业应用，为了统一企业的开发风格，针对企业的实际情况，提 供了简单实用的数据封装机制，易于开发使用的安全认证机制，统一的简单业务 模板及通用业务模块实现。 因此，如何建立一个满足要求的j 2 e e 开发架构即是本课题研究的主要内容， 具体为如下的几个方面： 1 从j 2 e e 体系结构入手，分析了现在流行的j 2 e e 开发架构，比较基于e j b 的j 2 e e 架构和轻量级j 2 e e 架构的各自特点和优势所在。 2 分析和研究了当前流行的轻量级j 2 e e 开发框架，根据项目的需求，架构基 础框架采用了目前成熟的多个开源框架( s t r u t s + s p r i n g + i - h b e m a t e ) ，将架构 分为4 层( v i e w + a c t i o n + s e r v i c e + d a o ) 3 除了基础框架，还采用了多个构件以完整开发平台。如使用e h c a c h e 管理 数据缓存，布局使用t i l e s ，校验采用v a l i d a t i o n 等。 4 整合架构各个构件，并在a c t i o n 层、s e r v i c e 层、d a o 层的上提供了简单 模版。 5 对整个架构进行集成和平滑融合，并应用到实际开发当中。 1 3 论文的组织结构 本文一共分为六章。 第一章：引言。介绍了本文的研究背景，该课题的来源所做的主要研究工作以 及本文的组织结构。 第二章：j 2 e e 架构技术分析。在这一章中对j 2 e e 的发展和现状做了介绍。引 入框架技术的概念，对j 2 e e 框架现状进行了深入的研究，剖析传统j 2 e e 框架存 在的问题。针对这些问题，提出了轻量级j 2 e e 解决方案，指出轻量级j 2 e e 架构 的优势所在。 第三章：本架构采用的框架和重要技术该章主要针对现实情况和需求，选择 了s t r u t s 作为w e b 层框架，s p r i n g 作为业务逻辑层框架，h i b e r n a t e 层作为数据持 久层框架，并且为了让架构提供完善的服务，采用了一些组件来加强架构的功能。 在进行框架和组件的选择同时，主要分析研究了这些框架和组件，解析了它们的 工作过程和他们采用的技术特性。 第四章：轻量级j 2 e e 开发架构设计与实现。本章首先建立了文中论述的开发 架构的模型，对架构层次进行了细分。然后把s t r u t s ，s p r i n g ，h i b e r n a t e 和其他开 3 电子科技大学硕士论文 源组件整合在一起，并提供异常处理，数据封装，架构安全，通用业务模板等以 加强该架构的功能。 第五章：本架构在出差管理系统中的应用。这一章通过一个出差管理系统的开 发，演示这个架构在实际开发中的应用过程，体现其适合快速简单w e b 应用开发 的特点。 第六章：总结和展望。综述本文所构建的架构实现现状和实现特色，总结架构 尚存在的不足，并对前景提出展望。 4 第二章j 2 e e 架构技术分析 2 1j 2 e e 概述 第二章j 2 e e 架构技术分析 j 2 e e ( j a v a 2p l a t f o r me n t e r p r i s ee d i t i o n ) 是s u n 公司提出的在分布式环境中的 一种体系结构，它提供了一种基于组件的设计、开发、集成、部署企业应用系统 的方法。j 2 e e 平台提供了多层分布式的应用系统模型、重用组件的能力、统一的 安全模型和灵活的事务控制。基于组件的j 2 e e 企业应用系统具有平台独立性， 所以不受任何软件产品和任何软件厂家a p i 的约束。 2 1 1 j 2 e e 的概念 j 2 e e 是一种利用j a v a2 平台来简化企业解决方案的开发、部署和管理相关的 复杂问题的体系结构。j 2 e e 技术的基础就是核心j a v a 标准平台。j 2 e e 不仅巩 固了标准版中的许多优点，例如“编写一次、随处运行”的特性，方便存取数据 库的j d b c a p i 、c o r b a 技术以及能够在i n t e m e t 应用中保护数据的安全模式等 等，同时还提供了对e j b ( e n t e r p r i s e j a v a b e a n s ) 、j a v a s e r v l e t s a p i 、j s p ( j a v a s e r v e r p a g e s ) 以及x m l 技术的全面支持“1 。其最终目的就是成为一个能够使企业应用 开发大幅缩短投放市场时间的体系结构。 j 2 e e 体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用 性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，j 2 e e 降低 了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完 全支持e n t e r p r i s e j a v a b e a n s ，有良好的向导支持打包和部署应用，添加目录支持， 增强了安全机制，提高了性能。 2 1 2j 2 e e 体系结构 j 2 e e 使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组 件根据他们所在的层分布在不同的机器上。事实上，s u n 设计j 2 e e 的初衷正是 为了解决两层模式( c l i e n t s e r v e r ) 的弊端，在传统模式中，客户端担当了过多的角 色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级或改进， 5 电子科技大学硕士论文 可伸展性也不理想，而且经常基于某种专有的协议通常是某种数据库协议。 它使得重用业务逻辑和界面逻辑非常困难。现在j 2 e e 的多层企业级应用模型将 两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务 提供一个独立的层，j 2 e e 典型的四层结构如图2 - 1 所示嘲： 图2 - 1j 2 e e 典型的四层结构 结合上图，我们可以看出，一个基于j 2 e e 的企业应用从结构上来看，可以分 成四部分。分别是客户层、w e b 层、业务层和企业信息层。下面是对它们的描述： 1 客户层( c l i e n tt i e r ) j 2 e e 应用可以是基于w e b 的，也可以是不基于w e b 的。在一个基于w e b 的 j 2 e e 应用中，用户的测览器在客户层中运行，并从一个w e b 服务器上下载w e b 层中的静态h t m l 页面或由j s p s e r v l e t s 生成的动态h t m l 页面。 2 w e b 层 w e b 层组件是在j 2 e ew e b 容器上运行的软件程序。w e b 容器主要支持多层结 构的表示层。它的功能是在m l t 协议上对w e b 请求( r e q u e s t ) 进行响应( r e s p o n s e ) 这些所谓响应其实就是动态生成的网页。每当用户在浏览器上点击一个链接或图 标，实际上就是通过w e b 向服务器发出请求。j 2 e e 平台的w e b 构件对这些请求 进行处理后回复给客户端相应的h t m l 或x m l 文件。j 2 e e w e b 构件包括s e r v l e t ， j a v a s e r v e r e a g e ( j s p ) 和j a v as e r v e rp a g e ss t a n d a r dt a gi i b r a r y ( j s t i j 。 3 业务层 业务层代码的逻辑用来满足银行，零售，金融等特殊商务领域的需要，由运行 6 第二章j 2 e e 架构技术分析 在业务层上的e n t e r p r i s eb e a n 进行处理。e n t e r p r i s eb e a n 从客户端程序接收数据， 进行处理( 如果必要的话) ，并发送到e i s 层储存的，这个过程也可以逆向进行。 业务层中的e j b 要运行在e j b 容器中，容器解决了底层的问题，如事务处理、 生命周期、状态管理、多线程安全管理、资源池等。 4 企业信息系统层 企业信息系统层运行企业信息系统软件，这层包括企业基础设施系统，例如企 业资源计划( e r p ) 、大型机事务处理、数据库系统及其他信息系统。j 2 e e 应用组件 通过j d b c 等方式访问企业信息系统。 2 2j 2 e e 架构 2 2 1 传统的j 2 e e 架构 在传统上，人们认为e j b 是实现j 2 e e 系统必不可少的部分。“在j 2 e e 平台中， 中间层的业务逻辑在中间层是通过e j b 组件实现的e j b 组件模型是j 2 e e 编程 模型的骨干枢纽”“”，所以，通常认为，j 2 e e 架构也就意味着这个架构。在轻量 级架构出现以前，所有人都认为j 2 e e 是一种分布式平台，s e s s i o nb e a n 和e n t i t y b e a n 在该平台占有中心地位，这些在这种传统的架构上得到了充分体现。 2 2 1 1 远程e j b 框架 远程e j b 架构是传统的j 2 e e 架构中最具代表性的框架之一，其结构如图2 - 2 所示： 7 电子科技大学硕士论文 w e bc o n t a i n e r l 砸“，s c i e t s ，w b bc i a s s 、 孽霉 l b u s i n e s sd e l e g a t e i il 肚d d i c ( r e m o t e ，n o n - w e b 砸c f r m i c l i e n t ) 啪c o n t a i n e r l 一一s n s i o n e i b l l e n t i t y e j b i j i 略面e f f q 隔 j 2 e e s e r v e r j 2 e e s e r v e r 侣a m eo r s e p a r a t e j v m ) 图2 - 2 远程e j b 框架结构示意图 在图2 - 2 所示的框架中，j a v a 类分散在不同的j v m 中嘲。 w e b 层一般由一个m v c 框架实现。可能会有一个客户端代理层，通过它调用 远程e j b ，能干净利落的解除w e b 层和e j b 之间的耦合。 所有的业务对象都是带远程接口的无状态s e s s i o nb e a n ，运行在e j b 容器里。 e j b 容器提供远程调用机制，事务管理，线程管理，基于角色的安全服务等。 在这个框架中，所有的数据访问都要通过e n t i t yb e a n 。现在通常使用e n t i t y b e a n 的话，带本地接口的c m p e n t i t y b e a n 是最好的选择，因为带远程接口的e n t i t y b e a n 乏善可陈，而且性能上还有很大风险。 e i s 层由一个或多个数据库加上遗留系统构成。如果存在多个带事务的资源， 通过e j b 容器的j t a 服务可以协调分布式事务处理。 该框架的优势：远程e j b 提供了一个严格定义的服务层；e j b 中包含很多有用 的服务；提供一个共享的中间层，能够支持各种类型的j 2 e e 客户端；能够把业务 8 第二章j 2 e e 架构技术分析 对象分布在多台服务器上，在某些情况下能带来较高的扩展性；如果应用系统不 做并置部署的话，可以独立于w e b 层更新业务逻辑。 该框架的弱项：在所有的框架中，这种框架在各个方面都是负担最重的，尤其 是应用性能和开发开销，这主要与分布式框架的特性有关系；为了分布化，框架 牺牲了o o 原则；难以测试，因为业务逻辑通常编写在e j b 的实现类中，而这些 类完全依赖于e j b 容器。 2 2 1 2 其他传统的框架 相对与远程f j b 框架，其有很多种改进的形式： 本地e b 框架是把远程e j b 替换成本地e i b 。这个变化消除了对象的分布化， 仅仅用e j b 来组织业务对象，提供事务管理之类的服务。 用某种透明持久化方案( 比如t o p l i n kh i b c m a t c 或j d o ) 来取代e n t i t yb e a n 。 不用e n t i t yb e a n ，而是s e s s i o nb e a n 来映射领域对象。这样做几乎会有明显的 改进。而且根据经验，这种架构成功的可能性要大得多。 用于基于s o l 的d b c 数据访问机制取代e n t i t yb e a n 。当o r 映射功能派不 上多大用场时，这个做法就比较合理。这也是一种相当常见的变体，但是往往 只是在若干特定用例中使用。 把业务逻辑从s l s b 中重构出来，放进后面的p o j o 里。这也是一种明显的改 进，尽量减少业务逻辑对f j b 容器的依赖，这样也提高了代码的重用程度。而 且也大大增加了可测性。 2 2 1 3 传统的j 2 e e 架构共同的实现问题 1 需要e j b 容器。这也意味着需要高端应用服务器。，而且比s e r v l c t 管理起 来要复杂得多。 2 在客户端层需要服务定位器和业务代表。 3 需要一些细粒度对象运行在会话接口之后、e j b 容器之前，管理这些对象会 出现一些问题嘲。即便是本地e j b ，最好也应该定义为相对细粒度的对象；所以为 了管理e j b 后面的细粒度对象，我们就需要一个额外的基础架构虽然e j b 部署 描述符提供了一种专门的机制，可以在x m l 中声明“环境变量”，然后就能通过 j n d i 访问这些变量，但是想要达到非常细粒度的配置，这种做法还是相当冗赘 简言之，f i b 中没有为p o l o 助手类提供生命周期支持。 9 电子科技大学硕士论文 4 一旦开始把业务逻辑放进e j b 容器之中，就很难停下来了。如果有几个业 务对象需要完成的任务是e j b 编程模型禁止的( 比如创建线程、开启网络连接、 读取文件、调用第三方a p i 、或是调用本地代码) ，那就会出现问题。 2 2 2e j b 3 0 s u n 公司也认识到了现有e i b 自身所具有的问题。为了解决这些问题，s u n 公 司推出了e j b 3 0 版。 e j b 3 0 借鉴了现在流行的轻量级架构的一些技术，尝试减轻e j b 开发的复杂 性和开发人员进行底层开发的工作量，它取消或最小化了很多( 以前这些是必须 实现) 回调方法的实现，并且降低了实体b e a n 及o r 映射模型的复杂性，f j b 3 0 的发展的几个显著特性有旧： 1 元数据的引入：以注释的形式表示元数据，取代了过去大量的配置文件。 2 各种e n t e r p r i s eb e a n 的定义都只需要定义一些p o j o 和p o j i 配合元数据即 可完成。以前的不需要的接口如h o m e 接口被移出了。 3 回调机制( c a l l b a c k ) 也是用普通的方法加以一定的注释，代替了原有的 e j b c r e a t e 之类的方法。 4 a o p 概念的引入：允许在类定义中和其他类中对方法进行拦截，它为我们 提供了“在任何对象的方法调用前或调用后加入自定义行为”的能力，这 使得我们可以处理企业应用中的横切( c r o s s c = t i n g ) 关注点，并且仍然保持强 类型。 5 依赖注入：允许通过添加特定注释向属性注入所依赖的对象，依赖注射模 式比起原来的j n d i 或者容器回调更加容易。通过依赖注入，框架扮演了对 象工厂的角色，它建立服务对象并且在运行时候注射这些对象给p o j o 。 6 基于h i b e r n a t e 的o r 映射模型。e j b 3 0 中的o r 映射模型也有了重要的 改变，它从原来的a b s t r a c t - p e r s i s t e n c e - s c h e m a - b a s e d 变成了现在的 h i b e r n a t e 。i n s p i r e d 模式。 2 2 3 轻量级j 2 e e 架构 如前文所述，传统的，基于f j b 的j 2 e e 架构有着难以避免的问题，而这些闯 题带来了一系列负面效果：部署复杂，运行缓慢；内在服务多，启动慢；规则特 别多，空间很小；难以测试等。这些负面效果，可以让我们把这种基于e j b 的j 2 e e 第二章j 2 e e 架构技术分析 架构叫作重量级的j 2 e e 架构。 随着技术的日益发展和企业级应用开发的不断复杂，对架构设计的要求也会提 出新的要求，如：架构简单，但功能强大；架构可以通过配置w e b 容器集群来达 到横向扩展；在不同的应用服务器之间具有高移植性；便于在应用服务器之外进 行业务对象的单元测试，而且，一些集成测试甚至可以让一些轻量级容器( 如j u n i t ) 来完成。 为了解决传统基于e j b 的j 2 e e 架构中的问题，人们提出了轻量级j 2 e e 架构 的概念。 2 2 3 1 轻量级j 2 e e 架构的概念 轻量级j 2 e e 架构是与重量级j 2 e e 架构相对比较而言的m 。轻量级框架主要是 指在j a v a 应用程序开发环境中，简化的编程模型和更具响应能力的容器。轻量级 架构旨在消除传统j 2 e ea p i 所具有的不必要的复杂性和限制。它也将缩短应用 程序的部署时间。 轻量级j 2 e e 架构致力于解决重量级框架所带来的问题，并且融入了新的模式， 提供更加灵活和可选择性的服务。轻量级容器一般不支持分布式环境，不过，并 不是所有的程序都需要这个服务的。 2 2 3 2 轻量级j 2 e e 架构的特点 1 从封装角度看，组件粒度一直是s a ( s o f t w a r e 砌i t 咖c ) 的最大问题脚。根 据e j b 模型，e j b 组件让我们把业务组件封装成粗粒度的业务组件。轻量级容 器这可以定义更为细粒度的组件，甚至这个组件只有一个对象以依赖注入( d i ， d e p e n d e n c yi n j e c t i o n ) 为代表的解耦模式，可以让组件不依赖容器( 运行环境) 的 a p i 。依赖注入作为容器的管道，承担中间人的角色，让使用者( c o m p o n e n t ) 和提 供者毫无关联。对于以何种粒度去设计业务组件，这就是业务的具体需求所决定 的。轻量级框架提供技术方面的支持可以让使用者有的放矢。 2 从组件角度看，真正的组件就像普通的u 盘，插到u s b 接口上就可以享受 其功能。轻量级容器通过反向控制( i o c ，i n v e 船i o no fc o n t r 0 1 ) 让容器具有主动权， 去管理插进来的组件。只要组件是符合标准的，就可以被轻量级容器管理。 3 从r u n n i n ga n y w h e r e 角度看，轻量级容器让组件以p o j o ( p l a i no l d j a v a o b j e c t ) 的形式存在，只要有j a v a c x c 就可以运行它。这样，组件根本就是一个独 立的功能集成类，根本不需要容器就可以实现测试行为。 1 l 电子科技大学硕士论文 2 3 本章小结 本章首先介绍了j 2 e e 体系结构和它的核心技术。其次，指出传统的基于e j b 的j 2 e e 架构在行业中的应用有很多不能适应行业的需求，分析这种传统的j 2 e e 架构为什么会带来这样的问题，并由此引出轻量级j 2 e e 架构的概念，归纳了轻量 级j 2 e e 架构的特点。文中还对e j l 3 的后续版本e j b 3 0 做了描述，可以看出e j b 3 0 是针对以前版本的问题做了很大的修改，并且借鉴了许多轻量级j 2 e e 框架的技术。 这一章通过传统j 2 e e 架构和轻量级j 2 e e 架构的比较，得出结论轻量级j 2 e e 架构 是对分布式、高级j 2 e e 特性要求不高的系统的较好选择，而采用e j b 的“重量级” j 2 e e 架构则正好相反。这个结论让我们的着眼点放在了轻量级的j 2 e e 架构上，下 一章，本文会深入研究本文准备提出的轻量级j 2 e e 开发架构所采用的技术框架、 重要组件和其他技术。 第三章本架构采用的框架和重要技术 第三章本架构采用的框架和重要技术 3 1w e b 层框架 现在流行的w e b 层的框架很多，各有各的优势。作为一个开发架构，它的技术 先进性固然重要，但是由于本文论述的开发架构是一个公司的生产工具，为了让 使用它的人能够快速的掌握和运用，本文采用的w e b 层框架是s t r u t s 。因为s t r u t s 出现很早，已经广泛的运用，基本上做j 2 e e 的开发人员对s t r u t s 都不陌生，这 可以使使用该架构的开发人员对其很快上手。s t r u t s 做为w e b 层框架的代表之一， 可以说是对m v c 模式的最好注解。 3 1 1s t r u t s 框架概述 s t r u t s 是一个开源框架，包含了一系列相互的类、s e r v l c t 和j s p 标记。s t r u t s 框架是基于m v c 模式开发w e b 应用程序的具体应用。使用s t r u t s 框架可以将商业 逻辑、控制和数据显示功能模块区分开来，这样对其中一个模块的改动不会影响 到其它模块。使用这一框架，开发人员可以分别集中开发商业逻辑模块、应用过 程控制模块和数据显示模块，而不用担心这三个模块的耦合问题。 3 1 2s t r u t s 框架的组织结构 s t r u t s 框架是m v c 模式的忠实体现。在s t r u t s 中，包括了客户端浏览器、控 制器、业务逻辑、模型和视图五个组成部分。其组织结构如图3 - 1 所示： 电子科技大学硕士论文 图3 - 1s t r u m 的组织结构图“4 客户端浏览器( c l i e n tb r o w s e r ) ：来自客户端浏览器的每个h t r p 请求创建一 个事件。w e b 容器将用一个h t l w 响应做出回应。 控制器( c o n t r o l l e r ) ：控制器接收来自浏览器的请求，并决定将这个请求发往 何处。就s t r u t s 而言，控制器是以s e r v l e t 实现的一个命令设计模式。可以通过配 置s t r u t s c o n f i g x m l 文件来配置控制器。 业务逻辑( b u s i n e s sl o g i c ) ：s t r u t s 框架本身没有提供模型组件，一般来说， 普通的j a v a 对象、e j b 组件、j a v a b e a n 组件都可以作为s t r u t s 应用程序的模型， 这些模型是由控制器被操作和处理的，它对控制器和视图一无所知。业务逻辑更 新模型的状态，并帮助控制应用程序的流程。就s t r u t s 而言，这是通过作为实际业 务逻辑包装的a c t i o n 类完成的。 模型( m o d e l ) ：模型表示应用程序的状态。a c t i o n f o n nb e a n 在会话级或请求 级表示模型的状态，而不是在持久级。j s p 文件使用j s p 标记读取来自a c t i o n f o r m b e a n 的信息。 视图( v i e w ) ：视图就是一个j s p 文件。其中没有流程逻辑，没有业务逻辑， 也没有模型信息，只有标记。标记是使s t r u t s 有别于其它框架因素之一。 3 1 3s t r u t s 框架中的组件 s 仃u t s 所使用的一些组件如下表3 1 ： 表3 - 1s t r u t s 组件列表 1 4 第三章本架构采用的框架和重要技术 i 垒塑兰塑坐i塑墅鳖型墨堑遣鲞堕墅型塑缝 i 3 1 3 1a c t i o n s e r v l e e 类 在s t r u t s l 1 中缺省采用a c t i o n s c r v l e t 类来充当控制器“4 。如果a c t i o n s c r v l c t 不能满足应用的需求