J2EE企业架构策略分析

资源类型:pdf 资源大小:100.00KB 文档分类:工业技术 上传者:盛小芳
关闭

文档信息

【作者】 李拴林  王昭顺 

【关键词】企业架构 Web服务 J2EE 

【出版日期】2005-04-18

【摘要】通过把软件分为表示层、业务层、持久层,并在每一个层次上选用合理的技术方案与设计模式进行精心架构,就能设计出结构清晰,易于维护,运行高效的软件系统。

【刊名】情报杂志

全文阅读

在对复杂的软件系统进行划分时 ,分层是软件设计者使用最多的方法。分层也是J2EE最具特色的一面 ,合理地使用分层技术可以将层次间的依赖性减到最少 ,还有利于标准化工作。从最一般的角度讲 ,可分为Web层 (表示层 )、业务层、持久层。1 软件架构的基本原则 1.1 可维护性 软件往往长期使用 ,必须有良好的架构增强其可维护性。现在的软件实践表明花费在维护上的费用远远超过开发费用 ,而可维护性的好坏关键取决于系统的架构设计。  1.2 重用性 重用性非常重要 ,它不仅可以减少开发中的重复劳动 ,更为重要的是把一些使用频率较高的逻辑进行通用化设计 ,使得结构更加清晰 ,可维护性更好。  1.3 扩展性 用户的需求经常变化 ,构建一个可重用的框架 ,必须考虑扩展性。底层提供的业务方法应当齐备 ,力求做到上层的扩展不会抖动底层。 1.4 简单实用 开发人员的水平层次不齐 ,让层次高的人设计可复用的底层架构 ,给前端开发人员留一个简单适用的API将会大大提高他们的开发效率。 1.5 低耦合性 分层架构的主要好处之一就是低耦合性 ,使得某一层的变化不影响或很少影响其他层 ,这样不仅宜于扩展和维护 ,而且可以并行开发。  1.6 高效性 分层架构的系统就像一个倒着的金字塔 ,底层核心代码虽少 ,但复用性很高 ,支撑着纷繁复杂的前端代码 ,所以必须注意效率问题。2 Web层 (表示层 )架构策略 2 .1 Web层的主要功能 Web层主要是接受用户的请求 ,并把业务层的处理结果返回给用户 ,提供控制器衔接业务层 ,管理从业务层抛回到表示层的异常 ,集合数据使其能在一个视图中显示。但一定要避免绕过业务层和数据库直接打交道。此外还要注意和应用相关的业务逻辑 ,事务管理切忌放入Web层。  2 .2 Web层的架构方式分析2 .2 .1 采用成熟的J2EEWebFramework架构Web层是一种传统稳妥的做法。这些Framework基本上都是基于MVC模式的Model2实现 ,避免了以页面为中心的Modle1方案的大部分缺点 ,并且提供了对主流应用服务器的支持。采用他们来架构Web层是比较合理的选择 ,因为如果直接采用Modle1方案虽然表面上简单 ,但最终会导致页面的混乱 ,到最后变得难以维护 ,如果自己去打造一个Framework则难度较大 ,其稳定性、健壮性、可扩展性不一定能够保证 ,而且延长项目的开发周期 ,增大项目风险。基于J2EE平台的Framework很多 ,对于大多数的项目 ,完全可以找出适合自己的。下面对主要的Framework进行分析。主要的J2EEFramework有Struts,Turbine,Tapestry ,JavaServ erFaces等。Struts是一个基于Servlet倾向于JSP视图技术的WebFramework ,它以简单易用 ,完全遵循J2EE规范而为人称颂。具有清晰的MVC角色定义、统一的视图导航管理 ,强大的JSP标签库。然而Struts是一个单纯的WebFramework,功能相对单薄。它具有表示层 (JSP)和控制层用来实现MVC结构 ,但它没有很重要的服务层和数据层。这就意味着你要是用它就必须为它选择服务层解决方案 (EJB技术中的会话Bean等 ,详见第二部分业务层架构策略 )与数据层的解决方案 (EJB技术中的实体Bean ,JDO等 ,详见第三部分持久层架构策略 )。此外Struts能与JSP完美结合 ,这对准备使用JSP视图技术的项目来讲非常合适 ,但Struts在视图技术的可替换性方面表现得不能令人满意。Turbine是一个基于Servlet的Web应用的完全解决方案。它不仅有表示层 (Velocity和JSP)与控制层 ,而且有数据层 (利用XML技术将关系性数据库和Java对象进行映射 )和服务层 (提供了大量的Web系统服务功能 )。它与Struts相比要复杂一些 ,功能更强 ,但Turbine并不完全符合J2EE规范。所以如果你的系统要求符合J2EE规范 ,建议使用Struts而不是Turbine。Tapestry是一个基于Servlet的WebFramework,它抛弃了JSP视图技术 ,使用组件对象模型来创建具有高度动态性和交互性的Web页面。Tapestry对Servlet做了完善的封装 ,基本上以组件驱动的方式完成用户请求和页面的生成。JavaServerFaces(JSF)是一个基于Servlet以J2EE标准的高姿态出现的WebFramework。是对J2EE规范的一个重大补充。JSF使得您能够轻松而方便地设计开发基于JAVA技术的Web应用 ,同时所开发出来的应用也会非常易于维护、重用和扩展。JAVA/J2EE业界普遍认为JSF将会在不久的未来取代目前业界非常流行的ApacheStruts框架。2 .2 .2 采用Portlet技术实现。如果您的项目是门户系统 ,则应该考虑Portlet技术。Portlet作为一种为门户系统量身定制的技术 ,在灵活性和组件的复用方面更胜一筹。IBM ,BEA等公司都推出了Portlet容器。JetSpeed是开源的Portlet容器。如果您想独立于Portlet容器厂商进行门户系统的开发 ,则可以在JetSpeed的基础上进行架构。2 0 0 3年 10月 7日 ,JavaCommunityProcess(JCP)发布了JSR16 8:PortletSpecification 1.0的最终版本。这样使用一种API就能编写Portlet应用 ,而且能运行在所有符合规范的Portal服务器上的。所以如果是门户系统 ,采用Portlet技术是可取的选择。3 业务层架构策略业务层完成业务逻辑的处理 ,是架构中非常关键的一层 ,但从编码的角度看 ,这一层经常被人忽略。常常能发现本该属于业务层的代码分散在表示层或持久层。这是一种错误的架构方式 ,因为这种紧耦合的应用和代码随着时间的推移、系统的扩大 ,将变得难以维护。 3.1 业务层设计模式的选用分析 模式的种类繁多 ,也有人批判过渡设计。但如果使用J2EE架构业务层 ,还是要注意设计模式的使用。只要处理适当 ,它们不仅会使系统的结构更加合理 ,而且还会提高性能。下面将概要性地分析在业务层应该使用的四种主要设计模式。3.1.1 工厂模式。工厂模式是应用最广模式之一 ,在应用程序中往往有很多对象的创建和销毁 ,所以大量地使用了该模式。工厂模式专门负责将大量有共同接口的类实例化 ,通常与单例模式、多例模式结合使用。3.1.2 业务代表 (也称代理模式 )。在表示层和业务层的交互方面应该使用该模式。如果不采用代理模式进行直接的交互会把业务层编程接口 (API)的底层实现细节暴露给表示层 ,这样表示层组件对业务层的变化是敏感的 :当业务服务的实现变化时 ,表示层的部分代码要同时更改 ,而且如果表示层组件直接使用底层的API,又没有客户端缓冲机制或汇聚服务时 ,将会出现更为糟糕的情况———加重网络负担。但如果使用业务代表可以向表示层常见服务请求提供缓冲机制和更好的性能。3.1.3 会话外观。企业Bean封装了业务逻辑和业务数据 ,并把它们的接口暴露给客户端 ,因而分布式服务的复杂性也暴露给客户层。如果采用会话外观模式把会话Bean用作外观 ,以封装参与工作流的业务对象之间交互的复杂性 ,这样就能向客户端提供统一的粗粒度服务访问层。在提高了性能、减少了细粒度方法的同时还可以进行集中的安全管理 ,集中化事务控制。此外向客户端提供的远程接口也会减少。3.1.4 值对象。J2EE应用程序把服务器端业务组件通常实现为会话bean和实体bean。业务组件的一些方法可以向客户端返回数据。但是客户端需要多次调用业务对象的get方法直到获得所有的属性值 ,对业务方法的调用一般是远程的 ,这样多次调用会使系统的性能大幅度下降。如果使用值对象来封装业务数据 ,客户端就可以只对企业bean作单个远程方法的调用来请求值对象 ,而不必启动多个远程调用来获取属性值。  3.2 技术方案的选用分析 架构业务层采用何种技术方案首先看你的系统是否采用分布式架构 ,如果不采用分布式架构 ,则采用一些经典模式使用普通Java对象设计即可 ,但一定要注意尽可能地降低与Web层和持久层的耦合度。如果采用的是分布式架构 ,传统的方式是使用以RMI/IIOP为基础的EJB(会话bean)来实现远程访问。随着Web服务标准的出台 ,采用Web服务架构分布式系统也是一种可选的方案 ,但Web服务主要是用来进行系统集成的 ,如果系统都采用J2EE技术 ,则不宜采用Web服务。这是因为Web服务虽然给开发和维护带来了方便 ,但对分布式组件的高级性能 (事务处理 ,安全特性等 )支持不够 ,而且XML的字符流与传统的二进制流相比 ,在处理的信息量上可以相差一个数量级以上 ,再加上编码 /解码的过程 ,差距会更大。4 持久层架构策略持久层负责数据的保存、修改、删除、查询 ,将直接与数据库交互。其架构的实现方案可以是 :采用EJB技术中的实体Bean实现 ;JDO技术 ;第三方O/R映射产品 ;构建定制的持久性框架 ;原始的JDBC解决方案。下面先讲一下数据访问对象 ,然后再详细分析各个实现方案。  4 .1 使用数据访问对象进行统一设计 在进行持久层的设计时 ,会注意到 ,根据数据源不同 ,数据访问也不同 ;根据存储的类型 (关系数据库 ,面向对象数据库 ,纯文件等 )和供应商实现的不同 ,持久性存储的访问也不同。所以在设计持久层时最好使用数据访问对象 (DAO)把接口统一化。使用数据访问对象 (DAO)来抽象和封装所有对数剧源的访问 ,这样DAO管理着与数据源的连接更加便于检索和存储数据。DAO实现了用来操作数据源的访问机制。数据源可以是诸如RDBMS的持久性存储、类似于B2B交换的外部服务、类似于LDAP数据库的资料库 ,或者通过CORBA和IIOP协议进行访问的业务服务。依赖于DAO的业务组件为其客户端使用DAO提供了更简单的接口。DAO完全向客户端隐藏了数据源实现细节。由于当底层数据源实现变化时 ,DAO向客户端提供的接口不会变化 ,所以该模式允许DAO调整到不同的存储模式 ,而不会影响其客户端或者业务组件。从实质上讲 ,DAO充当着组件和数据源之间的适配器。  4 .2 持久层实现方案分析 在持久层的架构方面 ,J2EE提供了多种技术方案 ,然而根据项目的实际需求进行最终的决定是架构师关心的问题。4 .2 .1 实体Bean。实体Bean作为J2EE规范的一部分 ,是架构J2EE项目持久层的一个可选技术方案。然而自从它诞生以来就陷入了人们的激烈争论之中。有人说它是性能杀手 ,有人说在恰当的环境中使用是一个好的决策。下面将从正反两个方面客观地进行分析。实体Bean提供了一个标准 ,可以用来创建具有透明的持久性、由容器管理的、分布式的、安全的、具有事务性的构件。尽管当我们在会话外观的幕后使用实体Bean时 ,它的许多好处都是多余的 ,但是实体Bean实际所能提供的好处 (一个标准的、透明的持久性管理、容器管理的持久性 )有时是很显著的。a.可移植性好。实体Bean被保证对于任何J2EE应用服务器都是可部署的 ,但如果使用第三方的持久性引擎开发普通Java对象 (POJO)只能运行在支持特有的O/R映像工具的应用服务器上。b.在运行环境范围之外的高级O/R映像。EJB的CMP机制本质上是一个标准的、在运行环境范围之外的持久性框架。这样当我们使用CMP实体Bean时 ,就不需要在第三方的O/R映像产品上花费金钱且慢慢学习。减少在一个软件系统中的可移动部件的数量 ,可以明显地减轻系统维护的负担。当然实体Bean的缺点在于重量级的运行时基础架构 ,造成性能上的大量耗损。4 .2 .2 第三方O/R映像产品。使用可以插入到J2EE应用服务器的第三方的O/R映像工具是最常用的替代实体Bean的方法。其优点是这些工具可以透明地将对象持久化 ,而不需

1 2

问答

我要提问
关闭