J2EE架构中WEB层实现策略

                                      Implementary Strategy of WEB Layer in J2EE Frame

DU Xue-ping

(Sichuan TOP Vocational Institute of Information Technology )

 

Abstract ：Currently we have abundance choice in technique and service of WEB layer in J2EE Multi-layer frame, but how to choose suitable technique to form stabilization frame. The paper combine the MVC design pattern to choose the most effective implementary strategy via analysing and comparing the pivotal technique of WEB layer, On the basis of which it can self-design and optimize to find the ideal design frame of WEB layer.

Key Word：MVC ;design pattern;J2EE platform; WEB

 

J2EE作为当今的主流开发平台之一,包括Java Server Pages(JSP)、Java SERVLET、 Enterprise Java Bean(EJB)、WEB Service等技术^[1][2][3]，为WEB应用提供了丰富的技术支持和服务选择。然而怎样把这些技术组合起来形成一个适应项目需要的稳定架构是项目开发过程中一个非常重要的步骤，这就给J2EE项目的实现带来了许多的困难和挑战。清晰合理的架构设计对于构建具有伸缩性的企业级应用无疑是至关重要的。在J2EE的参考模型多使用多层架构设计：WEB层、业务服务层和持久层。每一层都有丰富的技术和选择，本文主要针对当前WEB层的主要技术进行讨论，并根据实践提出实现策略并进行优化。

1 WEB层实现的基本理论

1.1 WEB层实现原则

对于良好的 J2EE应用，其WEB层的实现应遵循以下的原则^[4]：1）清晰性原则：WEB层的清晰意味着表现逻辑与控制流和业务对象的调用相分离。2）精炼性原则：WEB层的精炼性具有两层含义，首先WEB层应当负责将用户输入的处理结果转变成WEB界面的显示内容，除此之外，不应当承担更多的职责；同时WEB层应当只包含特定WEB的页面控制逻辑，而不应包含任何业务逻辑。3）分工性原则：WEB层的分工性意味着能为企业级WEB应用有效分离JAVA开发者和标记语言开发者的角色。

1.2基于MVC应用框架的WEB层实现策略

    MVC（model-view-controller）设计模式^[5][6]将WEB层组件分为三类对象：数据模型对象(model)、显示模型的视图（view）对象和响应用户输入，处理业务流程的控制器（controller）对象。模型封装了主要数据和完成业务处理，不关心显示的形式和内容，而视图层只包含用来显示的数据。控制器负责建立模型与视图间的联接。

 MVC是分离表示层逻辑和业务层逻辑，提供WEB界面组件和业务对象间的清晰交互的理想模式，因此，对于企业级的WEB应用而言，使用优秀的MVC应用框架可以很好地满足WEB层的实现原则，简化应用代码，是我们的首选策略。 

 

图1 MVC框架的数据流

2 WEB层的实现策略

2.1应用框架技术的比较分析

当前支持 J2EE标准的MVC应用框架很多，比如：JATO、Struts webwork  maverick   javaserverfaces tapestry以及turbine等^[7]。他们具有以下共同特性：1）使用一个通用的控制器servlet 作为整个应用的入口点，并在标准的WEB部署描述符文件“web.xml”中将请求URL全部映射到该控制器上，使用标准的或框架特定的JSP标签库来分离表现逻辑和业务逻辑。2）提供数据绑定功能，将http请求参数透明地更新到java bean (通常是命令对象) 的属性中去。3）在WEB层提供对表单数据的语法验证功能，并通过xml配置文件实现验证的参数化。4）提供对本地的支持。

它们在遵循以上这些原则的同时又具有各自的特色：

1） Struts 是最具有代表性的采用”拉”（pull）的方式的开源MVC应用框架。具有清晰的MVC角色定义、统一的视图导航管理以及强大的JSP标签库支持，在当今的J2EE WEB应用开发实践中使用最广泛。

2） Java server faces (JSF)是以WEB用户界面为侧重点的MVC应用框架，目的是通过对视图层的组件化处理，进一步丰富WEB用户界面的表现形式，并提供可视化及工具支持，JSF的一大特色是将组件类与组件的表现技术分离，从而不把开发者局限在某种特定的脚本技术或标记语言上，尽管JSF提供了一个基于HTML的组件标签库作为参考实现，开发者仍可以开发自己的组件标签库来表示定制组件。

