Java Web Framework综述

0.简介
本文介绍Java Web Framework的基本工作原理，和一些常用的开源Web MVC Framework(Struts, Web Work, Tapestry, Echo, JSF, Maverick, Spring MVC, Turbine, Cocoon, Barracuda)。

Web开发的最重要的基本功是HTTP；Java Web开发的最重要的基本功是Servlet Specification。HTTP和Servlet Specification对于Web Server和Web Framework的开发实现来说，是至关重要的协议规范。

应用和剖析开源Web Framework，既有助于深入掌握HTTP & Servlet Specification, 也有助于了解一些现代的B/S Web框架设计思想，如MVC，事件处理机制，页面组件，IoC，AOP等。在这个现代化的大潮中，即使Servlet规范本身也不能免俗，不断引入Filter、Listener等现代框架设计模式。同是Sun公司出品的JSF更是如此。

关于MVC模型、项目简介、配置文件、入门示例等基础知识，网上已经有大量的重复资料信息，本文不再赘述。

文中会提到一些相关的开源项目，和一些编程思想，如有需要，可以用相关的关键字在网上搜索，获取基本的背景知识。

本文力图言简意赅，突出重点。着重描述其他资料没有提到、或很少提到的较重要内容，如运行原理、主流用法，相关知识，关键特性等。

1. Java Web程序工作原理
Tomcat的Server.xml文件中定义了网络请求路径到主机本地文件路径的映射。比如，<context path="/yourapp" docBase="yourapp_dir/webapp"/>



我们来看一下，一个HTTP Request-Response Cycle的处理过程。

HTTP Request URL一般分为三段：host, context, path。

如http://yourhost/yourapp/en/index.html这个URL，分为host=yourhost, context=yourapp, path=en/index.html三段。其中，Context部分由request.getContext()获得，path部分由request.getServletPath()获得（返回结果是“/en/index.html”）。

yourhost主机上运行的Tomcat Web Server接收到这个URL，根据Context定义，把yourapp这个网络路径映射为yourapp_dir/webapp，并在此目录下定位en/index.html这个文件，返回到客户端。



如果我们这个URL更换为http://yourhost/yourapp/en/index.jsp，这个时候Tomcat会试图把yourapp_dir/webapp/en/index.jsp文件编译成Servlet，并调用运行这个Servlet。

我们再把这个URL更换为http://yourhost/yourapp/en/index.do。

注意，戏剧化的事情就发生在这个时候，Servlet规范中最重要的类RequestDispatcher登场了。RequestDispatcher根据WEB-INF/web.xml配置文件的定义，调用对应的Servlet来处理en/index.do这个路径。

假设web.xml里面有这样的定义。

<servlet>

  <servlet-name>DispatchServlet</servlet-name>

  <servlet-class>yourapp.DispatchServlet</servlet-class>

</servlet>

<servlet-mapping>

  <servlet-name>DispatchServlet</servlet-name>

  <url-pattern>*.do</url-pattern>

</servlet-mapping>

那么，RequestDispatcher会调用yourapp.DispatchServlet类处理这个路径。

如果web.xml没有定义对应en/index.do这个路径的Servlet，那么Tomcat返回“您请求的资源不存在”。

RequestDispatcher用于Web Server中，也可以用于应用程序中进行处理转向，资源定位。比如，我们在处理en/index.do的代码中调用，

request.getRequestDispatcher(“cn/index.jsp”).forward(request, response), 就可以转交另外的资源cn/index.jsp来处理。



几乎所有的Web Framework都需要定义自己的Dispatch作用的Servlet，并调用RequestDispatcher进行转向处理。

阅读Web Framework源代码，有两条主要线索，(1)根据web.xml找到对应的Servlet类；(2)搜索包含“RequestDispatcher”词的代码文件。



我们看到，request, response 这两个参数，被RequestDispatcher在各种Servlet之间传来传去（JSP也是Servlet）。所以，request的setAttribute()和getAttribute()方法是Servlet之间传送数据的主要方式。

在MVC结构中，一般的处理流程如下：

处理HTTP Request的基本单位一般称为Action，是一个比Servlet轻量得多的接口定义，通常只有一两个方法，如execute(perform), validate等。

我们知道，URL->Servlet映射，定义在Web.xml配置文件里，但MVC框架通常会有另外一个定义URL-> Action映射的配置文件。

入口Dispatcher Servlet根据URL -> Action的映射关系，把请求转发给Action。

Action获得输入参数，调用商业逻辑，并把结果数据和View标识给（Model & View）返回给Dispatcher Servlet。

Dispatcher Servlet根据这个View 标识，定位相应的View Template Path，把处理转交给View（JSP +TagLib, Velocity, Free Marker, XSL等）。

View一般通过request.getAttribute()获得结果数据，并显示到客户端。至于是谁把结果数据设置到request.attribute里面，有两种可能：Action或Dispatcher Servlet。

2. Struts
http://struts.apache.org/

Struts是目前用户群最大、开发厂商支持最多的开源Web Framework。

