当前流行的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 对象。

2.1.3. 优缺点

优势：

一些开发商开始采用并推广这个框架

做为开源项目，有不少先进的实现思想

对大型的应用支持的较好

有集中的网页导航定义

缺点：

不是业届标准

对开发工具的支持不够

复杂的taglib，须要比较长的时间来掌握

html form 和 actionform的搭配比较封闭，但这也是它的精华所在。

修改建议 把actionform属性的设置器和访问器修改为读取或生成xml文档的方法，而后 html form和actionform之间用xml文档进行数据交换，使之松散耦合，适应数据结构易变化的应用。

2.2. JATO

JATO应用程序框架是iPlanet 应用程序框架的旧名。它是一个成熟的、强大的，基于J2EE标准的面向于开发WEB应用程序的应用框架。结合了显示字段、应用程序事件、组件层次和以页面为中心的开发方法、以及MVC和服务到工做者service-to-workers的设计模式等概念。JATO可适用于中、大、超大规模的WEB应用。可是它也不是一个企业层的应用框架，也就是说它不会直接提供建立EJB, WEB services等企业层组件的方法，但用它能够构造出访问企业层组件的客户应用。

这个框架功能主要有三部分组成：

iPlanet应用框架核心；

iPlanet应用框架组件；

iPlanet应用框架扩展。

应用框架核心定义了基本接口、对象协议、简单组件，以及iPlanet应用框架程序的最小核心。包括视图简单组件、模型简单组件、请求分发组件和可重用命令对象。iPlanet应用框架组件利用框架核心定义的基本接口、协议和组件向开发者提供高层的重用组件，这些组件既有与特定视觉效果无关的水平组件，同时也有适应特定实用环境、提升可用性而特地提供的垂直型组件。框架扩展实现了用框架相容的方法访问非J2EE环境的方法。一般状况下，扩展被框架应用程序用来无缝访问J2EE容器特定功能。JATO平台栈图很清楚地表达了这个状况。

JATO最大的威力在：对于快速开发用户，你能利用框架组件和扩展提升生产率，对于要求更大灵活性的用户，你能实现框架核心提供的接口来保持应用的框架兼容性。

此图表示实现一个JATO应用程序，能够简单地实现控制组件module1Servlet，视图组件ListCustomersViewBean和模型组件CustomersModuleImpl，以及一个给客户代理显示界面的ListCustomers.jsp文件。并清楚地代表这些组件与JATO框架组件的继承关系。

JATO标签库提供了VIEW对象与JSP文件的接口。库中标签处理程序负责实现VIEW对象和JSP产生地客户端文档的信息同步和交换。这个图清楚地表达了这种对应关系

前端控制组件接收用户发来的任何请求，这个可在WEB.xml中指定 请求分发组件负责视图管理和导航，和前端控制组件封装在ApplicationSERVLETBase一块儿实现。应用程序开发者须要为每个子系统（人力资源，财务，CRM等）实现一个此类的继承。

请求分发组件分发请求给工做者，工做者实现了command接口。应用开发者能够实现这个接口。JATO提供了一个缺省实现：DefaultRequestHandingCommand，这个实现会把请求传给视图组件的特定事件。

组合视图是指视图组件在显示给用户时的层次关系：根视图是一个ViewBean类的对象 字段是一个DisplayField类的对象，容器视图是一个ContainerView类的对象。视图组件类的层次关系以下图：

2.2.2. 优缺点分析

优势：

这种框架的适应范围大，即提供了底层接口，也有当即可用的组件

具备与客户端RAD开发工具类似的开发概念如页为中心（等同于VB的FORM），事件处理等.

对大型的应用支持较好

缺点：

不是业届标准

目前尚未开发工具的支持（然JATO已经为工具支持作好了准备）

没有定义网页导航，开发者在视图中本身指定具体的导航URL

修改建议

把众多的VIEW/MODEL对应修改为xml文档传递数据，加上集中的网页导航定义