3）  Tapestry则是采用“推”（push）的方式的MVC应用框架的代表，符合传统的MVC开发理念。它以组件驱动的方式完成用户请求的处理和页面的生成，是面向对象的开源WEB应用框架。该设计借鉴了Turibine的某些长处，同时通过对无状态组件的管理和对页面基于html标记属性开发的独特处理，提供了更优化的性能以及程序开发与页面设计的完美分离，体现出有别于其他框架的突出特点。

4） Maverick是一个轻量的开源MVC应用框架，它只关注MVC工作流的实现，而不提供诸如标签库之类的表示层的支持。内置的dom化功能（将java bean模型透明地转换成xml节点）是它又一鲜明的特点。

5） JATO是SUN推荐的MVC框架，其特点是综合了多种J2EE设计模式（如：前端控制器模式、服务/工作者模式、组合视图模式以及业务代理模式等）来扩展MVC，并提供了可扩展的基本实现和可视化的构造工具支持。

6） WEBwork是另一个开源的MVC应用框架，它基于命令设计模式，力图将用户动作建模为不依赖于servlet API的命令对象,因而其基本的工作流设计更接近于Maverick 而不是Struts，此外，WEBWork不仅提供自己的JSP标签库还支持Velocity模版引擎。

7） Turbine提供了一套完整的WEB应用解决方案，页面逻辑的面向对象的表述，“可插拔”的后台服务框架设计，完善的用户权限控制及缓存功能是其优势所在。

通过比较上述 MVC应用框架的特点，因为Struts Tapestry是最具有代表性且已被广泛验证的成熟框架，用Struts或Tapestry作为WEB层的支撑框架是较佳的选择，而其它框架则或多或少存在某方面的缺陷。比如：JSF和Maverick只侧重于WEB层实现的某一方面，webwork的核心组件（代表用户动作的命令对象）不具备可重用性和线程安全性，JATO的J2EE设计模式组合显得过于简单化，缺乏细节的磨合；Turbine尽管功能强大，“自动化”程度高，但它却有许多独立于J2EE标准的设计，在它上面构件应用会造成对特定框架的依赖，灵活性不高。

2.2 自主的J2EE MVC应用框架设计

通常情况下，成熟的开源 MVC应用框架可以满足大多数J2EE项目的要求，不过，即使是最受欢迎的Struts 框架，依然存在值得改进的设计弱点，比如：

作为 Struts请求处理模型核心的ActionForm对象依赖于Servlet API，这就使它的验证逻辑与WEB层紧密耦合，从而很难在业务层重用。Struts过于面向JSP视图技术，尽管它并不排斥使用其它模板技术的可能性，但总的来说，Struts 在视图技术的可替换性方面表现不佳。Struts的设计完全基于具体类，是我们很难定制Struts的行为。而且产品化的要求也可能促使我们在特定情况下设计自己的MVC应用框架。

不过要完成“理想”的框架设计是一项复杂的工作，借鉴其它 MVC应用框架的长处无疑是一条便捷之路。本文结合Struts和Maverick工作的特点，实现一个“拉”方式的框架设计，图2中给出了该框架基本MVC控制流顺序图。

                                             图2 MVC控制流顺序图

该框架主要采用了 mapping-forward 机制，由RequestProcesser(请求处理器)对象来代理MVC中控制器角色的基本职责，即调用业务层对象的方法来执行业务逻辑，并根据调用结果及会话状态创建视图显示的模型数据。同时使用“命名视图”策略来解耦控制器与视图实现，该设计面向接口，具体执行步骤如下：

1） 控制器 Servlet接收http请求后，就要求handlerMapping接口的实现返回一个请求处理器来处理该请求。缺省的映射机制是采用基于URL的实现，其它更加复杂的实现也容易定制。

2）控制器 Servlet调用请求处理器的handleRequest()方法，该方法返回一个ModelAndView类型的对象，该对象类似于Maverick中的“单模型”对象。包含需要显示的视图名称以及相应的模型数据。

