/**
     * Describes the Request-For-Enhancement(RFE) that led
     * to the presence of the annotated API element.
     */
    public @interface RequestForEnhancement {
        int    id();
        String synopsis();
        String engineer() default "[unassigned]"; 
        String date();    default "[unimplemented]"; 
    }

    @RequestForEnhancement(
        id       = 2868724,
        synopsis = "Enable time-travel",
        engineer = "Mr. Peabody",
        date     = "4/1/3007"
    )
    public static void travelThroughTime(Date destination) { ... }

    /**
     * Indicates that the specification of the annotated API element
     * is preliminary and subject to change.
     */
    public @interface Preliminary { }

    @Preliminary public class TimeTravel { ... }

    /**
     * Associates a copyright notice with the annotated API element.
     */
    public @interface Copyright {
        String value();
    }

    @Copyright("2002 Yoyodyne Propulsion Systems")
    public class OscillationOverthruster { ... }

    import java.lang.annotation.*;

    /**
     * Indicates that the annotated method is a test method.
     * This annotation should be used only on parameterless static methods.
     */
    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.METHOD)
    public @interface Test { }

    public class Foo {
        @Test public static void m1() { }
        public static void m2() { }
        @Test public static void m3() {
            throw new RuntimeException("Boom");
        }
        public static void m4() { }
        @Test public static void m5() { }
        public static void m6() { }
        @Test public static void m7() {
            throw new RuntimeException("Crash");
        }
        public static void m8() { }
    }

Here is the testing tool:

    import java.lang.reflect.*;

    public class RunTests {
       public static void main(String[] args) throws Exception {
          int passed = 0, failed = 0;
          for (Method m : Class.forName(args[0]).getMethods()) {
             if (m.isAnnotationPresent(Test.class)) {
                try {
                   m.invoke(null);
                   passed++;
                } catch (Throwable ex) {
                   System.out.printf("Test %s failed: %s %n", m, ex.getCause());
                   failed++;
                }
             }
          }
          System.out.printf("Passed: %d, Failed %d%n", passed, failed);
       }
    }

    $ java RunTests Foo
    Test public static void Foo.m3() failed: java.lang.RuntimeException: Boom 
    Test public static void Foo.m7() failed: java.lang.RuntimeException: Crash 
    Passed: 2, Failed 2

package com.bjinfotech.practice.annotation;

/**
 * 演示如何使用java5内建的annotation
 * 参考资料：
 * http://java.sun.com/docs/books/tutorial/java/javaOO/annotations.html
 * http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html
 * http://mindprod.com/jgloss/annotations.html
 * @author cleverpig
 *
 */
import java.util.List;

public class UsingBuiltInAnnotation {
        //食物类
        class Food{}
        //干草类
        class Hay extends Food{}
        //动物类
        class Animal{
                Food getFood(){
                        return null;
                }
                //使用Annotation声明Deprecated方法
                @Deprecated
                void deprecatedMethod(){
                }
        }
        //马类-继承动物类
        class Horse extends Animal{
                //使用Annotation声明覆盖方法
                @Override
                Hay getFood(){
                        return new Hay();
                }
                //使用Annotation声明禁止警告
                @SuppressWarnings({"deprecation","unchecked"})
                void callDeprecatedMethod(List horseGroup){
                        Animal an=new Animal();
                        an.deprecatedMethod();
                        horseGroup.add(an);
                }
        }
}

package com.bjinfotech.practice.annotation;

import java.lang.annotation.*;
/**
 * 定义annotation
 * @author cleverpig
 *
 */
//加载在VM中，在运行时进行映射
@Retention(RetentionPolicy.RUNTIME)
//限定此annotation只能标示方法
@Target(ElementType.METHOD)
public @interface AnnotationDefineForTestFunction{}

package com.bjinfotech.practice.annotation;

import java.lang.reflect.*;

/**
 * 一个实例程序应用前面定义的Annotation：AnnotationDefineForTestFunction
 * @author cleverpig
 *
 */
public class UsingAnnotation {
        @AnnotationDefineForTestFunction public static void method01(){}
        
        public static void method02(){}
        
        @AnnotationDefineForTestFunction public static void method03(){
                throw new RuntimeException("method03");
        }
        
        public static void method04(){
                throw new RuntimeException("method04");
        }
        
        public static void main(String[] argv) throws Exception{
                int passed = 0, failed = 0;
                //被检测的类名
                String className="com.bjinfotech.practice.annotation.UsingAnnotation";
                //逐个检查此类的方法，当其方法使用annotation声明时调用此方法
            for (Method m : Class.forName(className).getMethods()) {
               if (m.isAnnotationPresent(AnnotationDefineForTestFunction.class)) {
                  try {
                     m.invoke(null);
                     passed++;
                  } catch (Throwable ex) {
                     System.out.printf("测试 %s 失败: %s %n", m, ex.getCause());
                     failed++;
                  }
               }
            }
            System.out.printf("测试结果： 通过: %d, 失败： %d%n", passed, failed);
        }
}

