Listing 1 
//...
//initialize RequestDispatcher object; set forward to home page by default
RequestDispatcher rd = request.getRequestDispatcher("home.jsp");

//Prepare connection and statement
rs = stmt.executeQuery("select password from USER where userName = '" + userName + "'");
if (rs.next()) { //Query only returns 1 record in the result set; only 1 
  password per userName which is also the primary key
   if (rs.getString("password").equals(password)) { //If valid password
      session.setAttribute("User", userName); //Saves username string in the session object
   }
   else { //Password does not match, i.e., invalid user password
      request.setAttribute("Error", "Invalid password."); 

      rd = request.getRequestDispatcher("login.jsp");
   }
} //No record in the result set, i.e., invalid username
   else {

      request.setAttribute("Error", "Invalid user name.");
      rd = request.getRequestDispatcher("login.jsp");
   }
}

//As a controller, loginAction.jsp finally either forwards to "login.jsp" or "home.jsp"
rd.forward(request, response);
//...

Listing 2 
//...
session.removeAttribute("User");
session.invalidate();
//...

Listing 3 
//...
String userName = (String) session.getAttribute("User");
if (null == userName) {
   request.setAttribute("Error", "Session has ended.  Please login.");
   RequestDispatcher rd = request.getRequestDispatcher("login.jsp");
   rd.forward(request, response);
}
//...
//Allow the rest of the dynamic content in this JSP to be served to the browser
//...

//...
response.setHeader("Cache-Control","no-cache"); //Forces caches to obtain a new copy of the page from the origin server
response.setHeader("Cache-Control","no-store"); //Directs caches not to store the page under any circumstance
response.setDateHeader("Expires", 0); //Causes the proxy cache to see the page as "stale"
response.setHeader("Pragma","no-cache"); //HTTP 1.0 backward compatibility
String userName = (String) session.getAttribute("User");
if (null == userName) {
   request.setAttribute("Error", "Session has ended.  Please login.");
   RequestDispatcher rd = request.getRequestDispatcher("login.jsp");
   rd.forward(request, response);
}
//...

清单5
//...
RequestDispatcher rd = request.getRequestDispatcher("home.jsp"); //Forward to homepage by default
//...
if (rs.getString("password").equals(password)) { //If valid password
   long lastLogonDB = rs.getLong("lastLogon");
   if (lastLogonForm > lastLogonDB) {
      session.setAttribute("User", userName); //Saves username string in the session object
      stmt.executeUpdate("update USER set lastLogon= " + lastLogonForm + " where userName = '" + userName + "'");
   }
   else {
      request.setAttribute("Error", "Session has ended.  Please login.");
      rd = request.getRequestDispatcher("login.jsp");        }
}
else   { //Password does not match, i.e., invalid user password
   request.setAttribute("Error", "Invalid password.");
   rd = request.getRequestDispatcher("login.jsp");   
}
//...
rd.forward(request, response);
//...

清单6
  public abstract class BaseAction extends Action {
   public ActionForward execute(ActionMapping mapping, ActionForm form,
      HttpServletRequest request, HttpServletResponse response) 
      throws IOException, ServletException {
      
      response.setHeader("Cache-Control","no-cache"); //Forces caches to obtain a new copy of the page from the origin server
      response.setHeader("Cache-Control","no-store"); //Directs caches not to store the page under any circumstance
      response.setDateHeader("Expires", 0); //Causes the proxy cache to see the page as "stale"
      response.setHeader("Pragma","no-cache"); //HTTP 1.0 backward compatibility 
      
      if (!this.userIsLoggedIn(request)) {
         ActionErrors errors = new ActionErrors();

         errors.add("error", new ActionError("logon.sessionEnded"));
         this.saveErrors(request, errors);

         return mapping.findForward("sessionEnded");
      }

      return executeAction(mapping, form, request, response);
   }

   protected abstract ActionForward executeAction(ActionMapping mapping,
      ActionForm form, HttpServletRequest request, HttpServletResponse response) 
      throws IOException, ServletException;      

   private boolean userIsLoggedIn(HttpServletRequest request) {
      if (request.getSession().getAttribute("User") == null) {
         return false;
      }

      return true;
   }
}

清单7
<action path="/secure1" 
   type="com.kevinhle.logoutSampleStruts.Secure1Action"           
   scope="request">
   <forward name="success" path="/WEB-INF/jsps/secure1.jsp"/>
   <forward name="sessionEnded" path="/login.jsp"/>
</action>

public class Secure1Action extends BaseAction {
   public ActionForward executeAction(ActionMapping mapping, ActionForm form,
      HttpServletRequest request, HttpServletResponse response)
      throws IOException, ServletException {
      
      HttpSession session = request.getSession();            
      return (mapping.findForward("success"));
   }
}

public static Credit getNewCredit() {
return new Credit();
} 
 
改进后的代码使用clone()方法，如下所示：

private static Credit BaseCredit = new Credit();
public static Credit getNewCredit() {
return (Credit) BaseCredit.clone();
}

for (val = 0; val < 100000; val +=5) { alterX = val * 8; myResult = val * 2; } 
 
用移位操作替代乘法操作可以极大地提高性能。下面是修改后的代码：

for (val = 0; val < 100000; val += 5) { alterX = val << 3; myResult = val << 1; }

修改后的代码不再做乘以8的操作，而是改用等价的左移3位操作，每左移1位相当于乘以2。相应地，右移1位操作相当于除以2。值得一提的是，虽然移位操作速度快，但可能使代码比较难于理解，所以最好加上一些注释。

前面介绍的改善性能技巧适合于大多数Java应用，接下来要讨论的问题适合于使用JSP、EJB或JDBC的应用。

1. 使用缓冲标记

