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产生地客户端文档的信息同步和交换。这个图清 楚地表达了这种对应关系
2.2.1. MVC分析
前端控制组件接收用户发来的任何请求，这个可在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数据交换。
