关于跨域名问题还是问题么，这方面的解决实践非常多，今天我就旧话重提把我所知道的通过几个应用场景来分别总结一下

先说明一点：我说的某某域名在您的控制下的意思是这个域名下的网页由您来负责开发内部的JavaScript
场景一：将bbs.xxx.com的页面用iframe嵌入到www.xxx.com的中，如何在iframe内外使用js通信
一级域名都是xxx.com 这个域名一定是在您的控制下，所以你只要在两个页面中同时升级域名即可
在父窗口和iframe内部分别加上js语句：document.domain=”xxx.com”;
之后2个页面就等于在同一域名下，通过window.parent oIframe.contentDocument就可以相互访问，进行无障碍的JS通信
在新浪、淘宝等很多页面都能找到这样的语句。不过document.domain不可以随便指定，只能向上升级，从bbs.xxx.com升级到yyy.com肯定会出错

场景二：将www.yyy.com的页面用iframe嵌入到www.xxx.com的中，两个域名都在您的控制下，如何在iframe内外进行一定的数据交流
你可以通过相互改变hash值的方式来进行一些数据的通信

这里的实现基于如下技术要点：
1、父窗口通过改变子窗口的src中的hash值把一部分信息传入，如果src只有hash部分改变，那么子窗口是不会重新载入的。
2、子窗口可以重写父窗口的location.href，但是注意这里子窗口无法读取而只能重写location.href所以要求前提是您控制两个域名，知道当前父窗口的location.href是什么并写在子窗口内，这样通过parent.location.href = “已知的父窗口的href”+”#”+hash。这样父窗口只有hash改变也不会重载。
3、上面两步分别做到了两个窗口之间的无刷新数据通知，那么下面的来说如何感知数据变化。标准中没有相关规定，所以当前的任意浏览器遇到location.hash变化都不会触发任何javaScript事件，也就是说您要自己写监听函数来监视loaction.hash的值的变化。做法是通过setTimeout或者setInterval来写一个监听函数每20-100ms查看一下hash是否变化，如果变化了驱动js根据新的数据做想做的事情。

这种实现的一些分析：
1、信息通道是双向的，当然会兼容单向，如果只是父窗口向子窗口通知数据，只需要子窗口写hash监听，反之亦然。
2、局限性也是颇大，因为这种通信的前提是双方知道对方的location.href。如果父窗口带有动态的location.search也就是查询参数，那么子窗口的处理上就比较困难，需要把父窗口的location.search作为传递信息的一部分告知子窗口。
3、另外的困扰会有浏览器带给你，IE之外的浏览器遇到hash的改变会记录历史，这样你在处理前进后退的时候会非常头疼

场景三：将www.yyy.com的页面用iframe嵌入到www.xxx.com的中，只有被嵌入的yyy.com在您的控制下，如何在iframe内外进行一定的交流
真实场景：google adsence的一个需求，你希望google发现您的页面不能匹配出相关性非常好的按点击付费广告时，你希望google的广告iframe能够隐藏。
google的广告iframe在google域下显然不能把自己隐藏掉，那么怎么办呢？
1、google会提供给你一个html页面
2、您将这个页面放置在您的域名下，并告诉google它的位置
3、当google发现没有很好的广告时，会将子窗口的loaction重定向到您的那个页面下，这样您的页面因为同域名就可以访问父页面来隐藏自己了
是不是很巧的方法？

场景四：您是内容发布商，如何改造接口，让其他域名下的页面可以从浏览器端出发获得您的数据
我们知道ajax的xmlHttpRequest()说到底是一个无刷新请求服务器数据的辅助工具，但是xmlHttpRequest并不能跨域名请求数据，在某些情况下成了极大的限制。
但是我们如果通过其他方式完成无刷新请求数据不也可以么，我们用Dom方法操作动态JS脚本请求来做这件事。
    //创建一个脚本节点
    var oScript = document.createElement(’script’);
    //指定脚本src src可以指向任意域名
    //注意src不再指向静态js，而是带着查询参数指向一个动态脚本广播服务。
    oScript.src = “http://yyy.com/query.php?”+yourQueryString;   
    //如果指定了charset 同时还可以解决xmlHttpRequest另一大困扰 乱码问题                                                                                                                           
    //oScript.charset = “utf-8″;
    //通过Dom操作把这个新的节点加入到文档当中                                 
    document.getElementsByTagName(”head”)[0].appendChild(oScript);

这样只要query.php的输出是可执行的javaScript脚本，比如：djsCallBack（{jsondata}）;
当他从服务器返回后就会自动执行,你可以方便的用json方式来做数据传递了。
要注意，您的脚本请求最好带上时间戳，避免浏览器缓存造成取回数据实时性下降。

如果您是数据提供者，您可以要求数据索取者在查询参数中提供回调函数名，比如query.php?callback=myDataHandler&key=…?
这样您就可以根据参数来提供给他myDataHandler({jsondata}),这样不同的数据索取者都会得到自定义的正确的异步回调。

场景五：通过后端程序语言，为了跨域名而做各自的后台数据抓取转化服务，比如php curl，YAHOO  CHINA NCP就是用这种方案。

场景六：通过flash proxy，因为flash的跨域调用可以通过crossdomain.xml和security.allowdomain(’*')文件实现，而js又可以和flash进行通信，所以js完全可以借用flash

               实现js跨域通信。

 
总结总结：
第一种场景，相应的处理办法有这非常好的效果，可以说完全解决了问题。
第二种场景，相应的处理办法具有一定的跨域数据交流功效，具有相当大的局限，并不适合在复杂业务流程中应用，实际上我也确实也没看到过基于此的大规模应用。
第三种场景，相应的处理办法比较巧妙，虽然redirect之后就不干你什么事了，但如果你是google一样面向众多域名的内容提供商，也是个不错的解决思路。
第四种场景，相应的处理办法非常强大，对比Ajax可以看到，跨域名没问题，无刷新没问题，本身又是异步的，JSON比xml快的多，同时解决乱码问题，只是请求都是Get方式的，不能做Post方式的请求。多一种武器自然可以从容选择了。

第五种场景，处理很方便，也很实用。

第六种场景，需要一定的flash基础哈，作用当然非常强大。

        从上面测试中感受到不同的用户体验.对大多数做web开发的人来说,判断浏览器是否支持Cookie并不是什么难事!难的是对细节的处理!
        也许我们与优秀的产品差距最大的是对细节的处理!
        
        附: 我测试用的是IE6.0

浏览和修改Web页的文档对象模型(DOM).通过多种技术方式定位、选定Web页上的特定元素.禁止或激活IE设置.查看HTML对象的类名、 ID,以及类似链接路径、tab顺序、快捷键等细节.描绘表格、单元格、图片或选定标签的轮廓.显示图片象素、大小、路径、替代文字等.即时重定义浏览器 窗口大小到800x600或自定义大小.清空浏览器缓存和cookie,被清除项可从所有对象或给定域中选择.直接访问关联W3C规范参考、IE开发组 blog或其他来源.－显示设计时标尺,帮助对齐对象. .... 

下载地址及相关资料：
http://www.microsoft.com/downloads/details.aspx?FamilyID=e59c3964-672d-4511-bb3e-2d5e1db91038&DisplayLang=en#Overview

HttpWatch
简介：强大的网页数据分析工具。集成在Internet Explorer工具栏。包括网页摘要。Cookies管理。缓存管理。消息头发送/接受。字符查询。POST 数据和目录管理功能。报告输出。

安装完HttpWatch后，就会在浏览器中找到他：

主界面：
 
下载地址：http://www.crsky.com/soft/3455.html

使用介绍：http://www.cnblogs.com/mayingbao/archive/2007/11/30/978530.html

Fiddler2

简介：Fiddler2是一个网络调试代理，用来监测本地计算 机和Internet之间所有的HTTP通讯。可以监测所有的HTTP通讯，设置断点，并且可以修改到进入到本地计算机的数据和从本地计算机出去的数据 （就是可以伪造数据）。Fiddler包含一个JScript .NET 事件脚本子系统（event-based scripting subsystem），可以使用任何一种.Net语言扩展。该软件是免费的，支持多种浏览器，包括Internet Explorer，Mozilla Firefox，Opera和其它一些浏览器。

从Fiddler官方网站上可以看见原版的英文介绍：http://www.fiddler2.com/fiddler2/
下载地址：http://www.fiddler2.com/fiddler2/

使用介绍：http://blog.csdn.net/lihongzhai/archive/2009/09/14/4551035.aspx

NUnit 

NUnit是一个单元测试框架，专门针对于。NET来写的.其实在前面有JUnit(Java)，CPPUnit(C++)，他们都是xUnit的一员。最初它是从JUnit而来。现在的版本是2.2.接下来我所用的都是基于这个版本。

下载地址：http://www.nunit.org/index.php

使用介绍：http://www.uml.org.cn/net/200702273.asp

PowerDesigner

简介：PowerDesigner是Sybase公司的CASE工具集，使用它可以方便地对管理信息系统进行分析设计，它几乎包括了数据库模型设计的全过程。
利用PowerDesigner可以制作数据流程图、概念数据模型、物理数据模型，可以生成多种客户端开发工具的应用程序，还可为数据仓库制作结构模型，也能对团队设计模型进行控制。

主要功能：DataArchitect：这是一个强大的数据库设计工具，使用DataArchitect 可利用实体-关系图为一个信息系统。创建"概念数据模型"－CDM（Conceptual Data Model）。并且可根据CDM 产生基于某一特定数据库管理系统（例如：Sybase System 11）的"物理数据模型"-PDM(Physical Data Model)。还可优化PDM，产生为特定DBMS 创建数据库的SQL 语句并可以文件形式存储以便在其他时刻运行这些SQL 语句创建数据库。另外，DataArchitect还可根据已存在的数据库反向生成
PDM，CDM 及创建数据库的SQL脚本。
ProcessAnalyst：这部分用于创建功能模型和数据流图，创建"处理层次关系"。
AppModeler：为客户/服务器应用程序创建应用模型。
ODBC Administrator：此部分用来管理系统的各种数据源。

下载地址：http://www.baidu.com/s?tn=sitehao123&bs=PowerDesigner&f=3&wd=powerdesigner%CF%C2%D4%D8&oq=powerdesigner&rsp=0 ：)

使用介绍： http://www.cnblogs.com/yxonline/archive/2007/04.html

 Reflector

简介：Visual Studio内置的ILDASM成为最初挖掘程序集的上佳工具。 但自从Reflector出现后，ILDASM相形见拙。因为，Reflector能提供更多的程序集信息。Reflector可以将.NET程序集中的 中间语言反编译成C#或者Visual Basic代码。除了能将IL转换为C#或Visual Basic以外，Reflector还能够提供程序集中类及其成员的概要信息、提供查看程序集中IL的能力以及提供对第三方插件的支持。

下载地址： /Files/gaoweipeng/Reflector.rar

使用介绍及其他相关下载：http://www.cnblogs.com/zzy2740/archive/2005/09/20/240216.html

1st JavaScript Editor

简介： 1st JavaScript Editor 是一款强大的JavaScript开发、校验和调试工具， 它简单易用，不论你是初学者或者是专业的开发人士，都可以轻松上手！同时它又是完美的Ajax (Asynchronous JavaScript and XML),CSS, HTML, DOM DHTML开发工具！它提供了简单而且实用的功能：丰富的代码编辑功能(JavaScript, HTML, CSS, VBScript, PHP ,ASP(Net))，语法高亮，内置预览功能，提供了完整的HTML 标记, HTML 属性, HTML 事件, JavaScript 事件和JavaScript 函数等完整的代码库，同时有着贴心的代码自动补全功能。

官网及下载地址：http://yaldex.com/

Regulator

简介：使用Reglator可以方便的验证正则表达式的执行结果，带有智能感知功能。帮助文档是一个很好的学习正则的入门教程，也可以当作参考手册。基本上就全了，同时进行学习和实践。还有生成c# or vb.net代码等附加功能。 类似的软件现在很多：RegexBuddy ，RegexTester。等

 下载地址：http://sourceforge.net/projects/regulator/

 使用介绍：http://www.ctochina.net/topic/ShowArticle/112.html

 小结：上面的开发工具都是我平时喜欢用的，希望通过此文的介绍，对没有使用过的朋友带来帮助。也希望园子中的朋友们秀一秀自己平时常用的开发工具，分享些更实用，方便的开发工具！

首先，请到http://www.andykhan.com/jexcelapi/index.html下载java excel api，主页上同时有比较详细的介绍。最新版本为2.4.3，同时也可以到：http://www.andykhan.com/jexcelapi/jexcelapi_2_4_3.tar.gz下载到该最新版的API，由于该项目是开源的，所以下载的文件中已经包含了源代码，同样的，文件中也有javadoc，大家在开发中可以参考javadoc。

下载完毕后，我们需要把文件中的jxl.jar加入到你的开发classpath中。
下图是现在要生产的excel截图：
http://blog.csdn.net/beming/gallery/image/3437.aspx

代码如下：

   File excel = new File("d:/aming.xls");
   if(!excel.exists()){
    excel.createNewFile();
   }   
   WritableWorkbook wwb = Workbook.createWorkbook(excel);
   WritableSheet ws = wwb.createSheet("testexcel",0);
   Label lable = null;
   
   //对中文的支持非常好
   lable = new Label(0,0,"我的中国心");
   ws.addCell(lable);
   
   //可以定义模板格式化你的cell
   WritableFont wf = new WritableFont(WritableFont.ARIAL,10,WritableFont.NO_BOLD,false,UnderlineStyle.NO_UNDERLINE, Colour.BLACK);
   WritableCellFormat wcf = new WritableCellFormat(wf);
   wcf.setBackground(Colour.WHITE);
   lable = new Label(0,1,"fdsl",wcf);
   ws.addCell(lable);
   
   wf = new WritableFont(WritableFont.TIMES,18,WritableFont.BOLD,true);
   wcf = new WritableCellFormat(wf);
   lable = new Label(0,2,"aming",wcf);
   ws.addCell(lable);
   
   //cell的类型同样可以定义为数字类型
   Number nb = new Number(0,3,21.4321321);
   ws.addCell(nb);
   
   //支持格式化你的数字串
   NumberFormat nf = new NumberFormat("#.###");
   wcf = new WritableCellFormat(nf);
   nb = new Number(0,4,21.43254354354354,wcf);
   ws.addCell(nb);

   //cell的类型可以为boolean类型
   Boolean bl = new Boolean(0,5,true);
   ws.addCell(bl);

   //cell的类型同样可以为日期，时间
   DateTime dt = new DateTime(0,6,new Date());
   ws.addCell(dt);

   //并且可以很好格式化你的日期格式
   DateFormat df = new DateFormat("MM dd yyyy hh:mm:ss");
   wcf = new WritableCellFormat(df);
   dt = new DateTime(0,7,new Date(),wcf);
   ws.addCell(dt);
   
   //开始写文件了
   wwb.write();
   wwb.close();

上面的下载地址无法打开.
下载请到:http://prdownloads.sourceforge.net/jexcelapi

5.2 分配JSP初始化参数
给JSP页面提供初始化参数在三个方面不同于给servlet提供初始化参数。
1）使用jsp-file而不是servlet-class。因此，WEB-INF/web.xml文件的servlet元素如下所示：

<servlet>
<servlet-name>PageName</servlet-name>
<jsp-file>/RealPage.jsp</jsp-file>
<init-param>
<param-name>...</param-name>
<param-value>...</param-value>
</init-param>
...
</servlet>

2) 几乎总是分配一个明确的URL模式。对servlet，一般相应地使用以http://host/webAppPrefix/servlet/ 开始的缺省URL。只需记住，使用注册名而不是原名称即可。这对于JSP页面在技术上也是合法的。例如，在上面给出的例子中，可用URL http://host/webAppPrefix/servlet/PageName 访问RealPage.jsp的对初始化参数具有访问权的版本。但在用于JSP页面时，许多用户似乎不喜欢应用常规的servlet的URL。此外，如果 JSP页面位于服务器为其提供了目录清单的目录中（如，一个既没有index.html也没有index.jsp文件的目录），则用户可能会连接到此 JSP页面，单击它，从而意外地激活未初始化的页面。因此，好的办法是使用url-pattern（5.3节）将JSP页面的原URL与注册的 servlet名相关联。这样，客户机可使用JSP页面的普通名称，但仍然激活定制的版本。例如，给定来自项目1的servlet定义，可使用下面的 servlet-mapping定义：