一些应用服务器加入了面向JSP的缓冲标记功能。例如，BEA的WebLogic Server从6.0版本开始支持这个功能，Open Symphony工程也同样支持这个功能。JSP缓冲标记既能够缓冲页面片断，也能够缓冲整个页面。当JSP页面执行时，如果目标片断已经在缓冲之中，则生成该片断的代码就不用再执行。页面级缓冲捕获对指定URL的请求，并缓冲整个结果页面。对于购物篮、目录以及门户网站的主页来说，这个功能极其有用。对于这类应用，页面级缓冲能够保存页面执行的结果，供后继请求使用。

对于代码逻辑复杂的页面，利用缓冲标记提高性能的效果比较明显；反之，效果可能略逊一筹。

2. 始终通过会话Bean访问实体Bean

直接访问实体Bean不利于性能。当客户程序远程访问实体Bean时，每一个get方法都是一个远程调用。访问实体Bean的会话Bean是本地的，能够把所有数据组织成一个结构，然后返回它的值。

用会话Bean封装对实体Bean的访问能够改进事务管理，因为会话Bean只有在到达事务边界时才会提交。每一个对get方法的直接调用产生一个事务，容器将在每一个实体Bean的事务之后执行一个“装入-读取”操作。一些时候，使用实体Bean会导致程序性能不佳。如果实体Bean的唯一用途就是提取和更新数据，改成在会话Bean之内利用JDBC访问数据库可以得到更好的性能。

3. 选择合适的引用机制

在典型的JSP应用系统中，页头、页脚部分往往被抽取出来，然后根据需要引入页头、页脚。当前，在JSP页面中引入外部资源的方法主要有两种：include指令，以及include动作。

include指令：例如

<%@ include file="copyright.html" %>

该指令在编译时引入指定的资源。在编译之前，带有include指令的页面和指定的资源被合并成一个文件。被引用的外部资源在编译时就确定，比运行时才确定资源更高效。

include动作：例如

<jsp:include page="copyright.jsp" />

该动作引入指定页面执行后生成的结果。由于它在运行时完成，因此对输出结果的控制更加灵活。但时，只有当被引用的内容频繁地改变时，或者在对主页面的请求没有出现之前，被引用的页面无法确定时，使用include动作才合算。

4. 在部署描述器中设置只读属性

实体Bean的部署描述器允许把所有get方法设置成“只读”。当某个事务单元的工作只包含执行读取操作的方法时，设置只读属性有利于提高性能，因为容器不必再执行存储操作。



5. 缓冲对EJB Home的访问

EJB Home接口通过JNDI名称查找获得。这个操作需要相当可观的开销。JNDI查找最好放入Servlet的init()方法里面。如果应用中多处频繁地出现EJB访问，最好创建一个EJBHomeCache类。EJBHomeCache类一般应该作为singleton实现。

6. 为EJB实现本地接口

本地接口是EJB 2.0规范新增的内容，它使得Bean能够避免远程调用的开销。请考虑下面的代码。

PayBeanHome home = (PayBeanHome)
javax.rmi.PortableRemoteObject.narrow
(ctx.lookup ("PayBeanHome"), PayBeanHome.class); 
PayBean bean = (PayBean)
javax.rmi.PortableRemoteObject.narrow 
(home.create(), PayBean.class);

第一个语句表示我们要寻找Bean的Home接口。这个查找通过JNDI进行，它是一个RMI调用。然后，我们定位远程对象，返回代理引用，这也是一个RMI调用。第二个语句示范了如何创建一个实例，涉及了创建IIOP请求并在网络上传输请求的stub程序，它也是一个RMI调用。要实现本地接口，我们必须作如下修改：

方法不能再抛出java.rmi.RemoteException异常，包括从RemoteException派生的异常，比如TransactionRequiredException、TransactionRolledBackException和NoSuchObjectException。EJB提供了等价的本地异常，如TransactionRequiredLocalException、TransactionRolledBackLocalException和NoSuchObjectLocalException。

所有数据和返回值都通过引用的方式传递，而不是传递值。本地接口必须在EJB部署的机器上使用。简而言之，客户程序和提供服务的组件必须在同一个JVM上运行。如果Bean实现了本地接口，则其引用不可串行化。

7. 生成主键

在EJB之内生成主键有许多途径，下面分析了几种常见的办法以及它们的特点。利用数据库内建的标识机制（SQL Server的IDENTITY或Oracle的SEQUENCE）。这种方法的缺点是EJB可移植性差。由实体Bean自己计算主键值（比如做增量操作）。它的缺点是要求事务可串行化，而且速度也较慢。

利用NTP之类的时钟服务。这要求有面向特定平台的本地代码，从而把Bean固定到了特定的OS之上。另外，它还导致了这样一种可能，即在多CPU的服务器上，同一个毫秒之内生成了两个主键。借鉴Microsoft的思路，在Bean中创建一个GUID。然而，如果不求助于JNI，Java不能确定网卡的MAC地址；如果使用JNI，则程序就要依赖于特定的OS。

还有其他几种办法，但这些办法同样都有各自的局限。似乎只有一个答案比较理想：结合运用RMI和JNDI。先通过RMI注册把RMI远程对象绑定到JNDI树。客户程序通过JNDI进行查找。下面是一个例子：