Struts劳苦功高，为普及MVC框架作出了不可磨灭的贡献。显赫的声望，趋于老化的厚重结构，令Struts成为很多现代Web Framework参照、挑战的目标。



Struts应用主要包括3件事情: 配置struts-config.xml文件,实现Action类，实现View；还有一些高级扩展用法。下面分别讲述。



1. 配置struts-config.xml文件：

Struts支持多级配置文件，具体用法和限制，详见Struts文档。这里只讨论struts-config.xml主流配置的内容。:-)



(1) URL Path到Action的映射。

如<action path="/LogonSubmit" type="app.LogonAction" ... />



Struts的入口Servlet是ActionServlet。

ActionServlet需要此信息把URL Path调用对应的Action类处理。

在Struts运行期间，一个URL Path，只存在一个对应的Struts Action实例。所有的该URL Path的请求，都经过这同一个Struts Action实例处理。所以Struts Action必须线程安全。

想想看，其实这个要求并不过分，Action只是一个处理程序，不应该保存跨HTTP请求的状态数据，按理来说，也应该做成线程安全的。



(2) Template Name到View Template Path的映射。

<forward name="success" path="/pages/Welcome.jsp"/>



Action类返回一个Template Name，ActionServlet根据这个Template Name获得对应的View Template Path，然后调用

request.getRequestDispatcher(“View Template Path”)，把处理转向路径对应的Servlet。在这个例子中，是转向/pages/Welcome.jsp编译后的Servlet。



我们来看一个一个Velocity的例子。

<include name="success" path="/pages/Welcome.vm"/>

web.xml的定义如下

<servlet>

<servlet-name>velocity</servlet-name>

<servlet-class>org.apache.velocity.tools.view.servlet.VelocityViewServlet</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>velocity</servlet-name>

<url-pattern>*.vm</url-pattern>

</servlet-mapping>



这时，request.getRequestDispatcher(“/pages/Welcome.vm”)会调用VelocityViewServlet，由VelocityViewServlet负责装并驱动运行/pages/Welcome.vm这个模板文件。

这里面有一个问题，如果调用的是DispatchRequester.include()方法，那么如何才能把pages/Welcome.vm传给VelocityViewServlet呢？

如前所说，RequestDispatcher传递的参数只有两个，request和response。那么只能通过request attribute。正是为了解决这个问题，Servlet2.3规范之后，加入了javax.servlet.include.servlet_path这个属性。

参见VelocityViewServlet的代码（velocity-tool开源项目）

// If we get here from RequestDispatcher.include(), getServletPath()

// will return the original (wrong) URI requested. The following special

// attribute holds the correct path. See section 8.3 of the Servlet

// 2.3 specification.

String path = (String)request.getAttribute("javax.servlet.include.servlet_path");



从这里我们可以看出，为什么通晓Servlet Specification对于通晓Web Framework至关重要。



(3) Form Bean的定义

如<form-bean name="logonForm" type="app.LogonForm"/>
Struts Form Bean需要继承ActionForm类。
Form Bean类，主要有三个作用：

[1]根据bean的定义，利用reflection机制，自动把request参数转化为需要的数据类型，填入到bean的属性当中。ActionForm类名中虽然有Form这个词，但不仅能够获取Form提交后的HTTP Post参数，也可以获取URL后缀的HTTP Get参数。

[2]输入验证。用户可以配置validation.xml，定义各属性的验证规则。

[3]当作View Object来用。用户需要熟练掌握Struts HTML TagLib的用法，才能把Form Bean的属性正确显示出来。



(4)其他定义。详见Struts文档。不再赘述。



2.实现Action。

Action类从Form Bean或直接从request中获得输入参数，调用商业逻辑，把结果数据（也许会包装成View Object），用request.setAttribute()放到request中，最后返回一个用ForwardMapping类包装的Template Name。



3.实现View。

Struts View的标准实现方法是JSP + Struts TagLib，其中最重要的就是Struts HTML TagLib。

html:form tag则是整个HTML Tag的核心，其它的如html:input, html:select等tag，都包含在html:form tag里面。

html:form tag用来映射Form Bean（也可以通过适当定义，映射其他的bean，但使用上会有很多麻烦）。html:form tag包含的其他Struts html tag用来映射Form Bean的属性。



Struts Bean TagLib的用法比较臃肿，一般情况下可以用JSTL代替。当然，如果需要用到bean:message tag实现国际化，那又另当别论。

Struts Tile TagLib用于页面布局。开源Portal项目Liferay使用了Struts Tile TagLib做为布局控制。



4.高级扩展用法

用户可以重载Struts的一些控制类，引入自己的一些定制类。详见Struts文档。

本文不是Struts专题，只讲述最重要的主流用法，其它边边角角的，不再赘述。

3. WebWork
http://www.opensymphony.com/webwork/

WebWork由于灵活的可插拔特性，受到很多资深程序员的欢迎。似乎很有可能大肆流行起来。

WebWork项目建立在XWork项目上。入口Servlet是WebWork项目中定义的ServletDispatcher，而Action在XWork项目中定义。