<servlet-mapping>
<servlet-name>PageName</servlet-name>
<url-pattern>/RealPage.jsp</url-pattern>
</servlet-mapping>

3）JSP页使用jspInit而不是init。自动从JSP页面建立的servlet或许已经使用了inti方法。因此，使用JSP声明提供一个init方法是不合法的，必须制定jspInit方法。
为 了说明初始化JSP页面的过程，程序清单5-9给出了一个名为InitPage.jsp的JSP页面，它包含一个jspInit方法且放置于 deployDemo Web应用层次结构的顶层。一般，http://host/deployDemo/InitPage.jsp 形式的URL将激活此页面的不具有初始化参数访问权的版本，从而将对firstName和emailAddress变量显示null。但是， web.xml文件（程序清单5-10）分配了一个注册名，然后将该注册名与URL模式/InitPage.jsp相关联。

程序清单5-9 InitPage.jsp

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD><TITLE>JSP Init Test</TITLE></HEAD>
<BODY BGCOLOR="#FDF5E6">
<H2>Init Parameters:</H2>
<UL>
<LI>First name: <%= firstName %>
<LI>Email address: <%= emailAddress %>
</UL>
</BODY></HTML>
<%!
private String firstName, emailAddress;
public void jspInit() {
ServletConfig config = getServletConfig();
firstName = config.getInitParameter("firstName");
emailAddress = config.getInitParameter("emailAddress");
}
%>

程序清单5-10 web.xml（说明JSP页面的init参数的摘录）

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- ... -->
<servlet>
<servlet-name>InitPage</servlet-name>
<jsp-file>/InitPage.jsp</jsp-file>
<init-param>
<param-name>firstName</param-name>
<param-value>Bill</param-value>
</init-param>
<init-param>
<param-name>emailAddress</param-name>
<param-value>gates@oracle.com</param-value>
</init-param>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name> InitPage</servlet-name>
<url-pattern>/InitPage.jsp</url-pattern>
</servlet-mapping>
<!-- ... -->
</web-app>

5.3 提供应用范围内的初始化参数
一般，对单个地servlet或JSP页面分配初始化参数。指定的servlet或 JSP页面利用ServletConfig的getInitParameter方法读取这些参数。但是，在某些情形下，希望提供可由任意servlet或 JSP页面借助ServletContext的getInitParameter方法读取的系统范围内的初始化参数。
可利用context-param元素声明这些系统范围内的初始化值。context-param元素应该包含param-name、param-value以及可选的description子元素，如下所示：
<context-param>
<param-name>support-email</param-name>
<param-value>blackhole@mycompany.com</param-value>
</context-param>
可 回忆一下，为了保证可移植性，web.xml内的元素必须以正确的次序声明。但这里应该注意，context-param元素必须出现任意与文档有关的元 素（icon、display-name或description）之后及filter、filter-mapping、listener或 servlet元素之前。
5.4 在服务器启动时装载servlet
假如servlet或JSP页面有一个要花很长时间执行的 init （servlet）或jspInit（JSP）方法。例如，假如init或jspInit方法从某个数据库或ResourceBundle查找产量。这种 情况下，在第一个客户机请求时装载servlet的缺省行为将对第一个客户机产生较长时间的延迟。因此，可利用servlet的load-on- startup元素规定服务器在第一次启动时装载servlet。下面是一个例子。

<servlet>
<servlet-name> … </servlet-name>
<servlet-class> … </servlet-class> <!-- or jsp-file -->
<load-on-startup/>
</servlet>

可以为此元素体提供一个整数而不是使用一个空的load-on-startup。想法是服务器应该在装载较大数目的servlet或JSP页面之前 装载较少数目的servlet或JSP页面。例如，下面的servlet项（放置在Web应用的WEB-INF目录下的web.xml文件中的web- app元素内）将指示服务器首先装载和初始化SearchServlet，然后装载和初始化由位于Web应用的result目录中的index.jsp文 件产生的 servlet。

<servlet>
<servlet-name>Search</servlet-name>
<servlet-class>myPackage.SearchServlet</servlet-class> <!-- or jsp-file -->
<load-on-startup>1</load-on-startup>
</servlet>
<servlet>
<servlet-name>Results</servlet-name>
<servlet-class>/results/index.jsp</servlet-class> <!-- or jsp-file -->
<load-on-startup>2</load-on-startup>
</servlet>

6 声明过滤器

servlet版本2.3引入了过滤器的概念。虽然所有支持servlet API版本2.3的服务器都支持过滤器，但为了使用与过滤器有关的元素，必须在web.xml中使用版本2.3的DTD。
过 滤器可截取和修改进入一个servlet或JSP页面的请求或从一个servlet或JSP页面发出的相应。在执行一个servlet或JSP页面之前， 必须执行第一个相关的过滤器的doFilter方法。在该过滤器对其FilterChain对象调用doFilter时，执行链中的下一个过滤器。如果没 有其他过滤器，servlet或JSP页面被执行。过滤器具有对到来的ServletRequest对象的全部访问权，因此，它们可以查看客户机名、查找 到来的cookie等。为了访问servlet或JSP页面的输出，过滤器可将响应对象包裹在一个替身对象（stand-in object）中，比方说把输出累加到一个缓冲区。在调用FilterChain对象的doFilter方法之后，过滤器可检查缓冲区，如有必要，就对它 进行修改，然后传送到客户机。
例如，程序清单5-11帝国难以了一个简单的过滤器，只要访问相关的servlet或JSP页面，它就截取请求并在标准输出上打印一个报告（开发过程中在桌面系统上运行时，大多数服务器都可以使用这个过滤器）。

程序清单5-11 ReportFilter.java