作者：Michael Juntao Yuan

06/29/2005

翻译：loryliu

版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
英文原文地址:
http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html
中文地址:
http://www.matrix.org.cn/resource/article/43/43718_Spring_EJB.html
关键词： Spring EJB

艾伯特.爱因斯坦曾经说过：“一切都应该尽可能地简单，但是不能更简单。”确实如此，简化一门理论的基本假设，使我们可以专注于真正关键的地方，这正是一直以来对科学真理的追求。企业软件开发同样如此。

提供一个将复杂的事物（例如，事务、安全或持久性）对开发者进行隐藏的应用框架是简化企业软件开发的关键。一个设计良好的框架可以提高代码重用率、开发者的生产力及软件的质量。然而，现有J2EE1.4的EJB2.1框架被普遍认为设计差，且过于复杂。不满于EJB2.1的框架结构，Java开发者尝试了各种各样的中间件服务传递方法。最引人注目的是，以下两个框架引起了开发者极大兴趣并得到了大量正面的反馈。他们以未来企业Java应用所选框架的姿态展现。

        Spring框架虽然很流行但并不是一个标准的开源框架。它主要由Interface21 Inc开发和控制。Spring框架结构是基于依赖注入(Dependency Injection (DI))的设计模式。它可以独立或在现有的应用服务器上运行，而且大量地使用了xml配置文件

        EJB3.0是由Java Community Process (JCP)制订的标准框架，为所有主要的J2EE厂商支持。JBoss已经提供了试用版EJB3.0标准的开源或商业性质实现。EJB3.0充分利用了Java的注释

这两个框架结构都有一个共同核心设计理念：将中间件服务传递给耦合松散的POJOS (Plain Old Java Objects, 简单洁净Java对象)。 这样的框架利用截取执行上下文或在运行时将服务对象注入POJO来把应用服务“缠绕”到POJO。POJO本身并不关心这种“缠绕”，对这种框架结构也没有什么依赖。因此，开发者可专注于业务逻辑和脱离框架的POJO单元测试。除此之外， 由于POJO并不须要继承框架的类或实现其接口，开发者能够极其灵活地搭建继承结构和建造应用。

然而，在拥有同一理念的同时，两个框架结构使用不同的方式来传递POJO服务。许多书籍或文章都将Spring 或EJB3.0和EJB2.1做了比较，但是对Spring 和EJB3.0的比较并没有仔细研究过。在本文中，我将对Srping和EJB3.0框架背后的关键不同处进行考察，并讨论其优缺点。本文的观点也适用于其它更少为人知的框架，因为他们都是对“耦合松散的POJO”的设计。希望这篇文章可以帮助你选择适合你需求的最好框架。

厂商无关性
开发者选择Java平台其中最引人注目的理由之一：厂商无关性。EJB3.0正是一套设计为厂商无关的开放性标准。EJB3.0标准为所有企业Java社团里开源或商业性质厂商所开发和支持。它将开发者与应用服务器实现完全隔离。例如，JBoss的 EJB3.0实现基于Hibernate，Oracle的基于TopLink，但是开发者并不须要学习Hibernate- 或TopLink的具体API来使应用可在Jboss或Oracle上运行。厂商无关性使EJB3.0与现今其它POJO中间件框架区别开来。

但是，正如许多EJB3.0评论家迅速所指出的，在本文撰写时EJB3.0标准还没有到达一个最终版本。大概还有一到两年的时间EJB3.0才能广泛地为所有主要J2EE厂商所支持。即使你的应用服务器本身不支持EJB3.0，你仍然可以通过下载安装”内嵌的”EJB3.0产品来运行EJB3.0的应用。例如，JBoss的内嵌EjB3.0是开源产品且可以在任何J2SE5.0兼容的环境运行(例如, 在任何Java服务器上)，此产品正处于软件测试阶段。其它厂商不久也将发布自己的内嵌EJB3.0产品，特别是针对标准中关于数据持久性的部分。

另一方面，Spring一直以来都是非标准的技术，在未来可预知的一段时间内这种情况将持续下去。虽然你可以在任何应用服务器上使用Spring框架，Spring应用会被锁入在Spring本身和你选择整合进Spring的具体服务中。

        Spring框架是一个开源项目，但同时它有一个XML格式的配置文件和编程接口。当然任何一个非标准的产品都会有这种“锁入”(lock-in)的情况，并不是Spring特有的。但Spring应用的长期生存能力仍然还得托Spring这个项目的福（或者是Interface21公司，它雇佣了大部分Spring核心开发人员）。除此之外，假如你用到任何一个具体的Spring服务，例如，Spring事务管理器或则Spring MVC，你也会被锁入到这些API里。
        Spring的应用对终端用户是不可知的。例如，对数据持久服务，Spring框架兼容不同的DAO和JDBC的模版帮助类，如Hibernate, iBatis, 和 JDO。所以假如你需要为spring应用切换在数据持久化服务（例如从JBDC到Hibernate），你需要修改你的代码以适合新的模版帮助类。