2.3. JSF(JavaServer Faces)

JSF是一个包括SUN在内的专家组正在定义的开发WEB应用用户界面的框架，JSF 技术包括：

一组API，它实现UI了组件，管理组件的状态，处理事件，输入校验，定义页面导航，支持国际化和访问；

一个JSP定制标签库实现与JSP的接口。

JSF很是简单，是一个定义良好的编程模型。利用这个技术，开发者经过在页面内组合可重用的UI组件，在把这些组件和应用的数据源相连，路由客户产生的事件到服务器端的事件处理器进行编程。JSP处理了全部幕后的复杂工做，使得开发者把关注重点放在应用代码上。

2.3.1. STRUTS、JATO和JSF比较

它们之间有部分重叠，但重点不同。

STRUTS和JATO都提供了一个MVC式的应用模型，而JSF只在用户界面上提供编程接口。这意味着前二者涉及的范围比后者广。JSF能够成为前二者在UI开发的部分。

JSF的规范的发布版将在 2002年末发布，实现可能要比这个时间晚些。另外将会有工具支持这个框架的应用开发。

2.4. WAF

WAF是WEB APPLICATION FRAMWORK的简称，是SUN蓝皮书例子程序中提出的应用框架。它实现了 MVC和其余良好的设计模式。

2.4.1. 细节分析

2.4.2. 视图-控制-模型

如图所示，开发人员编写的两个xml配置文件定义了WAF的运做参数。Screendefinition.xml定义了一系列的屏幕(screen)。Mapping.xml则定义了某个动做以后应该显示的屏幕，但没有指定屏幕到哪里拿数据。

用户发出一个HTTP请求（*.screen），由TemplateSERVLET屏幕前端控制组件接收，它提取请求信息，设置request对象CurrentScreen属性，再把请求发到模版JSP。模版JSP收到请求后，JSP中的Template标签察看这个当前屏幕，并从屏幕定义文件（Screendefinition.xml）中获取这个屏幕的具体参数，再生成html返回给客户。

假设返回给客户的html中包括了html表单，用户在输入必定数据以后提交，发出一个HTTP请求（*.do）。这个请求被MainSERVLET接收，它提取请求信息，察看动做映射文件（mapping.xml），设置处理这个请求的动做对象(HTTPAction对象)，交给requestprosessor对象处理。Requestprosessor对象调用动做对象完成任务，若是须要进一步处理，requestprosessor对象会调用WEBclientcontroler对象的事件处理机制。MainSERVLET在处理完请求以后，从屏幕流管理对象那里获得下一个屏幕，并把请求传给这个屏幕的JSP文件。

值得一提的是WEBclientcontroler事件处理机制最终把HTTP请求的数据传到了EJBAction对象那里处理。这样HTTPAction对象和EJBAction对象造成了两级处理机制，前一级与request对象紧密相关，把数据封装起来造成一个Event对象，再传给了EJBAction对象，后者与Request对象无关。这个方式能够造成一个session级别的数据处理机制。下图显示了这个方法。HTTPAction1对象处理一个请求，并把数据放到一个状态SessionBean内，HTTPAction2也如此，当HTTPAction3接收到HTTP请求以后，把控制传给EJBAction, 后者获取状态SessionBean数据，处理请求，成功后清控状态SessionBean的内容。这个机制很是适应多个输入页面才能知足一个业务的输入数据的状况（好比购物车）。

2.4.3. 优缺点分析

优势

屏幕导航定义明确

为框架的扩展提供了一个空间

缺点

源码比较乱，稳定性和可靠性没人验证。

只是一个框架躯干，没有正式的model层，视图的概念不强

没有模型到视图的定义

修改意见

只有一个框架躯干，正为实现本身的应用框架提供了灵活性。没有僵化的视图概念，提供了在网页输入到模型的扩充接口，好比插入XML数据交换。