package moreservlets;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;
/** Simple filter that prints a report on the standard output
* whenever the associated servlet or JSP page is accessed.
* <P>
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class ReportFilter implements Filter {
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws ServletException, IOException {
HttpServletRequest req = (HttpServletRequest)request;
System.out.println(req.getRemoteHost() +
" tried to access " +
req.getRequestURL() +
" on " + new Date() + ".");
chain.doFilter(request,response);
}
public void init(FilterConfig config)
throws ServletException {
}
public void destroy() {}
}

一旦建立了一个过滤器，可以在web.xml中利用filter元素以及filter-name（任意名称）、file-class（完全限定的类 名）和（可选的）init-params子元素声明它。请注意，元素在web.xml的web-app元素中出现的次序不是任意的；允许服务器（但不是必 需的）强制所需的次序，并且实际中有些服务器也是这样做的。但这里要注意，所有filter元素必须出现在任意filter-mapping元素之前， filter-mapping元素又必须出现在所有servlet或servlet-mapping元素之前。
例如，给定上述的ReportFilter类，可在web.xml中作出下面的filter声明。它把名称Reporter与实际的类ReportFilter（位于moreservlets程序包中）相关联。

<filter>
<filter-name>Reporter</filter-name>
<filter-class>moresevlets.ReportFilter</filter-class>
</filter>

一旦命名了一个过滤器，可利用filter-mapping元素把它与一个或多个servlet或JSP页面相关联。关于此项工作有两种选择。
首 先，可使用filter-name和servlet-name子元素把此过滤器与一个特定的servlet名（此servlet名必须稍后在相同的 web.xml文件中使用servlet元素声明）关联。例如，下面的程序片断指示系统只要利用一个定制的URL访问名为SomeServletName 的servlet或JSP页面，就运行名为Reporter的过滤器。

<filter-mapping>
<filter-name>Reporter</filter-name>
<servlet-name>SomeServletName</servlet-name>
</filter-mapping>

其次，可利用filter-name和url-pattern子元素将过滤器与一组servlet、JSP页面或静态内容相关联。例如，相面的程序片段指示系统只要访问Web应用中的任意URL，就运行名为Reporter的过滤器。

<filter-mapping>
<filter-name>Reporter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

例如，程序清单5-12给出了将ReportFilter过滤器与名为PageName的servlet相关联的web.xml文件的一部分。名字 PageName依次又与一个名为TestPage.jsp的JSP页面以及以模式http: //host/webAppPrefix/UrlTest2/ 开头的URL相关联。TestPage.jsp的源代码已经JSP页面命名的谈论在前面的3节"分配名称和定制的URL"中给出。事实上，程序清单5- 12中的servlet和servlet-name项从该节原封不动地拿过来的。给定这些web.xml项，可看到下面的标准输出形式的调试报告（换行是 为了容易阅读）。
audit.irs.gov tried to access
http://mycompany.com/deployDemo/UrlTest2/business/tax-plan.html
on Tue Dec 25 13:12:29 EDT 2001.

程序清单5-12 Web.xml（说明filter用法的摘录）

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<filter>
<filter-name>Reporter</filter-name>
<filter-class>moresevlets.ReportFilter</filter-class>
</filter>
<!-- ... -->
<filter-mapping>
<filter-name>Reporter</filter-name>
<servlet-name>PageName</servlet-name>
</filter-mapping>
<!-- ... -->
<servlet>
<servlet-name>PageName</servlet-name>
<jsp-file>/RealPage.jsp</jsp-file>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name> PageName </servlet-name>
<url-pattern>/UrlTest2/*</url-pattern>
</servlet-mapping>
<!-- ... -->
</web-app>

7 指定欢迎页 假如用户提供了一个像http: //host/webAppPrefix/directoryName/ 这样的包含一个目录名但没有包含文件名的URL，会发生什么事情呢？用户能得到一个目录表？一个错误？还是标准文件的内容？如果得到标准文件内容，是 index.html、index.jsp、default.html、default.htm或别的什么东西呢？ Welcome-file-list 元素及其辅助的welcome-file元素解决了这个模糊的问题。例如，下面的web.xml项指出，如果一个URL给出一个目录名但未给出文件名，服 务器应该首先试用index.jsp，然后再试用index.html。如果两者都没有找到，则结果有赖于所用的服务器（如一个目录列表）。 虽然许多服务器缺省遵循这种行为，但不一定必须这样。因此，明确地使用welcom-file-list保证可移植性是一种良好的习惯。

8 指定处理错误的页面 现在我了解到，你在开发servlet和JSP页面时从不会犯错误，而且你的所有页面是那样的清晰，一般的程序员都不会被它们的搞糊涂。但是，是人总会犯 错误的，用户可能会提供不合规定的参数，使用不正确的URL或者不能提供必需的表单字段值。除此之外，其它开发人员可能不那么细心，他们应该有些工具来克 服自己的不足。 error-page元素就是用来克服这些问题的。它有两个可能的子元素，分别是：error-code和exception- type。第一个子元素error-code指出在给定的HTTP错误代码出现时使用的URL。第二个子元素excpetion-type指出在出现某个 给定的Java异常但未捕捉到时使用的URL。error-code和exception-type都利用location元素指出相应的URL。此 URL必须以/开始。location所指出的位置处的页面可通过查找HttpServletRequest对象的两个专门的属性来访问关于错误的信息， 这两个属性分别是：javax.servlet.error.status_code和javax.servlet.error.message。 可回忆一下，在web.xml内以正确的次序声明web-app的子元素很重要。这里只要记住，error-page出现在web.xml文件的末尾附 近，servlet、servlet-name和welcome-file-list之后即可。

8.1 error-code元素 为了更好地了解error-code元素的值，可考虑一下如果不正确地输入文件名，大多数站点会作出什么反映。这样做一般会出现一个404错误信息，它表 示不能找到该文件，但几乎没提供更多有用的信息。另一方面，可以试一下在www.microsoft.com、www.ibm.com 处或者特别是在www.bea.com 处输出未知的文件名。这是会得出有用的消息，这些消息提供可选择的位置，以便查找感兴趣的页面。提供这样有用的错误页面对于Web应用来说是很有价值得。 事实上rm-error-page子元素）。由form-login-page给出的HTML表单必须具有一个j_security_check的 ACTION属性、一个名为j_username的用户名文本字段以及一个名为j_password的口令字段。 例如，程序清单5-19指示服务器使用基于表单的验证。Web应用的顶层目录中的一个名为login.jsp的页面将收集用户名和口令，并且失败的登陆将 由相同目录中名为login-error.jsp的页面报告。 程序清单5-19 web.xml（说明login-config的摘录）

9.2 限制对Web资源的访问 现在，可以指示服务器使用何种验证方法了。"了不起，"你说道，"除非我能指定一个来收到保护的 URL，否则没有多大用处。"没错。指出这些URL并说明他们应该得到何种保护正是security-constriaint元素的用途。此元素在 web.xml中应该出现在login-config的紧前面。它包含是个可能的子元素，分别是：web-resource-collection、 auth-constraint、user-data-constraint和display-name。下面各小节对它们进行介绍。 l web-resource-collection 此元素确定应该保护的资源。所有security-constraint元素都必须包含至少一个web-resource-collection项。此元 素由一个给出任意标识名称的web-resource-name元素、一个确定应该保护的URL的url-pattern元素、一个指出此保护所适用的 HTTP命令（GET、POST等，缺省为所有方法）的http-method元素和一个提供资料的可选description元素组成。例如，下面的 Web-resource-collection项（在security-constratint元素内）指出Web应用的proprietary目录中 所有文档应该受到保护。 重要的是应该注意到，url-pattern仅适用于直接访问这些资源的客户机。特别是，它不适合于通过MVC体系结构利用 RequestDispatcher来访问的页面，或者不适合于利用类似jsp:forward的手段来访问的页面。这种不匀称如果利用得当的话很有好 处。例如，servlet可利用MVC体系结构查找数据，把它放到bean中，发送请求到从bean中提取数据的JSP页面并显示它。我们希望保证决不直 接访问受保护的JSP页面，而只是通过建立该页面将使用的bean的servlet来访问它。url-pattern和auth-contraint元素 可通过声明不允许任何用户直接访问JSP页面来提供这种保证。但是，这种不匀称的行为可能让开发人员放松警惕，使他们偶然对应受保护的资源提供不受限制的 访问。 l auth-constraint 尽管web-resource-collention元素质出了哪些URL应该受到保护，但是auth-constraint元素却指出哪些用户应该具有 受保护资源的访问权。此元素应该包含一个或多个标识具有访问权限的用户类别role- name元素，以及包含（可选）一个描述角色的description元素。例如，下面web.xml中的security-constraint元素部 门规定只有指定为Administrator或Big Kahuna（或两者）的用户具有指定资源的访问权。 重要的是认识到，到此为止，这个过程的可移植部分结束了。服务器怎样确定哪些用户处于任何角色以及它怎样存放用户的口令，完全有赖于具体的系统。 例如，Tomcat使用install_dir/conf/tomcat-users.xml将用户名与角色名和口令相关联，正如下面例子中所示，它指出 用户joe（口令bigshot）和jane（口令enaj）属于administrator和kahuna角色。 l user-data-constraint 这个可选的元素指出在访问相关资源时使用任何传输层保护。它必须包含一个transport-guarantee子元素（合法值为NONE、 INTEGRAL或CONFIDENTIAL），并且可选地包含一个description元素。transport-guarantee为NONE值将 对所用的通讯协议不加限制。INTEGRAL值表示数据必须以一种防止截取它的人阅读它的方式传送。虽然原理上（并且在未来的HTTP版本中），在 INTEGRAL和CONFIDENTIAL之间可能会有差别，但在当前实践中，他们都只是简单地要求用SSL。例如，下面指示服务器只允许对相关资源做 HTTPS连接： l display-name security-constraint的这个很少使用的子元素给予可能由GUI工具使用的安全约束项一个名称。 9.3 分配角色名 迄今为止，讨论已经集中到完全由容器（服务器）处理的安全问题之上了。但servlet以及JSP页面也能够处理它们自己的安全问题。 例如，容器可能允许用户从bigwig或bigcheese角色访问一个显示主管人员额外紧贴的页面，但只允许bigwig用户修改此页面的参数。完成这 种更细致的控制的一种常见方法是调用HttpServletRequset的isUserInRole方法，并据此修改访问。 Servlet的 security-role-ref子元素提供出现在服务器专用口令文件中的安全角色名的一个别名。例如，假如编写了一个调用 request.isUserInRole（"boss"）的servlet，但后来该servlet被用在了一个其口令文件调用角色manager而不 是boss的服务器中。下面的程序段使该servlet能够使用这两个名称中的任何一个。 也可以在web-app内利用security-role元素提供将出现在role-name元素中的所有安全角色的一个全局列表。分别地生命角色使高级 IDE容易处理安全信息。 10 控制会话超时 如果某个会话在一定的时间内未被访问，服务器可把它扔掉以节约内存。可利用HttpSession的setMaxInactiveInterval方法直 接设置个别会话对象的超时值。如果不采用这种方法，则缺省的超时值由具体的服务器决定。但可利用session-config和session- timeout元素来给出一个适用于所有服务器的明确的超时值。超时值的单位为分钟，因此，下面的例子设置缺省会话超时值为三个小时（180分钟）。

11 Web应用的文档化 越来越多的开发环境开始提供servlet和JSP的直接支持。例子有Borland Jbuilder Enterprise Edition、Macromedia UltraDev、Allaire JRun Studio（写此文时，已被Macromedia收购）以及IBM VisuaAge for Java等。 大量的web.xml元素不仅是为服务器设计的，而且还是为可视开发环境设计的。它们包括icon、display-name和discription 等。 可回忆一下，在web.xml内以适当地次序声明web-app子元素很重要。不过，这里只要记住icon、display-name和 description是web.xml的web-app元素内的前三个合法元素即可。 l icon icon元素指出GUI工具可用来代表Web应用的一个和两个图像文件。可利用small-icon元素指定一幅16 x 16的GIF或JPEG图像，用large-icon元素指定一幅32 x 32的图像。下面举一个例子： l display-name display-name元素提供GUI工具可能会用来标记此Web应用的一个名称。下面是个例子。 l description description元素提供解释性文本，如下所示： 12 关联文件与MIME类型 服务器一般都具有一种让Web站点管理员将文件扩展名与媒体相关联的方法。例如，将会自动给予名为mom.jpg的文件一个image/jpeg的 MIME 类型。但是，假如你的Web应用具有几个不寻常的文件，你希望保证它们在发送到客户机时分配为某种MIME类型。mime-mapping元素（具有 extension和mime-type子元素）可提供这种保证。例如，下面的代码指示服务器将application/x-fubar的MIME类型分 配给所有以.foo结尾的文件。 或许，你的Web应用希望重载（override）标准的映射。例如，下面的代码将告诉服务器在发送到客户机时指定.ps文件作为纯文本 （text/plain）而不是作为PostScript（application/postscript）。

13 定位TLD JSP taglib元素具有一个必要的uri属性，它给出一个TLD（Tag Library Descriptor）文件相对于Web应用的根的位置。TLD文件的实际名称在发布新的标签库版本时可能会改变，但我们希望避免更改所有现有JSP页 面。此外，可能还希望使用保持taglib元素的简练性的一个简短的uri。这就是部署描述符文件的taglib元素派用场的所在了。Taglib包含两 个子元素：taglib-uri和taglib-location。taglib-uri元素应该与用于JSP taglib元素的uri属性的东西相匹配。Taglib-location元素给出TLD文件的实际位置。例如，假如你将文件chart-tags- 1.3beta.tld放在WebApp/WEB-INF/tlds中。现在，假如web.xml在web-app元素内包含下列内容。 给出这个说明后，JSP页面可通过下面的简化形式使用标签库。 14 指定应用事件监听程序 应用事件监听器程序是建立或修改servlet环境或会话对象时通知的类。它们是servlet规范的版本2.3中的新内容。这里只简单地说明用来向 Web应用注册一个监听程序的web.xml的用法。 注册一个监听程序涉及在web.xml的web-app元素内放置一个listener元素。在listener元素内，listener-class元 素列出监听程序的完整的限定类名，如下所示： <listener> 虽然listener元素的结构很简单，但请不要忘记，必须正确地给出web-app元素内的子元素的次序。listener元素位于所有的 servlet 元素之前以及所有filter-mapping元素之后。此外，因为应用生存期监听程序是serlvet规范的2.3版本中的新内容，所以必须使用 web.xml DTD的2.3版本，而不是2.2版本。 例如，程序清单5-20给出一个名为ContextReporter的简单的监听程序，只要Web应用的Servlet-Context建立（如装载 Web应用）或消除（如服务器关闭）时，它就在标准输出上显示一条消息。程序清单5-21给出此监听程序注册所需要的web.xml文件的一部分。 程序清单5-20 ContextReporterjava 程序清单5-21 web.xml（声明一个监听程序的摘录） 15 J2EE元素 本节描述用作J2EE环境组成部分的Web应用的web.xml元素。这里将提供一个简明的介绍，详细内容可以参阅 http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf的Java 2 Plantform Enterprise Edition版本1.3规范的第5章。 l distributable distributable 元素指出，Web应用是以这样的方式编程的：即，支持集群的服务器可安全地在多个服务器上分布Web应用。例如，一个可分布的应用必须只使用 Serializable对象作为其HttpSession对象的属性，而且必须避免用实例变量（字段）来实现持续性。distributable元素直 接出现在discription元素之后，并且不包含子元素或数据，它只是一个如下的标志。 l resource-env-ref resource -env-ref元素声明一个与某个资源有关的管理对象。此元素由一个可选的description元素、一个resource-env-ref- name元素（一个相对于java:comp/env环境的JNDI名）以及一个resource-env-type元素（指定资源类型的完全限定的 类），如下所示： l env-entry env -entry元素声明Web应用的环境项。它由一个可选的description元素、一个env-entry-name元素（一个相对于java: comp/env环境JNDI名）、一个env-entry-value元素（项值）以及一个env-entry-type元素（java.lang程序 包中一个类型的完全限定类名，java.lang.Boolean、java.lang.String等）组成。下面是一个例子： l ejb-ref ejb -ref元素声明对一个EJB的主目录的应用。它由一个可选的description元素、一个ejb-ref-name元素（相对于java: comp/env的EJB应用）、一个ejb-ref-type元素（bean的类型，Entity或Session）、一个home元素（bean的主 目录接口的完全限定名）、一个remote元素（bean的远程接口的完全限定名）以及一个可选的ejb-link元素（当前bean链接的另一个 bean的名称）组成。 l ejb-local-ref ejb-local-ref元素声明一个EJB的本地主目录的引用。除了用local-home代替home外，此元素具有与ejb-ref元素相同的属 性并以相同的方式使用。

<servlet>
<servlet-name>Test</servlet-name>
<servlet-class>moreservlets.TestServlet</servlet-class>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name>Test</servlet-name>
<url-pattern>/UrlTest</url-pattern>
</servlet-mapping>

URL模式还可以包含通配符。例如，下面的小程序指示服务器发送所有以Web应用的URL前缀开始，以..asp结束的请求到名为BashMS的servlet。

<servlet>
<servlet-name>BashMS</servlet-name>
<servlet-class>msUtils.ASPTranslator</servlet-class>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name>BashMS</servlet-name>
<url-pattern>/*.asp</url-pattern>
</servlet-mapping>

3.3 命名JSP页面
因为JSP页面要转换成sevlet，自然希望就像命名servlet一样命名JSP页面。毕竟，JSP 页面可能会从初始化参数、安全设置或定制的URL中受益，正如普通的serlvet那样。虽然JSP页面的后台实际上是servlet这句话是正确的，但 存在一个关键的猜疑：即，你不知道JSP页面的实际类名（因为系统自己挑选这个名字）。因此，为了命名JSP页面，可将jsp-file元素替换为 servlet-calss元素，如下所示：

<servlet>
<servlet-name>Test</servlet-name>
<jsp-file>/TestPage.jsp</jsp-file>
</servlet>

命名JSP页面的原因与命名servlet的原因完全相同：即为了提供一个与定制设置（如，初始化参数和安全设置）一起使用的名称，并且，以便能更 改激活 JSP页面的URL（比方说，以便多个URL通过相同页面得以处理，或者从URL中去掉.jsp扩展名）。但是，在设置初始化参数时，应该注意，JSP页 面是利用jspInit方法，而不是init方法读取初始化参数的。
例如，程序清单5-3给出一个名为TestPage.jsp的简单JSP 页面，它的工作只是打印出用来激活它的URL的本地部分。TestPage.jsp放置在deployDemo应用的顶层。程序清单5-4给出了用来分配 一个注册名PageName，然后将此注册名与http://host/webAppPrefix/UrlTest2/anything 形式的URL相关联的web.xml文件（即，deployDemo/WEB-INF/web.xml）的一部分。

程序清单5-3 TestPage.jsp

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE>
JSP Test Page
</TITLE>
</HEAD>
<BODY BGCOLOR="#FDF5E6">
<H2>URI: <%= request.getRequestURI() %></H2>
</BODY>
</HTML>

程序清单5-4 web.xml（说明JSP页命名的摘录）

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- ... -->
<servlet>
<servlet-name>PageName</servlet-name>
<jsp-file>/TestPage.jsp</jsp-file>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name> PageName </servlet-name>
<url-pattern>/UrlTest2/*</url-pattern>
</servlet-mapping>
<!-- ... -->
</web-app>

4 禁止激活器servlet

对servlet或JSP页面建立定制URL的一个原因是，这样做可以注册从 init（servlet）或jspInit（JSP页面）方法中读取得初始化参数。但是，初始化参数只在是利用定制URL模式或注册名访问 servlet或JSP页面时可以使用，用缺省URL http://host/webAppPrefix/servlet/ServletName 访问时不能使用。因此，你可能会希望关闭缺省URL，这样就不会有人意外地调用初始化servlet了。这个过程有时称为禁止激活器servlet，因为 多数服务器具有一个用缺省的servlet URL注册的标准servlet，并激活缺省的URL应用的实际servlet。
有两种禁止此缺省URL的主要方法：
l 在每个Web应用中重新映射/servlet/模式。
l 全局关闭激活器servlet。
重 要的是应该注意到，虽然重新映射每个Web应用中的/servlet/模式比彻底禁止激活servlet所做的工作更多，但重新映射可以用一种完全可移植 的方式来完成。相反，全局禁止激活器servlet完全是针对具体机器的，事实上有的服务器（如ServletExec）没有这样的选择。下面的讨论对每 个Web应用重新映射/servlet/ URL模式的策略。后面提供在Tomcat中全局禁止激活器servlet的详细内容。
4.1 重新映射/servlet/URL模式
在 一个特定的Web应用中禁止以http://host/webAppPrefix/servlet/ 开始的URL的处理非常简单。所需做的事情就是建立一个错误消息servlet，并使用前一节讨论的url-pattern元素将所有匹配请求转向该 servlet。只要简单地使用：
<url-pattern>/servlet/*</url-pattern>
作为servlet-mapping元素中的模式即可。
例如，程序清单5-5给出了将SorryServlet servlet（程序清单5-6）与所有以http://host/webAppPrefix/servlet/ 开头的URL相关联的部署描述符文件的一部分。

程序清单5-5 web.xml（说明JSP页命名的摘录）

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- ... -->
<servlet>
<servlet-name>Sorry</servlet-name>
<servlet-class>moreservlets.SorryServlet</servlet-class>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name> Sorry </servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>
<!-- ... -->
</web-app>

程序清单5-6 SorryServlet.java

package moreservlets;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
/** Simple servlet used to give error messages to
* users who try to access default servlet URLs
* (i.e., http://host/webAppPrefix/servlet/ServletName)
* in Web applications that have disabled this
* behavior.
* <P>
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class SorryServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String title = "Invoker Servlet Disabled.";
out.println(ServletUtilities.headWithTitle(title) +
"<BODY BGCOLOR=\"#FDF5E6\">\n" +
"<H2>" + title + "</H2>\n" +
"Sorry, access to servlets by means of\n" +
"URLs that begin with\n" +
"http://host/webAppPrefix/servlet/\n" +
"has been disabled.\n" +
"</BODY></HTML>");
}
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
doGet(request, response);
}
}

4.2 全局禁止激活器：Tomcat
Tomcat 4中用来关闭缺省URL的方法与Tomcat 3中所用的很不相同。下面介绍这两种方法：
1．禁止激活器： Tomcat 4
Tomcat 4用与前面相同的方法关闭激活器servlet，即利用web.xml中的url-mapping元素进行关闭。不同之处在于Tomcat使用了放在 install_dir/conf中的一个服务器专用的全局web.xml文件，而前面使用的是存放在每个Web应用的WEB-INF目录中的标准 web.xml文件。
因此，为了在Tomcat 4中关闭激活器servlet，只需在install_dir/conf/web.xml中简单地注释出/servlet/* URL映射项即可，如下所示：

<!--
<servlet-mapping>
<servlet-name>invoker</servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>
-->

再次提醒，应该注意这个项是位于存放在install_dir/conf的Tomcat专用的web.xml文件中的，此文件不是存放在每个Web应用的WEB-INF目录中的标准web.xml。
2．禁止激活器：Tomcat3
在Apache Tomcat的版本3中，通过在install_dir/conf/server.xml中注释出InvokerInterceptor项全局禁止缺省 servlet URL。例如，下面是禁止使用缺省servlet URL的server.xml文件的一部分。

<!--
<RequsetInterceptor
className="org.apache.tomcat.request.InvokerInterceptor"
debug="0" prefix="/servlet/" />
-->

5 初始化和预装载servlet与JSP页面

这里讨论控制servlet和JSP页面的启动行为的方法。特别是，说明了怎样分配初始化参数以及怎样更改服务器生存期中装载servlet和JSP页面的时刻。
5.1 分配servlet初始化参数
利 用init-param元素向servlet提供初始化参数，init-param元素具有param-name和param-value子元素。例如， 在下面的例子中，如果initServlet servlet是利用它的注册名（InitTest）访问的，它将能够从其方法中调用getServletConfig(). getInitParameter("param1")获得"Value 1"，调用getServletConfig().getInitParameter("param2")获得"2"。

<servlet>
<servlet-name>InitTest</servlet-name>
<servlet-class>moreservlets.InitServlet</servlet-class>
<init-param>
<param-name>param1</param-name>
<param-value>value1</param-value>
</init-param>
<init-param>
<param-name>param2</param-name>
<param-value>2</param-value>
</init-param>
</servlet>

在涉及初始化参数时，有几点需要注意：
l 返回值。GetInitParameter的返回值总是一个String。因此，在前一个例子中，可对param2使用Integer.parseInt获得一个int。
l JSP中的初始化。JSP页面使用jspInit而不是init。JSP页面还需要使用jsp-file元素代替servlet-class。
l 缺省URL。初始化参数只在通过它们的注册名或与它们注册名相关的定制URL模式访问Servlet时可以使用。因此，在这个例子中，param1和 param2初始化参数将能够在使用URL http://host/webAppPrefix/servlet/InitTest 时可用，但在使用URL http://host/webAppPrefix/servlet/myPackage.InitServlet 时不能使用。
例如，程序清单5-7给出一个名为InitServlet的简单servlet，它使用init方法设置firstName和emailAddress字段。程序清单5-8给出分配名称InitTest给servlet的web.xml文件。
程序清单5-7 InitServlet.java

package moreservlets;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
/** Simple servlet used to illustrate servlet
* initialization parameters.
* <P>
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class InitServlet extends HttpServlet {
private String firstName, emailAddress;
public void init() {
ServletConfig config = getServletConfig();
firstName = config.getInitParameter("firstName");
emailAddress = config.getInitParameter("emailAddress");
}
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String uri = request.getRequestURI();
out.println(ServletUtilities.headWithTitle("Init Servlet") +
"<BODY BGCOLOR=\"#FDF5E6\">\n" +
"<H2>Init Parameters:</H2>\n" +
"<UL>\n" +
"<LI>First name: " + firstName + "\n" +
"<LI>Email address: " + emailAddress + "\n" +
"</UL>\n" +
"</BODY></HTML>");
}
}

程序清单5-8 web.xml（说明初始化参数的摘录）

转自http://elevenet.javaeye.com/blog/67862

这篇文章还是不错的，有些老，有些地址还是直接翻译的。不是很准确。

关键字: J2EE

<servlet>
<servlet-name>Test</servlet-name>
<servlet-class>moreservlets.TestServlet</servlet-class>
</servlet>

package moreservlets;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
/** Simple servlet used to illustrate servlet naming
* and custom URLs.
* <P>
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String uri = request.getRequestURI();
out.println(ServletUtilities.headWithTitle("Test Servlet") +
"<BODY BGCOLOR=\"#FDF5E6\">\n" +
"<H2>URI: " + uri + "</H2>\n" +
"</BODY></HTML>");
}
}

　　该方法的实现原理很简单，就是用户访问Web系统时记录每个用户的信息，然后进行对照，并根据设定的策略(比如：1秒钟刷新页面10次)判断用户是否属于恶意刷新。

我们的入侵检测程序应该放到所有Java Web程序的执行前，也即若发现用户是恶意刷新就不再继续执行Java Web中的其它部分内容，否则就会失去了意义。这就需要以插件的方式把入侵检测的程序置入Java Web应用中，使得每次用户访问Java Web，都先要到这个入侵检测程序中报一次到，符合规则才能放行。

　　Java Web应用大致分为两种，一种纯JSP(+Java Bean)方式，一种是基于框架(如Struts、EasyJWeb等)的。第一种方式的Java Web可以通过Java Servlet中的Filter接口实现，也即实现一个Filter接口，在其doFilter方法中插入入侵检测程序，然后再web.xml中作简单的 配置即可。在基于框架的Web应用中，由于所有应用都有一个入口，因此可以把入侵检测的程序直接插入框架入口引擎中，使框架本身支持入侵检测功能。当然, 也可以通过实现Filter接口来实现。

　　在EasyJWeb框架中，已经置入了简单入侵检测的程序，因此，这里我们以EasyJWeb框架为例,介绍具体的实现方法及源码，完整的代码可以在EasyJWeb源码中找到。

　　在基于EasyJWeb的Java Web应用中(如http://www.easyjf.com/bbs/)，默认情况下你只要连续刷新页面次数过多，即会弹出如下的错误：

　　EasyJWeb框架友情提示!:-):
　　您对页面的刷新太快,请等待60秒后再刷新页面！
详细请查询http://www.easyjf.com

二、用户访问信息记录UserConnect.java类　　

这个类是一个简单的Java Bean，主要代表用户的信息，包括用户名、IP、第一次访问时间、最后登录时间、登录次数、用户状态等。全部

代码如下：

package com.easyjf.web;

import java.util.Date;
/**
*
*

Title:用户验证信息

Description:记录用户登录信息,判断用户登录情况

Copyright: Copyright (c) 2006

Company: www.easyjf.com

public void setFirstFailureTime(Date firstFailureTime) {
 this.firstFailureTime = firstFailureTime;
}

public String getIp() {
 return ip;
}

public void setIp(String ip) {
 this.ip = ip;
}

public Date getLastLoginTime() {
 return lastLoginTime;
}

public void setLastLoginTime(Date lastLoginTime) {
 this.lastLoginTime = lastLoginTime;
}

public String getUserName() {
 return userName;
}

public void setUserName(String userName) {
 this.userName = userName;
}

public int getStatus() {
 return status;
}

public void setStatus(int status) {
 this.status = status;
}

}

三、监控线程UserConnectManage.java类

这是入侵检测的核心部分，主要实现具体的入侵检测、记录、判断用户信息、在线用户的刷新等功能，并提供其它应用程序使用本组件的调用接口。

package com.easyjf.web;

import java.util.Date;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;

import org.apache.log4j.Logger;
/**
*
*

Title:用户入侵检测信息

Description:用于判断用户刷新情况检查，默认为10秒钟之内连续连接10次为超时

Copyright: Copyright (c) 2006

Company: www.easyjf.com

public static void reset(String ip,String userName)//重置用户信息
{ 
 Date now=new Date(); 
 String key=ip+":"+userName;
 UserConnect auth=(UserConnect)users.get(key);
 if(auth==null)//把用户当前的访问信息加入到users容器中
 {
  auth=new UserConnect();
  auth.setIp(ip);
  auth.setUserName(userName);
  auth.setFailureTimes(0);
  auth.setFirstFailureTime(now);
  users.put(key,auth);
 } 
 else
 {
  auth.setFailureTimes(0);
  auth.setFirstFailureTime(now);
 }
}
public static void remove(String ip,String userName)//删除用户在容器中的记录
{
 String key=ip+":"+userName;
 users.remove(key);
}
public static void clear()//清空容器中内容
{
 if(!users.isEmpty())users.clear();
}
public static long getMaxFailureInterval() {
 return maxFailureInterval;
}

public static void setMaxFailureInterval(long maxFailureInterval) {
 UserConnectManage.maxFailureInterval = maxFailureInterval;
}

public static int getMaxFailureTimes() {
 return maxFailureTimes;
}

public static void setMaxFailureTimes(int maxFailureTimes) {
 UserConnectManage.maxFailureTimes = maxFailureTimes;
}

public static int getMaxOnlineUser() {
 return maxOnlineUser;
}

public static void setMaxOnlineUser(int maxOnlineUser) {
 UserConnectManage.maxOnlineUser = maxOnlineUser;
}

public static long getWaitInterval() {
 return waitInterval;
}

public static void setWaitInterval(long waitInterval) {
 UserConnectManage.waitInterval = waitInterval;
}

四、调用接口

在需要进入侵检测判断的地方，直接使用UserConnectManage类中的checkLoginValidate方法即可。如EasyJWeb的核心Servlet　

com.easyjf.web.ActionServlet中调用UserConnectManage的代码：
   if(!UserConnectManage.checkLoginValidate(request.getRemoteAddr(),"guest"))
       {            
           info(request,response,new Exception("您对页面的刷新太快,请等待"+UserConnectManage.getWaitInterval()/1000+"秒

后再刷新页面！"));
           return;
       }      



五、总结
当然，这里提供的方法只是一个简单的实现示例，由于上面的用户信息是直接保存在内存中，若并发用户很大的时候的代码的占用，可以考虑引入数据库来记录用 户的访问信息，当然相应的执行效率肯定用降低。上面介绍的实现中，入侵检测判断的策略也只有用户访问次数及时间间隔两个元素，您还可以根据你的实现情况增 加其它的检测元素。

由于水平有限，该设计上有N不合理或者需要改进的地方，恳请大家指正！

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=657199

浏览器安全模型规定，XMLHttpRequest、框架（frame）等只能在一个域中通信。从安全角度考虑，这个规定很合理；但是，也确实给分布式（面向服务、混搭等等本周提到的概念）Web开发带来了麻烦。

为了实现跨域通信，通常的解决方案有3种：

本地代理：
需要一些硬件设施（没有服务器的客户端无法运行），并且带宽和潜伏时间也要加倍（远程服务器－代理服务器－客户端）。

Flash：
远程主机中需要部署一个crossdomain.xml文件，而且，Flash作为一门专有技术，其前途尚不明朗；换句话说，开发人员很可能要学习一种目标不确定的编程语言。

Script标签：
无法确切知道内容是否有效，没有标准的实现方法，又可能被认为是一种“安全风险”。

也就是说，客户端可以使用一个用于命名jsonp的查询参数来决定可以获取的数据。最简单的情况下，如果jsonp参数为空，则返回的数据就是被括在圆括号中的JSON。

下面，我们就以del.icio.us的JSON API为例，来说明JSONP的原理。该API有一个“script tag”变量（即，可以将下面的URL作为script标签的src属性值，用以加载del.icio.us这个API提供的数据。——译者注）如下所示：

http://del.icio.us/feeds/json/bob/mochikit+interpreter:

如果用JSONP的方式来表示，那么与此具有相同语义的URL应该是这样的：

http://del.icio.us/feeds/json/bob/mochikit+interpreter?
jsonp=if(typeof(Delicious)%3D%3D%27undefined%27)
Delicious%3D%7B%7D%3BDelicious.posts%3D

单纯看这个URL似乎没有什么，但我们可以要求服务器在数据有效时给出通知。因此，我可以编写一个用于跟踪数据的小系统：

根据以上假设，用于获取数据的URL应该如下所示：
http://del.icio.us/feeds/json/bob/mochikit+interpreter?jsonp=delicious_callbacks%5B12345%5D

可见，由于使用圆括号括住了返回的数据，这就相当于把一个JSONP请求转化成了一次函数调用，或者得到了一个纯粹的JSON直接量。服务器所要配合做的，就是在JSON数据的开头添加一小段文本（即回调函数的名称。——译者注）并将JSON数据放在括号中！

当然，接下来最好是使用Mochikit、Dojo等框架来抽象JSONP，从而让自己省去动手编写DOM以插入script标签的麻烦。

没错，JSONP只是解决了标准化的问题。假如远程主机想通过script标签向页面中注入恶意代码，而不是返回JSON数据，那么页面安全可能会 随时受到威胁。不过，一旦实现了JSONP，那么对开发人员来说肯定是一件省时省力的大好事，在此基础上各种一般化的抽象、教程及文档也会应运而生的。

注：缩写词 JSONP 由 Bob Ippolito 在一篇名为 “Remote JSON - JSONP” 的文章中提出。但许多支持以 JSONP 技术实现跨域通信的厂商没有称其为 JSONP。例如，雅虎公司就称这种技术为 “JSON with callbacks”。另外，原文发表于2005年12月5日。

留言(9)

hello cuckoo九月 16th, 2008 at 9:42 上午

中秋好。
怎么把我的链接去掉了呢？
给我做个链接可以吗？？？
非常感谢！！
我的EMAIL：hardcometure@163.com

vampire九月 16th, 2008 at 8:41 下午

大概是说通过script的src来实现跨域，通过经编码的json在url中传递数据？
是不是说页面上的js生产带有不同参数的jsonp，通过src传递给服务端，服务端根据该jsonp返回相应数据？有点不太明白，能否提供一个实例？谢谢

admin九月 17th, 2008 at 8:43 下午

@vampire

你的理解是对的，看来我的翻译你能看明白，呵呵。使用JSONP技术时，一般是由JS在客户端页面中动态插入script标签，将其src属性设置 为带参数的URL。当页面加载时，前述URL会将参数通过GET请求发送到相应服务器端应用程序（由URL表示），服务器根据参数返回数据——注意，这个 数据格式是JSON，并且（注意）被包含在一个函数调用中，例如：callback({json_data})。这样，在客户端页面中存在预定义的 callback(data)函数的定义时，服务器返回的函数调用就会立即执行，由客户端的函数对数据进行操作。

实际的例子有很多，如Yahoo Search、Google Base、Flickr Search、Amazon Search等等。要学习和使用这些站点提供的支持JSONP的API，一般要注意两点：一是有的站点要求注册密钥（使用时必须放到参数中），二是要注意 参数的使用方法。例如，有的API要求使用预定义的回调函数，而有的API则允许使用者自己定义回调函数。

下面就是向Flickr Search请求JSONP响应的URL，其中使用了预定义的回调函数jsonFlickrApi（参数中不必给出）：

http://api.flickr.com/services/rest/
?method=flickr.photos.search
&api_key=85618ad7d326d8ef93c6bee9ed32706f
&per_page=5&format=json&text=china

下面这个URL发送到Google Base，它允许开发人员使用自己定义的回调函数：

http://www.google.com/base/feeds/snippets
?q=jquery
&alt=json-in-script
&callback=customCallback

把前面的URL放到浏览器地址栏中，回车，即可看到结果。

为什么会这样？HTTP虽不是什么新事物，但人们使用它的方式却五花八门。其中有些做法符合Web设计者的初衷，但许多并非如此。要为你的HTTP 应用（无论是面向人类、还是计算机、或同时面向这两者使用的）应用REST原则，意味着你要恰好反过来：尽量“正确地”使用Web，或者说按符合REST 的方式使用Web（倘若你不喜欢用对或错来评判的话）。对许多人来说，这的确是一种崭新的方式方法。

我经常在文章里作同样的声明：REST、Web和HTTP是不同的事物；REST可以用多种不同技术来实现，而HTTP只是一种恰好符合REST架 构风格的具体架构。所以，其实我应该小心区分“REST”与“REST式HTTP”这两个概念的。但我没有这么做，在本文剩余部分，我们姑且认为它们是相 同的事物。

跟任何新的方式方法一样，发掘一些共同的模式是有益的。在本系列的第一和第二篇 文章中，我已经讲述了一些基础——比如集合资源的概念、将计算结果转换为资源本身、以及用聚合（syndication）来模仿事件。后续文章将进一步讲 述这些及其他模式。不过在本文中，我想主要说说反模式（anti-patterns）——即那些力求符合REST式HTTP、但未能成功而造成问题的典型 做法。

首先我们来看看我发掘了哪些反模式：

1. 全部采用GET
2. 全部采用POST
3. 忽视缓存
4. 忽视响应代码
5. 误用cookies
6. 忘记超媒体
7. 忽视MIME类型
8. 破坏自描述性

下面我们来逐个详细说明。

全部采用GET

在许多人看来，REST仅仅意味着用HTTP暴露一些应用功能。HTTP GET是最重要的基本操作（operation ）（严格地讲，用“动词（verb）”或“方法（method）”这样的术语比较好）。GET方法应当用于获取由URI标识的资源的一个表示 （representation），而许多（即便谈不上所有）现有的HTTP库和服务器编程API不是将URI视为一种资源标识符（resource identifier），而是将之视为一种传递参数的便利手段。这导致了以下这种URIs的出现：

http://example.com/some-api?method=deleteCustomer&id=1234

实际上，你无法根据构成URI的字符获知关于给定系统的“REST性（RESTfulness）”的任何信息，不过对于上面那个URI，我们可以判 断该 GET操作不是“安全的（safe）”——也就是说，调用者很可能要为结果（删除一个客户）负责，尽管规范里说在这种情况下使用GET方法是错误的。

这种做法唯一有利的方面在于它编程起来容易，而且在浏览器中调试也简单——你只要把URI粘贴到浏览器地址栏里、然后调整一些“参数”就行了。这种反模式主要存在以下问题：

1. URI没有被用作资源标识符，而是被用于传递操作及其参数了。
2. HTTP方法（HTTP method）不一定跟语义相符。
3. 这种链接一般不可加入书签。
4. 有“爬虫”造成非预期副作用的风险。

注意：符合这一反模式的APIs没准最终碰巧符合REST原则。这里有个例子：

http://example.com/some-api?method=findCustomer&id=1234

这个URI是标识操作及其参数呢，还是标识一个资源呢？两种情况都有可能：它可以是一个完全合法的、可加入书签的URI；对它做GET操作也许是“ 安全的 ”；它也许会根据Accept报头返回不同的格式，并支持复杂的缓存机制。在很多情况下，这将是偶然的。API经常在刚开始时采用这种方式来暴露一个“读 ”接口，但当开发者要增添“写”功能时就有问题了（因为你无法通过对上述URI做PUT操作来更新一个客户——开发者得构造另一个URI）。

全部采用POST

这一反模式跟前一个颇为相似，只不过这里用的是POST方法而已。POST除了携带一个URI，还携带一个实体主体（entity body）。一个典型的场景是：将单个URI作为POST请求的目标、通过发送不同的消息来表达不同的意图。实际上，SOAP 1.1 Web服务就是这样做的，它把HTTP当作一种“传输协议”来用。服务器根据SOAP消息（可能还包括一些WS-Addressing SOAP报头）决定做什么。

可能有人认为“全部采用POST”跟“全部采用GET”存在的问题完全一样，只是它更难用一些，而且不能利用缓存（甚至连偶尔的机会都没有），且无法支持书签。事实上，它并不是违反了哪条REST原则，而是根本忽视了REST原则。

忽视缓存

即使你按各个动词的原本意图来使用它们，你仍可以轻易禁止缓存机制。最简单的做法就是在你的HTTP响应里增加这样一个报头：

Cache-control: no-cache

这样可以禁止缓存机制发挥作用。当然，这也许正是你想要做的，然而通常这只是你的Web框架规定的一个缺省设置。不过，对高效的缓存与再验证 （caching and re-validation）的支持，是采用REST式HTTP的诸多关键优点之一。Sam Ruby表示，在判断是否符合REST原则时的一个关键问题就是“你支持ETag吗”？ （ETag是HTTP 1.1里引入的一种机制，它允许客户端通过加密的校验和来验证一个被缓存的表示是否仍然有效）。要生成正确的报头，最简单的做法就是把这个任务交给一个“ 知道”怎样做的基础设施——例如通过在Web服务器（比如Apache HTTPD）的目录里生成一个文件。

当然，这也要涉及到客户端一方：你在为一个REST式服务实现程序客户端时，你应充分利用现有的缓存机制，以免每次都重新获取表示。例如，服务器也 许已经发出信息：初次返回的表示在600秒内都可被认为是“新的”（比方说因为后端系统每30分钟才轮询一次）。这样的话，短时间内重复请求同一信息就完 全没必要了。在客户端设置一个代理缓存（比如Squid）也许比自行构建相应逻辑更好。

HTTP的缓存机制强大而复杂；Mark Nottingham的《缓存指南（Cache Tutorial）》是一个很好的指南。

忽视响应代码

HTTP提供了一组丰富的应用级状态代码， 它们可用于应付不同场合，不过许多Web开发者对此并不知晓。大部分人对200（“OK”）、404（“Not found”）和500（“Internal server error”）这些状态代码是比较熟悉的。但除此以外还有很多其他状态代码，正确使用这些状态代码意味着客户端与服务器可以在一个具备较丰富语义的层次上 进行沟通。

例如，201（“Created”）响应代码表明已经创建了一个新的资源，其URI在Location响应报头里。409（“Conflict”） 告诉客户端存在冲突，比如随PUT请求发送的是基于老版本资源的数据。再如，412（“Precondition Failed”）表明服务器不能满足客户端的预期。

正确使用状态代码的另一方面涉及客户端：应该根据一种统一的总体方法对不同类别的状态代码（例如所有2xx段代码、所有5xx段代码）作不同处理——例如，即便客户端不具备处理特定代码的逻辑，但至少应把所有2xx段代码视为成功信号。

许多声称符合REST的应用仅仅返回200或500，甚至只返回200（并在响应实体主体里给出错误文本——SOAP就是这样的）。你要是愿意，可 以称之为“通过状态代码200传达错误”，但无论你觉得采用哪个术语好，假如你不利用HTTP状态代码丰富的应用语义，那么你将错失提高重用性、增强互操 作性和提升松耦合性的机会。

误用cookies

利用cookies来传播某个服务端会话状态的键（key）是另一种REST反模式。

Cookies表明肯定哪个地方不符合REST了。是这样吗？不；不一定。REST的关键思想之一是无状态性（statelessness）——不 是说一个服务器不能保存任何数据：倘若是资源状态（resource state）或客户端状态（client state），那是可以的。服务器不能保存的是会话状态（session state），因为那会造成可伸缩性、可靠性及耦合方面的问题。Cookies的最典型的用法是：保存一个跟“某个保存在服务端内存里的数据结构”相关联 的键（key）。这意味着，浏览器随各次请求发出去的cookie是被用于构建会话状态的。

如果一个cookie被用于保存一些“服务器不依赖于会话状态即可验证”的信息（比如认证令牌），那么这样的cookies是完全符合REST原则 的—— 不过有一点需要注意：如果有其他更为标准的方式来传递一则信息（比如放在URI里、放在某个标准报头里、或较少见地放在消息主体里），那就不应将之放在 cookie里。例如，按REST式HTTP的观点来使用HTTP认证就比较好。

忘记超媒体

最不易接受的REST思想就是标准的方法集合。REST理论并没有规定标准集合由哪些方法组成，它只是规定必须有一组适用于所有资源的方法集合。对 于 HTTP来说，这组集合是GET、PUT、POST和DELETE（至少起初是这样），你需要一定适应时间才能掌握如何将所有应用语义投射到这四个动词 上。但你一旦适应了，就可以开始运用这个REST的子集——一种基于Web的CRUD（Create、Read、Update、 Delete）架构——了。暴露这种反模式的应用不是真正的“非REST式”应用（假如存在这种事物的话），它们只是未能利用一个REST核心概念——“ 超媒体即应用状态引擎（hypermedia as the engine of application state）”。

超媒体（hypermedia）是一个把事物链接起来的概念，正是它造就了Web这个网——一个互联的资源集合，应用通过跟随链接从一个状态进入另一个状态。这听上去也许有点深奥，不过其实遵从这一原则是有正当理由的。

“忘记超媒体”反模式的首要表现就是：表示（representation）里缺少链接。尽管通常客户端可以根据一定的规则来构造URI，但是因为 服务器没有发送任何链接，所以客户端将无法跟随链接。一种较好的做法是：即支持构造URI，又支持跟随链接——这里的链接通常反映了下层数据模型中的关 系。但最好的情况是：客户端应该只需知道一个URI；其他URI（各个URI及其构造模式，如：各种查询字符串）应该通过超媒体（作为资源表示里的链接） 来传达。 Atom发布协议（Atom Publishing Protocol）就是一个好例子，它有一个服务文档（service documents）的概念，服务文档为它所描述的域内的各个集合提供具名元素（named elements）。最后，应用可能经历的状态迁移应该是动态传播的，客户端应该可以不用掌握多少知识就可以跟随它们。HTML就是一个好榜样，它包含足 够的信息，以便浏览器可以向用户提供一个完全动态的接口。

我本想增加一个“人类可读的URI”反模式的。但我没那么做，因为我跟其他人一样也喜欢可读的、好“篡改”的URI。但是当人们采用REST时，他 们经常浪费许多时间来讨论“正确的”URI设计，而忘记了超媒体方面。所以，我建议你不要花太多时间来寻找正确的URI设计（毕竟，它们只是字符串而 已），而是多花一些精力在表示里寻找提供链接的正确地方。

忽视MIME类型

HTTP有个内容协商（content negotiation）的概念，它允许客户端根据需要获取资源的不同表示（representations）。例如，一个资源也许有不同格式的表示（如 XML、JSON或YAML等）以便于用各种不同语言（如Java、JavaScript及Ruby）实现的消费者所使用。再如，一个资源可能即有面向人 类的PDF或JPEG版表示，又有“机器可读的”XML版表示。还有，一个资源可能同时支持v1.1版和v1.2版的自定义表示格式。不管怎样，也许可以 为“只有一个表示格式”找到理由，但这常常意味着丢掉某种机会。

显然，若一个服务能为更多未预见到的客户端所用（或重用）那更好。因此，依靠现有、预定义、广为人知的格式，要好过发明私有格式——这会导致本文讲述的最后一个反模式。

破坏自描述性

这种反模式是如此普遍，以至于几乎在每个、甚至那些由所谓的“REST狂热者们”（包括我在内）创建的REST应用里都可以看到：违反自描述性约束 （这一努力目标并不像人们最初想象的那样跟人工智能科幻小说有多大牵连）。理想情况下，一个消息（HTTP 请求或HTTP响应，包括报头与主体）应该包含足够信息，以便任何通用客户端、服务器或媒介（intermediary）能够处理它。例如，当你的浏览器 获取某个受保护资源的PDF表示（representation）时，你可以看到由标准达成的协定是如何起作用的：有些HTTP认证交换发生，可能会发生 一些缓存（caching）和/或再验证（revalidation），服务器发送的content-type报头（application/pdf）触发了你系统里注册的PDF阅读器，最后你得以在自己的屏幕上阅读该PDF。所有用户都可以用他们自己的基础设施来执行同样的请求。若服务器开发者另外增加一种内容类型，那么服务器的客户端（或服务的消费者）只需确保他们安装了正确的阅读器即可。

你要是发明自己的报头、格式或协议，那就一定程度上破坏了自描述性约束。极端地讲，所有没有被某个标准化组织官方标准化的东西都违反此约束，因而可 被认为符合本反模式。在实践中，你应努力做到尽可能遵循标准，并懂得“某些协定可能只在一个较小的领域（比方说，你的服务和客户端是专门针对它开发的）中 适用” 的道理。

总结

自从“四人组（Gang of Four）”出版了书籍、 掀起模式运动的开端以来，许多人误解了它，并试图在尽可能多的场合下应用模式——这已被其他人所取笑。模式应当仅在符合上下文时才被应用。同样地，可能有 人会不遗余力地在所有场合下虔诚地努力避免所有反模式。许多时候，你有充分理由违反某一规则，或者按REST的术语放松某一约束。这么做是没问题的——但 了解实际情况、作出知情决策是有益的。

但愿本文能有助于你在开始首个REST项目时避免落入这些常见的陷阱。

非常感谢Javier Botana和Burkhard Neppert对本文初稿的反馈。

Stefan Tilkov是InfoQ SOA社区的首席编辑，以及位于德国/瑞士的innoQ公司的合伙人、首席顾问和主要的REST狂热主义者。

REST关键原则

大部分对REST的介绍是以其正式的定义和背景作为开场的。但这儿且先按下不表，我先提出一个简单扼要的定义：REST定义了应该如何正确地使用 （这和大多数人的实际使用方式有很大不同）Web标准，例如HTTP和URI。如果你在设计应用程序时能坚持REST原则，那就预示着你将会得到一个使用 了优质Web架构（这将让你受益）的系统。总之，五条关键原则列举如下：

• 为所有“事物”定义ID
• 将所有事物链接在一起
• 使用标准方法
• 资源多重表述
• 无状态通信

下面让我们进一步审视这些原则。

为所有“事物”定义ID

在这里我使用了“事物”来代替更正式准确的术语“资源”，因为一条如此简单的原则，不应该被淹没在术语当中。思考一下人们构建的系统，通常会找到一 系列值得被标识的关键抽象。每个事物都应该是可标识的，都应该拥有一个明显的ID——在Web中，代表ID的统一概念是：URI。URI构成了一个全局命 名空间，使用URI标识你的关键资源意味着它们获得了一个唯一、全局的ID。

对事物使用一致的命名规则（naming scheme）最主要的好处就是你不需要提出自己的规则——而是依靠某个已被定义，在全球范围中几乎完美运行，并且能被绝大多数人所理解的规则。想一下你 构建的上一个应用（假设它不是采用RESTful方式构建的）中的任意一个高级对象（high-level object），那就很有可能看到许多从使用唯一标识中受益的用例。比如，如果你的应用中包含一个对顾客的抽象，那么我可以相当肯定，用户会希望将一个指 向某个顾客的链接，能通过电子邮件发送到同事那里，或者加入到浏览器的书签中，甚至写到纸上。更透彻地讲：如果在一个类似于Amazon.com的在线商 城中，没有用唯一的ID（一个URI）标识它的每一件商品，可想而知这将是多么可怕的业务决策。

当面对这个原则时，许多人惊讶于这是否意味着需要直接向外界暴露数据库记录（或者数据库记录ID）——自从多年以来面向对象的实践告诫我们，要将持 久化的信息作为实现细节隐藏起来之后，哪怕是刚有点想法都常会使人惊恐。但是这条原则与隐藏实现细节两者之间并没有任何冲突：通常，值得被URI标识的事 物——资源——要比数据库记录抽象的多。例如，一个定单资源可以由定单项、地址以及许多其它方面（可能不希望作为单独标识的资源暴露出来）组成。标识所有 值得标识的事物，领会这个观念可以进一步引导你创造出在传统的应用程序设计中不常见的资源：一个流程或者流程步骤、一次销售、一次谈判、一份报价请求—— 这都是应该被标识的事物的示例。同样，这也会导致创建比非RESTful设计更多的持久化实体。

下面是一些你可能想到的URI的例子：

http://example.com/customers/1234

http://example.com/orders/2007/10/776654

http://example.com/products/4554

http://example.com/processes/salary-increase-234 

正如我选择了创建便于阅读的URI——这是个有用的观点，尽管不是RESTful设计所必须的——应该能十分容易地推测出URI的含义：它们明显地标识着单一“数据项”。但是再往下看：

http://example.com/orders/2007/11

http://example.com/products?color=green 

首先，这两个URI看起来与之前的稍有不同——毕竟，它们不是对一件事物的标识，而是对一类事物集合的标识（假定第一个URI标识了所有在2007年11月份提交的定单，第二个则是绿颜色产品的集合）。但是这些集合自身也是事物（资源），也应该被标识。

注意，使用唯一、全局统一的命名规则的好处，既适用于浏览器中的Web应用，也适用于机对机（machine-to-machine，m2m）通信。

来对第一个原则做下总结：使用URI标识所有值得标识的事物，特别是应用中提供的所有“高级”资源，无论这些资源代表单一数据项、数据项集合、虚拟亦或实际的对象还是计算结果等。

将所有事物链接在一起

接下来要讨论的原则有一个有点令人害怕的正式描述：“超媒体被当作应用状态引擎（Hypermedia as the engine of application state）”，有时简写为HATEOAS。（严格地说，这不是我说的。）这个描述的核心是超媒体概念，换句话说：是链接的思想。链接是我们在HTML中常见的概念，但是它的用处绝不局限于此（用于人们网络浏览）。考虑一下下面这个虚构的XML片段：

 

23 

 

 

 

如果你观察文档中product和customer的链接，就可以很容易地想象到，应用程序（已经检索过文档）如何“跟随”链接检索更多的信息。当然，如果使用一个遵守专用命名规范的简单“id”属性作为链接，也是可行的——但是仅限于应用环境之内。使用URI表示链接的优雅之处在于，链接可以指向由不同应用、不同服务器甚至位于另一个大陆上的不同公司提供的资源——因为URI命名规范是全球标准，构成Web的所有资源都可以互联互通。

超媒体原则还有一个更重要的方面——应用“状态”。简而言之，实际上服务器端（如果你愿意，也可以叫服务提供者）为客户端（服务消费者）提供一组链 接，使客户端能通过链接将应用从一个状态改变为另一个状态。稍后我们会在另一篇文章中探究这个方面的影响；目前，只需要记住：链接是构成动态应用的非常有 效的方式。

对此原则总结如下：任何可能的情况下，使用链接指引可以被标识的事物（资源）。也正是超链接造就了现在的Web。

使用标准方法

在前两个原则的讨论中暗含着一个假设：接收URI的应用程序可以通过URI明确地做一些有意义的事情。如果你在公共汽车上看到一个URI，你可以将它输入浏览器的地址栏中并回车——但是你的浏览器如何知道需要对这个URI做些什么呢？

它知道如何去处理URI的原因在于所有的资源都支持同样的接口，一套同样的方法（只要你乐意，也可以称为操作）集合。在HTTP中这被叫做动词 （verb），除了两个大家熟知的（GET和POST）之外，标准方法集合中还包含PUT、DELETE、HEAD和OPTIONS。这些方法的含义连同 行为许诺都一起定义在HTTP规范之中。如果你是一名OO开发人员，就可以想象到RESTful HTTP方案中的所有资源都继承自类似于这样的一个类（采用类Java、C#的伪语法描述，请注意关键的方法）：

class Resource {

Resource(URI u);

Response get();

Response post(Request r);

Response put(Request r);

Response delete();

} 

由于所有资源使用了同样的接口，你可以依此使用GET方法检索一个表述（representation）——也 就是对资源的描述。因为规范中定义了GET的语义，所以可以肯定当你调用它的时候不需要对后果负责——这就是为什么可以“安全”地调用此方法。GET方法 支持非常高效、成熟的缓存，所以在很多情况下，你甚至不需要向服务器发送请求。还可以肯定的是，GET方法具有幂等性[译 注：指多个相同请求返回相同的结果]——如果你发送了一个GET请求没有得到结果，你可能不知道原因是请求未能到达目的地，还是响应在反馈的途中丢失了。 幂等性保证了你可以简单地再发送一次请求解决问题。幂等性同样适用于PUT（基本的含义是“更新资源数据，如果资源不存在的话，则根据此URI创建一个新 的资源”）和DELETE（你完全可以一遍又一遍地操作它，直到得出结论——删除不存在的东西没有任何问题）方法。POST方法，通常表示“创建一个新资 源”，也能被用于调用任意过程，因而它既不安全也不具有幂等性。

如果你采用RESTful的方式暴露应用功能（如果你乐意，也可以称为服务功能），那这条原则和它的约束同样也适用于你。如果你已经习惯于另外的设计方式，则很难去接受这条原则——毕竟，你很可能认为你的应用包含了超出这些操作表达范围的逻辑。请允许我花费一些时间来让你相信不存在这样的情况。

来看下面这个简单的采购方案例子：

可以看到，例子中定义了两个服务程序（没有包含任何实现细节）。这些服务程序的接口都是为了完成任务（正是我们讨论的 OrderManagement和CustomerManagement服务）而定制的。如果客户端程序试图使用这些服务，那它必须针对这些特定接口进行 编码——不可能在这些接口定义之前，使用客户程序去有目的地和接口协作。这些接口定义了服务程序的应用协议（application protocol）。

在RESTful HTTP方式中，你将通过组成HTTP应用协议的通用接口访问服务程序。你可能会想出像这样的方式：

可以看到，服务程序中的特定操作被映射成为标准的HTTP方法——为了消除歧义，我创建了一组全新的资源。“这是骗人的把戏”，我听见你叫嚷着。 不，这不是欺骗。标识一个顾客的URI上的GET方法正好相当于getCustomerDetails操作。有人用三角形形象化地说明了这一点：

把三个顶点想象为你可以调节的按钮。可以看到在第一种方法中，你拥有许多操作，许多种类的数据以及固定数量的“实例”（本质上和你拥有的服务程序数 量一致）。在第二种方法中，你拥有固定数量的操作，许多种类的数据和许多调用固定方法的对象。它的意义在于，证明了通过这两种方式，你基本上可以表示任何 你喜欢的事情。

为什么使用标准方法如此重要？从根本上说，它使你的应用成为Web的一部分——应用程序为Web变成Internet上最成功的应用所做的贡献，与 它添加到Web中的资源数量成比例。采用RESTful方式，一个应用可能会向Web中添加数以百万计的客户URI；如果采用CORBA技术并维持应用的 原有设计方式，那它的贡献大抵只是一个“端点（endpoint）”——就好比一个非常小的门，仅仅允许有钥匙的人进入其中的资源域。

统一接口也使得所有理解HTTP应用协议的组件能与你的应用交互。通用客户程序（generic client）就是从中受益的组件的例子，例如curl、wget、代理、缓存、HTTP服务器、网关还有Google、Yahoo!、MSN等等。

总结如下：为使客户端程序能与你的资源相互协作，资源应该正确地实现默认的应用协议（HTTP），也就是使用标准的GET、PUT、POST和DELETE方法。

资源多重表述

到目前为止我们一直忽略了一个稍微复杂的问题：客户程序如何知道该怎样处理检索到的数据，比如作为GET或者POST请求的结果？原因是，HTTP 采取的方式是允许数据处理和操作调用之间关系分离的。换句话说，如果客户程序知道如何处理一种特定的数据格式，那就可以与所有提供这种表述格式的资源交 互。让我们再用一个例子来阐明这个观点。利用HTTP内容协商（content negotiation），客户程序可以请求一种特定格式的表述：

GET /customers/1234 HTTP/1.1

Host: example.com 

Accept: application/vnd.mycompany.customer+xml  

请求的结果可能是一些由公司专有的XML格式表述的客户信息。假设客户程序发送另外一个不同的请求，就如下面这样：

GET /customers/1234 HTTP/1.1

Host: example.com 

Accept: text/x-vcard 

结果则可能是VCard格式的客户地址。（在这里我没有展示响应的内容，在其HTTP Content-type头中应该包含着关于数据类型的元数据。）这说明为什么理想的情况下，资源表述应该采用标准格式——如果客户程序对HTTP应用协 议和一组数据格式都有所“了解”，那么它就可以用一种有意义的方式与世界上任意一个RESTful HTTP应用交互。 不幸的是，我们不可能拿到所有东西的标准格式，但是，或许我们可以想到在公司或者一些合作伙伴中使用标准格式来营造一个小环境。当然以上情况不仅适用于从 服务器端到客户端的数据，反之既然——倘若从客户端传来的数据符合应用协议，那么服务器端就可以使用特定的格式处理数据，而不去关心客户端的类型。

在实践中，资源多重表述还有着其它重要的好处：如果你为你的资源提供HTML和XML两种表述方式，那这些资源不仅可以被你的应用所用，还可以被任意标准Web浏览器所用——也就是说，你的应用信息可以被所有会使用Web的人获取到。

资源多重表述还有另外一种使用方式：你可以将应用的Web UI纳入到Web API中——毕竟，API的设计通常是由UI可以提供的功能驱动的，而UI也是通过API执行动作的。将这两个任务合二为一带来了令人惊讶的好处，这使得 使用者和调用程序都能得到更好的Web接口。

总结：针对不同的需求提供资源多重表述。

无状态通信

无状态通信是我要讲到的最后一个原则。首先，需要着重强调的是，虽然REST包含无状态性（statelessness）的观念，但这并不是说暴露功能的应用不能有状态——
事 实上，在大部分情况下这会导致整个做法没有任何用处。REST要求状态要么被放入资源状态中，要么保存在客户端上。或者换句话说，服务器端不能保持除了单 次请求之外的，任何与其通信的客户端的通信状态。这样做的最直接的理由就是可伸缩性—— 如果服务器需要保持客户端状态，那么大量的客户端交互会严重影响服务器的内存可用空间（footprint）。（注意，要做到无状态通信往往需要需要一些 重新设计——不能简单地将一些session状态绑缚在URI上，然后就宣称这个应用是RESTful。）

但除此以外，其它方面可能显得更为重要：无状态约束使服务器的变化对客户端是不可见的，因为在两次连续的请求中，客户端并不依赖于同一台服务器。一 个客户端从某台服务器上收到一份包含链接的文档，当它要做一些处理时，这台服务器宕掉了，可能是硬盘坏掉而被拿去修理，可能是软件需要升级重启——如果这 个客户端访问了从这台服务器接收的链接，它不会察觉到后台的服务器已经改变了。

理论上的REST

我承认：以上我所说的REST不是真正的REST，而且我可能有点过多地热衷于简单化。但因为我想有一个与众不同的开场，所以没有在一开始就介绍其正式的定义和背景。现在就让我们稍微简要地介绍一下这方面的内容。

首先，先前我并没有明确地区分HTTP、RESTful HTTP和REST。要理解这些不同方面之间的关系，我们要先来看看REST的历史。

Roy T. Fielding在他的博士学位论文（实际上你应该访问这个链接——至少对于一篇学术论文来说，它是相当易读的。此论文已被翻译成中文） 中定义了术语REST。Roy曾是许多基本Web协议的主要设计者，其中包括HTTP和URIs，并且他在论文中对这些协议提出了很多想法。（这篇论文被 誉为“REST圣经”，这是恰当的——毕竟，是作者发明了这个术语，所以在定义上，他写的任何内容都被认为是权威的。）在论文中，Roy首先定义一种方法 论来谈论架构风格——高级、抽象的模式，来表达架构方法背后的核心理念。每一个架构风格由一系列的约束（constraints）定义形成。架构风格的例子包括“没有风格”（根本没有任何约束）、管道和过滤器（pipe and filter）、客户端/服务器、分布式对象以及——你猜到它了——REST。

如果对你来说这些听起来都太抽象了，那就对了——REST在本质上是一个可以被许多不同技术实现的高层次的风格，而且可以被实例化——通过为它的抽 象特性赋上不同的值。比如，REST中包含资源和统一接口的概念——也就是说，所有资源都应该对这些相同的方法作出反应。但是REST并没有说明是哪些方 法，或者有多少方法。

REST风格的一个“化身”便是HTTP（以及一套相关的一套标准，比如URI），或者稍微抽象一些：Web架构自身。接着上面的例子，HTTP使 用HTTP动词作为REST统一接口的“实例”。由于Fielding是在Web已经（或者至少是大部分）“完善”了之后才定义的REST风格，有人可能 会争论两者是不是100%的匹配。但是无论如何，整体上来说Web、HTTP和URI仅仅是REST风格的一个主要实现。不过，由于Roy Fielding即是REST论文的作者，又对Web架构设计有过深远的影响，两者相似也在情理之中。

最后，我在前面一次又一次地使用着术语“RESTful HTTP”，原因很简单：许多使用HTTP的应用因为一些理由并没有遵循REST原则，有人会说使用HTTP而不遵循REST原则就等同于滥用HTTP。 当然这听起来有点狂热——事实上违反REST约束的原因通常是，仅仅因为每个约束带来的设计权衡可能不适合于一些特殊情况。但通常，违背REST约束的原 因可归咎于对其好处认知的缺乏。来看一个明显的反面案例：使用HTTP GET调用类似于删除对象的操作，这违反了REST的安全约束和一般性常识（客户程序不应为此负责，服务器端开发人员大概不是有意而为之）。但在随后的文 章中，我会提及更多这样或那样的对HTTP的滥用。

总结

本文试图对REST（Web架构）背后的概念提供快速的介绍。RESTful HTTP暴露功能的方式与RPC、分布式对象以及Web Services是不相同的；要真正理解这些不同是需要一些心态的转变。不管你构建的应用是仅仅想暴露Web UI还是想把API变成Web的一份子，了解下REST的原则还是有好处的。

Stefan Tilkov是InfoQ SOA社区的首席编辑，并且是位于德国和瑞士的innoQ公司的共同创始人、首席顾问和REST狂热分子首领。

   译者简介：苑永凯，软件设计师，毕业于山东大学。主要关注领域为Java EE企业应用、Java EE中间件技术以及敏捷开发方法实践，微有心得。他的Blog为http://blog.csdn.net/ai92，您也可以通过yuanyk[AT]gmail.com与他联系。参与InfoQ中文站内容建设，请邮件至china-editorial[at]infoq.com。

作者 骆古道 发布于 2007年5月27日 下午8时18分

社区

Ruby,

Java

主题

Web框架,

REST,

架构,

Ruby on Rails

标签

AJAX,

Ruby on Rails

一 种思维方式影响了软件行业的发展。REST软件架构是当今世界上最成功的互联网的超媒体分布式系统。它让人们真正理解我们的网络协议HTTP本来面貌。它 正在成为网络服务的主流技术，同时也正在改变互联网的网络软件开发的全新思维方式。AJAX技术和Rails框架把REST软件架构思想真正地在实际中很 好表现出来。今天微软也已经应用REST并且提出把我们现有的网络变成为一个语义网，这种网络将会使得搜索更加智能化。

REST与HTTP协议

REST软件架构是由Roy Thomas Fielding博士在2000年首次提出的。他为我们描绘了开发基于互联网的网络软件的蓝图。REST软件架构是一个抽象的概念，是一种为了实现这一互联网的超媒体分布式系统的行动指南。利用任何的技术都可以实现这种理念。而实现这一软件架构最著名的就是HTTP协议。通常我们把REST也写作为REST/HTTP，在实际中往往把REST理解为基于HTTP的REST软件架构，或者更进一步把REST和HTTP看作为等同的概念。

今天，HTTP是互联网上应用最广泛的计算机协议。HTTP不是一个简单的运载数据的协议，而是一个具有丰富内涵的网络软件的 协议。它不仅仅能够对于互联网资源进行唯一定位，而且还能告诉我们对于该资源进行怎样运作。这也是REST软件架构当中最重要的两个理念。而REST软件 架构理念是真正理解HTTP协议而形成的。有了REST软件架构理念出现，才使得软件业避免了对HTTP协议的片面理解。只有正确的理论指导，才能避免在 软件开发的实际工作过程中少走弯路。

REST与URI（资源定位）

REST软件架构之所以是一个超媒体系统，是因为它可以把网络上所有资源进行唯一的定位，不管你的文件是图片、文件Word还是视频文件，也不管你 的文件是txt文件格式、xml文件格式还是其它文本文件格式。它利用支持HTTP的TCP/IP协议来确定互联网上的资源。

REST与CRUD原则

REST软件架构遵循了CRUD原则，该原则告诉我们对于资源（包括网络资源）只需要四种行为：创建（Create）、获取（Read）、更新 （Update）和销毁（DELETE）就可以完成对其操作和处理了。其实世界万物都是遵循这一规律：生、变、见、灭。所以计算机世界也不例外。这个原则 是源自于我们对于数据库表的数据操作：insert（生）、select（见）、update（变）和delete（灭），所以有时候CRUD也写作为 RUDI，其中的I就是insert。这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最 基本的运算一样。

REST与网络服务

尽管在Java语言世界中网络服务目前是以SOAP技术为主，但是REST将是是网络服务的另一选择，并且是真正意义上的网络服务。基于REST思 想的网络服务不久的将来也会成为是网络服务的主流技术。REST不仅仅把HTTP作为自己的数据运输协议，而且也作为直接进行数据处理的工具。而当前的网 络服务技术都需要使用其它手段来完成数据处理工作，它们完全独立于HTTP协议来进行的，这样增加了大量的复杂软件架构设计工作。REST的思想充分利用 了现有的HTTP技术的网络能力。在德国电视台上曾经出现过一个这样的五十万欧元智力题：如何实现网络服务才能充分利用现有的HTTP协议？该问题给出了 四个答案：去问微软；WSDL2.0/SOAP1.2；WS-Transfer；根本没有。这个问题告诉我们HTTP并不是一个简单的数据传来传去的协 议，而是一个聪明的会表现自己的协议，这也许是REST = Representational State Transfer的真正含义。

实际上目前很多大公司已经采用了REST技术作为网络服务，如Google、Amazon等。在Java语言中重要的两个以SOAP技术开始的网络服务框架XFire和Axis也把REST作为自己的另一种选择。它们的新的项目分别是Apache CXF 和Axis2 。Java语言也制定关于REST网络服务规范：JAX-RS: Java API for RESTful Web Services (JSR 311)。相信还会出现更多与REST相关的激动人心的信息。

REST与AJAX技术

尽管AJAX技术的出现才不到两年时间，但是AJAX技术遵循了REST的一些重要原则。AJAX技术充分利用了HTTP来获取网络资源并且实现了 HTTP没有的对于异步数据进行传输的功能。AJAX技术还使得软件更好地实现分布性功能，在一个企业内只要一个人下载了AJAX引擎，其它企业内部的人 员，就可以共享该资源了。AJAX技术遵守REST准则的应用程序中简单和可伸缩的架构，凡是采用AJAX技术的页面简洁而又丰富，一个页面表现了丰富多 彩的形态。

AJAX技术还使用了一种不同于XML格式的JSON文件格式，这个意义在哪里呢？在REST软件架构下我们不能对于XML文件进行序列化处理，这 样程序员必须要使用自己的XML绑定框架。而以序列化的JavaScript对象为基础的JSON已经获得了广泛认可，它被认为能以远比XML更好的方式 来序列化和传输简单数据结构，而且它更简洁。这对REST是一个极大贡献和补充。

当前的网络应用软件还违背了REST的“无状态服务器”约束。REST服务器只知道自己的状态。REST不关心客户端的状态，客户端的状态自己来管 理，这是AJAX技术的应用之地。通过AJAX技术，可以发挥有状态网络客户机的优势。而REST的服务器关心的是从所有网络客户端发送到服务器操作的顺 序。这样使得互联网这样一个巨大的网络得到有序的管理。

REST与Rails框架

Ruby on Rails框架（简称Rails或者Rails框架）是一个基于Ruby语言的越来越流行的网络应用软件开发框架。它提供了关于REST最好的支持，也是 当今应用REST最成功的一个软件开发框架。Rails框架（从版本1.2.x起）成为了第一个引入REST作为核心思想的主流网络软件开发框架。在 Rails框架的充分利用了REST软件架构之后，人们更加坚信REST的重要性和必要性。Rails利用REST软件架构思想对网络服务也提供了一流的 支持。从最直观的角度看待REST，它是网络服务最理想的手段，但是Rails框架把REST带到了网络应用软件开发框架。这是一次飞跃，让REST的思 想从网络服务的应用提升到了网络应用软件开发。利用REST思想的simply_restful插件已经成为了Rails框架的核心内容。

REST安全性

我们把现有基于SOAP的网络服务和基于REST/HTTP网络服务作个比喻，前者是一种传统的寄信方式，而后者是现代网络的电子邮件方式。要是是 寄信和电子邮件都有病毒存在的话，传统的寄信被送到对方就很危险，而电子邮件是开发的，电子邮件供应商比如Google为我们检查了电子邮件是否有病毒。 这里并不是说明SOAP网络服务消息包含义病毒，而是说明HTTP是无法处理SOAP信息包究竟好不好，需要额外的软件工具解决这一问题，包括防火墙也用 不上和管不了。

REST/HTTP网络服务的信息包可以被防火墙理解和控制。你可以按照操作和链接进行过滤信息包，如你可以规定从外部来的只能读取（GET操作） 自己服务器的资源。这样对于系统管理员而言使得软件管理更为简单。REST的安全性还可以利用传输安全协议SSL/TLS、基本和摘要式认证（Basic und Digest Authentication）。除了这些REST自身的安全性功能外，还可以利用像基于信息的Web Services Security（JSR 155）作为REST不错的补充。

参考文献

• http://www.ibm.com/developerworks/cn/web/wa-ajaxarch/
• http://www.ibm.com/developerworks/cn/java/j-cb08016/

• http://e2c.91yee.com/columns/

• http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

不唐突的JavaScript的七条准则

RichClient/RIA原则与实践（上）

作者 陈金洲 发布于 2009年3月10日 上午4时8分

社区

.NET,

Agile,

Java

主题

RIA,

富客户端/桌面

标签

原则

Web领域的经验在过去十多年的不断的使用和锤炼中，整个 开发领域的技术、理念、缺陷已经趋于成熟。JavaEE Stack, .NET Stack, Ruby On Rails等框架代表了目前这个技术领域的所有经验积累。这样我们在开始一个新的项目的时候，只需要选择对应语言的最佳实践，基本上不会犯大的错误。例 如，如果使用Java开发一个新的Web应用，那么基本上Spring/Guice+Hibernate/iBatis/+Struts /SpringMVC这种架构是不会产生重大的架构问题的；如果使用RoR那么你已经在使用最佳实践了；系统的分层：领域层，数据库层，服务层，表现层等 等；为了保证系统的可扩展性，服务器端应当是无状态架构，等等。总而言之，web开发领域，它丰富的积累使得开发者逐渐将更多的精力投入到应用本身。

来看富客户端，或者富互联网应用。在我看来，今天的RichClient与RIA已经没有分别：只要代表着丰富界面元素和丰富用户体验，需要与服务器进行 交互的应用都可以称为RichClient或者RIA，虽然感觉上RichClient更“企业化”一些（服务器往往在企业内部），RIA更“个人化”一 些（服务器往往处于公网）。从最小的层面来说，我现在正在使用的离线模式的GoogleDoc就是一个RichClient应用──虽然它没有那么 Rich，采用和microsoft office一样土的界面; 我现在正在听音乐的Last.fm客户端显然是一个非常典型的RIA──它所有的个人喜好信息、音乐全都来自远在美国的服务器。本地的这个界面，只是提供 收集个人和音乐信息，以及控制音乐的播放和停止；目前拥有1150万玩家的魔兽世界，则是一个挣钱最多的，最“富”的客户端，10多G的客户端包含了电影 品质的广阔场景，华丽的魔法效果和极其复杂的人机交互。

如今的用户需求已经达到了一个新的高度，那些灰色的，方方正正的界面已经逐渐不能够满足客户的需求。从我们工作的客户看来，他们除了对“完成功能”有着基 本的期待外，对于将应用做得“酷”，也抱有极大的热情。我工作的上一个项目是一个CRM系统，它是基于.NET Framework 3.5的一个RichClient应用。它的主窗口是一个带着红色渐变背景的无边框窗口，还有请专业美工制作的图标，点击某一个菜单还有华丽的二级菜单滑 动效果。我们在这个项目中获得了很多，有些值得借鉴，有些仍然值得反思。我仍然记得我们在项目的不同阶段，做一个技术决定是如此的彷徨和忐忑：因为在当时 的RichClient企业开发领域，几乎没有任何丰富的经验可以借鉴，我们重新发明了一些轮子，然后又推翻它；我们偏离了UI框架给我们提供的各种便利 而自己实现种种基础特性，只是因为他们偏离了我们所倡导的测试性的原则。在写下本文的时候，我尝试搜索了一下，仍然没有比较深入的实践性文章来介绍企业环 境下RichClient开发。大多数的书，如Swing、JavaFX、.NET WPF开发等等，偏向于小规模特性介绍，而在大规模的企业应用中，这些小的技巧对于架构决策往往帮助很小。

我的工作经历应当是和大多数开始进行RichClient开发的开发者类似：有着丰富的Web开发的经验之后开始进行RichClient开发。加入 ThoughtWorks之后参加了多个不同的RichClient项目的开发工作，使用/尝试过的语言包括Java Swing, Flex/Adobe Air, .NET WinForm/.NET WPF. 对于不同平台之间的种种有些体会。在这里我将这些实践和原则总结如下。例子很可能过时，毕竟华丽的界面框架层出不穷，但原则应当通用的。使用和遵循这些原 则将会帮助你少犯错误──至少比我们过去犯的错误要少。如果你拥有一定的web开发经验，那么这篇文章你读起来会很亲切。

这些原则/实践往往不是孤立的，我尝试将他们之间用图的方式关联起来，帮助你在使用的过程中进行选择。例如，你遵循了“一切皆异步”的原则，那么很可能你 需要进行“线程管理”和“事件管理”；如果你需要引入“缓存与本地存储”，那么“数据交互模式”你也需要进行考虑。希望这张图能够帮助读者理解不同原则之间的联系。

下面列出的这些原则或者实践没有严格意义上的区分。按照上面的图，我推荐是，一旦你考虑到了某一个实践，那么与它直接关联的实践你最好也要实现。它会使得你的架构更全面，经得起用户功能的需求和交互的需求。

为了让这些实践更加通用，我采用伪代码书写。相信读者能够转化成相应的语言──Java, C#, ActionScript或者其他。这些实践并非与某一种语言相关。在某些特定的例子中，我会采用特定语言，但大多数都是伪代码描述的。

1 一切皆异步

所有耗时的操作都应当异步进行。这是第一条、也是最重要的原则，违背了这条原则将会导致你的应用完全不可用。

考虑这样的一个功能：点击一个"更新股票信息"按钮，系统会从股票市场（第三方应用）获得最新的股票信息，并将信息更新到主界面。丝毫不考虑用户体验的写法：

void updateStockDataButton_clicked() {
    stockData = stockDataService.getLatest(); // 从远程获取股票信息
    updateUI(stockData); // 这个方法会更新界面
}

那么，当用户点击updateStockDataButton的时候，会有什么反应？难说。如果是一个无限带宽、无限计算资源的世界，这段代码直观又易 懂，而且工作的非常好：它会从第三方股票系统读到股票数据，并且更新到界面上。可惜不是。这段代码在现实世界工作的时候，当用户点击这个按钮，整个界面会 冻结──知道那种感觉吗？就是点完这个按钮，界面不动了；如果你在使用Windows, 然后尝试拽住窗口到处移动，你会发现这个窗口经过的地方都是白的。你的客户不会理解你的程序实际上在很努力的从股票市场获得数据，他们只会很愤怒的说，这 个东西把我的机器弄死了！他们的思路被打断了。于是他们不再使用你的程序，你们的合作没了。你没钱了。你的狗也跑了。

出现界面冻结的原因是，耗时操作阻塞了UI线程。UI线程一般负责着渲染界面，响应用户交互，如果这个线程被阻塞，它将无法响应所有的用户交互请求，甚至 包括拖拽窗口这样简单的操作。所有的界面框架，无论是Java/.NET/ActionScript/JavaScript, 都只有一个UI线程，这个估计永远都不会变。

用户看到的应用通常与程序员大相径庭。用户对应用的期待级别分别是：能用、可用、好用、好看。而我观察到的大多数程序员停留在第一阶段：能用。“一切皆异步”这个原则说来简单，做起来也不会很难。把上面的代码稍作改动，如下：

void updateStockDataButton_clicked() {
    runInAnotherThread( function () {
        stockData = stockDataService.getLatest(); // 从远程获取股票信息
        updateUI(stockData); // 这个方法在UI线程更新界面
    }
}

注意加粗部分。runInAnotherThread是跟语言平台特定的。对于.net C#，可以是一个Dispatcher+delegate或者ThreadPool.QueueUserWorkItem；对于Java，可以干脆是一个Runable。对于AJAX, 可以是XMLHttpRequest或者把这个计算扔到一个IFrame中；对于ActionScript, 似乎没有什么好的方法，把获取数据的部分交给XML.load然后通过事件回调的方式来进行界面刷新吧。

耗时操作一般两种来源产生：网络带来的延迟以及大规模运算。两者对应的异步实现方式有所不同。前者往往可以通过特定语言、平台的获取数据的方式来进行异步，特别是缺乏多线程特性的动态语言。例如典型的AJAX方式：

xhr = new XmlHttpRequest()
xhr.send("POST", '/stockData/MSFT', function() {
    doSomethingWith(xhr.responseText);  // 只有当数据返回的时候，才会调用
})

大规模运算带来的耗时在Java/C#等支持多线程的语言环境中很容易实现，而对于JavaScript/ActionScript等很难，折衷的方式是 将复杂运算延迟到服务器端进行；或者将复杂运算拆解成若干个耗时较少的小运算，例如ActionScript的伪多线程实现方式。

“一切皆异步”这个原则说来容易，但要在企业应用中以一种一致的方式进行实现很难。上例中runInAnotherThread的方式貌似简单，也可能出 现在各种GUI框架的介绍中，但绝不是一个稍具规模的RichClient应当采用的方式。它很难作为一种编程范式被遵循，你绝不会希望看到在你的代码中 所有用到异步的地方都new Runnable(){...}。这样带来的问题不仅仅是异步被不被管理的到处乱扔，还带来了测试的复杂性。为了解决这些只有在至少有点规模的 RichClient中才出现的问题，你最好也实现了“4 线程管理”（见下篇），能够实现“3 事件管理”（见下篇）更好。终极方式是将这些抽象到应用的基础框架中，使得所有的开发人员以一种一致的方式进行编程。

2 视图管理

2.1 视图生命周期管理

视图这个概念在WEB开发中几乎被忽略。这里所说的视图是指页面、页面块等界面元素。在WEB开发中，视图的生命周期很短：在进入页面的时候创建，在离开页面的时候销毁。一不小心页面被弄糟了，或者不能按照预期的渲染了，点下刷新按钮，整个世界一片清净。

WEB下的视图导航也是如此自然。基于超链接的方式，每点击一次，就能够打开一个新的页面，旧的页面被浏览器销毁，新的页面诞生。（这里不考虑AJAX或者其他JavaScript特效）

如果把这种想法带入到RichClient开发，后果会很糟糕。每当点击按钮或者进行其他操作需要导航到新的窗口，你不加任何限制的创建新窗口或者新的视 图。然而CPU不是无限的。创建一个新的视图通常是很耗CPU和内存的。系统响应会变慢。用户会抱怨，拒绝付钱，于是因为饥饿，你的狗再次离开了你。

每次新创建视图产生的严重后果并不仅仅是非功能性的，还包括功能性的缺失。如果你用过Skype，当你在给张三通话的时候，再次点击张三并且进行通话，你 会发现刚刚的通话界面会弹出来，而不是开启新窗口。在我们的一个项目中，有一个功能：点击软件界面上的电话号码就能开启一个新窗口，并直接连到桌上的电话 拨号通话。可以想象，如果每次都会弹出新的窗口，软件的逻辑是根本错误的。

如何解决这个问题？最简单的方式是将所有已知的视图全都保存到本地的一个缓存中，我们命名为ViewFactory，当需要进行获取某个视图的时候，直接从ViewFactory拿到，如果没有创建，那么创建，并放到Cache中：

class ViewFactory {
     cache = {}
     View getView(Object key) {
        if cache.contains(key) {
            return cache[key]
        }
        cache[key] = createView(key)
        return cache[key]  
    }
}

需要注意的是，ViewFactory中key的选择。对于简单的应用，key可以干脆就是某个单独窗口的类名。例如整个系统中往往只有一个配置窗口，那 么key就是这个类名；对于需要复用的窗口，往往需要根据其业务主键来创建相应的视图。例如代码中只有一个UserDetailWindow, 需要用来展示不同用户的信息。当需要同时显示两个以上的用户信息的时候，用同一个窗口实例显然不对。这时候key的选择可以是类名+用户ID。

2.2 视图导航

上面的方案并没有解决导航的问题。导航需要解决的问题有两个，如何导航以及如何在导航时传递数据。这时候不得不羡慕WEB的解决方式。我要访问ID为1的用户信息，只需要访问类似于users/1的页面就好；需要访问搜索结果第5页，只需要访问/search?q=someword&page=5就好。这里/search是视图，q=someword和page=5是传递的数据。目前我还没有发现任何一本书来讲述如何进行视图导航。我们的方式是实现一个Navigator类用来导航，Navigator依赖于前面提到的ViewFactory：

class Navigator {
    Navigator(ViewFactory viewFactory) {
        this.viewFactory = viewFactory;
    }
    void goTo(Object viewKey) {
        this.viewFactory.getView(viewKey).show()
    }
}

（这个类看起来跟ViewFactory没什么大的差别，但他们逻辑上是完全不同，并且下面的扩展中会增强）

这样是可以解决问题的。如果要在不同的视图之间传递数据，只需要对Navigator.goTo方法稍加扩展，多添加一个参数就能够传递参数了。例如，在用户列表窗口点击用户名，发送一条消息并打开聊天窗口，可以写为：

void messageButton_clicked() {
    Navigator.goTo("ChatWindow#userId", "聊天消息")
}

然而这种方式并不完美。当你发现大量的数据在窗口之间交互的时候，这种将主动权交给调用方控制的方式，会给状态同步带来不少麻烦；如果你使用了本地存储，它越过存储层直接与服务器交互的方式也会带来不少的不便之处。更好的方式是使用“3 事件管理”（见下篇）。当然，如果窗口之间导航不存在数据传递，基于Navigator的方式仍然简单并且可用。

相关阅读：

[ ThoughtWorks实践集锦（1）] 我和敏捷团队的五个约定。

[ ThoughtWorks实践集锦（2）] 如何在敏捷开发中做好数据迁移。

作者介绍：陈金洲，Buffalo AJAX中文问题 Framework作者，ThoughtWorks咨询师，现居北京。目前的工作主要集中在RichClient开发，同时一直对Web可用性进行观察，并对其实现保持兴趣。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

RichClient/RIA原则与实践（下）

作者 陈金洲 发布于 2009年3月11日 下午10时7分

社区

.NET,

Agile,

Java

主题

RIA,

富客户端/桌面

标签

原则

3 事件管理

事件管理应当是整个RichClient/RIA开发中的最难以把握的部分。这部分控制的好，你的程序用起来将如行云流水，用户的思维不会被打断。任何一 个做RichClient开发的程序员，可以对其他方面毫无所知，但这部分应当非常熟悉。事件是RichClient的核心，是“一切皆异步”的终极实现。前面所说的例子，实际上可以被抽象为事件，例如第一个，获取股票数据，从事件的观点看，应该是：

• 开始获取股票数据
• 正在获取股票数据
• 获取数据完成
• 获取数据失败

看起来相当复杂。然而这样去考虑的时候，你可以将执行计算与界面展现清晰的分开。界面只需要响应事件，运算可以在另外的地方 悄悄的进行，并当任务完成或者失败的是时候报告相应的事件。从经验看来，往往同样的数据会在不同的地方进行不同的展示，例如skype在通话的时候这个人 的头像会显示为占线，而具体的通话窗口中又是另外不同的展现；MSN的个人签名在好友列表窗口中显示为一个点击可以编辑控件，而同时在聊天窗口显示为一个 不能点击只能看的标签。这是RichClient的特性，你永远不知道同一份数据会以什么形式来展现，更要命的是，当数据在一个地方更新的时候，其他所有 能展现的地方都需要同时做相应的更新。如果我们仍然以第一部分的例子，简单采用runInAnoterThread是完全不能解决这个问题的。

我们曾经犯过一些很严重的错误，导致最终即便重构都积重难返。无视事件的抽象带来的影响是架构级别的，小修小补将无济于事。

事件的实现方式可以有很多种。对于没有事件支持的语言，接口或者干脆某一个约束的方法就可以。有事件支持的语言能够享受到好处，但仍然是语法级别的，根本 是一样的。观察者模式在这里很好用。仍然以股票为例，被观察的对象就是获取股票数据对象StockDataRetriver，观察的就是StockWindow：

StockDataRetriver {
observers: []
retrieve() {
try {
theData = ...// 从远程获取数据
observers.each {|o| o.stockDataReady(theData)}  // 触发数据获取成功事件
} catch {
observers.each { |o| o.stockDataFailed() }  // 触发事件获取失败事件
}
}
}
StockDataRetriver.observers.add(StockWindow)  // 将StockWindow加入到观察者队列
StockWindow {
stockDataReady(theData) {
showDataInUIThread(); // 在UI线程显示数据
}
stockDataFailed() {
showErrorInUIThread(); // 在UI线程显示错误
}
}

你会发现代码变得简单。UI与计算之间的耦合被事件解开，并且区分UI线程与运算线程之间也变得容易。当尝试以事件的视角去观察整个应用程序的时候，你会更关注于用户与界面之间的交互。

让我们继续抽象。如果把“获取股票数据”这个按钮点击，让StockDataRetriver去获取数据当作事件来处理，应该怎么写呢？将按钮作为被观察 者，StockDataRetriver作为观察者显然不好，好不容易分开的耦合又黏在一起。引入一个中间的Events看起来不错：

Events {
listeners: {}
register(eventId, listener) {
listeners[eventId].add(listener)
}
broadcast(eventId) {
listeners[eventId].observers.each{|o| o.doSomething(); }
}
}

Events中维护了一个listeners的列表，它是一个简单的Hash结构，key是eventId，value是observer的列表；它提供了两个方法，用来注册事件监听以及通知事件产生。对于上面的案例，可以先注册StockDataRetriver为一个观察者，观察start_retrive_stock_data事件：

Events.register('start_retrive_stock_data', StockDataRetriever)

当点击“获取股票数据”按钮的时候，可以是这样：

Events.broadcast('start_retrive_stock_data')

你会发现StockDataRetriver能够老老实实的开始获取数据了。

需要注意的是，并非将所有事件定义为全局事件是一个好的实践。在更大规模的系统中，将事件进行有效整理和分级是有好处的。在强类型的语言（如 Java/C#）中，抽象出强类型的EventId，能够帮助理解系统和进行编程，避免到处进行强制类型转换。例如，StockEvent：

StockDataLoadedEvent {
StockData theData;
StockDataLoadedEvent(StockData theData);
}
Event.broadcast(new StockDataLoadedEvent(loadedData))

这个事件的监听者能够不加类型转换的获得StockData数据。上面的例子是不支持事件的语言，C#语言支持自定义强类型的事件，用起来要自然一些：

delegate void StockDataLoaded(StockData theData)

事件管理原则我相信并不难理解。然而困难的是具体实现。对一个新的UI框架不熟悉的时候，我们经常在“代码的优美”与“界面提供的特性”之间徘徊。实现这 样的一个事件架构需要在项目一开始就稍具雏形，并且所有的事件都有良好的命名和管理。避免在命名、使用事件的时候的随意性，对于让代码可读、应用稳定有非 常大的意义。一个好的事件管理、通知机制是一个良好RichClient应用的根本基础。一般说来，你正在使用的编程平台如Swing/WinForm /WPF/Flex等能够提供良好的事件响应机制，即监听事件、onXXX等，但一般没有统一的事件的监听和管理机制。对于架构师，对于要使用的编程平台 对于这些的原生支持要了熟于心，在编写这样的事件架构的时候也能兼顾这些语言、平台提供给你的支持。

采用了事件的事件后，你不得不同时实践“线程管理”，因为事件一般来说意味着将耗时的操作放到别的地方完成，当完成的时候进行事件通知。简单的模式下，你可以在所有需要进行异步运算的地方，将运算放到另外一个线程，如ThreadPool.QueueUserWorkItem, 在运算完成的时候通知事件。但从资源的角度考虑，将这些线程资源有效的管理也是很重要的，在“线程管理”部分有详细的阐述。另外，如果能将你的应用转变为 数据驱动的，你需要关注“缓存以及本地存储”。

4 线程管理

在WEB开发几乎无需考虑线程，所有的页面渲染由浏览器完成，浏览器会异步的进行文字和图片的渲染。我们只需要写界面和JavaScript就好。如果你认同“一切皆异步”，你一定得考虑线程管理。

毫无管理的线程处理是这样的：凡是需要进行异步调用的地方，都新起一个线程来进行运算，例如前面提到的runInThread的实现。这种方式如果托管在 在“事件管理”之下，问题不大，只会给测试带来一些麻烦：你不得不wait一段时间来确定是否耗时操作完成。这种方式很山寨，也无法实现更高级功能。更好 的的方式是将这些线程资源进行统筹管理。

线程的管理的核心功能是用来统一化所有的耗时操作，最简单的TaskExecutor如下：

TaskExecutor {
void pendTask(task) { //task: 耗时操作任务
runInThread {
task.run(); // 运行任务
}
}
}
RetrieveStockDataTask extends Task {
void run() {
theData = ... // 直接获取远程数据，不用在另外线程中执行
Events.broadcast(new StockDataLoadedEvent(theData)) // 广播事件
}
}

需要进行这个操作的时候，只需要执行类似于下面的代码：

TaskExecutor.pendTask(new RetrieveStockDataTask())

好处很明显。通过引入TaskExecutor，所有线程管理放在同一个地方，耗时操作不需要自行维护线程的生命周期。你可以在TaskExecutor中灵活定义线程策略实现一些有趣的效果，如暂停执行，监控任务状况等，如果你愿意，为了更好的进行调试跟踪，你甚至可以将所有的任务以同步的方式执行。

耗时任务的定义与执行被分开，使得在任务内部能够按照正常的方式进行编码。测试也很容易写了。

不同的语言平台会提供不同的线程管理能力。.NET2.0提供了BackgroundWorker, 提供了一序列对多线程调用的封装，事件如开始调用，调用，跨线程返回值，报告运算进度等等。它内部也实现了对线程的调度处理。在你要开始实现类似的TaskExecutor时，参考一下它的API设计会有参考价值。Java 6提供的Executor也不错。

一个完善的TaskExecutor可以包含如下功能：

• Task的定义：一个通用的任务定义。最简单的就是run()，复杂的可以加上生命周期的管理：start()、end()、success()、fail()..取决于要控制到多么细致的粒度。
• pendTask，将任务放入运算线程中
• reportStatus，报告运算状态
• 事件：任务完成
• 事件：任务失败

写这样的一个线程管理的不难。最简单的实现就是每当pendTask的时候新开线程，当运算结束的时候报告状态。或者使用像BackgroundWorker或者Executor这样的高级API。对于像ActionScript/JavaScript这样的，只能用伪线程， 或者干脆将无法拆解的任务扔到服务器端完成。

5 缓存与本地存储

纯粹的B/S结构，浏览器不持有任何数据，包括基本不变的界面和实际展现的数据。RichClient的一大进步是将界面部分本地持有，与服务器只作数据通讯，从而降低数据流量。像《魔兽世界》10多G的超大型客户端，在普通的拨号网络都可以顺畅的游戏。

缓存与本地存储之间的差别在于，前者是在线模式下，将一段时间不变的数据缓存，最少的与服务器进行交互，更快的响应客户；后者是在离线模式下，应用仍然能 够完成某些功能。一般来说，凡是需要类似于“查看XXX历史”功能的，需要“点击列表查看详细信息”的，都会存在本地存储的必要，无论这个功能是否需要向 用户开放。

无论是缓存还是本地存储，最需要处理的问题如何处理本地数据与服务器数据之间的更新机制。当新数据来的时候，当旧数据更新的时候，当数据被删除的时候，等 等。一般来说，引入这个实践，最好也实现基于数据变化的“事件管理”。如果能够实现“客户机-服务器数据交互模式”那就更完美了。

我们犯过这样一个错误。系统启动的时候，将当前用户的联系人列表读取出来，放到内存中。当用户双击这个联系人的时候，弹出这个联系人的详细信息窗口。由于 没有本地存储，由于采用了Navigator方式的导航，于是很自然的采用了Navigator.goTo('ContactDetailWindow', theContactInfo)。由于列表页面一般是不变的，因此显示出来的永远是那份旧的数据。后来有了编辑联系人信息的功能，为了总是显示更新的数 据，我们将调用更改为Navigator.goTo('ContactDetailWindow', 'contactId')，然后在ContactDetailWindow中按照contactId把联系人信息重新读取一次。远在南非的用户抱怨慢。还 好我没养狗，没有狗离开我。后来我们慢慢的实现了本地存储，所有的数据读取都从这个地方获得。当数据需要更新的时候，直接更新这个本地存储。

本地存储会在根本上影响RichClient程序的架构。除非本地不保存任何信息，否则本地存储一定需要优先考虑。某些编程平台需要你在本地存储界面和数 据，如Google Gears的本地存储，置于Adobe Air的AJAX应用等，某些编程平台只需要存储数据，因为界面完全是本地绘制的，如Java/JavaFX/WinForm/WPF等。缓存界面与缓存 数据在实现上差别很大。

本地存储的存储机制最好是采用某一种基于文件的关系数据库，如SQLite、H2（HypersonicSQL）、Firebird等。一旦确定要采用本地存储，就从成熟的数据库中选择一个，而不要尝试着自己写基于文件的某种缓存机制。你会发现到最后你实现了一个山寨版的数据库。

在没有考虑本地存储之前，与远端的数据访问是直接连接的：

我们上面的例子说明，一旦考虑使用本地存储，就不能直接访问远程服务器，那么就需要一个中间的数据层：

数据层的主要职责是维护本地存储与远程服务器之间的数据同步，并提供与应用相关的数据缓存、更新机制。数据更新机制有两种，一种是Proxy（代理）模式，一种是自动同步模式。

代理模式比较容易理解。每当需要访问数据的时候，将请求发送到这个代理。这个代理会检查本地是否可用，如果可用，如缓存处于有效期，那么直接从本地读取数 据，否则它会真正去访问远端服务器，获取数据，更新缓存并返回数据。这种手工处理同步的方式简单并且容易控制。当应用处于离线模式的时候仍然可以工作的很 好。

自动同步模式下，客户端变成都针对本地数据层。有一个健壮的自动同步机制与服务器的保持长连接，保证数据一直都是更新的。这种方式在应用需要完全本地可运行的时候工作的非常好。如果设计得好，自动同步方式健壮的话，这种方式会给编程带来极大的便利。

说到同步，很多人会考虑数据库自带的自动同步机制。我完全不推荐数据库自带的机制。他们的设计初衷本身是为了数据库备份，以及可扩展性 （Scalability）的考虑。在应用层面，数据库的同步机制往往不知道具体应用需要进行哪些数据的同步，同步周期等等。更致命的是，这种机制或多或 少会要求客户端与服务器端具备类似的数据库表结构，迁就这样的设计会给客户端的缓存表设计带来很大的局限。另外，它对客户机-服务器连接也存在一定的局限 性，例如需要开放特定端口，特定服务等等。对于纯粹的Internet应用，这种方式更是完全不可行的，你根本不知道远程数据库的结构，例如 Flickr, Google Docs.

当本地存储+自动同步机制与“事件管理”都实现的时候，应用会是一种全新的架构：基于数据驱动的事件结构。对于所有本地数据的增删改都定义为事件，将关心 这些数据的视图都注册为响应的观察者，彻底将数据的变化于展现隔离。界面永远只是被动的响应数据的变化，在我看来，这是最极致的方式。

结尾

限于篇幅，这篇文章并没有很深入的讨论每一种原则/实践。同时还有一些在RichClient中需要考虑的东西我们并没有讨论：

• 纯Internat应用离线模式的实现。像AdobeAir/Google Gears都有离线模式和本地存储的支持，他们的特点是缓存的不仅仅是数据，还包括界面。虽然常规的企业应用不太可能包含这些特性，但也具备借鉴意义。
• 状态的控制。例如管理员能够看到编辑按钮而普通用户无法看见，例如不同操作系统下的快捷键不同。简单情况下，通过if-else或者对应编程平台下提供的绑定能够完成，然而涉及到更复杂的情况时，特别是网络游戏中大量互斥状态时，一个设计良好的分层状态机模型能够解决这些问题。如何定义、分析这些状态之间的互斥、并行关系，也是处理超复杂
• 测试性。如何对RichClient进行测试？特别是像WPF、JavaFX、Adobe Air等用Runtime+编程实现的框架。它们控制了视图的创建过程，并且倾向于绑定来进行界面更新。采用传统的MVP/MVC方式会带来巨大的不必要的工作量（我们这么做过！），而且测试带来的价值并没有想象那么高。
• 客户机-服务器数据交互模式。如何进行客户机服务器之间的数据交互？最简单的方式是类似于Http Request/Response。这种方式对于单用户程序工作得很好，但当用户之间需要进行交互的时候，会面临巨大挑战。例如，股票代理人关注亚洲银行板块，刚好有一篇新的关于这方面的评论出现，股票代理人需要在最多5分钟内知道这个消息。如果是Http Request/Response, 你不得不做每隔5分钟刷一次的蠢事，虽然大多数时候都不会给你数据。项目一旦开始，就应当仔细考虑是否存在这样的需求来选择如何进行交互。这部分与本地存储也有密切的关系。
• 部署方式。RichClient与B/S 直接最大的差异就是，它需要本地安装。如何进行版本检测以及自动升级？如何进行分发？在大规模访问的时候如何进行服务器端分布式部署？这些问题有些被新技术解决了，例如Adobe Air以及Google Gears，但仍然存在考虑的空间。如果是一个安全要求较高的应用，还需要考虑两端之间的安全加密以及客户端正确性验证。新的UI框架层出不穷。开始一个新的RichClient项目的时候，作为架构师/Tech Lead首先应当关注的不是华丽的界面和效果，应当观察如何将上述原则和时间华丽的界面框架结合起来。就像我们开始一个web项目就会考虑domain 层、持久层、服务层、web层的技术选型一样，这些原则和实践也是项目一开始就考虑的问题。

感谢

感谢我的同事周小强、付莹在我写作过程中提供的无私的建议和帮助。小强推荐了介绍Google Gears架构的链接，让我能够写作“本地存储”部分有了更深的体会。

这篇文章是我近两年来在RichClient工作、网络游戏、WebGame众多思考的一个集合。我尝试过JavaFX/WPF/AdobAir 以及相关的文章，然而大多数的例子都是从华丽的界面入手，没有实践相关的内容。有意思的反而是《大型多人在线游戏开发》这本书，给了我在企业 RichClient开发很多启发。我们曾经犯了很多错误，也获得了许多经验，以后我们应当能做得更好。

参考

• .NET的BackgroundWorker定义：http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx
• ActionScript的伪线程：http://blogs.adobe.com/aharui/2008/01/threads_in_actionscript_3.html
• Google Gears架构：http://code.google.com/apis/gears/architecture.html

相关阅读：

[ ThoughtWorks实践集锦（1）] 我和敏捷团队的五个约定。

[ ThoughtWorks实践集锦（2）] 如何在敏捷开发中做好数据迁移。

[ ThoughtWorks实践集锦（3）] RichClient/RIA原则与实践（上）。

作者介绍：陈金洲，Buffalo AJAX中文问题 Framework作者，ThoughtWorks咨询师，现居北京。目前的工作主要集中在RichClient开发，同时一直对Web可用性进行观察，并对其实现保持兴趣。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

      Ajax的跨域访问问题是现有的Ajax开发人员比较常遇到的问题。
      IE对于跨域访问的处理是，弹出警告框，提醒用户。如果用户将该网站纳入可信任网站，或者调低安全级别，那么这个问题IE就不会在提醒你。  
         FireFox等其它非微软的浏览器遇到跨域访问，则解决方案统一是拒绝访问。
         有 人说，IE是主流浏览器，只要它能正常使用就好了。此言差已，IE虽然能够处理，但是是有前提的，要么用户不厌其烦地在页面弹出警告框之后点击是（点击否 就不执行该Ajax调用了），要么用户将该网站纳入可信任站点。这两种做法，在企业管理系统的应用中倒是比较常见，因为系统管理员可以以行政手段保证用户 的行为。但是对于互联网上的网站或者门户开发，这种做法则不行。
         最近遇到了这个问题，需要在跨域访问结束之后完成使主窗口出现一些特效，搜索了一些资料，通过不断尝试以及在不同浏览器中进行兼容性测试，找到了几个可行的方案：
         1、 Web代理的方式。即用户访问A网站时所产生的对B网站的跨域访问请求均提交到A网站的指定页面，由该页面代替用户页面完成交互，从而返回合适的结果。此 方案可以解决现阶段所能够想到的多数跨域访问问题，但要求A网站提供Web代理的支持，因此A网站与B网站之间必须是紧密协作的，且每次交互过程，A网站 的服务器负担增加，且无法代用户保存session状态。
         2、on-Demand方式。MYMSN的门户就用的这种方式，不过 MYMSN中不涉及跨域访问问题。动态控制script标记的生成，通过修改script标记的src属性完成对跨域页面的调用。此方案存在的缺陷 是，script的src属性完成该调用时采取的方式时get方式，如果请求时传递的字符串过大时，可能会无法正常运行。不过此方案非常适合聚合类门户使 用。
         3、iframe方式。查看过醒来在javaeye上的一篇关于跨域访问的帖子，他提到自己已经用iframe的方式解决 了跨域访问问题。数据提交跟获取，采用iframe这种方式的确可以了，但由于父窗口与子窗口之间不能交互（跨域访问的情况下，这种交互被拒绝），因此无 法完成对父窗口效果的影响。
         4、用户本地转储方式：IE本身依附于windows平台的特性为我们提供了一种基于 iframe，利用内存来“绕行”的方案，即两个window之间可以在客户端通过windows剪贴板的方式进行数据传输，只需要在接受数据的一方设置 Interval进行轮询，获得结果后清除Interval即可。FF的平台独立性决定了它不支持剪贴板这种方式，而以往版本的FF中存在的插件漏洞又被 fixed了，所以FF无法通过内存来完成暗渡陈仓。而由于文件操作FF也没有提供支持（无法通过Cookie跨域完成数据传递），致使这种技巧性的方式 只能在IE中使用。
         5、我自己用于解决这类问题的方式：结合了前面几种方式，在访问A网站时，先请求B网站完成数据处理，再根 据返回的标识来获得所需的结果。这种方法的缺点也很明显，B网站的负载增大了。优点，对session也实现了保持，同时A网站与B网站页面间的交互能力 增强了。最重要的一点，这种方案满足了我的全部需要.