当前流行的J2EE WEB应用架构分析（一）

1. 架构概述

J2EE体系包括java server pages(JSP) ,java SERVLET, enterprise bean，WEB service等技术。这些技术的出现给电子商务时代的WEB应用程序的开发提供了一个很是有竞争力的选择。怎样把这些技术组合起来造成一个适应项目须要的稳定架构是项目开发过程当中一个很是重要的步骤。完成这个步骤能够造成一个主要里程碑基线。造成这个基线有不少好处：

各类因数初步肯定

为了造成架构基线，架构设计师要对平台（体系）中的技术进行筛选，各类利弊的权衡。每每架构设计师在这个过程当中要阅读大量的技术资料，听取项目组成员的建议，考虑领域专家的需求，考虑赞助商成本（包括开发成本和运行维护成本）限额。一旦架构设计通过评审，这些因数初步地就有了在整个项目过程当中的对项目起多大做用的定位。

定向技术培训

一旦架构师设计的架构获得了批准造成了基线，项目开发和运行所采用的技术基本肯定下来了。众多的项目经理都会对预备项目组成员的技术功底感到担忧；他们须要培训部门提供培训，但就架构师面对的技术海洋，项目经理根本就提不出明确的技术培训需求。怎不可以对体系中全部技术都进行培训吧！有了架构里程碑基线，项目经理能肯定这个项目开发会采用什么技术，这是提出培训需求应该是最精确的。不过在实际项目开发中，技术培训能够在基线肯定以前与架构设计并发进行。

角色分工

有了一个好的架构蓝图，咱们就能准确划分工做。如网页设计，JSP 标签处理类设计，SERVLET 设计，session bean设计，还有各类实现。这些任务在架构蓝图上均可以清晰地标出位置，使得项目组成员能很好地定位本身的任务。一个好的架构蓝图同时也能规范化任务，能很好地把任务划分为几类，在同一类中的任务的工做量和性质相同或类似。这样工做量估计起来有一个很是好的基础。

运行维护

前面说过各个任务在架构图上都有比较好的定位。任何人能借助它很快地熟悉整个项目的运行状况，错误出现时能比较快速地定位错误点。另外，有了清晰的架构图，项目版本管理也有很好的版本树躯干。

扩展性

架构犹如一颗参天大树的躯干，只要躯干根系牢，树干粗，长一些旁支，加一些树叶垂手可得无疑。一样，有一个稳定的经得起考验的架构，增长一两个业务组件是很是快速和容易的。

你们都知道这些好处，一心想造成一个这样的J2EE应用程序架构（就像在windows平台中的MFC）。在这个路程中经历了两个大的阶段：

1.1. 模型1

模型1其实不是一个什么稳定架构，甚至谈不上造成了架构。模型1的基础是JSP文件。它从HTTP的请求中提取参数，调用相应的业务逻辑，处理HTTP会话，最后生成HTTP文档。一系列这样的JSP文件造成一个完整的模型1应用，固然可能会有其余辅助类或文件。早期的ASP 和 PHP 技术就属于这个状况。

总的看来，这个模型的好处是简单，可是它把业务逻辑和表现混在一块，对大应用来讲，这个缺点是使人容忍不了的。

1.2. 模型2

在通过一番实践，并普遍借鉴和总结经验教训以后，J2EE应用程序终于迎来了MVC（模型-视图-控制）模式。MVC模式并非J2EE行业人士标新立异的，因此前面我谈到广发借鉴。MVC的核心就是作到三层甚至多层的松散耦合。这对基于组件的，所覆盖的技术不断膨胀的J2EE体系来讲真是福音和救星。

它在浏览器（本文对客户代理都称浏览器）和JSP或SERVLET之间插入一个控制组件。这个控制组件集中了处理浏览器发过来的HTTP请求的分发逻辑，也就是说，它会根据HTTP请求的URL,输入参数，和目前应用的内部状态，把请求分发给相应的WEB 层的JSP 或SERVLET。另外它也负责选择下一个视图（在J2EE中，JSP,SERVLET会生成回给浏览器的html从而造成视图）。集中的控制组件也有利于安全验证，日志纪录，有时也封装请求数据给下面的WEB tier层。这一套逻辑的实现造成了一个像MFC的应用框架，位置如图：

1.3. 多层应用

下图为J2EE体系中典型的多层应用模型。

Client tier客户层

通常为浏览器或其余应用。客户层广泛地支持HTTP协议，也称客户代理。

WEB tier WEB应用层