服务整合
从一个很高的角度上看，Spring框架处于应用服务器和服务库的上方。服务整合的代码（如，数据访问模板和帮助类）属于框架，并暴露于应用开发者。相反，EJB3.0框架与应用服务器高度整合，服务整合代码也包装在一个标准接口后面。

因此，实现EJB3.0的厂商可以大大地优化整体性能和提升开发者的体验。例如，在JBoss EJB3.0的实现中，当你在用EntityManager持久化一个Entity Bean时，后台的Hibernate会话事务已经自动地帮定到调用方法的JTA 的事务上，在JTA 事务提交的同时Hibernate会话事务也提交了。你甚至可以使用一个简单的 @PersistenceContext 注释（稍候例子演示）将EntityManager和它后台的Hibernate事务绑定到一个stateful session bean的应用事务中。在一个会话中应用事务横跨多个线程，这在事务性网页应用很有用，例如，多页面的购物车。
由于高度整合的EJB3.0的框架，使简单、集成的编程接口成为可能。Oracle EJB3.0框架和其后台的Toplink持久化服务也同样程度地整合。

另一个EJB3.0整合服务的绝好例子就是集群支持。假如你在一个服务器集群上部署了一个EJB3.0的应用，所有容错(fail-over)、负载均衡、分布式缓冲和状态复制都已经自动为应用所获得可用。后台的集群支持被隐藏在EJB3.0的框架后面，对EJB3.0开发者来说这些都是完全透明不可见的。

在Spring里，很难优化框架和服务之间的通讯。例如，为了使用Spring里的声明事务服务来管理Hibernate事务，你必须显示地在XML文件中配置Spring TransactionManager和Hibernate SessionFactory对象。Spring必须电显示地管理横跨多个HTTP请求的事务。除此之外，没有别的方法均衡Spring应用里的集群。

服务组合的弹性
由于Spring的服务整合代码作为编程接口的一部份暴露在外，应用开发者有按自己需求装配服务的弹性。这个特点使你能够组合自己的轻量级应用服务器。Spring的一个普遍用法就是将Tomcat和Hibernate组合在一起支持数据库驱动的web应用。在这种情况，Spring本身提供事务服务，Hibernat提供持久化服务——这种设置创建了一个袖珍型的应用服务器。

EJB3.0应用服务器典型地不提供这种根据需求任你挑捡服务的弹性空间。大多数时间，你得到的只是一系列包装好的特性，其中一些你可能根本就不需要。但是如果应用服务器像JBoss一样提供一个模块性的内部设计，那么你可以只取其中一部分，而把不必要的部分剥去。在任何情况，去自定义一个功能强大的应用服务器是没有什么价值的。

当然，假如应用已经超过单个点，那么你应该加入常用服务器上的服务，例如，资源池（resource pooling），消息队列（message queuing）和集群（clustering）。就总体的资源消耗而言，Spring解决方法和其他EJB3.0解决方法一样是重量级的。

在Spring框架里，具有弹性的服务装配使得将虚拟对象而不是真正的业务对象绑定到应用中做脱离容器的单元测试更简单。在EJB3.0应用中，大多数组件都是简单POJO，他们可以很容易地在容器外被测试。但是对于与容器服务相关的对象（例如持久化实实体管理器EntityManager）建议用容器内测试。因为这样会比虚拟对象测试方法更简单，强壮及准确。

XML Vs.注解
从应用开发者的观点上来看，Spring的编程开发接口主要基于XML配置文件而EJB3.0广泛地应用Java注解。XML可以表达复杂的关系，但是它也冗长且不够健壮；注解简单明了，但是很难在注解里表达复杂或继承性的关系。

Spring选择XML或EJB3.0选择注解都是有他们两者框架后的体系结构决定的。因为注解只能容纳很少的配置信息，只有整合前的框架（重头戏都在框架里）才可以把广泛地使用注解作为配置选择。正如我们所讨论过的，EJB3.0刚好符合这个要求，而Spring作为一个普通的DI框架并不符合。

当然，EJB3.0和Spring都相互取长补短，在某种程度上他们都支持XML和注解。例如，在EJB3.0中，XML配置文件作为一个可选的重载机制来改变注解的默认行为。注解也可以配置一些Spring服务。

通过例子是学习XML和注解方式之间差异的最好方法。在下面几个环节里，让我们来看看Spring和EJB3.0是怎样提供关键服务给应用的。

声明性服务
Spring和EJB3.0都将运行时服务（例如，事务、安全、日志和配置服务）绑定到应用。因为这些服务于应用的业务逻辑是没有直接联系，他们只是由应用本身管理。换句话说，这些服务在运行时由容器透明地应用到应用中。开发者或是管理者配置容器，准确地告诉它什么时候怎样应用这些服务。

EJB3.0运用Java注解来配置声明性服务，而Sring使用XML配置文件。在大多数情况下，EJB3.0注解方式对于这种服务更简单明了。这里有一个在EJB3.0中将事务服务运用到POJO的例子。