public class keyGenerator
extends UnicastRemoteObject implements
Remote { private static long KeyValue = System.currentTimeMillis();
public static synchronized long getKey()
throws RemoteException { return KeyValue++; }

8. 及时清除不再需要的会话

为了清除不再活动的会话，许多应用服务器都有默认的会话超时时间，一般为30分钟。当应用服务器需要保存更多会话时，如果内存容量不足，操作系统会把部分内存数据转移到磁盘，应用服务器也可能根据“最近最频繁使用”（Most Recently Used）算法把部分不活跃的会话转储到磁盘，甚至可能抛出“内存不足”异常。在大规模系统中，串行化会话的代价是很昂贵的。当会话不再需要时，应当及时调用HttpSession.invalidate()方法清除会话。HttpSession.invalidate()方法通常可以在应用的退出页面调用。

9. 在JSP页面中关闭无用的会话

对于那些无需跟踪会话状态的页面，关闭自动创建的会话可以节省一些资源。使用如下page指令：

<%@ page session="false"%>

10. Servlet与内存使用

许多开发者随意地把大量信息保存到用户会话之中。一些时候，保存在会话中的对象没有及时地被垃圾回收机制回收。从性能上看，典型的症状是用户感到系统周期性地变慢，却又不能把原因归于任何一个具体的组件。如果监视JVM的堆空间，它的表现是内存占用不正常地大起大落。解决这类内存问题主要有二种办法。第一种办法是，在所有作用范围为会话的Bean中实现HttpSessionBindingListener接口。这样，只要实现valueUnbound()方法，就可以显式地释放Bean使用的资源。

另外一种办法就是尽快地把会话作废。大多数应用服务器都有设置会话作废间隔时间的选项。另外，也可以用编程的方式调用会话的setMaxInactiveInterval()方法，该方法用来设定在作废会话之前，Servlet容器允许的客户请求的最大间隔时间，以秒计算。

11. HTTP Keep-Alive

Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。市场上的大部分Web服务器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。对于提供静态内容的网站来说，这个功能通常很有用。但是，对于负担较重的网站来说，这里存在另外一个问题：虽然为客户保留打开的连接有一定的好处，但它同样影响了性能，因为在处理暂停期间，本来可以释放的资源仍旧被占用。当Web服务器和应用服务器在同一台机器上运行时，Keep-Alive功能对资源利用的影响尤其突出。

12. JDBC与Unicode

想必你已经了解一些使用JDBC时提高性能的措施，比如利用连接池、正确地选择存储过程和直接执行的SQL、从结果集删除多余的列、预先编译SQL语句，等等。除了这些显而易见的选择之外，另一个提高性能的好选择可能就是把所有的字符数据都保存为Unicode（代码页13488）。Java以Unicode形式处理所有数据，因此，数据库驱动程序不必再执行转换过程。但应该记住：如果采用这种方式，数据库会变得更大，因为每个Unicode字符需要2个字节存储空间。另外，如果有其他非Unicode的程序访问数据库，性能问题仍旧会出现，因为这时数据库驱动程序仍旧必须执行转换过程。

13. JDBC与I/O

如果应用程序需要访问一个规模很大的数据集，则应当考虑使用块提取方式。默认情况下，JDBC每次提取32行数据。举例来说，假设我们要遍历一个5000行的记录集，JDBC必须调用数据库157次才能提取到全部数据。如果把块大小改成512，则调用数据库的次数将减少到10次。在一些情形下这种技术无效。例如，如果使用可滚动的记录集，或者在查询中指定了FOR UPDATE，则块操作方式不再有效。

14. 内存数据库

许多应用需要以用户为单位在会话对象中保存相当数量的数据，典型的应用如购物篮和目录等。由于这类数据可以按照行/列的形式组织，因此，许多应用创建了庞大的Vector或HashMap。在会话中保存这类数据极大地限制了应用的可伸缩性，因为服务器拥有的内存至少必须达到每个会话占用的内存数量乘以并发用户最大数量，它不仅使服务器价格昂贵，而且垃圾收集的时间间隔也可能延长到难以忍受的程度。

一些人把购物篮/目录功能转移到数据库层，在一定程度上提高了可伸缩性。然而，把这部分功能放到数据库层也存在问题，且问题的根源与大多数关系数据库系统的体系结构有关。对于关系数据库来说，运行时的重要原则之一是确保所有的写入操作稳定、可靠，因而，所有的性能问题都与物理上把数据写入磁盘的能力有关。关系数据库力图减少I/O操作，特别是对于读操作，但实现该目标的主要途径只是执行一套实现缓冲机制的复杂算法，而这正是数据库层第一号性能瓶颈通常总是CPU的主要原因。

一种替代传统关系数据库的方案是，使用在内存中运行的数据库（In-memory Database），例如TimesTen。内存数据库的出发点是允许数据临时地写入，但这些数据不必永久地保存到磁盘上，所有的操作都在内存中进行。这样，内存数据库不需要复杂的算法来减少I/O操作，而且可以采用比较简单的加锁机制，因而速度很快。

这一篇中介绍的内容适合于图形用户界面的应用（Applet和普通应用），要用到AWT或Swing。 1. 用JAR压缩类文件

Java档案文件（JAR文件）是根据JavaBean标准压缩的文件，是发布JavaBean组件的主要方式和推荐方式。JAR档案有助于减少文件体积，缩短下载时间。例如，它有助于Applet提高启动速度。一个JAR文件可以包含一个或者多个相关的Bean以及支持文件，比如图形、声音、HTML和其他资源。要在HTML/JSP文件中指定JAR文件，只需在Applet标记中加入ARCHIVE = "name.jar"声明。

2. 提示Applet装入进程

你是否看到过使用Applet的网站，注意到在应该运行Applet的地方出现了一个占位符？当Applet的下载时间较长时，会发生什么事情？最大的可能就是用户掉头离去。在这种情况下，显示一个Applet正在下载的信息无疑有助于鼓励用户继续等待。下面我们来看看一种具体的实现方法。首先创建一个很小的Applet，该Applet负责在后台下载正式的Applet：

import java.applet.Applet;
import java.applet.AppletStub;
import java.awt.Label;
import java.awt.Graphics;
import java.awt.GridLayout;
public class PreLoader extends Applet implements Runnable, AppletStub {
String largeAppletName;
Label label;
public void init() {
// 要求装载的正式Applet
largeAppletName = getParameter("applet");// “请稍等”提示信息
label = new Label("请稍等..." + largeAppletName);
add(label);
}
public void run(){
try 
{
// 获得待装载Applet的类
Class largeAppletClass = Class.forName(largeAppletName);
// 创建待装载Applet的实例
Applet largeApplet = (Applet)largeAppletClass.newInstance();
// 设置该Applet的Stub程序
largeApplet.setStub(this);
// 取消“请稍等”信息
remove(label);
// 设置布局
setLayout(new GridLayout(1, 0));
add(largeApplet);
// 显示正式的Applet
largeApplet.init();
largeApplet.start();
}
catch (Exception ex)
{
// 显示错误信息
label.setText("不能装入指定的Applet");
}
// 刷新屏幕
validate();
}
public void appletResize(int width, int height)
{
// 把appletResize调用从stub程序传递到Applet
resize(width, height);
}
}

编译后的代码小于2K，下载速度很快。代码中有几个地方值得注意。首先，PreLoader实现了AppletStub接口。一般地，Applet从调用者判断自己的codebase。在本例中，我们必须调用setStub()告诉Applet到哪里提取这个信息。另一个值得注意的地方是，AppletStub接口包含许多和Applet类一样的方法，但appletResize()方法除外。这里我们把对appletResize()方法的调用传递给了resize()方法。

3. 在画出图形之前预先装入它

ImageObserver接口可用来接收图形装入的提示信息。ImageObserver接口只有一个方法imageUpdate()，能够用一次repaint()操作在屏幕上画出图形。下面提供了一个例子。

public boolean imageUpdate(Image img, int flags, int x, int y, int w, int h) {
if ((flags & ALLBITS) !=0 {
repaint();
}
else if (flags & (ERROR |ABORT )) != 0) {
error = true;
// 文件没有找到，考虑显示一个占位符
repaint();
}
return (flags & (ALLBITS | ERROR| ABORT)) == 0;
}

当图形信息可用时，imageUpdate()方法被调用。如果需要进一步更新，该方法返回true；如果所需信息已经得到，该方法返回false。

4. 覆盖update方法

update()方法的默认动作是清除屏幕，然后调用paint()方法。如果使用默认的update()方法，频繁使用图形的应用可能出现显示闪烁现象。要避免在paint()调用之前的屏幕清除操作，只需按照如下方式覆盖update()方法：

public void update(Graphics g) {
paint(g);
}

更理想的方案是：覆盖update()，只重画屏幕上发生变化的区域，如下所示:

public void update(Graphics g) {
g.clipRect(x, y, w, h);
paint(g);
}

5. 延迟重画操作

对于图形用户界面的应用来说，性能低下的主要原因往往可以归结为重画屏幕的效率低下。当用户改变窗口大小或者滚动一个窗口时，这一点通常可以很明显地观察到。改变窗口大小或者滚动屏幕之类的操作导致重画屏幕事件大量地、快速地生成，甚至超过了相关代码的执行速度。对付这个问题最好的办法是忽略所有“迟到”的事件。

建议在这里引入一个数毫秒的时差，即如果我们立即接收到了另一个重画事件，可以停止处理当前事件转而处理最后一个收到的重画事件；否则，我们继续进行当前的重画过程。

如果事件要启动一项耗时的工作，分离出一个工作线程是一种较好的处理方式；否则，一些部件可能被“冻结”，因为每次只能处理一个事件。下面提供了一个事件处理的简单例子，但经过扩展后它可以用来控制工作线程。

public static void runOnce(String id, final long milliseconds) {
synchronized(e_queue) {
// e_queue: 所有事件的集合
if (!e_queue.containsKey(id)) {
e_queue.put(token, new LastOne());
}
}
final LastOne lastOne = (LastOne) e_queue.get(token);
final long time = System.currentTimeMillis(); // 获得当前时间
lastOne.time = time;
(new Thread() {public void run() {
if (milliseconds > 0) {
try {Thread.sleep(milliseconds);} // 暂停线程
catch (Exception ex) {}
}
synchronized(lastOne.running) { // 等待上一事件结束
if (lastOne.time != time) // 只处理最后一个事件
return;
}
}}).start();
}
private static Hashtable e_queue = new Hashtable(); private static class LastOne {
public long time=0;
public Object running = new Object();
}

6. 使用双缓冲区

在屏幕之外的缓冲区绘图，完成后立即把整个图形显示出来。由于有两个缓冲区，所以程序可以来回切换。这样，我们可以用一个低优先级的线程负责画图，使得程序能够利用空闲的CPU时间执行其他任务。下面的伪代码片断示范了这种技术。

Graphics myGraphics;
Image myOffscreenImage = createImage(size().width, size().height);
Graphics offscreenGraphics = myOffscreenImage.getGraphics();
offscreenGraphics.drawImage(img, 50, 50, this);
myGraphics.drawImage(myOffscreenImage, 0, 0, this);

7. 使用BufferedImage

Java JDK 1.2使用了一个软显示设备，使得文本在不同的平台上看起来相似。为实现这个功能，Java必须直接处理构成文字的像素。由于这种技术要在内存中大量地进行位复制操作，早期的JDK在使用这种技术时性能不佳。为解决这个问题而提出的Java标准实现了一种新的图形类型，即BufferedImage。BufferedImage子类描述的图形带有一个可访问的图形数据缓冲区。一个BufferedImage包含一个ColorModel和一组光栅图形数据。这个类一般使用RGB（红、绿、蓝）颜色模型，但也可以处理灰度级图形。它的构造函数很简单，如下所示：

public BufferedImage (int width, int height, int imageType)

ImageType允许我们指定要缓冲的是什么类型的图形，比如5-位RGB、8-位RGB、灰度级等。



8. 使用VolatileImage

许多硬件平台和它们的操作系统都提供基本的硬件加速支持。例如，硬件加速一般提供矩形填充功能，和利用CPU完成同一任务相比，硬件加速的效率更高。由于硬件加速分离了一部分工作，允许多个工作流并发进行，从而缓解了对CPU和系统总线的压力，使得应用能够运行得更快。利用VolatileImage可以创建硬件加速的图形以及管理图形的内容。由于它直接利用低层平台的能力，性能的改善程度主要取决于系统使用的图形适配器。VolatileImage的内容随时可能丢失，也即它是“不稳定的（volatile）”。因此，在使用图形之前，最好检查一下它的内容是否丢失。VolatileImage有两个能够检查内容是否丢失的方法：

public abstract int validate(GraphicsConfiguration gc);public abstract Boolean contentsLost();

每次从VolatileImage对象复制内容或者写入VolatileImage时，应该调用validate()方法。contentsLost()方法告诉我们，自从最后一次validate()调用之后，图形的内容是否丢失。虽然VolatileImage是一个抽象类，但不要从它这里派生子类。VolatileImage应该通过Component.createVolatileImage()或者GraphicsConfiguration.createCompatibleVolatileImage()方法创建。

9. 使用Window Blitting

进行滚动操作时，所有可见的内容一般都要重画，从而导致大量不必要的重画工作。许多操作系统的图形子系统，包括WIN32 GDI、MacOS和X/Windows，都支持Window Blitting技术。Window Blitting技术直接在屏幕缓冲区中把图形移到新的位置，只重画新出现的区域。要在Swing应用中使用Window Blitting技术，设置方法如下：

setScrollMode(int mode);

在大多数应用中，使用这种技术能够提高滚动速度。只有在一种情形下，Window Blitting会导致性能降低，即应用在后台进行滚动操作。如果是用户在滚动一个应用，那么它总是在前台，无需担心任何负面影响

1．背景、形势
能够进行Web开发的编程语言和技术很多
(1) 动态解释语言
PHP; Perl; Python (Zope, Plone); Ruby (Ruby on Rails);
(2) 编译语言
Java; .net

Java Web开发远非一枝独秀：
除了受到来自.net 这个重量级对手的最大挑战之外，更受到Zope, Ruby on Rail 等新式轻骑兵的冲击（当然，也继续受到老式轻步兵PHP, Perl的冲击）。

官方Java走的是复杂路线，Servlet -> JSP -> Taglib。.net走的也是复杂路线，依靠成熟友好的集成化开发环境取胜。Java阵营好容易应对过来，从纷纭复杂的各种开发框架基础上，发展出了重量级Web开发框架JSF，以及相应的集成化开发环境；渴望以此应对.net的攻势。胜负未分，前途未卜。这时，另一个方向又杀来了新式轻骑Zope, Ruby on Rail。
Python, Ruby等动态解释语言，面向对象特性更好，先天支持 动态绑定、AOP、函数式编程、“编程即配置”等时髦概念。开发速度更快，代码量更小，达到killer级别。

传统的HTML Web开发领域里面，Java已经是腹背受敌。领域外也展开了征战，Rich Client Architecture的兴起：AJAX(XMLHttp), Flash RIA, XUL, XAML, Smart Client（以及从前的ActiveX, Applet, Web Start）。

Web的发展趋势是 语义Web，最终目的是让整个Web成为一个巨大的数据库。
这意味着，未来的Web应用将更加的面向文本内容数据，更加搜索引擎友好 – Search Engine Friendly.
二进制的客户端插件，如Flash RIA, ActiveX, Applet, Web Start等，虽然交互性能最好，但不是以文本内容数据为中心，搜索引擎不友好。所以，我只是保持适当关注。我更关注基于文本的UI表现，如HTML, XUL, XAML等。XUL, XAML还没有广泛流行，只是保持一种有兴趣的关注。
当下关注的重点，还是 XHTML + CSS + Javascript少量的 AJAX(XMLHttp)增加更好的交互性。

我一直认为：轻量、简洁、高效 才是硬道理。后面阐述我对Java Web开发的理解和构想。

2. Web开发框架层次概述
从上到下，Web开发框架的层次如下：
(1) HTML, JavaScript, CSS等页面资源。
(2) 页面模板层。
如JSP, Freemarker, Velocity, XSL，fastm等。用来生成HTML, JavaScript, CSS等页面资源。
(3) Web框架。把HTTP Request调度分派到对应的Service Entry。
(4) Business Logic.
(5) O/R Mapping.
(6) JDBC
(7) DB

根据我的经验，一个典型的Web应用中的代码比例如下：
页面逻辑约占 50%，商业逻辑约占30%, O/R 约占20%。

但事实上，页面却是最不受重视的部分，从来都被认为是脏活，累活，杂活。典型的开发过程通常是这样：
页面设计人员迅速的用Dreamweaver等生成一堆文本杂乱无章的页面，然后交给JSP程序员加入更加杂乱无章的Java代码和Taglib。
当页面布局风格需要改变的时候，页面设计人员用Dreamweaver等生成一堆新的页面。JSP程序员再重新加入更加杂乱无章的Java代码Taglib。
至于页面中的脚本逻辑调试，更是一门精深的工夫了。

根据社会规则，通常来说，工作内容越轻松，收入越高；工作内容越脏月累，收入越低；Web开发也是如此：做着最脏最累的活的页面程序员，工资一般比不上后台业务逻辑程序员。

开发框架通常会带来这样的结果：让简单的东西，变得更简单；让复杂的东西，变得更复杂。
这其中的原因在于：
一般来说，一个应用中简单重复的东西占80%，复杂特殊的东西占20%。
简单重复的东西很容易摸清规律，进行包装，通用化。但是，在包装的同时，经常就阻挡住了底层的一些灵活强大的控制能力。在复杂特殊的需求中，确实又需要这些底层控制能力，那么为了绕开框架的限制，付出的努力要比不用框架 大得多。
打个比方，一个比较极端的例子。编译语言比汇编语言的开发效率高很多，但是却无法直接操作寄存器。当需要在编译语言中操作寄存器的时候，就非常的痛苦。比如Java，也许需要JNI，写C代码，还要在C代码里面嵌入汇编。编译、连接都很麻烦。
所以，一个框架的开发效率，就在于这个80%简单 与 20%复杂之间的平衡。
假如，不用框架来开发，简单的80%要消耗 80个资源数，复杂的20%要消耗20个资源数，总资源数是100；使用了某个框架，简单的80%只要消耗10个资源数，复杂的20%要消耗40个资源数，总资源数是50。那么，我们说，这个开发框架是有效率的。

我的思路是，同时应对复杂和简单。当然，为了应对复杂，简单的东西可能就应对得不那么好。比如，做这样一个开发框架，简单的80%要消耗20个资源数，复杂的20%要消耗10个资源数，总资源数是30。
这种开发框架是有可能实现的。而且是很有意义的。尤其是在复杂部分的比例提高的时候。越复杂的系统，这种开发框架就越有意义。

后面的关于Web各层开发的论述，主要就按照这个“应对复杂、让复杂更简单”的思路展开。

3．页面资源
也许有人会说，页面资源，不就是HTML吗？太简单，太低极了，没劲。Dreamweaver、Frontpage多简单阿。随便找个人来用就可以了。文本内容乱糟糟不要紧，浏览器里面显示出来的效果好看就行。要增加炫的、酷的动画效果，那就写JavaScript呗。写在HTML里面，看看在IE里面能不能运行就可以了呗。
这也正是大多数公司开发页面资源的方式。因为页面的需求变化是最多、最快的，而页面的制作成本很低，人们不愿意在上面投入更多的资源。

我的看法是，万丈高楼平地起。应用程序的每一个部分都应该完善管理，结构优美。越是需求变化多的地方，越是脏乱差的地方，越应该加大力度处理好。

页面结构方面，Javaeye论坛的Dlee做了很多工作。

(1) 在 2005 年我们如何写 JavaScript
http://forum.javaeye.com/viewtopic.php?t=12973
(2)使用 Unordered Lists 制作的下拉菜单和树
http://forum.javaeye.com/viewtopic.php?t=12995
从上面的Dlee的论述和给出的资料。可以看出，页面资源分为三部分：
(1) XHTML。结构，Structure。
XHTML里面的Tag部分只应该包括 <ul> <table> <p> <div><span>等结构布局Tag，或者<strong><emphasis>表示语义的Tag。
XHTML里面不应该包括风格信息，比如字体、颜色、大小、粗细等，也不应该包括<font> <b> <i> <h> 等字体信息。
XHTML里面不应该包括Javascript的定义和调用。

(2) JavaScript。行为，behavior。
JavaScritp应该存在于一个独立于XHTML文件的独立文件中。这样可以做自动化单元测试。JavaScript应该只改变HTML DOM的结构和内容，而不应该改变它的风格。

(3) CSS。Style，风格。或者说，Presentation，表现。
前面说了，XHTML里面不应该包括JavaScript的调用。那么，XHTML的元素是如何JavaScript事件绑定起来？就是在CSS里面指定的。
当然，众所周知，CSS的本职工作是处理页面风格。

页面资源方面，我完全认同Dlee的观点。从技术和资源积累的长远目标看来，这方面的初期投入的回报将是非常丰厚的。
即使将来HTML消亡了，进入了XAML, XUL, RSS时代，这些结构清晰的各部分，重用的可能性都非常巨大。JavaScript + CSS + XML UI的这种经典设计思路，将留存很久。混杂成一团的HTML的命运只能是全盘被抛弃。

4．页面模板层
页面模板层是指Server端运行的用来生成HTML（或JavaScript，CSS）的Server Side Template Engine。
这一层也是著名的脏乱差楼层。著名的HTML的Java代码污染事件，就发生在这个楼层。不仅JSP有这个问题，其他的template, 如freemarker, velocity, tapestry等含有逻辑的脚本，都不同程度上有HTML的Script Logic污染问题。

Dlee的做法很美。直接就不要页面模板层，不用Server Side Template Engine。直接用JavaScript更改HTML DOM的结构、内容、数据。同时，会用到少量的浏览器端XSL。
这样带来的结果，Template就是很干净纯粹的HTML，不含有任何Server Side Script。这个效果，和Servier Side Template 的 Jivan，XMLC达到的一样。只是一个是在浏览器端执行，一个是在Server端执行。

我研究比较了几乎所有的Server Side Template Engine，力图采众家之长，避众家之短，写了一个Server Side Template Engine -- fastm, 能够最优雅方便的实现页面模板层。关于fastm，我的Blog上有不少文章论述。
我的Blog，里面专门有个fastm 分类。
http://blog.csdn.net/buaawhl
http://buaawhl.blogdriver.com

Fastm发布在java.net上。
https://fastm.dev.java.net


我仍然对Server Side Template Engine持肯定态度。基于如下原因：
(1) JavaScript代码量大、文件多的时候，不容易管理，不容易进行语法检查，不容易跟踪调试。
这里有人会争辩，Server Side Template Engine也用到了很多脚本阿，比如Freemarker, Velocity, 而且嵌在HTML中，怎么管理，怎么调试？即使是JSP，也是Java Code嵌在HTML里面，怎么管理，怎么调试？
这里我要说，Jivan, XMLC, fastm，Wicket等Template Engine的逻辑都是在Java Code里面。

(2) 用JavaScript生成文本内容，搜索引擎不友好。
一般的网络蜘蛛程序，只根据URL获取HTML文本，搜索里面的文本内容，而不会执行里面的JavaScript脚本。

(3) JavaScript代码重用还是有些局限
比如，有两个HTML文件，一个是Table布局，一个是List布局。
我有同样的一批数据，要在这两种布局中显示。
这时候，就要给这两个HTML分别写两套JavaScript。这里面的DOM层次，元素，属性都不同，再怎么定义ID，Class，也无法用完全相同的一套JavaScript处理。
这里有人会争辩，Server Side Template Engine也无法做到。别说JSP, Velocity, Freemarker等要在两套HTML里面嵌入相同的代码，就是Jivan, XMLC, Wicket也要分别写不同的两套Java Code，因为它们的XML DOM Node / Model View (Table, List) 都是不同的。
这里我要说。fastm可以做到只用一套代码逻辑。而且只有fastm可以。fastm的代码重用率是最高的。

关于Ajax(XMLHttp)，我的意见是必要时才用，而且最好采用粗粒度的用法 -- JavaScript发出一个URL请求，返回一整段HTML，直接替换到页面的某一块，而不是用JavaScript来做这样的把数据填充到HTML DOM中。如果你直接在浏览器里面输入那个URL，也可以获取那整段的HTML内容。
典型的应用场合是Portal。Portal页面的每个Portlet都含有这样的 Ajax(XMLHttp) javascript代码 -- 发出一个Portlet URL请求，返回一整段Portlet的内容，直接替换当前的Portlet块。
这样做的好处是：
(1) 减少JavaScript代码的量和复杂度。
(2) 搜索引擎友好。网络蜘蛛程序可以辨别JavaScript中的URL，并根据这个URL，获取整段处理好的HTML文本，进行内容搜索。
有人可能会争辩：如果URL请求返回的是XML数据，不是整段处理好的HTML，搜索引擎也可以进行内容搜索。
这点我同意。前提是XML数据的内容是足够连贯的，而不是散落的。比如，你返回的XML数据是“中国”。这个“中国”要放在HTML中的一个{country}位置，{country}足球。这个时候，结果HTML的内容含有“中国足球”。而XML数据中只含有“中国”。如果用户用“中国足球”作为关键字来搜索，就找不到这个URL。

从前面给出的fastm资料的连接中，可以得知。如同Jivan, XMLC, Wicket一样，fastm的template里面不含有逻辑，所有的逻辑都写在Java里面。
有人会争辩说：页面逻辑写在Java里面，我改变了页面逻辑，还需要重新编译。这也太不方便了。Velocity, Freemarker, JSP就不用重新编译。
这里我的看法是：业务逻辑代码改变了，不也需要重新编译吗？页面逻辑就不是逻辑了吗？HTML里面的脚本怎么语法检查、跟踪调试？业务逻辑需要语法检查、跟踪调试，页面逻辑就不需要语法检查、跟踪调试了吗？
对方可能会说：在我的应用中，页面逻辑的改动需求非常频繁，而且这些页面逻辑非常简单，不需要语法检查、跟踪调试。
这里我的意见是：
(1) 那就使用JSP, Velocity, Freemarker等脚本。
(2) fastm, Jivan, XMLC, Wicket的Java代码部分也可以写在脚本里面，比如，Server Side JavaScript, Jython(Python), Groovy, Bean Shell 等脚本语言都可以很方便的和Java相互调用。

fastm的生命周期将很长。
HTML, XUL, XAML都是，或将是可以在浏览器或可视化编辑工具里面显示的XML UI定义语言。Microsoft Office的Word, Excel, Powerpoint等格式都提供了相应的XML格式。这些XML文件都可以在Office里面显示，并编辑。
Adobe公司也提供了PDF的XML格式 -- XDP。可以在Adobe Designer里面显示并编辑。
由于fastm是Designer Friendly的XML UI所见即所得的模板技术。这方面具有很大的潜力。
根本不需要第三方花大力气专门做个IDE，来显示自定义的Tag。目标文件格式提供商自己的阅读编辑工具就可以直接用了，而且效果就是运行后产生的结果文件的效果。

即使没有可视化要求的场合。比如，Web Service需要的XML数据。fastm同样有用武之地。比如，
<!-- BEGIN DYNAMIC: users -->
<user>
<name>{name}</name>
<address>{name}</address>
</user>
<!-- END DYNAMIC: users -->

可以很容易的把一个Java Object List转化为XML数据。

另外，我不得不承认。浏览器端的JavaScript的页面逻辑，可移植性要高于Server Side Template Engine。因为Server Side Template Engine通常是特定语言相关的。
目前fastm是用Java实现的。由于实现很简单，移植到其它的语言，也很简单。如果是移植到Python, Ruby等动态解释语言，那就更简单了。我是有这个考虑，因为Zope, Ruby on Rails 的模板还是Logic 和 HTML混杂的，fastm这个思路有很大的用武之地。

前面讲了这么多。清理了两层有名的脏乱差的老大难的楼层 -- 页面资源层和页面模板层。让这两层变得和下面的楼层同样的优雅、清洁。

下面该讲到Web框架层了。在向下讲之前，由于前面提到了脚本，我想先插入一段关于“可配置”、“可编程”、“可热部署”、“脚本逻辑 vs XML Tag逻辑”的话题。把这个人们比较关心、讨论比较多的话题，先讲清楚。

5．可配置、可编程、可热部署、脚本逻辑 vs XML Tag逻辑
由于Java是编译语言，人们通常把变化的参数部分抽取出来，放到配置文件中。
这些配置文件通常是XML文件。这很好，没什么问题。XML很适合用来表达数据结构。
但是，对于某一种技术的狂热，通常引起对这种技术的过度使用，或者误用。
人们开始觉得，XML能够表达一切东西，包括for, if, else等逻辑。这方面的典型例子有 Workflow XML Definition，Logic TagLib, XSL Logic Tag等。
这点我不敢苟同。我的看法是，XML不适合表达逻辑，XML表达逻辑非常蹩脚。XML表达逻辑相当于自定义一门XML格式的脚本语言。

比如，Logic Tablib，很难自然的支持 if else, switch。只能蹩脚地支持一堆 <logic:if> <logic:ifNot> <logic:exists> <logic:notExists> <logic:ifNull> <logic:notNull>。
（注，好久没有接触过Taglib了。这些Tag Name都是凭以前的使用印象写的，也许名字不对，但表达这些意思的TagLib都还是有的）
如果要表达if () else if() else 就更蹩脚了。要进行非常麻烦的嵌套。

再比如，XSL 支持if, else 也非常蹩脚。非要多出来一个层次才行。
<xsl:choose>
<xsl:when test="…">
…. If ….
</xsl:when>
<xsl:otherwise>
… else …
</xsl:otherwise>
</xsl:choose>

同样，如果要表达if () else if() else 就更蹩脚了。
<xsl:choose>
<xsl:when test="…">
…. If ….
</xsl:when>
<xsl:otherwise>
<xsl:choose>
<xsl:when test="…">
…. If ….
</xsl:when>
<xsl:otherwise>
… else …
</xsl:otherwise>
</xsl:choose>
</xsl:otherwise>
</xsl:choose>

可以看到，XML Tag 表达逻辑，非常麻烦，可读性很差，完全是一种误用，没有半点优势。当然，逻辑简单的情况下，还是可以接受的。
有人会说：XML表达逻辑，可以免编译阿。
那么我说：语法检查呢，跟踪调试呢？
对方说：只是一些简单的逻辑，不需要语法检查、跟踪调试。
我说：如果只是为了免编译，前面列出的那么多的解释执行的脚本语言更适合。XML表达的逻辑，比Java等编译语言还要麻烦很多，而脚本语言比Java等编译语言简洁多了，可读性非常好，而且脚本语言和Java语言有很好的交互性，可以相互调用。重用、结构方面都具有优势。

有人会举出Spring IoC为例子，说：你看，Spring IoC的配置文件不都是XML格式吗？
我说：
(1) Spring IoC的配置文件基本都是属性设置，Bean ID声明。没有逻辑。
(2) 我也不是很赞同Spring IoC在XML配置文件里面引用Java类的做法。这方面，其它的容器如 Pico, Nano都支持多种配置方式，其中包括了不少脚本方式。我觉得，在脚本里面定义生成Java Object，比在XML中要好。当然，Web.xml里面也引用了Java Class名字。但那是非常简单的情况。没有嵌套引用、属性赋值、构造参数等复杂的定义方式。XML适合描述一些通用的资源、数据、结构。比如，HTML, XUL, XAML，RSS就是XML用的恰当的例子。

所以，我的基本观点是这样。
(1) 纯数据，不用说，应该定义在XML中。
(2) 如果是系统中一些Java Object要用到的基本属性。比如，连接池大小等。定义在properties, XML, Script中都可以。如果定义中没有出现具体的Java Class名，倾向于定义在properties, XML文件中。如果出现了具体的Java Class名，倾向于定义在Script中。这个界限不那么明显，两者皆可。
(3) 复杂结构的Java Bean的构造生成，那是肯定会出现具体的Java Class名，应该定义在Script中。

关于“可配置 vs 可编程”，有一点要明确：只要是可编程的，一定是可配置的。但如果是可配置的，却不一定是可编程的。
这里的可编程，是指框架给程序员提供了API；可配置，是指框架给程序员提供了配置文件的格式写法。
“可编程”一定是“可配置”的。
(1) 用户至少可以自己定义配置文件，读取参数，调用API。
(2) 有那么多的解释脚本可以直接和Java互操作，完全可以直接用来当作配置文件，定义参数。
“可配置” 却不一定“可编程”的。
如果框架只给你提供了配置方式，而没有API，那意味着，你只能进行参数的静态配置。很难在动态期间改变这些参数了。你总不能尝试着用代码去改变配置文件的内容吧？即使你改动了，如果框架不进行文件的时间戳检查，就是一开始装载进来，就不再检查更改了，你不就一点办法都没有了吗？
比如，Struts Tiles的XML定义，你只能静态配置，你想在运行期间改变布局，没有办法。Site Mesh也是如此。而我们可以在运行期间任意操作XML DOM Node，别说布局了，任何东西都可以改变。
所以，一个框架首要注重的是提供API，而不是提供配置方式。这是一个重要的原则。

讨论完了“可编程”、“可配置”问题，我们来看“热部署”问题。
XML配置文件、脚本文件支持“热部署”当然要比编译语言程序的热部署容易得多。只要解释执行前，检查一下时间戳就可以了。要注意的问题，只是做好测试，因为没有编译期的语法检查。
不过，Java程序也是可以“热部署”的。只是稍微麻烦一点。典型的例子是JSP, EJB Jar等。JSP修改之后，会自动编译执行；EJB Jar丢到EJB Container里面，会被检测到并装载到JNDI命名空间。
编译语言Java程序的热部署的一个可能的