在J2EE中，这一层由WEB 容器运行，它包括JSP, SERVLET等WEB部件。

EJB tier 企业组件层

企业组件层由EJB容器运行，支持EJB, JMS, JTA 等服务和技术。

EIS tier 企业信息系统层

企业信息系统包含企业内传统信息系统如财务，CRM等，特色是有数据库系统的支持。

应用框架目前主要集中在WEB层，旨在规范这一层软件的开发。其实企业组件层也能够实现这个模型，但目前主要以设计模式的形式存在。并且有些框架能够扩充，有了企业组件层组件的参与，框架会显得更紧凑，更天然，效率会更高。

2. 候选方案

目前，实现模型2的框架也在不断的涌现，下面列出比较有名的框架。

2.1. Apache Struts

Struts是一个免费的开源的WEB层的应用框架，apache软件基金致力于struts的开发。Struts具是高可配置的性，和有一个不断增加的特性列表。一个前端控制组件，一系列动做类，动做映射，处理XML的实用工具类，服务器端java bean 的自动填充，支持验证的WEB 表单，国际化支持，生成HTML，实现表现逻辑和模版组成了struts的灵魂。

2.1.1. Struts和MVC

模型2的目的和MVC的目的是同样的，因此模型2基本能够和MVC等同起来。下图体现了Struts的运做机理：

 

2.1.1.1. 控制

如图所示，它的主要部件是一个通用的控制组件。这个控制组件提供了处理全部发送到Struts 的HTTP请求的入口点。它截取和分发这些请求到相应的动做类（这些动做类都是Action类的子类）。另外控制组件也负责用相应的请求参数填充 From bean,并传给动做类。动做类实现核心商业逻辑，它能够经过访问java bean 或调用EJB。最后动做类把控制权传给后续的JSP 文件，后者生成视图。全部这些控制逻辑利用一个叫struts-config.xml文件来配置。

2.1.1.2. 模型

模型以一个或几个java bean的形式存在。这些bean分为三种：

Form beans(表单Beans)

它保存了HTTP post请求传来的数据，在Struts里，全部的Form beans都是 ActionFrom 类的子类。

业务逻辑beans

专门用来处理业务逻辑。

系统状态beans

它保存了跨越多个HTTP 请求的单个客户的会话信息，还有系统状态。

2.1.1.3. 视图

控制组件续传HTTP请求给实现了视图的JSP文件。JSP能访问beans 并生成结果文档反馈到客户。Struts提供JSP 标签库： Html，Bean，Logic，Template等来达到这个目的，并有利于分开表现逻辑和程序逻辑。

2.1.2. Struts的细节分析

2.1.2.1. 视图-控制-模型

用户发出一个*.do的HTTP请求，控制组件接收到这个请求后，查找针对这个请求的动做映射，再检查是否曾建立过相应的动做对象（action实例），若是没有则调用actionmapping生成一个动做对象，控制组件会保存这个动做对象供之后使用。接着调用actionmapping的方法获得actionForm对象。以后把actionForm做为参数传给动做对象的perform方法，这个方法结束以后会返回给控制组件一个 actionforward对象。控制组件接着从这个对象中获取下一个视图的路径和重定向属性。若是为重定向则调用HTTPSERVLETREPONSE的方法来显示下一个视图，不然相继调用requestdispatcher, SERVLETcontext的方法续传HTTP请求到下一个视图。

当动做对象运行perform方法时，可能出现错误信息。动做对象能够保存这些错误信息到一个error对象中，接着调用自身的saveerrors方法把这个错误保存到request对象的属性中。接着动做对象调用actionmapping对象的getInput方法从动做映射中获取input参数，也就是产生输入的视图，并以这个input为参数生成一个actionforward对象返回。这个input参数的JSP中通常有HTTP:errors定制标签读取这些错误信息并显示在页面上。

 

2.1.2.2. 模型到视图

模型到视图指视图在显示以前装载系统数据到视图的过程。系统数据通常为模型内java bean的信息。示意图表现了由控制组件forward过来的有html:form定制标签的JSP 的处理逻辑。

html:form定制标签处理对象从application scope（经过查询SERVLETCONTEXT对象的属性来实现）获取先前由控制组件actionSERVLET放在那里的动做映射等对象，由html:form 的action属性查得actionform名字、类型和范围等信息，在相应的范围内查找actionform，若是有则利用它的信息填充html form表单[实际填充动做在嵌套的html:text等定制标签的处理对象中]。不然在相应范围内建立一个actionform 对象。