XWork Action接口的execute()方法没有参数，不像Struts Action那样接受request, response参数，所以XWork Action能够脱离Web环境被直接调用，便于单元测试。

这里引入了一个问题。没有了request参数，那么XWork Action如何获得request parameters作为输入数据？又通过什么桥梁（Struts用request.setAttribute）把结果数据传送到View层？

在Web Work中，只能通过Action本身的getter, setter属性来传送输入参数和输出结果。

比如，我们有这样一个实现了XWork Action接口的类，

YourAction implements Action{

int productId = null;

String productName = null;



public void setProductId(int productId){this.productId = productId;}

public String getProductName(){return productName;}



public String execute(){

    productName = findNameById(productId);

    return “success”;

}

}

这个类里面的productId将接受request输入参数，productName是输出到页面显示的结果。

比如，这样的请求，http://yourhost/yourapp/MyAction.action?productId=1

Web Work会把1填到YourAction的productId里面，然后执行execute()方法，JSP里的语句<ww:property value=“productName”>会把YourAction的productName显示在页面上。



如果一个Web Framework采用了这种屏蔽Action的request, response参数的设计方式，一般也同时会采用这种Action和输入输出数据结合成一体的解决方式。类似的情形也存在于Tapestry和Maverick中，后面会讲到。

当WebWork ServletDispatcher接收到HTTP Request的时候，首先把所有相关的信息（包括request, response, session, servlet config, servelt context, 所有request参数）等存放到AcationContext中，然后根据Interceptor配置信息，生成一个YourAction的动态代理类对象。实际上运行的正是这个代理对象，如同Servlet Filter的工作机制一般，所有注入的Interceptor方法会先于Actio方法运行。

我们来看一下Action和Interceptor的地位：Action没有参数，无法获得ActionContext；而Interceptor接受的ActionInvoication参数拥有包括ActionContext在内的所有重要信息。

这种权力分配的不平等，注定了Action的作用非常有限，只限于调用商业逻辑，然后返回一个成功与否标志。所有与外部Web世界打交道、协调内部工作流程的重担，都责无旁贷地落在Interceptor的肩上。

我们可以设想一个极端的例子。我们声明一批不做任何事情的空Action，我们只是需要它们的空壳类名；我们制作一批对应的Interceptor，所有的转发控制、商业逻辑都在Interceptor上实现，然后把Interceptor都注入到对应的空Action。这在理论上是完全可行的。

在Web海洋的包围中，Action可少，Interceptor不可少。Action是一个孤岛,如果没有外来盟友Interceptor的协助，只能在自己的小范围内独立作战（比如Unit Test），而对整体大局的作战目标无法产生影响。

下面我们来看一下Action是如何在Interceptor的全程监管下工作的。



在WebWork中，我们需要如下配置XWork.xml。

<xwork>

<!-- Include webwork defaults (from WebWork-2.1 JAR). -->

<include file="webwork-default.xml" />



<!-- Configuration for the default package. -->

<package name="default" extends="webwork-default">

  <!-- Default interceptor stack. -->

  <default-interceptor-ref name=" defaultStack" />



  <!-- Action: YourAction. -->

  <action name="youraction" class="yourapp.YourAction">

    <result name="success" type="dispatcher">

YourAction.jsp

</result>

</action>

</package>

</xwork>



webwork-default.xml里面的相关定义如下：

<interceptors>

<interceptor name="validation" class="com.opensymphony.xwork.validator.ValidationInterceptor"/>



<interceptor name="static-params" class="com.opensymphony.xwork.interceptor.


StaticParametersInterceptor"/>

<interceptor name="params" class="com.opensymphony.xwork.interceptor.ParametersInterceptor

"/>

<interceptor name="conversionError" class="com.opensymphony.webwork.interceptor.


WebWorkConversionErrorInterceptor"/>

<interceptor-stack name="defaultStack">

  <interceptor-ref name="static-params"/>

  <interceptor-ref name="params"/>

  <interceptor-ref name="conversionError"/>

</interceptor-stack>

</interceptors>



从上述的配置信息中可以看出，YourAction执行execute()方法的前后，会被

defaultStack所定义的三个Intercepter截获。这些Interceptor的任务之一就是把输入参数设置到Action的对应属性当中。

如果我们需要加入对YourAction的属性的验证功能，只要把上述定义中的validation Interceptor加入到defaultStack中就可以了。当然，实际工作还没有这么简单，一般来说，还要为每个进行属性验证的Action的都配置一份validation.xml。

XWork Interceptor能够在Package和Action级别上，进行截获处理。

Servlet Filter能够在URL Patten级别上，进行截获处理。虽然实际上，Servlet Filter截获的是Servlet，但某些情况下，可以达到和截获一批Action的同样效果。

比如，在Web Work中，我们可以为所有admin package的Action，加入一个Interceptor，当检查到当前Session的用户没有admin权限时，统一返回一个警告页面：您没有足够的权限执行这个操作。

我们看到也可以为所有URL Pattern为“admin/*.action”的URL定义一个Servlet Filter，当检查到当前Session的用户没有admin权限时，统一返回一个警告页面：您没有足够的权限执行这个操作。