1. 在数据库表中建立一个blob字段存放用户上传文件.
2. 在服务器上建立一个文件夹保存用户上传文件,数据库表中只存放该文件的url地址.

我本人现在比较倾向于第2种方案, 主要原因是担心方案1的效率（我用的是mysql数据库）。 但是处理过程中除了维护数据库中表的字段还要维护上传的文件,稍微麻烦一点。

大家在项目里面又是怎么做呢？ 给我点建议！谢谢

    访问控制技术是由美国国防部（Department of Defense, DoD）资助的研究和开发成果演变而来的。这一研究导致两种基本类型访问控制的产生：自主访问控制（Discretionary Access Control, DAC）和强制访问控制（Mandatory Access Control, MAC）。最初的研究和应用主要是为了防止机密信息被未经授权者访问，近期的应用主要是把这些策略应用到为商业领域。

    自主访问控制，允许把访问控制权的授予和取消留给个体用户来判断。为没有访问控制权的个体用户授予和废除许可。自主访问控制机制允许用户被授权和
取 消访问其控制之下的任何客体（object），换句话说，用户就是他们控制下的客体的拥有者。然而，对于多数组织来说，最终用户对所访问的信息没有拥有 权。对于这些组织，公司或代理机构是事实上的系统客体和处理他们的程序的拥有者。访问优先权受组织控制，而且也常常基于雇员功能而不是数据所有权。

   强制访问控制，在美国国防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定义如下：“一种限制访问客体的手段，它以包含在这些客体中的信息敏感性和访问这些敏感性信息的主体的正式授权信息（如清除）为基础”。
  
   以上访问控制策略对于处理一些无需保密但又敏感的信息的政府和行业组织的需求并不是特别的适合。在这样的环境下，安全目标支持产生于现有法律、道德规范、 规章、或一般惯例的高端组织策略。这些环境通常需要控制个体行为的能力，而不仅仅是如何根据信息的敏感性为其设置标签从而访问这一信息的个人能力。
    

什么是基于角色访问控制（Role-Based Access Control, RBAC）？NIST 有如下定义。
  
   访问是一种利用计算机资源去做某件事情的的能力，访问控制是一种手段，通过它这种能力在某些情况下被允许或者受限制（通常是通过物理上和基于系统的控 制）。基于计算机的访问控制不仅可规定是“谁”或某个操作有权使用特定系统资源，而且也能规定被允许的访问类型。这些控制方式可在计算机系统或者外部设备 中实现。
  
    就基于角色访问控制而言，访问决策是基于角色的，个体用户是某个组织的一部分。用户具有指派的角色（比如医生、护士、出纳、经理）。定义角色的过程应该基于对组织运转的彻底分析，应该包括来自一个组织中更广范围用户的输入。
   
    访问权按角色名分组，资源的使用受限于授权给假定关联角色的个体。例如，在一个医院系统中，医生角色可能包括进行诊断、开据处方、指示实验室化验等；而研究员的角色则被限制在收集用于研究的匿名临床信息工作上。
   
    控制访问角色的运用可能是一种开发和加强企业特殊安全策略，进行安全管理过程流程化的有效手段。
     

用户（User）和角色（Role）

    用户指访问系统中的资源的主体，一般为人，也可为 Agent 等智能程序。角色指应用领域内一种权力和责任的语义综合体，可以是一个抽象概念，也可以是对应于实际系统中的特定语义体，比如组织内部的职务等。针对角色 属性的不同，某些模型中将角色进一步细分为普通角色和管理员角色（可理解为全局角色）。

许可（Permissions）和权限（Permission）

    许可描述了角色对计算机资源的访问和操作所具有的权限，其反映的是授权的结果。比如授予某个角色对计算机资源有读的权限，则代表了一个许可的存在，这个许 可表示：角色获取了对计算机资源的读许可。针对操作来说，其描述的是许可和操作之间的一种关联关系，而这层关系则表示了某一角色对某一操作所具有的权限及 权限状态。

     
角色和指派（Assignment）

    指派包含两个方面，用户指派和许可指派。用户指派表示的是，将用户指派给特定的角色。许可指派表示的是为角色指派计算机资源的访问和操作许可。

会话（session）

    会话表示的是用户和角色之间的关系。用户每次必须通过建立会话来激活角色，得到相应的访问权限。

角色和角色等级（Role Hierarchies）

    角色本身仅仅只是一个名词，其本身并不能代表权限的大小。比如，我们可以定一个“Director”的角色，也可以定一个“Project Leader”的角色。对于现实中我们来说，看到这样两个角色，就清楚 DIR 的权限要比一个 PL 的权限级别高。但是对计算机来说，这两个角色仅仅是两个“词语”，是等同的。可以采用分等级角色，在角色上实现层次化来解决这些问题。也可以采用复合角色 （其表示的就是一个角色组的概念），对角色实现一定的分组和复合，以便于权限指派。在一些 OA 产品中经常出现分等级角色。
   

限制（Constraints）
   
    模型中的职责分离关系（Separation of Duty），用于控制冲突（Conflict）。静态职责分离（Static SD）指定角色的互斥关系，用于用户指派阶段。避免同一用户拥有互斥的角色。实现简单，角色互斥语义关系清楚，便于管理不够灵活，不能处理某些实际情况。 动态职责分离（Dynamic SD）指定角色的互斥关系，用于角色激活阶段。允许同一用户拥有某些互斥的角色，但是不允许该用户同时激活互斥的角色。更灵活，直接与会话挂钩，适应实际 管理需要，实现复杂，不易管理。

参考文献

《工作流授权控制模型》        胡长城

《基于角色的权限管理综述》 俞诗鹏

最后，感谢宏云博士对本文翻译提供的指导。   


请注意！引用、转贴本文应注明原作者：Rosen Jiang 以及出处：http://www.blogjava.net/rosen

Java本身是一种设计的非常简单，非常精巧的语言，所以Java背后的原理也很简单，归结起来就是两点：

1、JVM的内存管理

理解了这一点，所有和对象相关的问题统统都能解决

2、JVM Class Loader

理解了这一点，所有和Java相关的配置问题，包括各种App Server的配置，应用的发布问题统统都能解决

就像张无忌学太极剑，本质就是一圈一圈的画圆，你要是懂得了太极剑的本质，那么太极剑就那么一招而已，本身是很容易学的，只是难度在于你要能够举一 反三，化一式剑意为无穷无尽的剑招，这就需要一点悟性和不断的实践了；反过来说，如果学剑不学本质，光学剑招，你就是学会了1万招，碰到了第1万零1招， 还是不会招架，败下阵来。

技术世界本来就是丰富多彩，企图统一标准，实际上也做不到，但是世界本质其实并不复杂。学习技术，特别是某种具体的软件工具的时候，应该学会迅速把 握事物的本质，不要过多搅缠细节。软件工具应该为我所用，而不是我被工具所驾驭。当你具备了对整个J2EE架构的设计和实施的能力，你还会被具体的工具束 缚吗？哪种工具适合你的架构，你就用什么，哪种不适合你，你就抛弃它，软件皆臣服于你的脚下，而不是你被什么软件牵着鼻子走，到了这种程度，你难道还害怕 学习什么新的软件？

我自己也在一直朝着这个方向努力，在我心中，设计软件，架构是第一位的，采用什么技术要为架构服务。如果我发现什么技术对我的架构来说很重要，那么 我会花时间去学习，去钻研，就像我花时间去钻研ORM一样，如果我觉得什么技术对我的架构来说没有用，即使技术再火爆，我也不去碰它。

总之要学会抓住本质，驾驭技术，而不是被技术所驾驭。当你掌握了本质原理，其实学什么都很快，毕竟都是相通的，我先看JDO，后看 Hibernate，其实两者就很类似，所以学得很快，以后如果有工作需要，要我学习别的ORM，那我也不会觉得有什么困难的，一样手到拿来。

更有说服力的是Unix类的操作系统，那就更相似了，只要抓住了Unix最本质的几点，例如shell命令和编程，文件系统结构和配置，系统启动原 理和过程，所有的Unix都是无师自通的。我自己会用Linux，FreeBSD，SCO Unix， Solaris，HP-UX 和 AIX等6种Unix，更体会到一通百通的道理。

拿刚出了光明顶密道的张无忌来说吧，(我很喜欢张无忌这个角色)，他也没有练过什么武功，但是他已经把天下武学之本质：九阳神功 + 乾坤大挪移学会了，所以不管什么功夫，他都是看一遍就会，马上为我所用，看了空性用了一遍龙爪手，就会用龙爪手来破对方；和昆仑派打了一架，就会用昆仑剑 法和灭绝师太过招；七伤拳更是无师自通；太极拳也是看一遍就会。

总之，学习方法还是很重要，别被五花八门的技术给搞不清学习方向了。

一、Struts的国际化
    Struts是一种支持国际化的MVC的Web Framework。可是如何来使用struts国际化是一个问题。下面我们来探讨一下，如何实现Struts的国际化。Web程式的国际化涉及到3个层面的东西。第一、jsp部分的输入/输出；第二、应用处理程序的国际化；第三、DB的国际化问题。这里主要探讨的是jsp部分的输入/输出问题。

二、静态部分的国际化
   Struts的jsp页面静态内容（包括静态文字，静态图片）国际化问题，是通过资源文件来实现的。要实现国际化，需要做如下几项工作：1、定义web.xml的动ActionServlet的参数；2、定义资源文件；3、定义JSP页面的字符集合；4、在JSP页面获取资源文件里面的内容。
1、定义web.xml的动ActionServlet的参数