3）控制器 Servlet根据请求处理器返回的视图名称，调用ViewResolver(视图解析器)对象来获得对View对象的引用。视图解析器对象根据本地化的支持，根据Locale返回不同的视图实例。

4）控制器 Servlet调用视图对象的render()方法来生成内容。

接下来，除了要对上述工作流的角色作进一步的细化，比如：为请求处理器提供不同的实现——直接处理请求参数的简单处理器、支持复杂参数绑定功能的“表单”处理器以及映射到方法的多动作处理器等。一个优秀的 MVC框架设计还应体现出框架的可扩展性以及视图的可替换性，这样贯穿整个框架的面向接口的设计以及“纯”模型的概念就显得尤为重要。纯模型是指模型仅代表完整业务操作结果的哑存储，本身不执行任何数据访问，也不接触任何业务对象。它不对Servlet API或WEB应用框架产生依赖可以在WEB层外使用，是严格意义上的JAVA BEAN。在“纯”模型的基础上结合面向接口的设计，不仅可以保证框架的松散耦合，而且很方便地实现了视图的可替换性，该可替换性是表示：基于相同的模型和视图技术可进行视图替换而不必修改模型和控制器代码，这实现起来比较容易。同时采用Template()方法提供不同的内部实现来完成，对于基于XSLT的实现，相应地要对“纯”模型作DOM处理。

2.3优化策略

无论采用那种 MVC框架，WEB层会话管理的方式都会给应用的性能和伸缩性带来很大的影响。在WEB客户端维护用户状态会受到安全性和应用方面的许多限制；基于服务器的的会话管理则能简化应用编码、提高性能和安全性，通常是最佳选择。

在服务器集群环境中需要复制会话状态以降低服务器的亲和性和保证失效性恢复，由于潜在的状态复制开销，一般采纳以下优化原则：

1）避免不必要的创建会话状态：使用JSP视图技术时，为了避免JSP访问和操纵会话状态，我们使用以下脚本来阻止JSP缺省的会话创建功能<%@page session =”false ”%> 。必要时我们可以在模型中包含所需的会话状态数据，这样既可以允许视图访问这些数据，又不破坏视图技术的可替换性。

 2）使服务器端会话状态对象所维护的数据量最少：保存不必要的数据将减缓复制过程，浪费服务器资源，如果内存中保存了太多的会话数据，服务器就需要把会话数据保存到持久性存储中，这样当钝化的会话状态对象被重新活化时，会带来极大的性能开销。

3）使用细粒度的会话状态对象，而不是粗粒度对象：由于在集群中只有发生状态改变的会话对象才被复制，因此在可能的情况下，应当尽量将粗粒度的会话对象分解为多个细粒度对象。此外在会话数据发生改变时，还应重建httpsession的会话属性，这将有助于某些流行的J2EE服务器识别会话对象的状态改变，确保正确的复制。

3结语

随着开发 WEB应用服务程序的增加，运用J2EE开发平台进行开发中技术选择和优化是一个主要方面，通过比较和实践选择满足自己所需要的应用框架，并对框架进行自主的产品化设计，使其在满足通用性和可替换性的同时更能满足你的某些需要。文中通过组合技术给出WEB层一种框架，为WEB层其它技术组合和J2EE的业务服务层和持久层提供一个参考模型。

 

参考文献：

[1] http://java.sun.com:java技术规范

[2] http://www-900.ibm.com/developWorks/cn:Java技术专区

[3] J2EE的MVC体系结构及其设计模式， http://www.csai.cn/: 2004/08/30：中国系统分析员

[4] 飞思科技产品研发中心，JSP应用开发详解.北京：电子工业出版社，2004

[5] 设计模式，作者Erich Gamma 等，ISBN 7-111-07575-7, 机械工业出版社 2000.9

[6] Core J2EE Patterns, 作者Deepak Alurm 等, ISBN 0-13-064884-1, Sun Microsystems Inc, 2001年

[7] 周警伟，MVC在Web系统中的模式与应用，UML软件工程组织

 

 

作者简介：

杜雪平，讲师，四川托普信息技术职业学院计算机科学与技术系教师