public class Foo {        @TransactionAttribute(TransactionAttributeType.REQUIRED)    public bar () {      // do something ...    }    }

你也可以为一个代码段声明多个属性，应用多个服务。这是一个在EJB3.0里同时应用事务和安全服务到POJO的例子。

@SecurityDomain("other")public class Foo {        @RolesAllowed({"managers"})    @TransactionAttribute(TransactionAttributeType.REQUIRED)    public bar () {      // do something ...    }   }

使用XML说明代码属性和配置声明性服务会导致冗长和不稳定的配置文件。下面是一个在Spring应用中的XML片段，其应用一个非常简单的Hibernate事务到方法Foo.bar()中。

<!-- Setup the transaction interceptor --><bean id="foo"   class="org.springframework.transaction        .interceptor.TransactionProxyFactoryBean">        <property name="target">        <bean class="Foo"/>    </property>        <property name="transactionManager">        <ref bean="transactionManager"/>    </property>        <property name="transactionAttributeSource">        <ref bean="attributeSource"/>    </property></bean><!-- Setup the transaction manager for Hibernate --><bean id="transactionManager"   class="org.springframework.orm         .hibernate.HibernateTransactionManager">        <property name="sessionFactory">        <!-- you need to setup the sessionFactory bean in              yet another XML element -- omitted here -->        <ref bean="sessionFactory"/>    </property></bean><!-- Specify which methods to apply transaction --><bean id="transactionAttributeSource"  class="org.springframework.transaction         .interceptor.NameMatchTransactionAttributeSource">      <property name="properties">        <props>            <prop key="bar">        </props>    </property></bean>

XML的复杂度会以几何级数增长，如果你向同一个POJO添加更多的拦截器(interceptors)（例如安全拦截器）。意识到只有XML配置文件的局限，Spring使用Apache Commons 元数据在Java源码中来说明事务属性。最新版本的Spring1.2也支持JDK-1.5风格注解。要使用事务元数据，你须要将上面的transactionAttributeSourc bean变成一个AttributesTransactionAttributeSource实例。并为元数据拦截器添加额外邦定。

    class="org.springframework.aop.framework.autoproxy           .DefaultAdvisorAutoProxyCreator"/><bean id="transactionAttributeSource"    class="org.springframework.transaction.interceptor           .AttributesTransactionAttributeSource"    autowire="constructor"/><bean id="transactionInterceptor"    class="org.springframework.transaction.interceptor           .TransactionInterceptor"    autowire="byType"/><bean id="transactionAdvisor"    class="org.springframework.transaction.interceptor           .TransactionAttributeSourceAdvisor"    autowire="constructor"/><bean id="attributes"    class="org.springframework.metadata.commons           .CommonsAttributes"/>

当你有很多事务性方法时，Spring元数据可以简化transactionAttributeSource。但是这并没有解决XML配置文件的根本问题。冗长而又繁琐的事务拦截器, transactionManager,和transactionAttributeSource仍然需要。

依赖注入(Dependency Injection, DI)

中间件容器的一个关键好处之一就是它可以让开发者建造一个关系耦合松散的应用。服务端客户只需要知道服务的接口。容器依据具体的实现实例化服务对象，使他们为客户端所用。在不改变接口和客户端代码的情况下，这使得容器可以在多种服务实现之间切换。

依赖注入的模式是实现耦合松散应用的最好方法之一。它更易用，比其他方法也明了多了，比如通过JNDI依赖性查询或容器回调。使用DI，框架就像一个对象工厂，它创建服务对象然后按照运行时配置将这些服务对象注入到应用的POJO里。站在应用开发者的角度，客户端POJO在被使用时可自动获得正确的服务对象。

Spring和EJB3.0都提供广泛的DI模式支持。但是他们之间仍存在很大的不同之处。Spring支持一般意义上且复杂的DI API，其基于XML配置文件。EJB3.0支持大多数普通服务对象（如EJB及context对象）的注入和任何简单注解的JDNI。

EJB63.0注解非常简单易用。@Resource 标记表示注入大多数普通服务对象和JDNI对象。以下例子展示了怎样把服务的JDNI的默认DataSource 对象注入到POJO的一个属性变量中。DefaultDS是DataSource.的JDNI名字。MyDb变量在第一次被使用时被赋上了正确的值。

public class FooDao {    @Resource (name="DefaultDS")    DataSource myDb;        // Use myDb to get JDBC connection to the database}

除了直接属性变量注入，Ejb3.0的@Resource注解也可以用来在setter方法里面注入对象。例如，下面的例子就是注入session context对象。应用从不会显示地调用setter方法，其在其他方法被调用前由容器来触发。

@Resource public void setSessionContext (SessionContext ctx) {     sessionCtx = ctx; }

针对更复杂的服务对象，定义了专用的注入注解。例如，@EJB注释用来注入EJB的Stub，@PersistenceContext注解用来注入处理EJB3.0实体bean访问数据库的EntityManager对象。下面是一个怎样将EntityManager对象注入有状态的 session bean的例子。@PersistenceContext的type属性具体说明了被注入的EntityManager有一个扩展的事务transaction context。transaction context并不会同JTA transaction manager一起自动提交。因此它可以用在在一个会话横跨多个线程的应用事务中。

@Statefulpublic class FooBean implements Foo, Serializable {    @PersistenceContext(      type=PersistenceContextType.EXTENDED    )    protected EntityManager em;        public Foo getFoo (Integer id) {        return (Foo) em.find(Foo.class, id);    }}

EJB3.0标准通过注解可以被注入的服务器资源。但是它并支持将用户定义的应用POJO之间的相互注入。

在Spring中，首先你必须为POJO中的服务对象定义一个setter方法。下面的例子说明POJO需要一个Hibernate session 的引用

public class FooDao {        HibernateTemplate hibernateTemplate;        public void setHibernateTemplate (HibernateTemplate ht) {        hibernateTemplate = ht;    }        // Use hibernateTemplate to access data via Hibernate    public Foo getFoo (Integer id) {        return (Foo) hibernateTemplate.load (Foo.class, id);    }}

然后，以XML里的元素作为桥梁具体描述容器怎样在运行时得到服务对象并将其注入到POJO里。以下是一个XML例子，具体描述了将一个数据源绑定到一个Hibernate session factory，然后从Hibernate session factory到Hibernate template object，最后从template object到应用的POJO。Spring代码如此复杂的部分原因是因为我们须手手动注入后台Hibernate plumbing objects。而EJB3.0 EntityManager是自动被服务器管理和配置。这又将我们带回到Spring并不像EJB3.0那样高度与服务整合的论点上。

<bean id="dataSource"   class="org.springframework         .jndi.JndiObjectFactoryBean">    <property name="jndiname">        <value>java:comp/env/jdbc/MyDataSource</value>    </property></bean><bean id="sessionFactory"   class="org.springframework.orm         .hibernate.LocalSessionFactoryBean">    <property name="dataSource">        <ref bean="dataSource"/>    </property></bean><bean id="hibernateTemplate"   class="org.springframework.orm         .hibernate.HibernateTemplate">    <property name="sessionFactory">        <ref bean="sessionFactory"/>    </property>    </bean><bean id="fooDao" class="FooDao">    <property name="hibernateTemplate">        <ref bean="hibernateTemplate"/>    </property></bean><!-- The hibernateTemplate can be injected        into more DAO objects -->

虽然，Spring里基于XML的依赖注入语法复杂，但却功能强大。你可以将任何POJO注入到另一个POJO，包括你自己在应用定义的那些POJO。假如你想在EJB3.0应用中用Spring的DI功能 ，你可以通过JNDI把一个Spring bean factory注入到EJB。在一些EJB3.0的应用服务器里，厂商可能会额外定义非标准的POJO注入API。一个很好的例子就是JBoss MicroContainer。它比Spring更一般化，因为它处理Aspect-Oriented Programming（AOP）的依赖。

结论

Spring和Ejb3.0虽然都是为了向企业服务提供耦合松散的POJO，但是使用了不同方法来达到这个目的。两者都大量地使用了依赖注入。

对于EJB3.0，基于标准的方案、注解的广泛使用、与应用服务器的高度整合都使得EJB3.0拥有更好的厂商无关性，更高的开发效率。依赖注入和集中的XML配置文件协调一致的使用使开发者能够构建更有弹性的应用，并且可以同时和几个应用服务提供者一起协作。

鸣谢
作者感谢tephen Chambers,、ill Burke、Andy Oliver的珍贵意见。

资源
Spring框架(参见CodeZoo: Spring)
EJB 3.0
JBoss EJB 3.0
Oracle Application Server EJB 3.0 Preview

Michael Juntao Yuan 善长于提供end-to-end的企业解决方案， 也是一个移动方面的专家，是avid这个开源项目的支持者。

第1课：切勿绕过服务器端验证
　　作为一位软件顾问，我曾有机会不但设计并实现了Web应用程序，而且还评估/审核了许多Web应用程序。在复杂的、并且用JavaScript客户端封装的应用程序内，我经常遇到对用户输入信息执行大量检查的Web页面。即使HTML元素具有数据有效性的属性也如此，例如MAXLENGTH。只有在成功验证所有输入信息后，才能提交HTML表单。结果，一旦服务器端收到通知表单（请求），便恰当地执行业务逻辑。
　　在此，您发现问题了么？开发人员已经做了许多重要的假设。例如，他们假设所有的Web应用程序用户都同样诚实。开发人员还假设所有用户将总是使用他们测试过的浏览器访问Web应用程序。还有很多其他的假设。这些开发人员忘记了利用可以免费得到的工具，通过命令行很容易地模拟类似浏览器的行为。事实上，通过在浏览器窗口中键入适当的URL，您可以发送任何“posted”表单，尽管如此，通过禁用这些页面的GET请求，您很容易地阻止这样的“表单发送”。但是，您不能阻止人们模拟甚至创建他们自己的浏览器来入侵您的系统。
根本的问题在于开发人员不能确定客户端验证与服务器端验证的主要差别。两者的主要差别不在于验证究竟发生在哪里，例如在客户端或者在服务器端。主要的差别在于验证背后的目的不同。
　　客户端验证仅仅是方便。执行它可为用户提供快速反馈——使应用程序似乎做出响应，给人一种运行桌面应用程序的错觉。
　　另一方面，服务器端验证是构建安全Web应用程序必需的。不管在客户端一侧输入的是什么，它可以确保客户端送往服务器的所有数据都是有效的。
　　因而，只有服务器端验证才可以提供真正应用程序级的安全。许多开发人员陷入了错误感觉的圈套：只有在客户端进行所有数据的验证才能确保安全。下面是说明此观点的一个常见的示例：
　　一个典型的登录页面拥有一个用来输入用户名的文本框和一个输入密码的文本框。在服务器端，某人在接收servlet中可能遇到一些代码，这些代码构成了下面形式的SQL查询：
"SELECT * FROM SecurityTable WHERE username = '" + form.getParameter("username") + "' AND password = '" + form.getParameter("password") + "';"，并执行这些代码。如果查询在结果集的某一行返回，则用户登录成功，否则用户登录失败。
　　第一个问题是构造SQL的方式，但现在让我们暂时忽略它。如果用户在用户名中输入“Alice'--”会怎样呢？假设名为“Alice”的用户已经在SecurityTable中，这时此用户（更恰当的说法是黑客）成功地登录。我将把找出为什么会出现这种情况的原因做为留给您的一道习题。
　　许多创造性的客户端验证可以阻止一般的用户从浏览器中这样登录。但对于已经禁用了JavaScript的客户端，或者那些能够使用其他类似浏览器程序直接发送命令（HTTP POST和GET命令）的高级用户（或者说黑客）来说，我们又有什么办法呢？服务器端验证是防止这种漏洞类型所必须的。这时，SSL、防火墙等都派不上用场了。

第2课：安全并非是附加物
　　如第1课所述，我曾有幸研究过许多Web应用程序。我发现所有的JavaServer Page（JSP）都有一个共同的主题，那就是具有类似下面伪代码的布局：

<%
User user =
session.getAttribute("User");
if(user == null)
{
// redirect to
// the logon page…
}
if(!user.role.equals("manager"))
{
// redirect to the
// "unauthorized" page…
}
%>
<!-
HTML, JavaScript, and JSP
code to display data and
allow user interaction -->

　　如果项目使用诸如Struts这样的MVC框架，所有的Action Bean都会具有类似的代码。尽管最后这些代码可能运行得很好，但如果您发现一个bug，或者您必须添加一个新的角色（例如，“guest”或者“admin”），这就会代表一场维护恶梦。
　　此外，所有的开发人员，不管您多年轻，都需要熟悉这种编码模式。当然，您可以用一些JSP标签来整理JSP代码，可以创建一个清除派生Action Bean的基本Action Bean。尽管如此，由于与安全相关的代码会分布到多个地方，所以维护时的恶梦仍旧存在。由于Web应用程序的安全是强迫建立在应用程序代码的级别上（由多个开发人员），而不是建立在架构级别上，所以Web应用程序还是很可能存在弱点。
　　很可能，根本的问题是在项目接近完成时才处理安全性问题。最近作为一名架构师，我曾在一年多的时间里亲历了某一要实现项目的6个版本，而直到第四版时我们才提到了安全性——即使该项目会将高度敏感的个人数据暴露于Web上，我们也没有注意到安全性。为了更改发布计划，我们卷入了与项目资助人及其管理人员的争斗中，以便在第一版中包含所有与安全相关的功能，并将一些“业务”功能放在后续的版本中。最终，我们赢得了胜利。而且由于应用程序的安全性相当高，能够保护客户的私有数据，这一点我们引以为荣，我们的客户也非常高兴。
　　遗憾的是，在大多数应用程序中，安全性看起来并未增加任何实际的商业价值，所以直到最后才解决。发生这种情况时，人们才匆忙开发与安全相关的代码，而丝毫没有考虑解决方案的长期可维护性或者健壮性。忽视该安全性的另一个征兆是缺乏全面的服务器端验证，如我在第1课中所述，这一点是安全Web应用程序的一个重要组成部分。
　　记住：J2EE Web应用程序的安全性并非仅仅是在Web.xml 和ejb-jar.xml文件中使用合适的声明，也不是使用J2EE技术，如Java 认证和授权服务（Java Authentication and Authorization Service，JAAS）。而是经过深思熟虑后的设计，且实现一个支持它的架构。

第3课：国际化（I18N）不再是纸上谈兵
　　当今世界的事实是许多英语非母语的人们将访问您的公共Web应用程序。随着电子政务的实行，由于它允许人们（某个国家的居民）在线与政府机构交互，所以这一点特别真实。这样的例子包括换发驾照或者车辆登记证。许多第一语言不是英语的人们很可能将访问这样的应用程序。国际化（即：“i18n”，因为在“internationalization”这个单词中，字母i和字母n之间一共有18个字母）使得您的应用程序能够支持多种语言。
　　显然，如果您的JSP 页面中有硬编码的文本，或者您的Java代码返回硬编码的错误消息，那么您要花费很多时间开发此Web应用程序的西班牙语版本。然而，在Web应用程序中，为了支持多种语言，文本不是惟一必须“具体化”的部分。因为许多图像中嵌有文字，所以图形和图像也应该是可配置的。在极端的情况下，图像（或者颜色）在不同的文化背景中可能有完全不同的意思。类似地，任何格式化数字和日期的Java代码也必须本地化。但问题是：您的页面布局可能也需要更改。
　　例如，如果您使用HTML表格来格式化和显示菜单选项、应用程序题头或注脚，则您可能必须为每一种支持的语言更改每一栏的最小宽度和表格其他可能的方面。为了适应不同的字体和颜色，您可能必须为每一种语言使用单独的样式表。
　　显然，现在创建一个国际化的Web应用程序面临的是架构挑战而不是应用程序方面的挑战。一个架构良好的Web应用程序意味着您的JSP页面和所有与业务相关的（应用程序特有的）Java代码都不知不觉地选择了本地化。要记住的教训是：不要因为Java、J2EE支持国际化而不考虑国际化。您必须从第一天起就记住设计具有国际化的解决方案。

第4课：在MVC表示中避免共同的错误
　　J2EE开发已经足够成熟，在表示层，大多数项目使用MVC架构的某些形式，例如Struts。在这样的项目中，我常见到的现象是对MVC模式的误用。下面是几个示例。
　　常见的误用是在模型层（例如，在Struts的Action Bean中）实现了所有的业务逻辑。不要忘了，表示层的模型层仍然是表示层的一部分。使用该模型层的正确方法是调用适当的业务层服务（或对象）并将结果发送到视图层（view layer）。用设计模式术语来说，MVC表示层的模型应该作为业务层的外观（Fa?ade）来实现。更好的方法是，使用核心J2EE模式（Core J2EE Patterns）中论述到的Business Delegate模式。这段自书中摘录的内容精彩地概述了将您的模型作为Business Delegate来实现的要点和优点：
　　Business Delegate起到客户端业务抽象化的作用。它抽象化，进而隐藏业务服务的实现。使用Business Delegate，可以降低表示层客户端和系统的业务服务.之间的耦合程度。根据实现策略不同，Business Delegate可以在业务服务API的实现中，保护客户端不受可能的变动性影响。这样，在业务服务API或其底层实现变化时，可以潜在地减少必须修改表示层客户端代码的次数。
　　另一个常见的错误是在模型层中放置许多表示类型的逻辑。例如，如果JSP页面需要以指定方式格式化的日期或者以指定方式排序的数据，某些人可能将该逻辑放置在模型层，对该逻辑来说，这是错误的地方。实际上，它应该在JSP页面使用的一组helper类中。当业务层返回数据时，Action Bean应该将数据转发给视图层。这样，无需创建模型和视图之间多余的耦合，就能够灵活支持多个视图层（JSP、Velocity、XML等）。也使视图能够确定向用户显示数据的最佳方式。
　　最后，我见过的大多数MVC应用程序都有未充分应用的控制器。例如，绝大多数的Struts应用程序将创建一个基本的Action类，并完成所有与安全相关的功能。其他所有的Action Bean都是此基类的派生类。这种功能应该是控制器的一部分，因为如果没有满足安全条件，则首先调用不应该到达Action Bean（即：模型）。记住，一个设计良好的MVC架构的最强大功能之一是存在一个健壮的、可扩展的控制器。您应该利用该能力以加强自己的优势。

第5课：不要被JOPO束缚住手脚
　　我曾目睹许多项目为了使用Enterprise JavaBean而使用Enterprise JavaBean。因为EJB似乎给项目带来优越感和妄自尊大的表现，所以有时它是显酷的要素（coolness factor）。而其他时候，它会使J2EE和EJB引起混淆。记住，J2EE和EJB不是同意词。EJB只是J2EE 的一部分，J2EE 是包含JSP、servlet、Java 消息服务（JMS）、Java数据库连接（JDBC）、JAAS、 Java管理扩展（JMX）和EJB在内的一系列技术，同样也是有关如何共同使用这些技术建立解决方案的一组指导原则和模式。
　　如果在不需要使用EJB的情况下使用EJB，它们可能会影响程序的性能。与老的Web服务器相比，EJB一般对应用服务器有更多的需求。EJB提供的所有增值服务一般需要消耗更大的内存和更多的CPU时间。许多应用程序不需要这些服务，因此应用服务器要与应用程序争夺资源。
　　在某些情况下，不必要地使用EJB可能使应用程序崩溃。例如，最近我遇到了一个在开源应用服务器上开发的应用程序。业务逻辑封装在一系列有状态会话bean（EJB）中。开发人员为了在应用服务器中完全禁用这些bean的“钝化”费了很大的劲。客户端要求应用程序部署在某一商用应用服务器上，而该服务器是客户端技术栈的一部分。该应用服务器却不允许关闭“钝化”功能。事实上，客户端不想改变与其合作的应用服务器的设任何置。结果，开发商碰到了很大的麻烦。（似乎）有趣的事情是开发商自己都不能给出为什么将代码用EJB（而且还是有状态会话bean）实现的好理由。不仅仅是开发商会遇到性能问题，他们的程序在客户那里也无法工作。
　　在Web应用程序中，无格式普通Java 对象（POJO）是EJB强有力的竞争者。POJO是轻量级的，不像EJB那样负担额外的负担。在我看来，对许多EJB的优点，例如对象入池，估计过高。POJO是您的朋友，不要被它束缚住手脚。

第6课：数据访问并不能托管O/R映射
　　我曾参与过的所有Web应用程序都向用户提供从其他地方存取的数据，并且因此需要一个数据访问层。这并不是说所有的项目都需要标识并建立这样一个层，这仅仅说明这样层的存在不是隐含的就是明确的。如果是隐含的数据层，数据层是业务对象（即：业务服务）层的一部分。这适用于小型应用程序，但通常与大一些项目所接受的架构指导原则相抵触。
　　总之，数据访问层必须满足或超出以下四个标准：
　　具有透明性
　　业务对象在不知道数据源实现的具体细节情况下，可以使用数据源。由于实现细节隐藏在数据访问层的内部，所以访问是透明的。
　　易于迁移
　　数据访问层使应用程序很容易迁移到其他数据库实现。业务对象不了解底层的数据实现，所以迁移仅仅涉及到修改数据访问层。进一步地说，如果您正在部署某种工厂策略，您可以为每个底层的存储实现提供具体的工厂实现。如果是那样的话，迁移到不同的存储实现意味着为应用程序提供一个新的工厂实现。
　　尽量减少业务对象中代码复杂性
　　因为数据访问层管理着所有的数据访问复杂性，所以它可以简化业务对象和使用数据访问层的其他数据客户端的代码。数据访问层，而不是业务对象，含有许多与实现相关的代码（例如SQL语句）。这样给开发人员带来了更高的效率、更好的可维护性、提高了代码的可读性等一系列好处。
　　把所有的数据访问集中在单独的层上
　　由于所有的数据访问操作现在都委托给数据访问层，所以您可以将这个单独的数据访问层看做能够将应用程序的其他部分与数据访问实现相互隔离的层。这种集中化可以使应用程序易于维护和管理。
　　注意：这些标准都不能明确地调出对O/R（对象到关系）映射层的需求。O/R映射层一般用O/R映射工具创建，它提供对象对关系数据结构的查看和感知（look-and-feel）。在我看来，在项目中使用O/R映射与使用EJB类似。在大多数情况下，并不要求它。对于包含中等规模的联合以及多对多关系的关系型数据库来说，O/R映射会变得相当复杂。由于增加O/R 映射解决方案本身的内在复杂性，例如延迟加载（lazy loading）、高速缓冲等，您将为您的项目带来更大的复杂性（和风险）。
　　为了进一步支持我的观点，我将指出按照Sun Microsystem所普及的实体Bean（O/R映射的一种实现）的许多失败的尝试，这是自1.0版以来一直折磨人的难题。在SUN的防卫措施中，一些早期的问题是有关EJB规范的开发商实现的。这依次证明了实体Bean规范自身的复杂性。结果，大多数J2EE架构师一般认为从实体Bean中脱离出来是一个好主意。
　　大多数应用程序在处理他们的数据时，只能进行有限次数的查询。在这样的应用程序中，访问数据的一种有效方法是实现一个数据访问层，该层实现执行这些查询的一系列服务（或对象、或API）。如上所述，在这种情况下，不需要O/R映射。当您要求查询灵活性时，O/R映射正合适，但要记住：这种附加的灵活性并不是没有代价的。
　　就像我承诺的那样，在本文中，我尽量避免陈腐的最佳实践。相反，关于J2EE项目中每一位架构师必须做出的最重要的决定，我集中讲解了我的观点。最后，您应该记住：J2EE并非某种具体的技术，也不是强行加入到解决方案中的一些首字母缩写。相反，您应该在适当的时机，恰当的地方，使用合适的技术，并遵循J2EE的指导原则和J2EE中所包含的比技术本身重要得多的实践。

关于作者
Tarak Modi是North Highland（一家管理和技术咨询公司）的高级专家。他在COM、MTS、COM+、.NET、J2EE以及 CORBA等方面有丰富的专业经验。2002年曾与人合作编写Professional Java Web Services （Wrox Press）。作者的个人网站是：http://www.tekNirvana.com。