2、定义资源文件
在/WEB-INF/classes下面添加UTF-8资源束文件。每一个资源文件是“键－值”对的集合。在JSP页面里面可以通过键来找到相应的数据值。本例子的文件名是ApplicationResources，所以相应的资源文件束是(包括e文，简体中文，繁体中文)
ApplicationResources.properties : 默认资源文件。当在其他资源文件里面找不到某个资源的时候，就使用该资源文件里面的定义。
ApplicationResources_zh_CN.properties：简体中文资源文件。
ApplicationResources_zh_TW.properties：繁体中文资源文件。
资源文件的格式为：默认资源文件名_国别_语言.properties。其中每个文件都是通过%JAVA_HONE%/BIN/native2ascii.exe工具转换而来。你也可以使用其他工具来处理得到(http://java.sun.com/products/jilkit/ 有一个工具Internationalization Java Internationalization and Localization Toolkit 可以处理)。下面是一个例子,我们显示如何使用%JAVA_HONE%/BIN/native2ascii.exe命令来定义资源束文件。
2.1 准备文件
//ApplicationResources.properties ；默认资源文件，通常里面的内容是英文的。
label.username=USERNAME :
label.password=PASSWORD :

//ApplicationResources_zh_CN.bak ；简体中文的资源文件。里面的内容是中文的。它需要工具将其中的内容处理成UTF-8
label.username=用户名 :
label.password=密  码 :

//ApplicationResources_zh_TW.bak : 繁体中文的资源文件。里面的内容是中文的。它需要工具将其中的内容处理成UTF-8,下面的内容是繁体码。
label.username=ノめ?W :
label.password=ノめ?W :

2.2 准备完成以后，使用如下的命令创建UTF-8资源文件束
native2ascii -encoding gb2312 ApplicationResources_zh_CN.bak ApplicationResources_zh_CN.properties
native2ascii -encoding big5 Applica tionResources_zh_TW.bak ApplicationResources_zh_TW.properties

3、定义JSP页面的字符集合
定义JSP页面的语言为UTF-8。在每个JSP页面，必须有如下的内容（如果使用的模板技术，则只是需要在模板页面添加，其他使用该模板的页面无需添加）
<%@ page contentType="text/html;charset=UTF-8"%>

4、在JSP页面获取资源文件里面的内容。
在JSP里面需要显示静态内容的地方使用<bean:message />strus的bean tag包里面的message标签。例如下面的页面

<table>
  <tr>
    <td align="right"><bean:message key="label.username" /></td>   
  </tr>
  <tr>
    <td align="right"><bean:message key="label.password" /></td>
  </tr>
</table>

好了，在这个页面显示的时候，如果客户的IE的语言集合是zh_CN的话，就会显示
用户名：
口  令：

如果是客户的IE的语言是zh_TW的话，就会显示
用户名：
用户名：

可以在IE的工具->Internet选项->语言的地方，来选择，定义IE的语言。

三、表单的数据的处理。
对于表单数据的处理，我们是通过添加一个Filter来实现的。所有提交的请求，都需要做字符处理。然后在web.xml里面定义该Filter。这样我们就不需要在程序里面做任何的字符处理。
3.1 定义Filter。下面是一个例子。
package com.webapps.commons;

import java.io.*;
import javax.servlet.*;

public class CharsetEncodingFilter implements Filter{
  private FilterConfig config = null;
  private String defaultEncode = "UTF-8";

  public void init(FilterConfig config) throws ServletException {
    this.config = config;
    if(config.getInitParameter("Charset")!=null){
        defaultEncode=config.getInitParameter("Charset");
    }
  }

  public void destroy() {
    this.config = null;
  }

  public void doFilter(ServletRequest request, ServletResponse response,
                       FilterChain chain) throws IOException, ServletException {
    ServletRequest srequest=request;
    srequest.setCharacterEncoding(defaultEncode);
    chain.doFilter(srequest,response);
  }
}

3.2 在web.xml里面声明使用该Filter
<filter>
  <filter-name>Character Encoding</filter-name>
  <filter-class>com.webapps.commons.CharsetEncodingFilter</filter-class>
</filter>
<filter-mapping>
  <filter-name>Character Encoding</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

四、扩展
待续的是应用程序部分的国际化问题，和DB的国际化问题。

使用 AppFuse 的七个理由

学习 Java 开放源码工具 —— 并使用这些工具提高生产效率

级别: 初级 Matt Raible (mraible@virtuas.com), 开放源码实践先驱, Virtuas Open Source Solutions 2006 年 8 月 31 日 开 始学习在 Java™ 平台上使用诸如 Spring、Hibernate 或 MySQL 之类的开放源码工具时可能非常困难。再加上 Ant 或 Maven，以及与 DWR 一起的小 Ajax，还有 Web 框架 —— 即 JSF，我们必须睁大眼睛盯着如何配置应用程序。AppFuse 减少了集成开放源码项目的痛苦。它可以把测试变成一等公民，让我们可以从数据库表生成整个 UI，并使用 XFire 来支持 Web 服务。另外，AppFuse 的社区也非常健全，这是不同 Web 框架用户可以一起融洽相处的地方之一。 AppFuse 是一个开放源码的项目和应用程序，它使用了在 Java 平台上构建的开放源码工具来帮助我们快速而高效地开发 Web 应用程序。我最初开发它是为了减少在为客户构建新 Web 应用程序时所花费的那些不必要的时间。从核心上来说，AppFuse 是一个项目骨架，类似于通过向导创建新 Web 项目时 IDE 所创建的东西。当我们使用 AppFuse 创建一个项目时，它会提示我们将使用开放源码框架，然后才创建项目。它使用 Ant 来驱动测试、代码生成、编译和部署。它提供了目录和包结构，以及开发基于 Java 语言的 Web 应用程序所需要的库。 与大部分 “new project” 向导不同，AppFuse 创建的项目从最开始就包含很多类和文件。这些文件用来实现特性，不过它们同时也会在您开发应用程序时被用作示例。通过使用 AppFuse 启动新项目，我们通常可以减少一到两周的开发时间。我们不用担心如何将开放源码框架配置在一起，因为这都已经完成了。我们的项目都已提前配置来与数据库进 行交互，它会部署到应用服务器上，并对用户进行认证。我们不必实现安全特性，因为这都早已集成了。 当我最初开发 AppFuse 时，它只支持 Struts 和 Hibernate。经过几年的努力，我发现了比 Struts 更好的 Web 框架，因此我还添加了为这些 Web 框架使用的选项。现在，AppFuse 可以支持 Hibernate 或 iBATIS 作为持久性框架。对于 Web 框架来说，我们可以使用 JavaServer Faces（JSF）、Spring MVC、Struts、Tapestry 或 WebWork。 AppFuse 提供了很多应用程序需要的一些特性，包括： 认证和授权 用户管理 Remember Me（这会保存您的登录信息，这样就不用每次都再进行登录了） 密码提醒 登记和注册 SSL 转换 E-mail URL 重写 皮肤 页面修饰 模板化布局 文件上载 这种 “开箱即用” 的功能是 AppFuse 与其他 CRUD 代 框架的区别之一（CRUD 取自创建、检索、更新 和删除 几个操作的英文首字母），包括 Ruby on Rails、Trails 和 Grails。上面提到的这些框架，以及 AppFuse，都让我们可以从数据库表或现有的模型对象中生成主页/细节页。 图 1 阐述了一个典型 AppFuse 应用程序的概念设计： 图 1. 典型的 AppFuse 应用程序 清单 1 给出了我们在创建 devworks 项目时所使用的命令行交互操作，同时还给出了所生成的结果。这个项目使用了 WebWork 作为自己的 Web 框架（请参考下面 参考资料 一节给出的链接）。 清单 1. 使用 AppFuse 创建新项目 alotta:~/dev/appfuse mraible$ ant new Buildfile: build.xml clean: [echo] Cleaning build and distribution directories init: new: [echo] [echo] +-------------------------------------------------------------+ [echo] | -- Welcome to the AppFuse New Application Wizard! -- | [echo] | | [echo] | To create a new application, please answer the following | [echo] | questions. | [echo] +-------------------------------------------------------------+ [input] What would you like to name your application [myapp]? devworks [input] What would you like to name your database [mydb]? devworks [input] What package name would you like to use [org.appfuse]? com.ibm [input] What web framework would you like to use [webwork,tapestry,spring,js f,struts]? webwork [echo] Creating new application named 'devworks'... [copy] Copying 359 files to /Users/mraible/Work/devworks [copy] Copying 181 files to /Users/mraible/Work/devworks/extras [copy] Copying 1 file to /Users/mraible/Work/devworks [copy] Copying 1 file to /Users/mraible/Work/devworks install: [echo] Copying WebWork JARs to ../../lib [copy] Copying 6 files to /Users/mraible/Work/devworks/lib [echo] Adding WebWork entries to ../../lib.properties [echo] Adding WebWork classpath entries [echo] Removing Struts-specific JARs [delete] Deleting directory /Users/mraible/Work/devworks/lib/struts-1.2.9 [delete] Deleting directory /Users/mraible/Work/devworks/lib/strutstest-2.1.3 [echo] Deleting struts_form.xdt for XDoclet [delete] Deleting directory /Users/mraible/Work/devworks/metadata/templates [echo] Deleting Struts merge-files in metadata/web [delete] Deleting 7 files from /Users/mraible/Work/devworks/metadata/web [echo] Deleting unused Tag Libraries and Utilities [delete] Deleting 2 files from /Users/mraible/Work/devworks/src/web/org/appfu se/webapp [echo] Modifying appgen for WebWork [copy] Copying 12 files to /Users/mraible/Work/devworks/extras/appgen [echo] Replacing source and test files [delete] Deleting directory /Users/mraible/Work/devworks/src/web/org/appfuse/ webapp/form [delete] Deleting directory /Users/mraible/Work/devworks/src/web/org/appfuse/ webapp/action [copy] Copying 13 files to /Users/mraible/Work/devworks/src [delete] Deleting directory /Users/mraible/Work/devworks/test/web/org/appfuse /webapp/form [delete] Deleting directory /Users/mraible/Work/devworks/test/web/org/appfuse /webapp/action [copy] Copying 5 files to /Users/mraible/Work/devworks/test [echo] Replacing web files (images, scripts, JSPs, etc.) [delete] Deleting 1 files from /Users/mraible/Work/devworks/web/scripts [copy] Copying 34 files to /Users/mraible/Work/devworks/web [delete] Deleting: /Users/mraible/Work/devworks/web/WEB-INF/validator-rules-c ustom.xml [echo] Modifying Eclipse .classpath file [echo] Refactoring build.xml [echo] ---------------------------------------------- [echo] NOTE: It's recommended you delete extras/webwork as you shouldn't ne ed it anymore. [echo] ---------------------------------------------- [echo] Repackaging info written to rename.log [echo] [echo] +-------------------------------------------------------------+ [echo] | -- Application created successfully! -- | [echo] | | [echo] | Now you should be able to cd to your application and run: | [echo] | > ant setup test-all | [echo] +-------------------------------------------------------------+ BUILD SUCCESSFUL Total time: 15 seconds 为什么使用 WebWork？ Struts 社区最近在热情地拥抱 WebWork，这种结合导致为 Java 平台提供了一个非常优秀的新 Web 框架：Struts 2。当然，Spring MVC 是一个非常优秀的基于请求的框架，但是它不能像 Struts 2 一样支持 JSF。基于内容的框架（例如 JSF 和 Tapestry）也都很好，但是我发现 WebWork 更为直观，更容易使用（更多有关 Structs 2 和 JSF 的内容请参看 参考资料）。 在创建一个新项目之后，我们就得到了一个类似于图 2 所示的目录结构。Eclipse 和 Intellij IDEA 项目文件都是作为这个过程的一部分创建的。 图 2. 项目的目录结构 这个目录结构与 Sun 为 Java 2 Platform Enterprise Edition（J2EE）Web 应用程序推荐的目录结构非常类似。在 2.0 版本的 AppFuse 中，这个结构会变化成适合 Apache Maven 项目的标准目录结构（有关这两个目录介绍的内容，请参看 参考资料 中的链接）。AppFuse 还会从 Ant 迁移到 Maven 2 上，从而获得相关下载的能力和对生成 IDE 项目文件的支持。目前基于 Ant 的系统要求提交者维护项目文件，而 Maven 2 可以通过简单地使用项目的 pom.xml 文件生成 IDEA、Eclipse 和 NetBeans 项目文件。（这个文件位于您项目的根目录中，是使用 Maven 构建应用程序所需要的主要组件）。它与利用 Ant 所使用的 build.xml 文件非常类似。） 现在我们对 AppFuse 是什么已经有一点概念了，在本文剩下的部分中，我们将介绍使用 AppFuse 的 7 点理由。即使您选择不使用 AppFuse 来开始自己的项目，也会看到 AppFuse 可以为您提供很多样板代码，这些代码可以在基于 Java 语言的 Web 应用程序中使用。由于它是基于 Apache 许可证的，因此非常欢迎您在自己的应用程序中重用这些代码。 理由 1：测试 测试是在软件开发项目中很少被给予足够信任的一个环节。注意我并不是说在软件开发的一些刊物中没有得到足够的信任！很多文章和案例研究都给出了测试 优先的开发方式和足够的测试覆盖面以提高软件的质量。然而，测试通常都被看作是一件只会延长项目开发时间的事情。实际上，如果我们使用测试优先的方法在编 写代码之前就开始撰写测试用例，我相信我们可以发现这实际上会加速 开发速度。另外，测试优先也可以使维护和重用更加 容易。如果我们不编写代码来测试自己的代码，那么就需要手工对应用程序进行测试 —— 这通常效率都不高。自动化才是关键。 当我们首次开始使用 AppFuse 时，我们可能需要阅读这个项目 Web 站点上提供的快速入门指南和教程（请参看 参考资料 中的链接）。这些教程的编写就是为了您可以首先编写测试用例；它们直到编写接口和/或实现之后才能编译。如果您有些方面与我一样，就会在开始编写代码之前 就已经编写好测试用例了；这是真正可以加速编写代码的惟一方式。如果您首先编写了代码的实现，通过某种方式验证它可以工作，那么您可能会对自己说，“哦， 看起来不错 —— 谁需要测试呢？我还有更多的代码需要编写！”这种情况不幸的一面是您通常都会做一些事情 来测试自己的代码；您简单地跳过了可以自动化进行测试的地方。 AppFuse 的文档展示了如何测试应用程序的所有 层次。它从数据库层开始入手，使用了 DbUnit（请参看 参考资料）在运行测试之前提前使用数据来填充自己的数据库。在数据访问（DAO）层，它使用了 Spring 的 AbstractTransactionalDataSourceSpringContextTests 类（是的，这的确是一个类的名字！）来允许简单地加载 Spring 上下文文件。另外，这个类对每个 testXXX() 方法封装了一个事务，并当测试方法存在时进行回滚。这种特性使得测试 DAO 逻辑变得非常简单，并且不会对数据库中的数据造成影响。 在服务层，jMock （请参看 参考资料）用来编写那些可以消除 DAO 依赖的真正 单元测试。这允许进行验证业务逻辑正确的快速测试；我们不用担心底层的持久性逻辑。 HtmlUnit 支持 HtmlUnit 团队在 1.8 发行版中已经完成了相当多的工作来确保包可以与流行的 Ajax 框架（Prototype 和 Scriptaculous）很好地工作。 在 Web 层，测试会验证操作（Struts/WebWork）、控件（Spring MVC）、页面（Tapestry）和管理 bean（JSF）如我们所期望的一样进行工作。Spring 的 spring-mock.jar 可以非常有用地用来测试所有这些框架，因为它包含了一个 Servlet API 的仿真实现。如果没有这个有用的库，那么测试 AppFuse 的 Web 框架就会变得非常困难。 UI 通常是开发 Web 应用程序过程中最为困难的一部分。它也是顾客最经常抱怨的地方 —— 这既是由于它并不是非常完美，也是由于它的工作方式与我们期望的并不一样。另外，没有什么会比在客户面前作演示的过程中看到看到异常堆栈更糟糕的了！您的 应用程序可能会非常可怕，但是客户可能会要求您做到十分完美。永远不要让这种事情发生。Canoo WebTest 可以对 UI 进行测试。它使用了 HtmlUnit 来遍历测试 UI，验证所有的元素都存在，并可以填充表单的域，甚至可以验证一个假想的启用 Ajax 的 UI 与我们预期的工作方式一样。（有关 WebTest 和 HTMLUnit 的链接请参看 参考资料。） 为了进一步简化 Web 的测试，Cargo（请参看 参考资料）对 Tomcat 的启动和停止（分别在运行 WebTest 测试之前和之后）进行了自动化。 理由 2：集成 正如我在本文简介中提到的一样，很多开放源码库都已经预先集成到 AppFuse 中了。它们可以分为以下几类： 编译、报告和代码生成：Ant、Ant Contrib Tasks、Checkstyle、EMMA、Java2Html、PMD 和 Rename Packages 测试框架：DbUnit、Dumbster、jMock、JUnit 和 Canoo WebTest 数据库驱动程序：MySQL 和 PostgreSQL 持久性框架：Hibernate 和 iBATIS IoC 框架：Spring Web 框架：JSF、Spring MVC、Struts、Tapestry 和 WebWork Web 服务：XFire Web 工具：Clickstream、Display Tag、DWR、JSTL、SiteMesh、Struts Menu 和 URL Rewrite Filter Security：Acegi Security JavaScript 和 CSS：Scriptaculous、Prototype 和 Mike Stenhouse 的 CSS Framework 除了这些库之外，AppFuse 还使用 Log4j 来记录日志，使用 Velocity 来构建 e-mail 和菜单模板。Tomcat 可以支持最新的开发，我们可以使用 1.4 或 5 版本的 Java 平台来编译或构建程序。我们应该可以将 AppFuse 部署到任何 J2EE 1.3 兼容的应用服务器上；这已经经过了测试，我们知道它在所有主要版本的 J2EE 服务器和所有主要的 servlet 容器上都可以很好地工作。 图 3 给出了上面创建的 devworks 项目的 lib 目录。这个目录中的 lib.properties 文件控制了每个依赖性的版本号，这意味着我们可以简单地通过把这些包的新版本放到这个目录中并执行诸如 ant test-all -Dspring.version=2.0 之类的命令来测试这些包的新版本。 图 3. 项目依赖性 预先集成这些开放源码库可以在项目之初极大地提高生产效率。尽管我们可以找到很多文档介绍如何集成这些库，但是定制工作示例并简单地使用它来开发应用程序要更加简单。 除了可以简化 Web 应用程序的开发之外，AppFuse 让我们还可以将 Web 服务简单地集成到自己的项目中。尽管 XFire 也在 AppFuse 下载中一起提供了，不过如果我们希望，也可以自己集成 Apache Axis（请参看 参考资料 中有关 Axis 集成的教程）。另外，Spring 框架和 XFire 可以一起将服务层作为 Web 服务非常简单地呈现出来，这就为我们提供了开发面向服务架构的能力。 另外，AppFuse 并不会将我们限定到任何特定的 API 上。它只是简单地对可用的最佳开放源码解决方案重新进行打包和预先集成。AppFuse 中的代码可以处理这种集成，并实现了 AppFuse 的基本安全性和可用性特性。只要可能，就会减少代码，以便向 AppFuse 的依赖框架添加一个特性。例如，AppFuse 自带的 Remember Me 和 SSL 切换特性最近就因为类似的特性而从 Acegi Security 中删除了。 理由 3：自动化 Ant 使得简化了从编译到构建再到部署的自动化过程。Ant 是 AppFuse 中的一等公民，这主要是因为我发现在命令行中执行操作比从 IDE 中更加简单。我们可以使用 Ant 实现编译、测试、部署和执行任何代码生成的任务。 尽管这种能力对于有些人来说非常重要，但是它并不适用于所有的人。很多 AppFuse 用户目前都使用 Eclipse 或 Intellij IDEA 来构建和测试自己的项目。在这些 IDE 中运行 Ant 的确可以工作，但是这样做的效率通常都不如使用 IDE 内置的 JUnit 支持来运行测试效率高。 幸运的是，AppFuse 支持在 IDE 中运行测试，不过管理这种特性对于 AppFuse 开发人员来说就变得非常困难了。最大的痛苦在于 XDoclet 用来生成 Hibernate 映射文件和 Web 框架所使用的一些工件（例如 ActionForms 和 Struts 使用的 struts-config.xml）。IDE 并不知道需要生成的代码，除非我们配置使用 Ant 来编译它们，或者安装了一些可以认识 XDoclet 的插件。 这种对知识的缺乏是 AppFuse 2.0 切换到 JDK 5 和 Maven 2 上的主要原因。JDK 5、注释和 Struts 2 将让我们可以摆脱 XDoclet。Maven 2 将使用这些生成的文件和动态类路径来生成 IDE 项目文件，这样对项目的管理就可以进行简化。目前基于 Ant 的编译系统已经为不同的层次生成了一些工件（包括 dao.jar、service.jar 和 webapp.war），因此切换到 Maven 的模型上应该是一个非常自然的调整。 除了 Ant 之外（它对于编译、测试、部署和报告具有丰富的支持），对于 CruiseControl 的支持也构建到了 AppFuse 中。CruiseControl 是一个 Continuous Integration 应用程序，让我们可以在源代码仓库中代码发生变化时自动运行所有的测试。extras/cruisecontrol 目录包含了我们为基于 AppFuse 的项目快速、简单地设置 Continuous Integration 时所需要的文件。 设置 Continuous Integration 是软件开发周期中我们首先要做的事情之一。它不但激发程序员去编写测试用例，而且还通过 “You broke the build!” 游戏促进了团队之间的合作和融合。 理由 4：安全特性和可扩展性 AppFuse 最初是作为我为 Apress 编写的书籍 Pro JSP 中示例应用程序的一部分开发的。这个示例应用程序展示了很多安全特性和用于简化 Struts 开发的特性。这个应用程序中的很多安全特性在 J2EE 的安全框图中都不存在。使用容器管理认证（CMA）的认证方法非常简单，但是 Remember Me、密码提示、SSL 切换、登记和用户管理等功能却都不存在。另外，基于角色的保护方法功能在非 EJB 环境中也是不可能的。 最初，AppFuse 使用自己的代码和用于 CMA 的解决方案完全实现了这些特性。我在 2004 年年初开始学习 Spring 时就听说过有关 Acegi Security 的知识。我对 Acegi 所需要的 XML 的行数（175）与 web.xml 中所需要的 CMA 的行数（20）进行了比较，很快就决定丢弃 Acegi 了，因为它太过复杂了。 一年半之后 —— 在为另外一本书 Spring Live 中编写了一章有关使用 Acegi Security 的内容之后 —— 我就改变了自己的想法。Acegi 的确（目 前仍然）需要很多 XML，但是一旦我们理解了这一点，它实际上是相当简单的。当我们最终作出改变，使用 Acegi Security 的特性来全部取代 AppFuse 的特性之后，我们最终删除了大量的代码。类之上的类都已经没有了，“Acegi handles that now” 中消失的部分现在全部进入了 CVS 的 Attic 中了。 Acegi Security 是 J2EE 安全模型中曾经出现过的最好模型。它让我们可以实现很多有用的特性，这些特性在 Servlet API 的安全模型中都不存在：认证、授权、角色保护方法、Remember Me、密码加密、SSL 切换、用户切换和注销。它让我们还可以将用户证书存储到 XML 文件、数据库、LDAP 或单点登录系统（例如 Yale 的 Central Authentication Service (CAS) 或者 SiteMinder）中。 AppFuse 对很多与安全性相关的特性的实现从一开始都是非常优秀的。现在 AppFuse 使用了 Acegi Security，这些特性 —— 以及更多特性 —— 都非常容易实现。Acegi 有很多地方都可以进行扩充：这是它使用巨大的 XML 配置文件的原因。正如我们已经通过去年的课程对 Acegi 进行集成一样，我们已经发现对很多 bean 的定义进行定制可以更加紧密地与 AppFuse 建立联系。 Spring IoC 容器和 Acegi Security 所提供的简单开发、容易测试的代码和松耦合特性的组合是 AppFuse 是这么好的一种开发平台的主要原因。这些框架都是不可插入的，允许生成干净的可测试代码。AppFuse 集成了很多开放源码项目，依赖注入允许对应用程序层进行简单的集成。 理由 5：使用 AppGen 生成代码 有些人会将代码生成称为代码气味的散播（code smell）。在他们的观点中，如果我们需要生成代码，那么很可能就会做一些错事。我倾向于这种确定自己代码使用的模式和自动化生成代码的能力应该称为代码香味的弥漫（code perfume）。如果我们正在编写类似的 DAO、管理器、操作或控件，并且不想为它们生成代码，那么这就需要根据代码的气味来生成代码。当然，当语言可以为我们提供可以简化任务的特性时，一切都是那么美好；不过代码生成通常都是一个必需 —— 通常其生产率也非常高 —— 的任务。 AppFuse 中提供了一个基于 Ant 和 XDoclet 的代码生成工具，名叫 AppGen。默认情况下，常见的 DAO 和管理器都可以允许我们对任何普通老式 Java 对象（POJO）进行 CRUD 操作，但是在 Web 层上这样做有些困难。AppGen 有几个特性可以用来执行以下任务： （使用 Middlegen 和 Hibernate 工具）从数据库表中生成 POJO 从 POJO 生成 UI 为 DAO、管理器、操作/控制器和 UI 生成测试 在运行 AppGen 时，您会看到提示说 AppGen 要从数据库表或 POJO 中生成代码。如果在命令行中执行 ant install-detailed，AppGen 就会安装 POJO 特定的 DAO、管理器以及它们的测试。运行 ant install 会导致 Web 层的类重用通用的 DAO 和默认存在的管理器。 为了阐述 AppGen 是如何工作的，我们在 devworks MySQL 数据库中创建了如清单 2 所示的表： 清单 2. 创建一个名为 cat 的数据库表 create table cat ( cat_id int(8) auto_increment, color varchar(20) not null, name varchar(20) not null, created_date datetime not null, primary key (cat_id) ) type=InnoDB; 在 extras/appgen 目录中，运行 ant install-detailed。这个命令的输出结果对于本文来说实在太长了，不过我们在清单 3 中给出了第一部分的内容： 清单 3. 运行 AppGen 的 install-detailed 目标 $ ant install-detailed Buildfile: build.xml init: [mkdir] Created dir: /Users/mraible/Work/devworks/extras/appgen/build [echo] [echo] +-------------------------------------------------------+ [echo] | -- Welcome to the AppGen! -- | [echo] | | [echo] | Use the "install" target to use the generic DAO and | [echo] | Manager, or use "install-detailed" to general a DAO | [echo] | and Manager specifically for your model object. | [echo] +-------------------------------------------------------+ [input] Would you like to generate code from a table or POJO? (table,pojo) table [input] What is the name of your table (i.e. person)? cat [input] What is the name, if any, of the module for your table (i.e. organization)? [echo] Running Middlegen to generate POJO... 要对 cat 表使用这个新生成的代码，我们需要修改 src/dao/com/ibm/dao/hibernate/applicationContext-hibernate.xml，来为 Hibernate 添加 Cat.hbm.xml 映射文件。清单 3 给出了我们修改后的 sessionFactory bean 的样子： 清单 4. 将 Cat.hbm.xml 添加到 sessionFactory bean 中 <bean id="sessionFactory" class="..."> <property name="dataSource" ref="dataSource"/> <property name="mappingResources"> <list> <value>com/ibm/model/Role.hbm.xml</value> <value>com/ibm/model/User.hbm.xml</value> <value>com/ibm/model/Cat.hbm.xml</value> </list> </property> ... </bean> 在运行 ant setup deploy 之后，我们就应该可以在部署的应用程序中对 cat 表执行 CRUD 操作了： 图 4. Cat 列表 图 5. Cat 表单 我们在上面的屏幕快照中看到的记录都是作为代码生成的一部分创建的，因此现在就有测试数据了。 理由 6：文档 我们可以找到 AppFuse 各个风味的教程，并且它们都以 6 种不同的语言给出了：中文、德语、英语、韩语、葡萄牙语和西班牙语。使用风味（flavor） 一词，我的意思是不同框架的组合，例如 Spring MVC 加上 iBATIS、Spring MVC 加上 Hibernate 或 JSF 加上 Hibernate。使用这 5 种 Web 框架和两种持久框架，可以有好几种组合。有关它们的翻译，AppFuse 为自己的默认特性提供了 8 种翻译。可用语言包括中文、荷兰语、德语、英语、法语、意大利语、葡萄牙语和西班牙语。 除了核心教程之外，还添加了很多教程（请参看 参考资料） 来介绍与各种数据库、应用服务器和其他开放源码技术（包括 JasperReports、Lucene、Eclipse、Drools、Axis 和 DWR）的集成。 理由 7：社区 Apache 软件基金会对于开放源码有一个有趣的看法。它对围绕开放源码项目开发一个开放源码社区最感兴趣。它的成员相信如果社区非常强大，那么产生高质量的代码就是一个自然的过程。下面的内容引自 Apache 主页： “我们认为自己不仅仅是一组共享服务器的项目，而且是一个开发人员和用户的社区。” AppFuse 社区从 2003 年作为 SourceForge 上的一个项目（是 struts.sf.net 的一部分）启动以来，已经获得了极大的增长。通过在 2004 年 3 月转换到 java.net 上之后，它已经成为这里一个非常流行的项目，从 2005 年 1 月到 3 月成为访问量最多的一个项目。目前它仍然是一个非常流行的项目（有关 java.net 项目统计信息的链接，请参看 参考资料），不过在这个站点上它正在让位于 Sun 赞助的很多项目。 在 2004 年年末，Nathan Anderson 成为继我之后第一个提交者。此后有很多人都加入了进来，包括 Ben Gill、David Carter、Mika G?ckel、Sanjiv Jivan 和 Thomas Gaudin。很多现有的提交者都已经通过各种方式作出了自己的贡献，他们都帮助 AppFuse 社区成为一个迅速变化并且非常有趣的地方。 邮件列表非常友好，我们试图维护这样一条承诺 “没有问题是没有人理会的问题”。我们的邮件列表归档文件中惟一一条 “RTFM” 是从用户那里发出的，而不是从开发者那里发出的。我们绝对信奉 Apache 开放源码社区的哲学。引用我最好的朋友 Bruce Snyder 的一句话，“我们为代码而来，为人们而留下”。目前，大部分开发者都是用户，我们通常都喜欢有一段美妙的时间。另外，大部分文档都是由社区编写的；因此， 这个社区的知识是非常渊博的。 结束语 我们应该尝试使用 AppFuse 进行开发，这是因为它允许我们简单地进行测试、集成、自动化，并可以安全地生成 Web 应用程序。其文档非常丰富，社区也非常友好。随着其支撑框架越来越好，AppFuse 也将不断改进。 从 AppFuse 2.0 开始，我们计划迁移到 JDK 5（仍然支持部署到 1.4）和 Maven 2 上去。这些工具可以简化使用 AppFuse 的开发、安装和升级。我们计划充分利用 Maven 2 的功能来处理相关依赖性。我们将碰到诸如 appfuse-hibernate-2.0.jar 和 appfuse-jsf-2.0.jar 之类的工件。这些工件都可以在 pom.xml 文件中进行引用，它们负责提取其他相关依赖性。除了在自己的项目中使用 AppFuse 基类之外，我们还可以像普通的框架一样在 JAR 中对这些类简单地进行扩展，这应该会大大简化它的升级过程，并鼓励更多用户将自己希望的改进提交到这个项目中。 如果没有其他问题，使用 AppFuse 可以让您始终处于 Java Web 开发的技术前沿上 —— 就像我们一样！ 参考资料 学习 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。 AppFuse：该项目的主页。 AppFuse Demos：查看演示和视频。 Struts 2 和 JSF：了解为什么要将这些技术放到一起工作。 Sun 的 J2EE 项目目录结构指南：AppFuse 非常接近于这些指南。 Maven 的 Standard Directory Layout：AppFuse 2.0 将转换到这个目录结构上。 AppFuse 快速入门指南：快速入门并使用 AppFuse。 AppFuse 教程：深入学习更多有关使用 AppFuse 的知识。 Apache Axis 集成：如何将 Apache Axis 集成到自己的 AppFuse 项目中。 Java.net 项目状态：请查看 2005 年 1 月、2 月 和 3 月 的动态。还可以查看 java.net 上的最佳项目 。 获得产品和技术 AppFuse on java.net：下载不同风味的 AppFuse。 WebWork：了解这个易于使用的 Web 框架。 DbUnit：查看更多有关 JUnit 扩展的内容。 jMock：创建动态仿真对象来简化真正的单元测试。 Canoo WebTest：自动化 Web 应用程序的 UI 测试。 HtmlUnit：WebTest 的优秀 JavaScript 支持背后的基础。 Cargo：自动启动和停止容器。 Greenbox：一种代码生成框架。 讨论 AppFuse 论坛：与同行开发人员交流技巧。 关于作者 Matt Raible 居住在美国科罗拉多州的丹佛，他在那里是 Spring 和 Web 框架对 Virtuas Open Source Solutions 的实践先驱。他在开放源码领域具有丰富的经验，是这个领域的专家。他在这个领域中既是用户，又是一名开发人员。Matt 是 SourceBeat Publishing 上 Spring Live 的作者。他还为 Apress 的书籍 Pro JSP Third Edition 作出了很大的贡献。他是很多开放源码会议的积极倡导者，包括 ApacheCon、MySQL User's Conference 和 OSCON，同时他还是 http://raibledesigns.com 上一名非常活跃的博客。Raible 的大部分生活都被计算机所包围了，尽管他是在连电都没有的 Montana 长大的。当不工作的时候时，他总是试图让妻子 Julie 成为世界上最幸福的女人，或者与他们的孩子 Abbie 和 Jack 一起玩耍。

Jive 默认编码方式是 ISO8859_1 。下面以安装在英文 Linux 操作系统上为例：

（ 1 ）安装数据库。在 database 目录中选择对应数据库，如果数据库是 MySQL ，则使用 jive_mysql.sql ，然后通过数据库的管理工具将 jive_mysql.sql 导入相应数据库中。 Jive 所需要的数据库都已经准备完成。

（ 2 ）由于 Jive 是 Servlet/JSP 系统，必须在 Web 容器支持下才能运行。因此，必须安装 Web 服务器软件，例如 Tomcat 等。

最后需要将 Jive 部署到 Tomcat 中。有两种办法，其中直接复制的办法比较简单，修改 server.xml 办法可以见其他章节介绍。

将 Jive 的 application 目录下所有文件复制到 Tomcat 应用目录 webapps 的指定目录下，如 Tomcat/webapps/jive 下。

（ 3 ）在运行设置 Jive 之前，还需要设定 Jive 的初始值，在上述应用目录的 WEB-INF/classes/ 下，创建或编辑 jive_init.properties ，加入行：

jiveHome=C:\\javasource\\jive\\WEB-INF\\jiveHome

这是指定 jivHome 的目录， jiveHome 主要放置 Jive 的配置文件和搜索等内部工作文件，一般是建立在 WEB-INF 目录下，这样， jiveHome 的内容就不会被外界通过浏览器直接访问到，要注意是绝对路径。

（ 4 ）可以安装设置 Jive 系统。通过浏览输入网址： http://localhost:8080/jive/admin/setup/ ， Jive 的安装导航程序会自动进行安装检查。由于 Jive 编码是 ISO8859_1 ，如果涉及需要设置 Java 编码方式的提问，都设置为英文。

管理员密码最好更改一下，默认用户名和密码是 admin 和 admin 。

全部设置完成后，进入 http://localhost:8080/jive/ 可以浏览。

进入 http://localhost:8080/jive/admin 可以实现论坛管理，可以设置全局过滤器，一般设置如下过滤器：

·          TextStyle 文本格式。

·          Newline 新一行。

·          Profanity 过渡亵渎或不恰当词语。

·          URLConverter URLConverter 。

·          ImageFilter ImageFilter 支持上传图片。        

·          CodeHighlighter CodeHighlighter 。

另外，缓存设置也很重要，可根据访问量、缓存击中率以及实际内存大小调整，可以提高论坛的性能。

图片上传路径的设置需要通过手工修改 jiveHome 下的 jive_config.xml 。打开 jive_config.xml 会发现，所有在管理配置中配置的信息都保存在这里，找到下列配置：

<upload>

        <dir>/home/bqlr/jive/upload/</dir>

        <relurl>upload/</relurl>

</upload>

其中， dir 是上传图片存放的绝对路径； relurl 是网址的相对路径，比如 upload/ ，那就表示输入下列网址：“ http://localhost:8080/jive/upload/xxxx.jpg ”，就可以看到上传的图片。因为上传图片有自动缩小功能，因此需要 Linux 安装时是带图形 X86 的完全安装。用户如为中文名，将影响图片文件名。

以上是 Jive 论坛的安装 。

8  小结

本章主要介绍了一个基于 J2EE Web 技术进行设计开发的论坛系统，通过这个系统的剖析，能够了解和掌握 GOF 设计模式，学会 Java 实战中一些处理技巧和技术。

使用 GOF 设计模式的主要优点：使得复杂系统的架构变得更加清晰而且有条理，而这一点正是许多程序员在开发实用系统中所缺乏的，可能导致的结果是大大降低 Java 系统可维护性以及可拓展性，重新回到了传统编程语言的陷阱中。

因此， GOF 设计模式对于 Java 设计编程的重要性是无论怎么强调也不过分，它能够帮助程序员更加深入地理解 Java 完全面向对象特性，从而以真正的面向对象设计概念进行实用系统的设计和开发。

Jive 系统是一个完全的 Web 系统，整个系统的最大特点是自我定制实现，它为了提高数据库的访问性能，使用了自己开发的数据库连接池；为了提高系统的数据处理系统，它使用了缓存机制；为了实现用户安全管理机制，它使用 Proxy 模式实现了角色权限的定位和检查等。这些模块功能在很多系统中都是需要的，但是如果想从 Jive 系统提炼出这些模块功能以达到重用，又是非常困难的。

因此，开发者需要一种具有一定高度的框架技术。在这个框架技术中，所有这些通用技术都能够自动实现，无需再自行设计和开发，能够将更多精力投入到与业务有关的特定功能开发中。 J2EE 的 EJB 技术实际就是这种框架技术。

学习和研究 Jive 论坛系统也非常有助于程序员学习和理解 EJB 和 J2EE 完整的框架技术，因为它们的目的都是一样，只不过实现的途径不一样而已。

Jive 提供了强大的论坛功能，但是有些功能离实际需求还是有一定的距离，例如论坛是用于信息交流讨论的场所。而信息不只是文字，有时还包括图片或一些 PDF 等类型的文件，那么如何在 Jive 中实现这样的功能呢？

6.1  图片上传处理

在 HTML 中，使用表单 Form 主要是用来向服务器提交数据，格式如下：

＜ FORM ACTION="URL"

METHOD="GET|POST"

ENCTYPE="…" TARGET="..." ＞

. . .

＜ /FORM ＞

enctype 指定了表单提交给服务器时的内容形式（ Content-Type ），默认值是 "application/x-www-form-urlencoded" ，这时，表单信息一般采用 URL 编码制。

但是，当向服务器传送图片或文件这样包含非 ASCII 字符或二进制数的数据时，根据 RFC1867 规定，就必须使用“ multipart/form-data ”内容类型。

其实无论是默认表单信息，还是图片文件，这些内容都是装载在 HTTP 协议的正文内容部分，都可以看成 HTTP 协议携带的对象，只是两种正文内容形式不一样。前者是 String 字符串类型，而后者则是一个通用的数据对象类型（ Object ）。在以后章节中将专门讨论 HTTP 协议装载数据对象的底层细节。

使用“ multipart/form-data ”上传文件的格式写法如下：

＜ FORM ACTION="URL" METHOD="GET|POST" ENCTYPE=" multipart/form-data " ＞

  <INPUT TYPE ＝ FILE NAME ＝ file1>

＜ /FORM ＞

文件通过 HTTP 协议传送到服务器端后，需要在服务器端对该文件进行专门的接受。 HttpServletRequest 没有提供直接获取文件数据的方法，因此需要开发专门的服务器文件处理组件。

目前有两种上传文件处理组件：一种是基于完全 JSP 结构的，使用 JSP 来处理上传的文件，以 SmartUpload （ http://www.jspsmart.com ）最常用；还有一种是完全的 JavaBeans 组件： Cos 文件上传组件包（ http://www.servlets.com/cos/index.html ）， Cos 可以使用在 JSP 中，也可以使用在 Servlet 或 Servlet Filter 中。

由于在实际应用中，文件上传功能往往和其他正常表单参数一起混合使用，而不是独立使用的。因此，可以设定一个 Servlet 专门用来处理这类混合表单的请求，在将文件接受处理后，自动导向到处理表单正常参数的 JSP/Servlet 去处理。

表单调用示例如下：

<form action="<%=request.getContextPath()%>/multipartformserv"

     method="post" enctype="multipart/form-data">

   <input type="hidden" name="FORWARDNAME" value="login.jsp" > 

   <input type="file" name="file1" >

   <input type="hidden" name="maxwidth" value="120" >

   <input type="hidden" name="maxheight" value="60" >

   <input type="text" name="username" >

   <input type="text" name="password" >

</form>

在这个表单中，既有文件提交，也有 username 这样正常的参数需要提交，提交的 Servlet 名为 multipartformserv 。由 multipartformserv 来处理上传的文件，然后再自动转交到 FORWARDNAME 的值 login.jsp 进行 username 等正常参数的处理。

在表单中，如果设定 maxwidth 和 maxiheight ，那么表示如果上传的图片超过这个尺寸，服务器将缩小图片到这个尺寸。

编制一个专门用来统一处理 Jive 系统中所有文件处理的 Servlet ，这样有利于简化系统。编制 MultipartFormServ 如下：

public class MultipartFormServ extends HttpServlet {

  static final private String CONTENT_TYPE = "text/html";

  // 文件上传处理

  private static MultipartFormHandle mf = MultipartFormHandle.getInstance();

  // 文件上传后存放的临时目录

  private String dirName;

  private ServletContext context;

  public void init() throws ServletException {

    // 从 web.xml 中读取上传目录参数

    dirName = mf.getUploaddir();

    if (dirName == null) {

      throw new ServletException("Please supply uploadDir parameter");

    }

  }

  // 处理带有文件内容的请求

  public void doPost(HttpServletRequest request, HttpServletResponse response)

         throws ServletException, IOException {

    try {

       mf.init(dirName,request); // 调用文件上传处理器处理

       // 得到 FORWARDNAME 参数值

       String forward=mf.getForwardProgram();

      if (forward.equals(""))

       {

         errorMessage("no forward program", response);

         return;

      }

      String param=mf.getForwardProgramParam();

      mf.clear();

       // 引导分流到 forward 参数值进行其他文本参数处理

      getServletConfig().getServletContext().

           getRequestDispatcher("/"+forward+"?"+param).forward(request, response);

    }catch (Exception Ex) {

          throw new ServletException(Ex.getMessage());

    }

  }

}

MultipartFormHandler 主要调用 Cos 组件处理上传文件，对上传文件图形大小进行处理，然后将图形搬迁到指定的目录；同时也将请求信号中的正常参数提取出来，以作为转发使用。

这样一个图形或文件上传系统已经形成了一个框架结构，可以重复使用在任何需要图片或文件上传处理的系统中，如图 3-8 所示。

图 3-8 中上传文件处理额 Servlet 相当于请求信号 Request 的一个过滤器，既然正常的 Request 处理机制不能从 Request 提取携带的文件，那么，使用一个过滤器先将文件提取出来，剩余的再通过正常 Request 处理机制去处理。

6.2  服务器端图形处理

Java 最初是以 Applet 等客户端图形处理为技术起点的，而本节讨论的是如何在 Servlet/JSP 中实现图形处理。

在 Jive 中，图片可以用来显示用户的头像，用户在上传自己头像图片时，该图片的大小可能不一，但是由于版面原因，显示的头像图片又有大小限制，那么就需要在用户上传图片时对图片大小做一个检查。如果超过规定大小，就进行一定的缩放处理。

缩放处理有两种方式：是在 HTML 显示时，使用 image 语法的 width 和 height 来 限制大小，但是这样做只是解决了表面问题，无法解决大字节图片传送到客户端带来的性能影响，这个图片因为是用户发言的头像，将会在每个帖子里面显示。如果 头像都是巨大图片，对帖子显示速度的影响是很大，因此必须在服务器端进行缩小后，再传送到客户端，这样提高了论坛系统性能。

服务器端的图形处理需要使用到 Java 的图形处理技术，而且图形处理是在服务器端的 Web 容器中进行的。和以往 Java 在客户端进行图形处理稍微有所不同，相同的是都要使用计算机的底层图形支持资源。

J2SE 1.4 提供新的增强的图形处理功能， JDK1.4 中最新的 javax.imageio.ImageIO 对图片进行读写操作，而使用 java.awt.geom.AffineTransform 对图片进行尺寸缩放处理。

import java.io.File;

import java.awt.image.BufferedImage;

import java.awt.Image;

import java.awt.image.AffineTransformOp;

import javax.imageio.ImageIO;

import java.awt.geom.AffineTransform;

public class UploadImg{

     /**

     * 参数设置

     * @param fromdir 图片的原始目录

     * @param todir 处理后的图片存放目录

     * @param imgfile 原始图片

     * @param sysimgfile 处理后的图片文件名前缀

     */

           public void init(String fromdir,String todir,String imgfile,String sysimgfile)

           {

                  this.fromdir=fromdir;

                  this.todir=todir;

                  this.imgfile=imgfile;

                  this.sysimgfile=sysimgfile;

             }

    …

    public boolean CreateThumbnail() throws Exception

    {

        //ext 是图片的格式 gif 、 JPG 或 png

        String ext=""

        double Ratio=0.0;

        File oldFile = new File(fromdir,imgfile);

        if (!F.isFile())  // 检查是否存在此图片文件

             throw new Exception(F+" is not image file error in CreateThumbnail!");

         // 首先判断上传的图片是 gif 还是 JPG ImageIO ，只能将 gif 转换为 png

         if (isJpg(imgfile)){

            ext="jpg";

        }else{

           ext="png";

        }

        File newFile = new File(todir,sysimgfile+"."+ext);

        BufferedImage Bi = ImageIO.read(oldFile);  // 读取原始图片

        if ((Bi.getHeight()>120) || (Bi.getWidth()>120)){

            if (Bi.getHeight()>Bi.getWidth())

              Ratio = 120.0/Bi.getHeight();

            else

              Ratio = 120.0/Bi.getWidth();

       }

       // 进行图片转换

       AffineTransformOp op =

          new AffineTransformOp(AffineTransform.getScaleInstance(Ratio, Ratio), null);

       Image itemp = op.filter(Bi, null);

       try { // 写入转换后的图片

           ImageIO.write((BufferedImage) itemp, ext, newFile);

       }catch (Exception ex) {

            throw new Exception(ex.getMessage());

       }

       return (true);

   }

}

该类中由于使用到了 Java 的 AWT ，虽然没有实际显示，但 Linux 系统下需要 X11 Windows 的支持（安装 Linux 时需安装 XFree86 ， Linux 完全安装方式包括安装 XFree86 ）。

该缩放功能是在图片上传到服务器后再进行的处理，可以对 JPG 进行缩小放大；对上传是 GIF 的图片，缩放后变成 PNG 图片格式文件。

Jive 论坛的一个主要特点就是其性能速度快，因此很多巨大访问量的网站都采用了 Jive 论坛。这些都是由于 Jive 采取了高速缓存机制。

缓存（ Cache ）机制是提高系统运行性能必不可少的技术。缓存机制从原理上讲比较简单，就是在原始数据第一次读取后保存在内存中，下次读取时，就直接从内存中读取。原始数据有可能保存在持久化介质或网络上。缓存机制也是代理模式的一种实现。

4.1  缓存原理和实现

Jive 的 Cache 总体来说实现得不是非常精简和有效。它是针对每个具体数据对象逐个实现缓冲，这种“穷尽”的办法不是实践所推荐的用法。通过使用动态代理模式，可以根据具体方法的不同来实现缓存是值得推荐的做法。 Jive 的缓存实现得比较简单，可以用来学习和研究缓存机制。

Jive 中的 Cache 实现了缓存机制的大部分行为，它是将对象用惟一的关键字 Key 作标识保存在 HashMap 或 Hashtable 中。当然，必须知道这些对象的大小，这个前提条件的设定可以保证缓存增长时不会超过规定的最大值。

如果缓存增长得太大，一些不经常被访问的对象将首先从缓存中删除。如果设置了对象的最大生命周期时间，即使这个对象被反复频繁访问，也将从缓存中删除。这个特性可以适用于一些周期性需要刷新的数据，如来自数据库的数据。

在 Cach 中除了 getObject() 方法的性能依据缓存大小，其他方法的性能都是比较快的。一个 HashMap 用来实现快速寻找，两个 LinkedList 中一个以一定的访问顺序来保存对象，叫 accessed LinkedList ；另外一个以它们加入缓存的顺序保存这些对象，这种保存对象只是保存对象的引用，叫 age LinkedList 。注意，这里的 LinkedList 不是 JDK 中的 LinkedList ，而是 Jive 自己定义的 LinkedList 。

当对象被加入缓存时，首先被 CacheObject 封装。封装有以下信息：对象大小（以字节计算），一个指向 accessed LinkedList 的引用，一个指向 age LinkedList 的引用。

当从缓存中获取一个对象如 ObjectA 时，首先， HashMap 寻找到指向封装 ObjectA 等信息的 CacheObject 对象。然后，这个对象将被移动到 accessed LinkedList 的前面，还有其他一些动作如缓存清理、删除、过期失效等都是在这个动作中一起触发实现的。

public class Cache implements Cacheable {

    /**

     * 因为 System.currentTimeMillis() 执行非常耗费性能，因此如果 get 操作都执行

* 这条语句将会形成性能瓶颈， 通过一个全局时间戳来实现每秒更新

* 当然，这意味着在缓存过期时间计算上有一到几秒的误差

     */

    protected static long currentTime = CacheTimer.currentTime;

    //CacheObject 对象

    protected HashMap cachedObjectsHash;

    //accessed LinkedList 最经常访问的排列在最前面

    protected LinkedList lastAccessedList;

    // 以缓存加入顺序排列，最后加入排在最前面；越早加入的排在最后面

    protected LinkedList ageList;

    // 缓存最大限制 默认是 128k 可根据内存设定，越大性能越高

    protected int maxSize =  128 * 1024;

    // 当前缓存的大小

    protected int size = 0;

    // 最大生命周期时间，默认是没有

    protected long maxLifetime = -1;

    // 缓存的击中率，用于评测缓存效率

    protected long cacheHits, cacheMisses = 0L;

    public Cache() {

        // 构造 HashMap. 默认 capacity 是 11

        // 如果实际大小超过 11 ， HashMap 将自动扩充，但是每次扩充都

// 是性能开销，因此期初要设置大一点

        cachedObjectsHash = new HashMap(103);

        lastAccessedList = new LinkedList();

        ageList = new LinkedList();

    }

    public Cache(int maxSize) {

        this();

        this.maxSize = maxSize;

    }

    public Cache(long maxLifetime) {

        this();

        this.maxLifetime = maxLifetime;

    }

    public Cache(int maxSize, long maxLifetime) {

        this();

        this.maxSize = maxSize;

        this.maxLifetime = maxLifetime;

    }

    public int getSize() {        return size;    }

    public int getMaxSize() {        return maxSize;    }

    public void setMaxSize(int maxSize) {

        this.maxSize = maxSize;

        // 有可能缓存大小超过最大值，需要激活删除清理动作

        cullCache();

    }

    public synchronized int getNumElements() {

        return cachedObjectsHash.size();

    }

    /**

     * 增加一个 Cacheable 对象

* 因为 HashMap 不是线程安全的，所以操作方法要使用同步

* 如果使用 Hashtable 就不必同步

     */

    public synchronized void add(Object key, Cacheable object) {

        // 删除已经存在的 key

        remove(key);

        int objectSize = object.getSize();

        // 如果被缓存对象的大小超过最大值，就放弃

        if (objectSize > maxSize * .90) {            return;        }

        size += objectSize;

        // 创建一个 CacheObject 对象

        CacheObject cacheObject = new CacheObject(object, objectSize);

        cachedObjectsHash.put(key, cacheObject);  // 保存这个 CacheObject

        // 加入 accessed LinkedList ， Jive 自己的 LinkedList 在加入时可以返回值

        LinkedListNode lastAccessedNode = lastAccessedList.addFirst(key);

        // 保存引用

        cacheObject.lastAccessedListNode = lastAccessedNode;

        // 加入到 age LinkedList

        LinkedListNode ageNode = ageList.addFirst(key);

        // 这里直接调用 System.currentTimeMillis(); 用法值得讨论

        ageNode.timestamp = System.currentTimeMillis();

        // 保存引用

        cacheObject.ageListNode = ageNode;

        // 做一些清理工作

        cullCache();

    }

    /**

     * 从缓存中获得一个被缓存的对象，这个方法在下面两种情况返回空

     *    <li> 该对象引用从来没有被加入缓存中

     *    <li> 对象引用因为过期被清除 </ul>

     */

    public synchronized Cacheable get(Object key) {

        // 清除过期缓存

        deleteExpiredEntries();

        // 以 Key 从缓存中获取一个对象引用

        CacheObject cacheObject = (CacheObject)cachedObjectsHash.get(key);

        if (cacheObject == null) {

            // 不存在，增加未命中率

            cacheMisses++;

            return null;

        }

        // 存在，增加命中率

        cacheHits++;

        // 从 accessed LinkedList 中将对象从当前位置删除

        // 重新插入在第一个

        cacheObject.lastAccessedListNode.remove();

        lastAccessedList.addFirst(cacheObject.lastAccessedListNode);

        return cacheObject.object;

    }

    …

}

在 Cache 中，关键字 Key 是一个对象，为了再次提高性能，可以进一步将 Key 确定为一个 long 类型的整数。

4.2  缓存使用

建立 LongCache 只是为了提高原来的 Cache 性能，本身无多大意义，可以将 LongCache 看成与 Cache 一样的类。

LongCache 的关键字 Key 是 Forum 、 ForumThread 以及 ForumMessage 等 long 类型的 ID ，值 Value 是 Forum 、 ForumThread 以及 ForumMessage 等的对象。这些基本是通过 DatabaseCacheManager 实现完成，在主要类 DbForumFactory 的初始化构造时，同时构造了 DatabaseCacheManager 的实例 cacheManager 。

前面过滤器功能分析中， Message 对象获得方法的第一句如下：

protected ForumMessage getMessage(long messageID, long threadID, long forumID) throws

      ForumMessageNotFoundException {

    DbForumMessage message = cacheManager.messageCache.get(messageID);

    …

}

其中， cacheManager 是 DatabaseCacheManager 的实例， DatabaseCacheManager 是一个缓存 Facade 类。在其中包含了 5 种类型的缓存，都是针对 Jive 的 5 个主要对象， DatabaseCacheManager 主要代码如下：

public class DatabaseCacheManager {

…

    public UserCache userCache;                          // 用户资料缓存

    public GroupCache groupCache;                       // 组资料缓存

    public ForumCache forumCache;                       //Forum 论坛缓存

    public ForumThreadCache threadCache;                //Thread 主题缓存

    public ForumMessageCache messageCache;          //Message 缓存

    public UserPermissionsCache userPermsCache;     // 用户权限缓存

    public DatabaseCacheManager(DbForumFactory factory) {

        …

        forumCache =

            new ForumCache(new LongCache(forumCacheSize, 6*HOUR), factory);

        threadCache =

            new ForumThreadCache(

                  new LongCache(threadCacheSize, 6*HOUR), factory);

        messageCache = new ForumMessageCache(

                  new LongCache(messageCacheSize, 6*HOUR), factory);

        userCache = new UserCache(

                  new LongCache(userCacheSize, 6*HOUR), factory);

        groupCache = new GroupCache(

                  new LongCache(groupCacheSize, 6*HOUR), factory);

        userPermsCache = new UserPermissionsCache(

                new UserPermsCache(userPermCacheSize, 24*HOUR), factory

        );

    }

    …

}

从以上代码看出， ForumCache 等对象生成都是以 LongCache 为基础构建的，以 ForumCache 为例，代码如下：

public class ForumCache extends DatabaseCache {

    // 以 Cache 构建 ID 缓存

    protected Cache forumIDCache = new Cache(128*1024, 6*JiveGlobals.HOUR);

    // 以 LongCache 构建整个对象缓存

    public ForumCache(LongCache cache, DbForumFactory forumFactory) {

        super(cache, forumFactory);

    }

    public DbForum get(long forumID) throws ForumNotFoundException {

        …

        DbForum forum = (DbForum)cache.get(forumID);

        if (forum == null) {    // 如果缓存没有从数据库中获取

            forum = new DbForum(forumID, factory);

            cache.add(forumID, forum);

        }

        return forum;

    }

public Forum get(String name) throws ForumNotFoundException {

         // 以 name 为 key ，从 forumIDCache 中获取 ID

 CacheableLong forumIDLong = (CacheableLong)forumIDCache.get(name);

        if (forumIDLong == null) { // 如果缓存没有 从数据库获得

            long forumID = factory.getForumID(name);

            forumIDLong = new CacheableLong(forumID); // 生成一个缓存对象

            forumIDCache.add(name, forumIDLong);

        }

        return get(forumIDLong.getLong());

    }

    …

}

由此可以看到， LongCache 封装了 Cache 的核心功能，而 ForumCache 等类则是在 LongCache 核心外又包装了与应用系统相关的操作，这有点类似装饰（ Decorator ）模式。

从中也可以看到 Cache 和 LongCache 两种缓存的用法。

使用 Cache 时的关键字 Key 是任何字段。如上面代码中的 String name ，如果用户大量帖子主题查询中， Key 是 query + blockID ，见 DbForum 中的 getThreadBlock 方法；而值 Value 则是 Long 类型的 ID ，如 ForumID 或 ThreadID 等。

LongCache 的关键字 Key 是 Long 类型的 ID ，如 ForumID 或 ThreadID 等；而值 Value 则是 Forum 、 ForumThread 或 ForumMessage 等主要具体对象。

在实际使用中，大多数是根据 ID 获得对象。但有时并不是这样，因此根据应用区分了两种 Cache ，这其实类似数据库的数据表，除了主关键字外还有其他关键字。

4.3  小结

缓存中对象是原对象的映射，如何确保缓存中对象和原对象的一致性？即当原对象发生变化时，缓存中的对象也必须立即更新。这是缓存机制需要解决的另外一个基本技术问题。

Jive 中是在原对象发生变化时，立即进行清除缓存中对象，如 ForumMessage 对象的创建。在 DbForumThread 的 AddMessage 方法中有下列语句：

factory.cacheManager.threadCache.remove(this.id);

factory.cacheManager.forumCache.remove(this.forumID);

即当有新的帖子加入时，将 ForumThreadCache 和 ForumCache 相关缓冲全部清除。这样，当有相关对象读取时，将直接从数据库中读取，这是一种非常简单的缓存更新方式。

在复杂的系统，例如有一台以上的服务器运行着 Jive 系统。如果一个用户登陆一台服务器后，通过这台服务器增加新帖。那么按照上述原理，只能更新本服务器 JVM 中的缓存数据，而其他服务器则无从得知这种改变，这就需要一种分布式的缓存机制。

到目前可以发现 ， 整个 Jive 系统其实是围绕 Forum 、 ForumThread 和 ForumMessage 等这些主要对象展开的读取、修改或创建等操作。由于这些对象原先持久化保存在数据库中，为了提高性能和加强安全性， Jive 在这些对象外面分别实现两层包装，如图 3-7 所示。

客户端如果需要访问这些对象，首先要经过它们的代理对象。进行访问权限的检查，然后再从缓存中获取该对象。只有缓存不存在时，才会从数据库中获取。

这套机制是大多数应用系统都面临的必须解决的基本功能，因此完全可以做成一个通用的可重复使用的框架。这样在具体应用时，不必每个应用系统都架设开发这样的机制。其实 EJB 就是这样一套框架，实体 Bean 都由缓存机制支持，而通过设定 ejb-jar.xml 可以实现访问权限控制，这些工作都直接由 EJB 容器实现了，不必在代码中自己来实现。剩余的工作是调整 EJB 容器的参数，使之适合应用系统的具体要求，这些将在以后章节中讨论。

在 Jive 中，图 3-7 的机制是通过不同方式实现的。基本上是一配二模式：一个对象有一个缓冲对象和一个代理对象，这样做的一个缺点是导致对象太多，系统变得复杂。这点在阅读 Jive 源码时可能已经发现。

如果建立一个对象工厂，工厂内部封装了图 3-7 机制实现过程，客户端可以根据不同的工厂输入参数获得具体不同的对象。这样也许代码结构要更加抽象和紧凑， Java 的动态代理 API 也许是实现这个工厂的主要技术基础。有兴趣者可以进一步研究提炼。

在 Jive 中除了前面介绍的有关设计模式实现组件外，还有其他有一定特点的组件功能，分析研究这些组件功能可以更加完整透彻地理解 Jive 论坛系统。

Jive 安全管理机制基本是由下列部分组成：

·          安全验证机制。主要是验证用户名和密码组合是否与数据库中注册时的数据一致，以确认该用户身份为注册用户。这是对所有的 JSP 访问都进行拦截访问。

·          访问权限控制（ ACL ）。对不同的数据不同用户拥有不同的访问权限，例如，一个帖子普通用户可以浏览，但是不能更该；但是管理员却可以编辑删除。这部分功能是通过代理模式实现，为每个关键数据都建立一个代理类用来实现访问权限检查，这在前面讨论过。

·          用户资料管理系统。主要是管理用户的资料数据，进行用户组和用户关系的建立等。

1  安全验证机制

Jive 的安全验证机制是按照比较通用的思路设计的。类似前面“简单的用户注册管理系统”中的介绍， Jive 也是在所有的 JSP 页面中 include 一个安全检验功能的 global.jsp 。由于 global.jsp 是在每个 JSP 一开始必须执行的功能，因此通过拦截 global.jsp 拦截发往各个 JSP 页面的请求（ request ）。如果这个请求是合法的，将被允许通过；如果不是，将注明请求者身份是 Anonymous （匿名者）。

global.jsp 代码如下：

boolean isGuest = false;

Authorization authToken = SkinUtils.getUserAuthorization(request, response);

if (authToken == null) {// 未被验证通过

    authToken = AuthorizationFactory.getAnonymousAuthorization();

    isGuest=true;

}

在 Jive 中，以 Authorization 对象作为验证通过的标志，它的接口代码如下：

public interface Authorization {

    public long getUserID();   

    public boolean isAnonymous();

}

具体实现是 DbAuthorization ，代码如下：

public final class DbAuthorization implements Authorization, Serializable {

    private long userID;

    protected DbAuthorization(long userID) {

        this.userID = userID;

    }

    public long getUserID() {

        return userID;

    }

    public boolean isAnonymous() {

        return userID == -1;

    }

}

此类只是一个 userID ，因此只是一个象征性的标志。

SkinUtils 是一个为 JSP 服务的类，它的 getUserAuthorization 代码如下：

public static Authorization getUserAuthorization

        (HttpServletRequest request, HttpServletResponse response)

  {

    HttpSession session = request.getSession();

    // 从 HttpSession 中获取 Authorization 实例

    Authorization authToken =

(Authorization)session.getAttribute(JIVE_AUTH_TOKEN);

    if (authToken != null) {     return authToken;  }

    // 如果 HttpSession 中没有，检查用户浏览器 cookie

    Cookie cookie = getCookie(request, JIVE_AUTOLOGIN_COOKIE);

    if (cookie != null) {

        try {

           String[] values = decodePasswordCookie(cookie.getValue());

           String username = values[0];

           String password = values[1];

           // 从 cookie 中获得用户名和密码后，进行安全验证

           authToken = AuthorizationFactory.getAuthorization(username,password);

        }catch (Exception e) {}

        // put that token in the user's session:

        if (authToken != null) {// 如果通过验证，保存 authToken 在 http Session

           session.setAttribute(JIVE_AUTH_TOKEN, authToken);

        }

       // return the authorization token

        return authToken;

    }

    return null;

}

用户验证预先通过两个步骤。首先检查 HttpSession 中是否保存了该用户的验证信息，如果用户第一次验证通过，反复访问，这道关口检查就可以通过。

如果 HttpSession 中没有验证信息，那么从该用户的浏览器 cookie 中寻找用户名和密码。如果该用户激活了 cookie 保存这些登录信息，那么应该可以找到用户名和密码，这样就省却了用户再次从键盘输入用户名和密码，将用户名和密码通过下列语句进行数据库验证：

authToken = AuthorizationFactory.getAuthorization(username,password);

这一举是验证关键。 AuthorizationFactory 是一个抽象类，定义了 Jive 安全验证机制所需的所有方法， AuthorizationFactory 的实现类似前面讨论的 ForumFactory 实现，是使用工厂模式加动态类反射机制完成的，代码如下：

public abstract class AuthorizationFactory {

   // 定义一个数据库具体实现

    private static String className =

        " com.Yasna.forum.database.DbAuthorizationFactory";

    private static AuthorizationFactory factory = null;

    // 验证方法 如果没有 UnauthorizedException 抛出，表示验证通过

    public static Authorization getAuthorization(String username,

            String password) throws UnauthorizedException

    {

        loadAuthorizationFactory();

        return factory.createAuthorization(username, password);

    }

    // 匿名者处理方法

    public static Authorization getAnonymousAuthorization() {

        loadAuthorizationFactory();

        return factory.createAnonymousAuthorization();

    }

    // 需要具体实现的抽象方法

    protected abstract Authorization createAuthorization(String username,

            String password) throws UnauthorizedException;

    protected abstract Authorization createAnonymousAuthorization();

    // 动态配置 AuthorizationFactory 的具体实现，可以在配置文件中定义一个

    // 基于 LDAP 的实现。类似 ForumFactory 的 getInstance 方法

    private static void loadAuthorizationFactory() {

        …

    }

}

AuthorizationFactory 看上去很复杂，实际只有一个核心方法 getAuthorization 。实现用户名和密码的验证。如果无法通过验证，有两个信息实现显示：一个是抛出 UnauthorizedException ，另外一个是返回空的 Authorization 对象。

那么，子类 DbAuthorizationFactory 毫无疑问就是查询数据库，将输入的用户名和密码与数据库保存的用户名和密码进行校验。

Jive 的安全验证机制比较简单易懂，值得在实践中学习借鉴。但是注意到这套安全验证机制只是 Web 层的“手工”验证，资源访问权限（ ACL ）也是自己“手工”来实现的。如果使用 EJB 技术，因为 EJB 容器本身有一定的资源访问控制体系，因此在 Web 层验证通过后，需要将这些登录信息传递到 EJB 层。当然如果直接使用 Web 容器的安全验证机制，那么 Web 层与 EJB 层之间的登录信息传递将由容器实现，这样就更加简单方便。

Jive 这种的安全验证并不是使用 Web 容器的安全验证机制，如何使用 Web 容器的安全验证机制将在以后章节介绍。尽管如此， Jive 这套安全验证机制对付小型系统的应用也是足够的。

2  用户资料管理

在 Jive 中，用户 User 对象的操作访问类似于论坛 Forum 对象的访问，与 User 对象有关的操作都封装在一个类中操作，这是外观（ Facade ）模式的应用。

在 Jive 中，用户资料管理属于大系统中的一个子系统，在这个子系统中，用户子系统和其他系统又有一定的关系，涉及的类不少，通过建立一个 UserManager 类来统一对外接口，使得整个子系统条目结构清晰。

UserManager 中无外乎用户数据的管理，如用户的创建、修改、查询和删除。 DbUserManager 是 UserManager 的一个数据库实现，可是看看 DbUserManager 中除了删除功能是直接通过 SQL 语句进行数据库删除操作外，其他都委托给 User 的具体实现 DbUser 实现的。这种实现非常类似于 EJB 中 Session Bean 和实体 Bean 之间的关系。以创建用户资料为例，代码如下：

public User createUser(String username, String password, String email)

            throws UserAlreadyExistsException

 {

        User newUser = null;

        try {

            // 以 username 查询改用户是否存在

            User existingUser = getUser(username);

            // 如果没有抛出 UserNotFoundException 异常，表示该用户存在

            //The user already exists since now exception, so:

            throw new UserAlreadyExistsException();

        } catch (UserNotFoundException unfe) {

            // 该用户不存在，创建一个新用户

            newUser = new DbUser(username, password, email, factory);

        }

        return newUser;

}

DbUser 的构造方法实际是用户资料的新增创建：

protected DbUser(String username, String password, String email,

            DbForumFactory factory)

{

        this.id = SequenceManager.nextID(JiveGlobals.USER);  // 获得自增 ID

        this.username = username;

        // Compute hash of password.

        this.passwordHash = StringUtils.hash(password);  // 获得加密的密码

        this.email = email;

        this.factory = factory;

        long now = System.currentTimeMillis();

        creationDate = new java.util.Date(now);

        modifiedDate = new java.util.Date(now);

        properties = new Hashtable();

        insertIntoDb();              // 数据库插入数据

}

在 Jive 中，数据修改的保存是由 DbUser 的 saveToDb 方法实现的，而 saveToDb 方法调用是在每个 setXXXX 方法中。即每当外界调用 DbUser 的 setXXXX ，则表示需要改变某些字段属性值，在这个方法中直接进行数据库存储，这也类似 EJB 中 CMP 实体 Bean 的数据字段修改保存。

Jive 中组 Group 与用户 User 处理几乎差不多，只是在 Group 中整合了权限方面的信息，这种做法是有一定的局限性，不是很值得借鉴，要想设计一个动态扩展灵活的权限系统，必须在用户或组与权限之间引入角色概念，也就是比较先进的基于角色的权限系统（ RBAC Roled-Based Access Control ，相关网址： http://csrc.nist.gov/rbac/ ）。

在 RBAC 中，用户组只是用户的一个集合，应该是通过角色和权限发生联系。所以 RBAC 认为，如果给用户组赋予权限，那么用户组也接近角色的概念。

Jive 功能需求分析类似于一个新系统的需求分析。只有了解 Jive 系统实现了哪些论坛功能，才能进一步研究和学习它是怎样巧妙、优雅地实现这些功能的。

论坛系统是网络交流的一种主要互动功能系统，如图 3-1 所示。通过论坛系统，用户可以共同就某个话题不断进行讨论，通过发贴功能发布新的话题，通过回贴功能回复别人的话题。 Jive 论坛系统可以允许管理员动态地创建新的论坛、编辑论坛的内容、设置论坛过滤信息以及管理注册用户等。

图 3-1  Jive 用例图

在 Jive 论坛系统中，用户角色和权限是紧密联系在一起的。主要分两大角色：普通用户和管理员，具体的表现形式是通过权限组合来体现的。管理方面的权限有：

·          SYSTEM_ADMIN ，系统管理员，可以管理整个系统。

·          FORUM_ADMIN ，论坛管理员，可以管理某个特定的论坛。

·          USER_ADMIN 和 GROUP_ADMIN ，用户和组管理员，可以管理一些特定用户和用户 组。

论坛的读写权限包括：读权限，创建一个新主题，创建一个新的帖子等。

Jive 中没有明确定义普通用户和管理员角色，而是直接通过以上权限组合和具体用户直接建立联系，并将这种直接联系保存到数据库中。

在权限不是很复杂的情况下，这种没有引入角 色的做法比较简单直接。但由于用户和权限直接挂钩，而用户和权限都可能在不断地动态变化，那么它们之间由于联系太直接和紧密，对各自变化形成了限制。所 以，对于复杂的权限系统，引入了基于角色的权限系统，这将在以后章节中进一步讨论。

Jive 论坛业务对象主要分为 Forum 、 ForumThread 和 ForumMessage ，它们之间的关系如图 3-2 所示。

每个论坛 Forum 包含一系列 ForumThread （主题），而每个主题都是由很多内容帖子 ForumMessage 组成的，这是一个聚集关系。这 3 种对象中每一个对象都涉及到对象数据的创建、编辑、查询和删除，这些对象数据分别保存在数据库中。这 3 个对象对于不同的角色可操作访问权限是不一样的，只有系统管理员和论坛管理员可以对 Forum 相关数据实行操作，普通用户可以创建或编辑 ForumThread 和 ForumMessage 。

Jive 论坛为了实现不同用户对不同基本对象的不同操作权限，通过设定一个统一的入口，在这个入口将检查客户端每次对数据的操作权限，如图 3-3 所示。

图 3-2  基本对象关系图                             图 3-3  入口示意图

客户端每次对数据库的操作，都要经过 ForumFactory 入口进入。在 ForumFactory 中会动态生成一个访问控制代理 ForumFactoryProxy ，通过 ForumFactoryProxy 检查客户端访问方法是否符合整体权限访问控制要求。

下面将从 ForumFactory 作为 Jive 论坛系统分析入手，结合设计模式逐步分解论坛功能的具体实现。