xmlrpc.execute("ChatService.validateUser",params);
execute方法是xml-rpc client执行远程调用的方法。
第一个参数是方法名，第二个是这个远程方法的参数，用Vector传递。
基本上就是这样一个流程。一点都不复杂，有什么不明白的就给我发信，欢迎讨论。
源码下载：http://www.blogjava.net/Files/mstar/AppletRPC.rar
项目是用JBuilder2006做的，不知道以前版本的JBuilder能不能打开啊。

动态代理工具 是 java.lang.reflect 包的一部分，在 JDK 1.3 版本中添加到 JDK，它允许程序创建 代理对象，代理对象能实现一个或多个已知接口，并用反射代替内置的虚方法分派，编程地分派对接口方法的调用。这个过程允许实现“截取”方法调用，重新路由它们或者动态地添加功能。本期文章中，Brian Goetz 介绍了几个用于动态代理的应用程序。请在本文伴随的 讨论论坛 上与作者和其他读者分享您对这篇文章的想法。（也可以单击文章顶部或底部的 讨论 访问讨论论坛。）

动态代理为实现许多常见设计模式（包括 Facade、Bridge、Interceptor、Decorator、Proxy（包括远程和虚拟代理）和 Adapter 模式）提供了替代的动态机制。虽然这些模式不使用动态代理，只用普通的类就能够实现，但是在许多情况下，动态代理方式更方便、更紧凑，可以清除许多手写或生成的类。

Proxy 模式

Proxy 模式中要创建“stub”或“surrogate”对象，它们的目的是接受请求并把请求转发到实际执行工作的其他对象。远程方法调用（RMI）利用 Proxy 模式，使得在其他 JVM 中执行的对象就像本地对象一样；企业 JavaBeans （EJB）利用 Proxy 模式添加远程调用、安全性和事务分界；而 JAX-RPC Web 服务则用 Proxy 模式让远程服务表现得像本地对象一样。在每一种情况中，潜在的远程对象的行为是由接口定义的，而接口本质上接受多种实现。调用者（在大多数情况下）不能区分出它们只是持有一个对 stub 而不是实际对象的引用，因为二者实现了相同的接口；stub 的工作是查找实际的对象、封送参数、把参数发送给实际对象、解除封送返回值、把返回值返回给调用者。代理可以用来提供远程控制（就像在 RMI、EJB 和 JAX-RPC 中那样），用安全性策略包装对象（EJB）、为昂贵的对象（EJB 实体 Bean）提供惰性装入，或者添加检测工具（例如日志记录）。

在 5.0 以前的 JDK 中，RMI stub（以及它对等的 skeleton）是在编译时由 RMI 编译器（rmic）生成的类，RMI 编译器是 JDK 工具集的一部分。对于每个远程接口，都会生成一个 stub（代理）类，它代表远程对象，还生成一个 skeleton 对象，它在远程 JVM 中做与 stub 相反的工作 —— 解除封送参数并调用实际的对象。类似地，用于 Web 服务的 JAX-RPC 工具也为远程 Web 服务生成代理类，从而使远程 Web 服务看起来就像本地对象一样。

不管 stub 类是以源代码还是以字节码生成的，代码生成仍然会向编译过程添加一些额外步骤，而且因为命名相似的类的泛滥，会带来意义模糊的可能性。另一方面，动态代理机制支持在编译时没有生成 stub 类的情况下，在运行时创建代理对象。在 JDK 5.0 及以后版本中，RMI 工具使用动态代理代替了生成的 stub，结果 RMI 变得更容易使用。许多 J2EE 容器也使用动态代理来实现 EJB。EJB 技术严重地依靠使用拦截（interception）来实现安全性和事务分界；动态代理为接口上调用的所有方法提供了集中的控制流程路径。

回页首

动态代理机制

动态代理机制的核心是 InvocationHandler 接口，如清单 1 所示。调用句柄的工作是代表动态代理实际执行所请求的方法调用。传递给调用句柄一个 Method 对象（从 java.lang.reflect 包），参数列表则传递给方法；在最简单的情况下，可能仅仅是调用反射性的方法 Method.invoke() 并返回结果。

清单 1. InvocationHandler 接口

public interface InvocationHandler { Object invoke(Object proxy, Method method, Object[] args) throws Throwable; }

每个代理都有一个与之关联的调用句柄，只要代理的方法被调用时就会调用该句柄。根据通用的设计原则：接口定义类型、类定义实现，代理对象可以实现一个或多个接口，但是不能实现类。因为代理类没有可以访问的名称，它们不能有构造函数，所以它们必须由工厂创建。清单 2 显示了动态代理的最简单的可能实现，它实现 Set 接口并把所有 Set 方法（以及所有 Object 方法）分派给封装的 Set 实例。

清单 2. 包装 Set 的简单的动态代理

public class SetProxyFactory { public static Set getSetProxy(final Set s) { return (Set) Proxy.newProxyInstance (s.getClass().getClassLoader(), new Class[] { Set.class }, new InvocationHandler() { public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { return method.invoke(s, args); } }); } }

SetProxyFactory 类包含一个静态工厂方法 getSetProxy()，它返回一个实现了 Set 的动态代理。代理对象实际实现 Set —— 调用者无法区分（除非通过反射）返回的对象是动态代理。SetProxyFactory 返回的代理只做一件事，把方法分派给传递给工厂方法的 Set 实例。虽然反射代码通常比较难读，但是这里的内容很少，跟上控制流程并不难 —— 只要某个方法在 Set 代理上被调用，它就被分派给调用句柄，调用句柄只是反射地调用底层包装的对象上的目标方法。当然，绝对什么都不做的代理可能有点傻，是不是呢？

什么都不做的适配器

对于像 SetProxyFactory 这样什么都不做的包装器来说，实际有个很好的应用 —— 可以用它安全地把对象引用的范围缩小到特定接口（或接口集）上，方式是，调用者不能提升引用的类型，使得可以更安全地把对象引用传递给不受信任的代码（例如插件或回调）。清单 3 包含一组类定义，实现了典型的回调场景。从中会看到动态代理可以更方便地替代通常用手工（或用 IDE 提供的代码生成向导）实现的 Adapter 模式。

清单 3. 典型的回调场景

public interface ServiceCallback { public void doCallback(); } public interface Service { public void serviceMethod(ServiceCallback callback); } public class ServiceConsumer implements ServiceCallback { private Service service; ... public void someMethod() { ... service.serviceMethod(this); } }

ServiceConsumer 类实现了 ServiceCallback（这通常是支持回调的一个方便途径）并把 this 引用传递给 serviceMethod() 作为回调引用。这种方法的问题是没有机制可以阻止 Service 实现把 ServiceCallback 提升为 ServiceConsumer，并调用 ServiceConsumer 不希望 Service 调用的方法。有时对这个风险并不关心 —— 但有时却关心。如果关心，那么可以把回调对象作为内部类，或者编写一个什么都不做的适配器类（请参阅清单 4 中的 ServiceCallbackAdapter）并用 ServiceCallbackAdapter 包装 ServiceConsumer。ServiceCallbackAdapter 防止 Service 把 ServiceCallback 提升为 ServiceConsumer。

清单 4. 用于安全地把对象限制在一个接口上以便不被恶意代码不能的适配器类

public class ServiceCallbackAdapter implements ServiceCallback { private final ServiceCallback cb; public ServiceCallbackAdapter(ServiceCallback cb) { this.cb = cb; } public void doCallback() { cb.doCallback(); } }

编写 ServiceCallbackAdapter 这样的适配器类简单却乏味。必须为包装的接口中的每个方法编写重定向类。在 ServiceCallback 的示例中，只有一个需要实现的方法，但是某些接口，例如 Collections 或 JDBC 接口，则包含许多方法。现代的 IDE 提供了“Delegate Methods”向导，降低了编写适配器类的工作量，但是仍然必须为每个想要包装的接口编写一个适配器类，而且对于只包含生成的代码的类，也有一些让人不满意的地方。看起来应当有一种方式可以更紧凑地表示“什么也不做的限制适配器模式”。

通用适配器类

清单 2 中的 SetProxyFactory 类当然比用于 Set 的等价的适配器类更紧凑，但是它仍然只适用于一个接口：Set。但是通过使用泛型，可以容易地创建通用的代理工厂，由它为任何接口做同样的工作，如清单 5 所示。它几乎与 SetProxyFactory 相同，但是可以适用于任何接口。现在再也不用编写限制适配器类了！如果想创建代理对象安全地把对象限制在接口 T，只要调用 getProxy(T.class,object) 就可以了，不需要一堆适配器类的额外累赘。

清单 5. 通用的限制适配器工厂类

public class GenericProxyFactory { public static<T> T getProxy(Class<T> intf, final T obj) { return (T) Proxy.newProxyInstance(obj.getClass().getClassLoader(), new Class[] { intf }, new InvocationHandler() { public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { return method.invoke(obj, args); } }); } }

回页首

动态代理作为 Decorator

当然，动态代理工具能做的，远不仅仅是把对象类型限制在特定接口上。从 清单 2 和 清单 5 中简单的限制适配器到 Decorator 模式，是一个小的飞跃，在 Decorator 模式中，代理用额外的功能（例如安全检测或日志记录）包装调用。清单 6 显示了一个日志 InvocationHandler，它在调用目标对象上的方法之外，还写入一条日志信息，显示被调用的方法、传递的参数，以及返回值。除了反射性的 invoke() 调用之外，这里的全部代码只是生成调试信息的一部分 —— 还不是太多。代理工厂方法的代码几乎与 GenericProxyFactory 相同，区别在于它使用的是 LoggingInvocationHandler 而不是匿名的调用句柄。

清单 6. 基于代理的 Decorator，为每个方法调用生成调试日志

private static class LoggingInvocationHandler<T> implements InvocationHandler { final T underlying; public LoggingHandler(T underlying) { this.underlying = underlying; } public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { StringBuffer sb = new StringBuffer(); sb.append(method.getName()); sb.append("("); for (int i=0; args != null && i<args.length; i++) { if (i != 0) sb.append(", "); sb.append(args[i]); } sb.append(")"); Object ret = method.invoke(underlying, args); if (ret != null) { sb.append(" -> "); sb.append(ret); } System.out.println(sb); return ret; } }

如果用日志代理包装 HashSet，并执行下面这个简单的测试程序：

Set s = newLoggingProxy(Set.class, new HashSet()); s.add("three"); if (!s.contains("four")) s.add("four"); System.out.println(s);

会得到以下输出：

add(three) -> true contains(four) -> false add(four) -> true toString() -> [four, three] [four, three]

这种方式是给对象添加调试包装器的一种好的而且容易的方式。它当然比生成代理类并手工创建大量 println() 语句容易得多（也更通用）。我进一步改进了这一方法；不必无条件地生成调试输出，相反，代理可以查询动态配置存储（从配置文件初始化，可以由 JMX MBean 动态修改），确定是否需要生成调试语句，甚至可能在逐个类或逐个实例的基础上进行。

在这一点上，我认为读者中的 AOP 爱好者们几乎要跳出来说“这正是 AOP 擅长的啊！”是的，但是解决问题的方法不止一种 —— 仅仅因为某项技术能解决某个问题，并不意味着它就是最好的解决方案。在任何情况下，动态代理方式都有完全在“纯 Java”范围内工作的优势，不是每个公司都用（或应当用） AOP 的。

动态代理作为适配器

代理也可以用作真正的适配器，提供了对象的一个视图，导出与底层对象实现的接口不同的接口。调用句柄不需要把每个方法调用都分派给相同的底层对象；它可以检查名称，并把不同的方法分派给不同的对象。例如，假设有一组表示持久实体（Person、Company 和 PurchaseOrder） 的 JavaBean 接口，指定了属性的 getter 和 setter，而且正在编写一个持久层，把数据库记录映射到实现这些接口的对象上。现在不用为每个接口编写或生成类，可以只用一个 JavaBean 风格的通用代理类，把属性保存在 Map 中。

清单 7 显示的动态代理检查被调用方法的名称，并通过查询或修改属性图直接实现 getter 和 setter 方法。现在，这一个代理类就能实现多个 JavaBean 风格接口的对象。

清单 7. 用于把 getter 和 setter 分派给 Map 的动态代理类

public class JavaBeanProxyFactory { private static class JavaBeanProxy implements InvocationHandler { Map<String, Object> properties = new HashMap<String, Object>(); public JavaBeanProxy(Map<String, Object> properties) { this.properties.putAll(properties); } public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { String meth = method.getName(); if (meth.startsWith("get")) { String prop = meth.substring(3); Object o = properties.get(prop); if (o != null && !method.getReturnType().isInstance(o)) throw new ClassCastException(o.getClass().getName() + " is not a " + method.getReturnType().getName()); return o; } else if (meth.startsWith("set")) { // Dispatch setters similarly } else if (meth.startsWith("is")) { // Alternate version of get for boolean properties } else { // Can dispatch non get/set/is methods as desired } } } public static<T> T getProxy(Class<T> intf, Map<String, Object> values) { return (T) Proxy.newProxyInstance (JavaBeanProxyFactory.class.getClassLoader(), new Class[] { intf }, new JavaBeanProxy(values)); } }

虽然因为反射在 Object 上工作会有潜在的类型安全性上的损失，但是，JavaBeanProxyFactory 中的 getter 处理会进行一些必要的额外的类型检测，就像我在这里用 isInstance() 对 getter 进行的检测一样。

回页首

性能成本

正如已经看到的，动态代理拥有简化大量代码的潜力 —— 不仅能替代许多生成的代码，而且一个代理类还能代替多个手写的类或生成的代码。什么是成本呢？ 因为反射地分派方法而不是采用内置的虚方法分派，可能有一些性能上的成本。在早期的 JDK 中，反射的性能很差（就像早期 JDK 中几乎其他每件事的性能一样），但是在近 10 年，反射已经变得快多了。

不必进入基准测试构造的主题，我编写了一个简单的、不太科学的测试程序，它循环地把数据填充到 Set，随机地对 Set进行插入、查询和删除元素。我用三个 Set 实现运行它：一个未经修饰的 HashSet，一个手写的、只是把所有方法转发到底层的 HashSet 的 Set 适配器，还有一个基于代理的、也只是把所有方法转发到底层 HashSet 的 Set 适配器。每次循环迭代都生成若干随机数，并执行一个或多个 Set 操作。手写的适配器比起原始的 HashSet 只产生很少百分比的性能负荷（大概是因为 JVM 级有效的内联缓冲和硬件级的分支预测）；代理适配器则明显比原始 HashSet 慢，但是开销要少于两个量级。

我从这个试验得出的结论是：对于大多数情况，代理方式即使对轻量级方法也执行得足够好，而随着被代理的操作变得越来越重量级（例如远程方法调用，或者使用序列化、执行 IO 或者从数据库检索数据的方法），代理开销就会有效地接近于 0。当然也存在一些代理方式的性能开销无法接受的情况，但是这些通常只是少数情况。

Dennis Sosnoski
主席, Sosnoski Software Solutions, Inc.
2005 年 7 月 25 日

许多 J2SE 5.0 语言特性应该对旧版 JVM 也有用，但是实现这些特性的编译器会生成需要 JDK 5.0 或更高版本的代码。幸运的是，有一个开放源代码项目 Retroweaver 在 J2SE 5.0 与旧版 JVM 之间架起了一座桥梁。Retroweaver 转换您的类文件以消除 JDK 5.0 依赖性，同时添加其自己的支持函数库以使得大多数 5.0 特性在旧版 JVM 上完全有用。如果您喜欢 J2SE 5.0 语言特性，却无法在运行时使用 JDK 5.0，那么 Retroweaver 就是您所需要的。

J2SE 5.0 为 Java 语言带来了巨大的改变，因此即使是经验丰富的 Java 开发人员也需要深入的培训才能利用 5.0 特性。不幸的是，实现这些语言特性的 JDK 5.0 编译器在生成特定于 JDK 5.0 或更高版本的代码时不支持这些特性。如果试图在早期的 JVM 上运行生成的代码，将会得到 java.lang.UnsupportedClassVersionError 错误。

即使生成的类指定 JDK 5.0 和更高的 JVM，但是故事并没有结束。开发人员发现，一些新特性实际上生成与旧版 JVM 完全兼容的代码，而其他特性可以与标准库的少量扩展兼容。有一个名叫 Toby Reyelts 的开发人员决定消除 JDK 5.0 编译器限制。结果就是开放源代码的 Retroweaver 项目（参见 参考资料）。Retroweaver 使用 classworking 技术来修改由 JDK 5.0 编译器生成的二进制类表示，以便这些类可以与早期的 JVM 一起使用。

对于本文来说，我将展示 Retroweaver 的基本使用。Retroweaver 实际上非常容易使用，所以不用花太大的篇幅去介绍它，所以我还将修改 上个月 介绍的 annotations+ASM 运行时代码生成方法以使用 5.0 之前的 JDK，期间使用了 Retroweaver 来回避 JDK 5.0 编译器限制。

向后兼容 J2SE 5.0
Retroweaver 包含两个逻辑组件：一个字节码增强器和一个运行时库。字节码增强器使用 classworking 技术来修改由 JDK 5.0 编译器生成的类文件，使得这些类可以用于旧版 JVM。作为类文件修改的一部分，Retroweaver 可能需要替换对添加到 J2SE 5.0 中的标准类的引用。实际的替换类包含在运行时库中，以便在您执行修改过的代码时它们是可用的。

按照标准开发周期来说，字节码增强器需要在 Java 代码编译之后、类文件为部署而打包之前运行。在您使用一个 IDE 时，该更改是一个问题 ——“集成”一个类转换工具到“开发环境”是很痛苦的事情，因为 IDE 一般假设它们拥有类文件。限制这一痛苦的一种方式是，只对 IDE 中的大多数测试使用 JDK 5.0。这样，您只需要在想要为部署打包文件或者想要测试实际的部署 JVM 时转换类文件。如果使用 Ant 风格的构建过程，就没有问题；只添加 Retroweaver 字节码增强器作为编译之后的一个步骤。

Retroweaver 具有一个小小的限制：尽管 Retroweaver 允许您在运行在旧版 JVM 上的代码中使用 J2SE 5.0 语言特性，但是它并不支持也包含在 J2SE 5.0 中的所有添加到标准 Java 类的特性。如果您的代码使用任何添加到 J2SE 5.0 中的类或方法，那么就将在试图加载旧版 JVM 中的代码时得到错误，哪怕是在 Retroweaver 处理完成之后也如此。避免对标准库的 J2SE 5.0 添加不应该是一个主要问题，但是如果使用 IDE 中的感应弹出特性并偶然挑选了一个仅添加到 J2SE 5.0 中的方法或类，它就有可能让您得到错误。

它做什么
J2SE 5.0 的更改既发生在 JVM 中，也发生在实际的 Java 语言，但是 JVM 更改相当小。有一个新的字符可以用于字节码中的标识符中 ("+")，一些处理类引用的指令发生了修改，还有一个不同的方法用于处理合成组件。 Retroweaver 在字节码增强步骤中处理这些 JVM 更改，方法是把这些更改返回原样，即替换成用于 J2SE 5.0 之前相同目的的方法（比如标识符中的 + 字符，就是用 $ 取代它）。

包含在 J2SE 5.0 中的语言更改要稍微复杂一点。一些最有趣的更改，比如增强的 for 循环，基本上只是语法更改，即为表示编程操作提供快捷方式。比如泛型更改 —— 泛型类型信息 —— 由编译器用于实施编译时安全，但是生成的字节码仍然到处使用强制转换。但是大多数更改使用了添加到核心 Java API 中的类或方法，所以您不能直接使用为 JDK 5.0 生成的字节码并将它直接运行在早期的 JVM 上。Retroweaver 为支持 J2SE 5.0 语言更改所需的新类提供其自己的等价物，并且用对其自己的类的引用替换对标准类的引用，这是字节码增强步骤的一部分。

Retroweaver 字节码增强不能对所有的 J2SE 5.0 语言更改提供完全支持。例如，没有对处理注释的运行时支持，因为运行时支持涉及到对基本 JVM 类加载器实现的更改。但是一般来说，只是不支持那些不会影响普通用户的小特性。

Retroweaver 发挥作用
使用 Retroweaver 简直是太容易了。可以使用一个简单的 GUI 界面或者控制台应用程序来在应用程序类文件上运行字节码增强。两种方式都只要在将要转换的类文件树的根目录指出 Retroweaver 即可。在运行时，如果使用任何需要运行时支持的特性（比如 enums），那么就需要在类路径中包含 Retroweaver 运行时 jar。

清单 1 给出了一个简单的示例程序，其中使用了一些 J2SE 5.0 特性。com.sosnoski.dwct.Primitive 是一个针对 Java 语言原语类型的 enum 类。main() 方法使用增强的 for 循环来迭代通过不同的原语，并在当前实例上使用一个简单的 switch 语句来设置每个原语的大小值。

package com.sosnoski.dwct;

public enum Primitive
{
    BOOLEAN, BYTE, CHARACTER, DOUBLE, FLOAT, INT, LONG, SHORT;
    
    public static void main(String[] args) {
        for (Primitive p : Primitive.values()) {
            int size = -1;
            switch (p) {
                case BOOLEAN:
                case BYTE:
                    size = 1;
                    break;
                case CHARACTER:
                case SHORT:
                    size = 2;
                    break;
                case FLOAT:
                case INT:
                    size = 4;
                    break;
                case DOUBLE:
                case LONG:
                    size = 8;
                    break;
            }
            System.out.println(p + " is size " + size);
        }
    }
}

使用 JDK 5.0 编译并运行清单 1 代码会给出清单 2 中的输出。但是不能在早期的 JDK 下编译或运行清单 1 代码；由于特定于 J2SE 5.0 的特性会导致编译失败，而运行失败会抛出 java.lang.UnsupportedClassVersionError 异常。

[dennis@notebook code]$ java -cp classes com.sosnoski.dwct.Primitive
BOOLEAN is size 1
BYTE is size 1
CHARACTER is size 2
DOUBLE is size 8
FLOAT is size 4
INT is size 4
LONG is size 8
SHORT is size 2

清单 3 展示了在 Primitive 类上运行 Retroweaver。这个类实际上编译为两个类文件，一个用于 enum 类，另一个支持在 switch 语句中使用 enum。（注意，清单代码换行是为了适应页面宽度。）

[dennis@notebook code]$ java -cp retro/release/retroweaver.jar:retro/lib/bcel-5.1.jar:retro/lib/
  jace.jar:retro/lib/Regex.jar com.rc.retroweaver.Weaver -source classes
[RetroWeaver] Weaving /home/dennis/writing/articles/devworks/series/may05/code/
  classes/com/sosnoski/dwct/Primitive$1.class
[RetroWeaver] Weaving /home/dennis/writing/articles/devworks/series/may05/code/
  classes/com/sosnoski/dwct/Primitive.class

在运行 Retroweaver 之后，这些类就可以用于 JDK 5.0 和 JDK 1.4 JVM 上了。当使用 1.4 JVM 运行修改后的类时，输出与 清单 2 中的相同。Retroweaver 提供命令行选项来指定旧的 1.3 和 1.2 JVM 以取代默认的 1.4 目标，但是我下载的运行时 jar 版本需要 1.4，我不想重新构建它以检查对早期 JVM 的支持。

JDK 1.4 上的注释
既然已经看到了 Retroweaver 如何让您运行在早期 JVM 上的同时在源代码中使用 J2SE 5.0 特性，我将返回到 上个月 的代码。以防您没有阅读上一期，我在此做一个总结：我展示了如何使用 ASM 2.0 基于注释实现运行时类转换，并给出一个注释的特定例子，该注释用于指定 toString() 方法中应该包括哪些字段。

上个月的代码只适用于 JDK 5.0 或更高版本。在本文中，我将修改代码以适用于早期 JVM。与 Retroweaver 一起使用，自动化 toString() 生成的好处将会扩展到许多还停留在 J2SE 5.0 之前运行时的 Java 开发人员。

回忆 ToStringAgent
我用于对 JDK 5.0 实现 toString() 方法生成的 com.sosnoski.asm.ToStringAgent 类对于旧版 JVM 有一个小小的问题：它使用 J2SE 5.0 中新增的 instrumentation API 来在运行时截取类加载和修改类。在早期 JVM 中截取类加载不太灵活，但是并不是不可能 —— 只需要用您自己的版本来取代用于应用程序的类加载器就可以了。由于所有的应用程序类都是通过您的自定义类加载器加载的，所以在它们被实际提供给 JVM 之前，您可以自由地修改类表示。

更新 上个月 的代码以使用自定义类加载器方法是很容易的。清单 4 展示了带有所有修改的类。该类取代了上一期文章中使用的 com.sosnoski.asm.ToStringAgent 类。上一期中使用到的其他类保持不变。

package com.sosnoski.asm;

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.lang.reflect.Method;
import java.net.URL;
import java.net.URLClassLoader;

import org.objectweb.asm.ClassReader;
import org.objectweb.asm.ClassWriter;

public class ToStringLoader extends URLClassLoader
{
    private ToStringLoader(URL[] urls, ClassLoader parent) {
        super(urls, parent);
    }

    // override of ClassLoader method
    protected Class findClass(String name) throws ClassNotFoundException {
        String resname = name.replace('.', '/') + ".class";
        InputStream is = getResourceAsStream(resname);
        if (is == null) {
            System.err.println("Unable to load class " + name +
                " for annotation checking");
            return super.findClass(name);
        } else {
            System.out.println("Processing class " + name);
            try {
                
                // read the entire content into byte array
                ByteArrayOutputStream bos = new ByteArrayOutputStream();
                byte[] buff = new byte[1024];
                int length;
                while ((length = is.read(buff)) >= 0) {
                    bos.write(buff, 0, length);
                }
                byte[] bytes = bos.toByteArray();
                
                // scan class binary format to find fields for toString() method
                ClassReader creader = new ClassReader(bytes);
                FieldCollector visitor = new FieldCollector();
                creader.accept(visitor, true);
                FieldInfo[] fields = visitor.getFields();
                if (fields.length > 0) {
                    
                    // annotated fields present, generate the toString() method
                    System.out.println("Modifying " + name);
                    ClassWriter writer = new ClassWriter(false);
                    ToStringGenerator gen = new ToStringGenerator(writer,
                            name.replace('.', '/'), fields);
                    creader.accept(gen, false);
                    bytes = writer.toByteArray();
                }
                
                // return the (possibly modified) class
                return defineClass(bytes, 0, bytes.length);
                
            } catch (IOException e) {
                throw new ClassNotFoundException("Error reading class " + name);
            }
        }
    }

    public static void main(String[] args) {
        if (args.length >= 1) {
            try {
                
                // get paths to be used for loading
                ClassLoader base = ClassLoader.getSystemClassLoader();
                URL[] urls;
                if (base instanceof URLClassLoader) {
                    urls = ((URLClassLoader)base).getURLs();
                } else {
                    urls = new URL[] { new File(".").toURI().toURL() };
                }
                
                // load the target class using custom class loader
                ToStringLoader loader =
                    new ToStringLoader(urls, base.getParent());
                Class clas = loader.loadClass(args[0]);
                    
                // invoke the "main" method of the application class
                Class[] ptypes = new Class[] { args.getClass() };
                Method main = clas.getDeclaredMethod("main", ptypes);
                String[] pargs = new String[args.length-1];
                System.arraycopy(args, 1, pargs, 0, pargs.length);
                Thread.currentThread().setContextClassLoader(loader);
                main.invoke(null, new Object[] { pargs });
                
            } catch (Exception e) {
                e.printStackTrace();
            }
            
        } else {
            System.out.println("Usage: com.sosnoski.asm.ToStringLoader " +
                "report-class main-class args...");
        }
    }
}

为了使用清单 4 代码，我仍然需要使用 JDK 5.0 编译与注释相关的代码，然后在产生的类集合上运行 Retroweaver。我也需要在类路径中包含 retroweaver.jar 运行时代码（因为 Retroweaver 对已转换的注释使用它自己的类）。清单 5 展示了运行与 上个月 相同的测试代码所产生的输出，但是这一次使用了 Retroweaver 和清单 4 中的 ToStringLoader 类，其中命令行换行是为了适应页面宽度）。

[dennis@notebook code]$ java -cp classes:retro/release/retroweaver-rt.jar:lib/
  asm-2.0.RC1.jar:lib/asm-commons-2.0.RC1.jar
  com.sosnoski.asm.ToStringLoader com.sosnoski.dwct.Run
Processing class com.sosnoski.dwct.Run
Processing class com.sosnoski.dwct.Name
Modifying com.sosnoski.dwct.Name
Processing class com.sosnoski.dwct.Address
Modifying com.sosnoski.dwct.Address
Processing class com.sosnoski.dwct.Customer
Modifying com.sosnoski.dwct.Customer
Customer: #=12345
 Name: Dennis Michael Sosnoski
 Address: street=1234 5th St. city=Redmond state=WA zip=98052
 homePhone=425 555-1212 dayPhone=425 555-1213

清单 5 显示了生成的 toString() 方法的输出，其末尾部分与 上个月 代码的 JDK 5.0 版本的结果相同。被处理的类列表几乎是相同的，只是用于截取类加载的技术不同。用于 JDK 1.4 的自定义类加载器方法不提供 JDK 5.0 instrumentation API 的完全灵活性，但是它适用于所有最近的 JVM，并允许您修改任何应用程序类。

结束语
在本期文章中，我展示了如何使用 Retroweaver 来使 J2SE 5.0 Java 代码可运行在旧版 JVM 上。如果您喜欢新的 J2SE 5.0 语言特性，并迫不及待想在自己的应用程序中使用这些特性，那么 Retroweaver 提供了完美的解决方案：您可以马上在开发中开始使用这些语言特性，根本不会影响生产平台。作为 Retroweaver 发挥作用的一个例子，我也 backport 了 上个月 的基于注释的 ToString 生成器，以在早期 JVM 上运行。

对于下个月的文章，我将回到在上一期文章中简要提到的一个问题，即注释与外部配置文件之间的权衡。在配置文件疯狂了很多年之后，整个的 Java 扩展集合似乎都一股脑儿转向使用注释了。但是难道注释总是提供配置类型信息的最佳方式吗？我对此表示怀疑，下个月我将提供一些例子，以及一些我个人的最佳实践指导方针。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• 单击本文顶部或底部的 代码 图标，下载文中讨论的源代码。
  
  
• 想要开始在旧版 JVM 上使用 J2SE 5.0 语言特性？请直接查看 Retroweaver 项目 的开放源代码。
  
  
• 获得 ASM 这个快速而灵活的 Java 字节码操作框架的所有详细资料。
  
  
• 对 J2SE 5.0 与旧版 Java 平台的区别感兴趣？请查看 John Zukowski 撰写的 驯服 Tiger 系列，了解所有的更改。
  
  
• 在 JSR-175: A Metadata Facility for the Java Programming Language 中找到关于 J2SE 注释的所有信息。
  
  
• 关于使用自定义类加载器在运行时进行类转换的深入讨论，请参阅作者的文章“Java 编程的动态性，第 5 部分: 动态转换类”（developerWorks, 2004 年 2 月）。
  
  
• 不要错过 Dennis Sosnoski 撰写的 Classworking 工具箱 系列中的其他文章。
  
  
• 请参阅 Peter Haggar 撰写的“Java bytecode: Understanding bytecode makes you a better programmer”（developerWorks, 2001 年 7 月），了解关于 Java 字节码设计的更多信息。
  
  
• 同样由 Dennis Sosnoski 撰写的 Java 编程的动态性 系列，将带您漫游 Java 类结构、发射和 classworking。
  
  
• Jikes 开放源代码项目提供了 Java 编程语言的非常快速和高兼容性的编译器。可以使用它来老式地生成字节码 —— 从 Java 源代码生成。
  
  
• 要了解更多关于 Java 技术的信息，请访问 developerWorks Java 专区。您将找到技术文档、how-to 文章、教程、下载、产品信息，以及更多内容。
  
  
• 请访问 New to Java technology 站点，找到帮助您开始 Java 编程的最新资源。
  
  
• 通过参与 developerWorks blogs 加入 developerWorks 社区。
  

June 22, 2005

Much has already been much written and discussed concerning the upcoming changes to Enterprise JavaBeans (EJB) with the proposed 3.0 specification. The simplifications of the component model and metadata configuration will definitely make this update an important evolution of J2EE. One of the most significant changes within EJB 3.0 is the new persistence model. This new persistence API and approach to modeling is based on the success of leading object-relational mapping products that use a Plain Old Java Object (POJO) approach to persistence.

We'll look into EJB 3.0 persistence and address the concerns of enterprise application developers and architects who are currently using EJB 2.1 CMP. The process of moving from EJB 2.1 persistence to EJB 3.0 can range from coexistence to a full migration and adoption of the new model. Although much has already been written about the new persistence model, specific strategies and development and design patterns have not been detailed. We'll attempt to fill these gaps with concrete solution options while visiting the key benefits that application developers will gain through this migration. We assume that you are familiar with the basic elements of the new persistence API. (Note: Look for an upcoming article on migrating J2EE applications to EJB 3.0 in Java Pro magazine by Debu Panda, a member of the Oracle Application Server Development team, that will post on FTPOnline in July, 2005.)

Why Migrate?
One question participants in J2EE projects should discuss when planning an upgrade to an EJB 3.0-enabled J2EE container is: Why should we migrate our application? These new EJB 3.0 containers will be backward compatible and thus support their existing application without modification. This backward compatibility means that upgrading a container to EJB 3.0 does not mean in itself that an application needs to be rewritten. However, what about this new persistence API?

SELECT NEW example.EmpView(
  e.id, e.firstName, e.lastName, 
  d.name)
FROM Employee e JOIN 
  e.department d 
WHERE e.salary > 50000

@Entity
public class Employee {
  private Department department;

  // ...

  @ManyToOne
  public Department 
    getDepartment() {
      return department;
  }

  public void setDepartment(
    Department dept) {
      this. department = dept;
  }
}
Much as how the table and field names are assumed by default and can be overridden, so can the foreign key column names. For these the relationship mapping annotations make use of @JoinColumn to provide column names that are different from the defaults. 

It is important to note that at this point, there are no behavioral changes to the existing application. We have merely added metadata to the original entity DTOs that makes it possible to use them as persistent EJB 3.0 entities. Assuming there is a DAO layer in place that manages the entity DTOs, this layer can now be updated to use the EntityManager to retrieve, store, and update the newly annotated persistent objects. 
Migrate EJB 2.1 Entity Beans
The other alternative for migrating to the new EJB 3.0 persistence model is to leverage the existing EJB 2.1 entity model. For the purposes of this discussion, we'll assume that only local interfaces to the entity beans are used because these are the most prevalent in today's applications and because entities as remote objects are not supported in EJB 3.0. For those applications using entity beans as remote objects, the migration will involve more-fundamental design changes.
The goal in this type of migration is to minimize the changes to client code, which is bound to the local and home interfaces of an entity: 
Remove the abstract designation on the bean class, and provide concrete implementations of the property accessor (get/set) methods. 
Annotate the bean class with the object-relational annotations that map the entity to the database, and describe its relationships. 
Rename the bean class to be that of the local interface, and remove the local interface to minimize changes to application code that already uses the bean through this interface. 
Convert finders and selects associated with the bean to @NamedQuery annotations on the bean class. 
If your entity bean acts as a client to other beans, this code must be migrated as application client code, as discussed later. Consider this EJB 2.1 Department bean: 
public abstract class 
  DepartmentBean implements 
  EntityBean {
  public abstract Long getId();
  public abstract void setId(
    Long id);
  public abstract String 
    getName();
  public abstract void setName(
    String name);
  public abstract Collection 
    getEmployees();
  public abstract void 
    setEmployees(
    Collection employees);

  public void ejbCreate(Long id) 
    throws CreateException {}
  public void ejbPostCreate(
    Long id) throws 
    CreateException {}
  public void ejbStore() {}
  public void ejbLoad() {}
  public void ejbRemove() {}
  public void ejbActivate() {}
  public void ejbPassivate() {}
  public void setEntityContext(
    EntityContext ctx) {}
  public void unsetEntityContext() 
    {}
}

It contains the following finder definitions: 
<query&th;
  <description></description>
  <query-method>
    <method-name>findAll
    </method-name>
    <method-params/>
  </query-method>
  <result-type-mapping>Local
  </result-type-mapping>
  <ejb-ql>Select OBJECT(d) From 
    Department d</ejb-ql>
</query>
<query>
  <description></description>
  <query-method>
    <method-name>findByDeptName
    </method-name>
    <method-params>
      <method-param>
        java.lang.String
      </method-param>
      </method-params>
  </query-method>
  <result-type-mapping>Local
  </result-type-mapping>
  <ejb-ql>SELECT DISTINCT 
    OBJECT(d) FROM Department d 
    WHERE d.name = ?1</ejb-ql>
</query>

By following the steps listed previously, we end up with the code you see in Listing 2. 
Of special interest is the use of EJB 2.1 container-managed relationships (CMR). In EJB 3.0, relationship management is performed with standard Java coding practices. It is the responsibility of the developer to ensure that both sides of a relationship are updated correctly when relationships are formed. Generally speaking, one additional line of code is required for every relationship operation to ensure that the model is consistent. With respect to collections, we recommend the use of helper methods such as add and remove instead of direct manipulation of the collection in client code: 
@Entity
public class Department {
  private Collection<Employee> employees;

  // ...

  public void addEmployee(
    Employee emp) {
    employees.add(emp);
    emp.setDepartment(this);
  }
}
Besides these more common migration changes, there is additional EJB 2.1 entity bean implementation that may require work. These include the use of the EntityContext within the bean itself and ejbHome methods. An EJB 3.0 entity will not have an EntityContext. The entity can simply use "this" to resolve to itself and pass itself into other beans’ methods. Any ejbHome methods implemented can simply remain as is or be converted into static methods to make their use more obvious. 
Migrate EJB 2.1 Entity Homes
The home interface is the primary mechanism that enables application code to locate and manage entity beans. Because EJB 3.0 has nothing equivalent to home interfaces, it also presents the greatest challenge in migration.
To minimize changes to client code, the easiest approach to migrating homes is to create a helper class that holds onto an EntityManager and implement the methods called on the home by the application code. The example shown in Listing 3 demonstrates a helper class that functions as a replacement home. 
This helper class leverages the named queries we defined on the entity class to implement finders, although dynamic queries could also have been used. The remove method on this helper replaces the EJBLocalObject.remove() previously on the entity bean. It is important that all calls to the bean’s remove method be migrated to call this one provided on the helper or to directly make the call with the EntityManager. 
The application code that makes use of EJB 2.1 entity beans is coupled tightly to the Home and Local or Remote interfaces of the entity beans. The migration of this code is least likely to be automated; however: 
Home interface lookup and query execution must be modified to either directly use the EntityManager or a Home-helper class that is not managed by the container. 
Code using the entity beans interfaces must be changed to use the new EJB 3.0 entity. The entity class can be the interface, the entity DTO, or some new entity bean class. The selection and intrusiveness of these changes will depend on the chosen model-migration approach. 
Entity DTO detachment and attachment code can be removed, in favor of detachment/attachment of the entities. 
View DTO creation code can be replaced with EJB QL queries that dynamically create the nonpersistent view objects. 
Although it is not possible to dive into all of the details of a migration from EJB 2.1 CMP to the new EJB 3.0 persistence model, we have addressed the major issues. Understanding the differences between the models and migration options available is key to planning such an effort. As the persistence vendors continue to make early previews of the technology available, more detailed technical information and tooling to assist in this migration will become available. 
Those wanting to try these migration steps today require an EJB 3.0 preview and an IDE with good refactoring and J2SE 5.0 support. Oracle's EJB 3.0 preview and technical information are available at http://otn.oracle.com/ejb3. For those wanting to get more involved in the EJB 3.0 persistence specification, the drafts are available at http://java.sun.com/products/ejb, and you can provide feedback at ejb3-feedback@sun.com. 
About the Authors
Merrick Schincariol is a senior engineer for Oracle Application Server and one of the lead developers of the Oracle Application Server EJB 3.0 Preview. Doug Clarke is a senior principal product manager for the Oracle TopLink product, with extensive development, consulting, and educational field experience focusing on persistence. Contact Merrick at merrick.schincariol@oracle.com, and contact Doug at douglas.clarke@oracle.com. 

July 21, 2005

The programming model for Enterprise JavaBeans (EJBs) has been simplified dramatically in EJB 3.0 and is being hailed by Java developers as the new standard of server-side business logic programming. Meanwhile, the existence of thousands of J2EE applications written with earlier versions of the EJB API has raised concerns about both the interoperability of EJB 3.0 with these applications and migrating the applications to use EJB 3.0.

Major application server vendors that already provide EJB 3.0 features will continue to support EJB 2.x in the new EJB 3.0 container. This support means that applications written with EJB 2.x will continue to run without any change whatsoever. However, some organizations will certainly want to migrate their applications to use the EJB 3.0 API to improve maintainability by simplifying their code and take advantage of the performance and scalability benefits of the persistence API.

Let's look at some of the issues relevant to migrating applications to EJB 3.0. The topics discussed here compose a subset of all possible issues a migration effort will encounter, and because the spec is not finalized other issues may still arise.

The main goals of EJB 3.0 are to simplify the programming model and to define a persistence API for the Java platform. Some general changes to the EJB spec that will simplify life for EJB developers are: EJB artifacts are Plain Old Java Objects (POJOs), XML descriptors are no longer necessary, annotations may be used instead, defaults are assumed whenever possible, unnecessary artifacts and life-cycle methods are optional, and the client view is simplified by dependency injection.

Standardization of the POJO persistence model (such as the one used by Oracle TopLink and JBoss Hibernate) within the context of J2EE finally provides users with the inheritance and polymorphism that have until now been available only outside the container or in proprietary products. Furthermore, the POJO entity beans can now be used and tested both inside and outside the EJB container.

Migrate Session Beans
The main changes in EJB 3.0 session beans simplify development by making beans POJOs that use annotations instead of XML descriptors and dependency injection instead of complex JNDI lookup. Hence, it is very easy to migrate the session beans to use the EJB 3.0 programming model. The changes in EJB 3.0 sessions fall into two categories: the server side and the client side. By client side we mean using resources, EJBs, and so on from other EJBs. Using EJBs from other types of clients outside the EJB container will be standardized with the J2EE 5.0 specification.

Some application servers allow migration of server-side components without affecting the clients, thus allowing incremental migration of applications.

There are some changes that need to be made to EJB 2.x session beans to migrate to EJB 3.0. In EJB 3.0 the remote and local interfaces do not have to implement javax.ejb.EJBObject or javax.ejb.EJBLocalObject. The component interface can become a business interface, and @Remote annotations can be used to mark remote interfaces.

import javax.ejb.EJBObject;
import java.rmi.RemoteException;

public interface HelloWorld 
	extends EJBObject {
	void sayHello(String name) 
		throws RemoteException;
}

and the EJB 3.0 remote interface:

import javax.ejb.Remote;

@Remote
public interface HelloWorld {
	void sayHello(String name);
}
Bean classes do not need to implement javax.ejb.SessionBean—rather, their business interfaces. Life-cycle methods that are not required do not need to be present on the bean class, and callbacks may be indicated by annotations. Here is the EJB 2.x stateless session bean: 
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;

public class HelloWorldBean 
	implements SessionBean {

	public void ejbCreate() {}
	public void ejbActivate() {}
	public void ejbPassivate() {}
	public void ejbRemove() {}
	public void setSessionContext(
		SessionContext ctx) {}

	public void sayHello(
		String name) {
	System.out.println(
		"Hello " + name);
	}
}
and here is the stateless session bean migrated to EJB 3.0: 
import javax.ejb.Stateless;

@Stateless
public class HelloWorldBean 
	implements HelloWorld {
	public void sayHello(
		String name)  {
		System.out.println(
			"Hello " + name);
	}
}

Stateful session bean ejbCreate() methods become business methods used at initialization time. Removal methods are annotated with @Remove. Optionally, you can migrate session bean code to use annotations for transactions and security. 
EJB 3.0 simplifies the use of resources and EJB references by making use of the principle of dependency injection. Injection of resources or references can occur through either annotation of the injection target or specification of the target in the ejb-jar.xml descriptor. Table 1 lists some of the differences. 
EJB 2.x
EJB 3.0
Using another EJB:
ejb-ref in XML descriptor Do JNDI lookup to get the home interface 

Call home.create to obtain instance 
ejb-ref no longer requires the home interface Change the home interface to the business interface

Remove home.create and directly invoke the methods on the EJB 

Optionally annotate the EJB business interface property/field to obtain an instance 
Resource access:
Do JNDI lookup to obtain a resource
Optionally annotate a resource property/field to obtain a resource

Table 1 Inject Simplification

EJB 3.0's principle of dependency injection simplifies the use of resources and EJB references. Annotation of the injection target or specification of the target in the ejb-jar.xml descriptor provides for the occurrence of resources or references. Compare the differences.

For example, if you are using the CartEJB in another EJB named OrderBean, with EJB 2.x you have to make a reference to the CartEJB in the deployment descriptor using ejb-ref: 
<ejb-ref-name>MyCart
</ejb-ref-name>
	<ejb-ref-type>Session
	</ejb-ref-type>
	<home>CartHome</home>
	<remote>Cart</remote>
Do a lookup of the home interface for the CartEJB, using JNDI, and create an instance of the CartEJB: 
Object homeObject = 
context.lookup(
	"java:comp/env/MyCart");
CartHome home = (
	CartHome)PortableRemoteObject.
	narrow(homeObject, 
	CartHome.class);
	Cart cart =(
		Cart)PortableRemoteObject.
		narrow(home.create(), 
		Cart.class);
cart.addItem("Item1");
After migration to the EJB 3.0 injection pattern, this code can become much simpler and would look like this: 
@EJB Cart cart;
	public void addItems() { 
		cart.addItem("Item1");
		}
A session bean can also be used as a façade for CMP entity beans, giving rise to a migration strategy for moving CMP entity beans to the EJB 3.0 persistence API. 
More Migrations
Migrating Message-Driven Beans (MDBs) to use EJB 3.0 is by far the easiest migration task. In EJB 3.0, MDBs do not have to implement the javax.ejb.MessageDriven interface but can instead be annotated with @MessageDriven. Resources and EJB references can be injected into MDBs in the same way as session beans. Similarly, you can inject the context (MessageDrivenContext for MDB) into the message-driven bean. Table 2 summarizes the changes in MDB between EJB 2.x and EJB 3.0.
EJB 2.x
EJB 3.0
Implements javax.ejb.MessageDriven
POJO: May annotate with @MessageDriven
Specify destination type, name, and so on in the deployment descriptor.
May be annotated with @ActivationConfigProperty
MessageDrivenContext is acquired using setMessageDrivenContext().
MessageDrivenContext is achieved using dependency injection—for example: @Inject javax.ejb.MessageDrivenContext mc; 
Resource usage, such as Queue or Topic, is required resource-ref in the deployment descriptor and JNDI lookup.
Can be used using dependency injection: @Inject private Queue destQueue; 

Table 2 MDB Migration
MDBs do not have to implement the javax.ejb.MessageDriven interface in EJB 3.0, but they can instead be annotated with @MessageDriven. 










Persistence is one of the greatest challenges facing Java developers, compounded further by the lack of a standard persistence API for the J2EE platform. J2EE applications typically use one of these persistence choices: EJB 2.x CMP entity beans; a POJO persistence framework such as Oracle TopLink, JBoss Hibernate, or another custom O/R mapping framework; Data Access Objects with JDBC; and Java Data Objects (JDO). 
Of these options, migrating EJB 2.x CMP entity beans presents the most interesting case because the change in programming model brings the EJB 3.0 persistence API to the same level of "POJOness" as other persistence solutions, which is worth taking some time to explore. 
EJB 2.x CMP entity beans represent coarse-grained data objects and follow the distributed component model that includes security, transaction, and concurrency management. Because of these facilities they also carry the container management costs associated with it. EJB 3.0 entities are lightweight objects that can model fine-grained data. The difference between the 2.x and 3.0 models extends beyond simply converting the classes but should be considered at the modeling domain level. This difference does not mean that they cannot be converted, but that they should be migrated with some forethought and consideration of how they might best be remodeled. 
Let's take a detailed look at some of the issues you will encounter as you migrate an EJB 2.x CMP entity to use the new EJB persistence API. 
Remodel your entities. With EJB 3.0 entities becoming POJOs, it is probably the best idea to remodel your entities and leverage richer OO modeling benefits such as inheritance, polymorphism, and so on. The details of remodeling of entity beans vary from one application to another and are beyond the scope of this article. 
Data transfer objects. The Data Transfer Object (DTO) pattern is a common pattern that allows data from entities to be accessible directly to nonlocal clients outside a transaction. It involved creating simple container objects to hold the entity data and transferring them to any tier as necessary. The EJB 3.0 specification makes the DTO pattern unnecessary because entities can already be shipped wherever they are required. The EntityManager API that is used for CRUD operations for entities allows detachment and merging of detached objects. An object can be detached from persistence storage and can be sent to the client, and then the changes can be merged/synchronized using the EntityManager.merge() method after the client sends it back to the server making updates to the object locally. 
If DTOs already exist in an application, it is quite likely that they are the shortest path to making the EJB 2.x entities POJOs. The DTO becomes the candidate for the new entity bean if you simply add the logic into it and annotate/map it accordingly. 
More Issues
Migration of component interfaces. Business interfaces are optional for EJB 3.0 entity beans, and if they exist, they are only regular Java interfaces (POJIs). You can either convert existing local or remote component interfaces to regular Java interfaces by no longer extending the javax.ejb.EJBObject or EJBLocalObject interfaces, or discard them entirely. 
Conversion to POJO. EJB 3.0 entity beans no longer expect that the bean class implements the javax.ejb.EntityBean interface. They may extend any class and implement virtually any interface. The EntityBean interface can be removed from the implements clause. You have to convert the entity class and the get/set access methods from abstract to concrete. The previously virtual container-managed fields (cmp-fields) should have concrete implementations added to them. 
EntityContext. Lightweight entities now inherit their context from the calling method and have no context of their own. You must remove the EntityContext and replace use of the context by any methods with suitable alternatives. For example, the getPrimaryKey() method would be replaced with a method on the bean or business interface that exposes the primary key to the user. 
Home interfaces. The typed local and remote home interfaces in EJB 2.x are replaced by functionality in the EntityManager. Local and remote home interfaces should no longer be used, and clients that look them up should be converted to call the EntityManager directly to obtain or access the bean. 
There are four different types of methods in the home interface: create methods, remove methods, home methods, and finders. The create methods can be converted easily into constructors that initialize the state information on the instance. The remove methods should be redirected to the EntityManager. The home methods may remain as they are because they can be invoked on any instance, regardless of the state of the instance. I'll discuss Finder methods later. 
Optionally, you can keep the local home interface that clients use as a helper class for finders and factory style creation to minimize client code change and produce a nice clean usage pattern for your entity bean. 
Migration of life-cycle methods. EJB 2.x has a strict requirement to implement the EntityBean interface that defined the complete suite of life-cycle methods. Some of these life-cycle events no longer apply. Table 3 suggests strategies for migrating existing implementations of these methods. 
EJB 2.x life-cycle method
What to do in EJB 3.0
ejbCreate()
Implement logic in init methods/constructors.
ejbPostCreate()
Implement logic in a constructor, or create a business method and annotate it as @PostPersist.
ejbRemove()
Create a business method, and annotate it with @PreRemove.
setEntityContext() 
unSetEntityContext()
No longer applies.
ejbActivate()
Create a business method, and annotate it as @PostLoad
ejbPassivate()
No longer applies (it can be removed).
ejbStore()
Create a business method, and annotate it with either @PrePersist or @PreUpdate.

Table 3 Migration Strategies
Because some of the life-cycle events in EJB 2.x no longer apply, here are some possible strategies for migrating existing implementations of these life-cycle methods.
Migration of O/R mapping. Before EJB 3.0, O/R mappings were always in the domain of the vendor and, as such, were typically stored in a vendor-specific deployment descriptor. Now that the O/R mappings have been integrated into the EJB standard, they can be defined either as annotations on the bean class or in a standard XML file. Most vendors should be providing ways to translate their mappings into the standard EJB mappings, either through a migration tool or from their graphical mapping editors. 
Exception handling. Exceptions are in a different Java package and are not checked; the same CreateException, RemoveException, and FinderException catch phrases do not apply. 
Even More Issues
Migration of finder methods. In EJB 2.x, the finder methods were defined in a home interface, and the EJB QL query for the finder was specified in the deployment descriptor. There are a few options for migrating EJB 2.x entity bean finders to EJB 3.0. The finder method can become a method in any class, and the EJB QL can be incorporated into either a named query or a dynamic query. Here is a finder method example defined in EJB 2.x in the deployment descriptor:
<query>
	<query-method>
		<method-name>findAllByName
		</method-name>
		<method-params>
			<method-param>String
			</method-param>
		</method-params>
	</query-method>
	<ejb-ql>
		SELECT OBJECT(c) FROM 
		Customer c WHERE c.name LIKE 
		?1
	</ejb-ql>
</query>
A named query would look like this: 
public Collection findAllByName(
	String nameString) {
	return getEntityManager()
	.createNamedQuery(
		"findAllByName")
		.setParameter(
			"custName", nameString)
		.getResultList();
}
This example assumes that a NamedQuery annotation is defined this way: 
@NamedQuery(
	name="findAllByName", 
		queryString=
		"SELECT OBJECT(c) FROM 
		Customer c WHERE c.name 
		LIKE :custName")
Container-managed relationships. In EJB 2.x, the container was responsible for updating the other side of a relationship when one side was updated. EJB 3.0 opted to require the bean to manage its own relationships (to allow out-of-container entity testing and the like). Therefore, you must add management code to beans that have existing container-managed relationships, which is typically a one-line code change: 
public addOrder(Order order) {
	getOrders().add(order);
}
Adding the management code would require the backpointer assignment: 
public addOrder(Order order) {
	getOrders().add(order);
	order.setCustomer(this);
}
Migrating CMP clients. In EJB 2.x, local and/or remote clients accessed entity beans. A well-documented best practice was to keep the entity beans local and wrap them in a session façade. In EJB 3.0, entities, being regular Java objects, are always local and can never be remote (RMI) objects. They are obtained and queried for through the EntityManager API. Client code (a session bean in the case of a session façade) must change its use of entity home or component-specific methods to use the EntityManager to access the entities on which it operates. 
Local and remote entity references used to be required declarations in the deployment descriptor. In the client code the home would be looked up in JNDI, and home operations such as creates and finds could then be performed. Here's an example of a client lookup: 
public void createNewCustomer(
	String name, String city) 
throws CreateException, 
	NamingException, 
	RemoteException {
InitialContext ctx = new 
	InitialContext();
CustomerHome home = 
	(CustomerHome) ctx.lookup(
	"java:comp/env/ejb/CustomerHome"
	);
CustomerLocal customer = null;
	customer = home.create(
	name, city);
}
The migrated version of this code would look like this: 
@Resource private EntityManager 
	em;
public void createNewCustomer(
	String name, String city) {
		Customer cust = new 
		Customer();
		cust.setName(name);
		cust.setCity(city);
		em.persist(cust);
}
It is clear from the preceding discussion that migrating EJB 2.x entity beans to EJB 3.0 is the most complex task, will have an impact on clients, and needs careful planning. 
Migrating POJO applications. Some frameworks have been persisting Java objects to relational databases for a long time, and vast numbers of applications are written by use of O/R frameworks. Applications that are currently using a POJO persistence framework are well positioned to migrate to the EJB persistence API because the domain objects are already Java objects. Further, the persistence frameworks' transaction mechanisms and session-level APIs are similar to those of the new EJB persistence API. 
The result is that very little code rework is required. If you are currently evaluating a persistence framework for your J2EE applications, probably using a POJO persistence framework is the best choice because it can easily get you to the EJB 3.0 Persistence API. 
Get to It
Change the session APIs used in the persistence framework to EntityManager APIs.
Change proprietary O/R XML to O/R mapping annotations or O/R XML defined by the EJB 3.0 persistence API. 
The technical details of migration of POJO persistence to EJB 3.0 are covered in the article, "Prepare for the New EJB 3.0 Persistence API" (FTPOnline, June 2005)—see Resources online at www.javapro.com. 
Migration of J2EE applications to EJB 3.0 is certainly not rocket science; however, like any other migration effort, it takes education, resources, and planning. The first step is to become aware of where the platform is moving and understand where it plans to end up. Once you understand the technology, you should undertake planning to decide the best strategy for getting there. 
The prudent approach to migration is to migrate a subsection of the application before applying the practices to the whole. This strategy will ferret out many of the difficult migration issues and allow for experimentation to discover which approach might be best suited to the application. Features such as interoperability between EJB 2.x and EJB 3.0 components are critical when you're pursuing this kind of strategy. You can start trying out EJB 3.0 with an early implementation, and get ready for migrating to EJB 3.0.
About the Author
Debu Panda is a principal product manager of the Oracle Application Server development team and is responsible for the EJB container and Transaction Manager. Visit his J2EE-focused blog, or contact Debu at debabrata.panda@oracle.com. 

Editor's note: the following is a syndicated feature, which first published in Object Computing's "Java News Brief -- Java Technical Insight of the Month."

Starting with J2SE 1.4, the standard set of APIs will include the Preferences API made up of classes and interfaces in the java.util.prefs package. The Preferences API has been designed to provide a platform independent interface for storing preferences data. This article explores the Preferences API as it is implemented in the J2SE 1.4 Beta 2. Note that some details of the implementation may change in the final release of J2SE 1.4.

Preferences Overview

The Preferences API allows preference data to be divided into two categories, "System" preferences and "User" preferences. It is left to the application developer to categorize each preference into one of these. Generally system preferences include system wide attributes such as port numbers and other data that should be shared by all users of the system. User preferences include things like font or color preferences that may be user dependant.

Each of the two preference categories are structured as a hierarchical tree to allow for fine grained organization of the data. For example, under either of the two preferences trees there might be a hierarchy like apps/JAsteroids/HighScores/ or apps/JAsteroids/ScreenPreferences/. In this case, the "apps" node is the parent node to the "JAsteroids" node and the "JAsteroids" node is the parent node to both the "HighScores" node and the "ScreenPreferences" nodes.

Any node in a preference tree may contain other nodes and may contain preference data. The types of data that can be stored as preferences are...

• int
• float
• long
• double
• boolean
• byte[]
• String

The API

Retrieving A Preferences Object

An instance of java.util.prefs.Preferences represents a particular node in one of the two preference trees. As Preferences is an abstract class, an instance may not be created directly but instead should be retrieved from one of the static methods in the Preferences class.

// retrieve a reference to the root 
// of the user preferences tree
Preferences userPreferencesRoot = Preferences.userRoot();

// retrieve a reference to the root of 
// the system preferences tree
Preferences sysPreferencesRoot = Preferences.systemRoot();

These methods return references to the root node of the user preference tree and the system preference tree respectively.

There are two other static methods in the Preferences class that return a Preferences instance, Preferences.userNodeForPackage(Object) and Preferences.systemNodeForPackage(Object). These methods return a Preferences instance that is associated with the argument's package.

package com.ociweb.preferencestest;
  
import java.util.prefs.*;
  
public class PreferenceTestFrame extends JFrame {
  
  // A reference to Preferences object
  private Preferences myPreferences = null;
  
  public PreferenceTestFrame() {
    super("Preferences Test Window");
  
    // Obtain a references to a Preferences object
    myPreferences = Preferences.userNodeForPackage(this);
  }
}

This PreferenceTestFrame class is defined to be in the com.ociweb.preferencestest package. The call to Preferences.userNodeForPackage(this) returns a Preferences object that is associated with the com/ociweb/preferencestest/ node in the user preferences tree. If that node does not exist it will be created.

Two instance methods in the Preferences class that return references to other Preferences objects are parent() and node(String). The parent() method returns a Preferences object that is associated with the parent node of the node on which the method was called. This method returns null if called on one of the root nodes. The node(String) method returns a Preferences object associated with some node relative to the node the method was called on. For example, if the Preferences object P1 is associated with the apps/JAsteroids/ node, then a call to P1.node("ScreenPreferences/") returns a Preferences object associated with the apps/JAsteroids/ScreenPreferences/ node. If the requested node does not exist, it will be created.

Storing And Retrieving Data

Each piece of preference data stored using the Preferences API is stored in a particular node in one of the two preference trees and has a String key associated with it which must be unique within that particular node of the tree. There are 7 "get" methods and 7 "put" methods in the Preferences class, 1 method for each of the valid preference types.

• int getInt(String key, int default)
• float getFloat(String key, float default)
• long getLong(String key, long default)
• double getDouble(String key, double default)
• boolean getBoolean(String key, boolean default)
• byte[] getByteArray(String key, byte[] default)
• String get(String key, String default)

• void putInt(String key, int value)
• void putFloat(String key, float value)
• void putLong(String key, long value)
• void putDouble(String key, double value)
• void putBoolean(String key, boolean value)
• void putByteArray(String key, byte[] value)
• void put(String key, String value)

Each of the "get" methods accepts a default value. This value will be returned if the specified key does not exist at that particular node. They keys() method returns an array of String objects that includes all of the keys stored at that particular node.

Note the absence of support for storing arbitrary objects and collections of objects. The API is designed to support simple data, not complex objects. A simple collection of attributes could be stored as a tokenized String. For example, if an application needs to store the location and size of a window the application could store 4 separate pieces of data (x-location, y-location, width and height) or the application could store a tokenized String that contains all 4 pieces of data and that String would need to be parsed after being retrieved.

package com.ociweb.preferencestest;

import java.awt.event.*;
import java.util.prefs.*;
import javax.swing.*;

/**
* A frame to test some basic functionality
* in the Preferences API
*
* @author Object Computing Inc.
*/
public class PreferenceTestFrame extends JFrame {

// A reference to a Preferences object
private Preferences myPreferences = null;

// Default values for this frame's preferences
public static final int DEFAULT_WINDOW_X = 50;
public static final int DEFAULT_WINDOW_Y = 50;
public static final int DEFAULT_WINDOW_WIDTH = 300;
public static final int DEFAULT_WINDOW_HEIGHT = 100;

// Keys for this frame's preferences
public static final String WINDOW_X_KEY = "TEST_WINDOW_X";
public static final String WINDOW_Y_KEY = "TEST_WINDOW_Y";
public static final String WINDOW_WIDTH_KEY = "TEST_WINDOW_WIDTH";
public static final String WINDOW_HEIGHT_KEY = "TEST_WINDOW_HEIGHT";

public PreferenceTestFrame() {
super("Preferences Test Window");

// Obtain a references to a Preferences object
myPreferences = Preferences.userNodeForPackage(this);

// Retrieve the location of the frame from the Preferences object
int windowX = myPreferences.getInt(WINDOW_X_KEY, DEFAULT_WINDOW_X);
int windowY = myPreferences.getInt(WINDOW_Y_KEY, DEFAULT_WINDOW_Y);

// Retrieve the size of the frame from the Preferences object
int windowWidth =
myPreferences.getInt(WINDOW_WIDTH_KEY, DEFAULT_WINDOW_WIDTH);
int windowHeight =
myPreferences.getInt(WINDOW_HEIGHT_KEY, DEFAULT_WINDOW_HEIGHT);

// Set the size and location of the frame
setBounds(windowX, windowY, windowWidth, windowHeight);

addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent we) {
exitApp();
}
});
}

private void exitApp() {
// Save the state of the window as preferences
myPreferences.putInt(WINDOW_WIDTH_KEY, getWidth());
myPreferences.putInt(WINDOW_HEIGHT_KEY, getHeight());
myPreferences.putInt(WINDOW_X_KEY, getX());
myPreferences.putInt(WINDOW_Y_KEY, getY());
System.exit(0);
}

public static void main(String[] args) {
new PreferenceTestFrame().show();
}
}

This application exercises the Preferences API by storing its window size and location as preferences and then retrieving them each time the application is executed so the window is restored to its previous location. The Preferences object is retrieved by calling Preferences.userNodeForPackage(this) so the data will be stored at the com/ociweb/preferencestest/ node in the user preferences tree.

This implementation stores each of the window attributes as a separate preference. Alternatively, the implementation could have combined all of these pieces of information into a String formed something like <x-location>:<y-location>:<width>:<height>.

Where Is The Data?

The details about where the data is actually stored may vary from platform to platform. Each of the static methods in the Preferences class that returns a Preferences object are relying on a factory that creates the Preferences object. This factory is some concrete implementation of the java.util.prefs.PreferencesFactory interface. The name of the concrete factory class to use is specified by the java.util.prefs.PreferencesFactory system property. The documentation explicitly states that this is NOT part of the specification and is subject to change in future releases. On Linux, the value of this system property is java.util.prefs.FileSystemPreferencesFactory so the Preferences API will use an instance of that class whenever an instance of Preferences is requested via one of the static methods in the Preferences class. This particular implementation stores all of the preference data in files on the file system. On Windows 2000, the value of this system property is java.util.prefs.WindowsPreferencesFactory. This implementation stores all of the preference data in the Windows Registry. Specifically, system preferences are stored under HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs and user preferences are stored under HKEY_CURRENT_USER\Software\JavaSoft\Prefs.

This screen shot shows the data stored by the PreferenceTestFrame application shown above. Of course the application code makes no references to the Windows Registry. The application is written to the standard Preferences API.

There are facilities built into the Preferences API to allow preference data to be exported and imported to and from an eXtensible Markup Language (XML) file.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE preferences SYSTEM 'http://java.sun.com/dtd/preferences.dtd'>

<preferences EXTERNAL_XML_VERSION="1.0">
<root type="user">
<map />
<node name="com">
<map />
<node name="ociweb">
<map />
<node name="preferencestest">
<map>
<entry key="TEST_WINDOW_WIDTH" value="256" />
<entry key="TEST_WINDOW_HEIGHT" value="314" />
<entry key="TEST_WINDOW_X" value="540" />
<entry key="TEST_WINDOW_Y" value="63" />
</map>
</node>
</node>
</node>
</root>
</preferences>

This XML was created by calling the exportSubtree(OutputStream) method on an instance of Preferences that was associated with the root of the user preference tree. These are the same preferences reflected in the Windows Registry screenshot shown above. The exportSubTree(OutputStream) method exports any particular node and all of its sub-nodes in the tree. The exportNode(OutputStream) method exports a particular node and does not include any of its sub-nodes. Each of those methods are instance methods as they operate on a particular node in the tree.

The static method importPreferences(InputStream) in the Preferences class imports preferences from an XML source and adds those preferences to the appropriate preference tree. If any of the nodes represented in the XML do not exist in the preference tree, they are created.

Comparing With Property Files

Without the Preferences API, many applications have taken advantage of Java Property files for storing simple data like that accounted for by the Preferences API. In comparison to using Property files, the Preferences API provides a more robust mechanism for organizing the data without introducing complexity. For example, Property files do not provide any easy way to group data hierarchically. This flexibility is built into the Preferences model. Property files are dependent on a file system, which may not exist on every platform with a Java VM, for example a cellular telephone. There is nothing about the Preferences API that depends on a file system. For platforms without a file system, an implementation of java.util.prefs.PreferencesFactory could be developed that stores the data using whatever mechanisms are appropriate for that platform.

Summary

The Preferences API provides a nice interface for storing application preferences in a platform independent way. While the details about the storage of the data vary from platform to platform, the application code is as portable as any other Java code.

This article has been written as of J2SE v1.4 beta 2. Keep an eye out for changes that may be made to the API before the final release of v1.4.

Abhijit Belapurkar
高级技术架构师, Infosys Technologies Limited
2005 年 7 月 11 日

Abhijit Belapurkar 通过介绍 JCSP 开发高级主题，结束了由三部分组成的介绍适用于 Java 开发人员的 CSP 的系列文章，介绍的内容包括：JCSP 与 AOP 的相似性、JCSP 与 java.util.concurrent 的比较，以及用 JCSP 进行高级同步。

如果您从开始就一直阅读这个系列，那么到了现在，您应当同意 CSP 是一个值得研究的编程范式，而 JCSP 库则值得您添加到工具包中。在第 3 部分中，我只是给您提供了更多的研究 JCSP 理由。我将从讨论 CSP 的复合技术与面向方面编程（或 AOP） 的模块化技术之间的相似性开始。然后介绍 JCSP 的一些更高级的同步构造，并讨论适合应用它们的场景，还将更广泛地讨论使用 JCSP 进行多线程编程的好处，比如验证、维护以及可应用于分布式编程的一种方法。

我还要回答以下问题：如果已经采用了 java.util.concurrent 的并发性工具，那么是否还有学习 JCSP 的必要。（显然，我认为有这个必要！）

如果还没有阅读本文的 第 1 部分 和 第 2 部分，那么在继续我们的介绍之前，您可能需要这么做。

AOP 和 CSP
面向方面编程，即 AOP，是现在大多数 Java 开发人员都知道的一个术语。AOP 把系统当成方面或者关注点的的组合，而不是单纯地将系统看成是对象的组合。它试图通过把切入点组合成独立的模块，由模块代码解决一个特定关注，从而提高系统的模块性。这些模块可以用静态或动态编织技术编织在一起。

这个系列文章中已经介绍了很多内容，所以对您来说，应当很容易就可以看出 AOP 的概念 把模块编织在一起 与 CSP 的概念 组合进程网络 之间的相似性。两个技术之间的相似（绝对不是故意的！）主要是由于后者的复合性质。

一个基于安全性检测的示例被频繁地用作 AOP 的示例。在这个示例中，包含解决应用程序安全问题的代码的模块是以方面的形式编写和打包的；然后，这个方面将应用于整个应用程序中所有适当的业务对象。为了用 CSP 解决同样的问题，可以先从编写进程开始，编写一个包含业务对象的功能的进程，再编写另一个包含应用程序的安全性检测功能的进程。然后可以用 One2One 通道把两个进程连接起来。CSP 技术的优势与 AOP 技术类似：都可以将关注点分隔开。

不要错过本系列其余部分！ “适用于 Java 程序员的 CSP”是由三部分组成的介绍通信顺序进程（Communicating Sequential Processes —— CSP）的一个系列。CSP 是并发编程的一个范式，它承认了并发编程的复杂性，却没有把复杂性留给开发人员。请阅读本系列的其他部分： 第 2 部分：用 JCSP 进行并发编程 第 3 部分： JCSP 的高级主题

高级 JCSP 同步
通道不是进程间同步的惟一可用选择，也不总是最合适的选择。通道总是在以下两个进程间同步：阅读器和写入器。是否在运行多个阅读器/写入器并不重要，因为在 Any2One、One2Any 和 Any2Any 模型中，每种类型的进程都只有一个进程能够积极地参与到通道两边进行的会话中。

为了获得更高级的同步，即在多个进程之间的同步，JCSP 提供了 Barrier、Bucket 和 CREW 构造，还提供了一个叫作 ProcessManager 的类负责管理 CSProcess 实例。

Barrier 构造
barrier 是一个 JCSP 事件，可以充当多个进程之间的同步机制。每个 barrier 都能与多个进程相关联，任何在这个 barrier 上同步的进程都将被阻塞，直到其他进程已经同步为止。

必须用需要在 Barrier 类上同步的进程的数量来创建它，其中每个进程都运行在独立的线程中。在完成当前一轮工作之后，每个进程都调用 Barrier 实例的 sync() 方法，然后等候其他进程完成。

Barrier 内部
从内部来看，Barrier 包含一个成员变量，在创建 Barrier 对象时，这个成员变量被初始化为指定的进程总数。每当进程调用 sync() 方法时，这个变量就减一，并发出 wait() 调用。（您会想起已经介绍过的内容：Java 线程在能够调用 wait() 方法之前必须一直持有恰当的锁。在这里，由于将 Barrier 的 sync() 方法标记为同步的，所以 Barrier 实例本身充当着锁的作用。） 检测是在最后一个调用 sync() 的进程所在的线程上进行的。如果成员变量变成 0，则清楚地表明，所有进程已经完成了对 sync() 的调用 ，可以安全的发出 notifyAll() 了。这时，内部的计数器被重新设置回最初提供的进程总数，从而使得 Barrier 实例可以在下一轮同步中重复使用。

注意，Barrier 并没有把进程的身份和自身关联起来。所以，只有能得到 Barrier 对象，任何进程（除了要在 Barrier 上同步的进程之外）都能调用对象上的sync，从而将一个或多个合法进程排除在外。要想防止这个问题，可以对 Barrier 对象的可见性进行严格控制，只允许那些已经在 Barrier 上同步的进程集看到它。

似曾相识！
如果您认为 Barrier 工作方式的描述听起来很熟悉，那就对了。Parallel 构造自行控制运行多个 CSProcess 实例的基础就是 Barrier 构造的底层机制。

您会想起前面介绍过，在您调用 Parallel 实例上的 run 方法时，它创建了 (n-1) 个线程来运行前面 (n-1) 个 CSProcess 实例，然后在自己的线程中运行最后一个 CSProcess 实例。所有这些进程都在一个公共的 Barrier 实例上进行 sync，这个实例是在 Parallel 类的构造函数中创建的（而且通过负责运行 CSProcess 的每个 n-1 线程的构造函数，可以将实例传递给每个线程）。

Barrier 是一个比 Parallel 级别低的构造，因此，相应地也就带来了更多的复杂性，进程可以在任意时间从 Barrier 对象 enroll（登记）或 resign（退出）。例如，在一个工作进程运行时，它可能想与时钟同步（实际上是模拟时钟滴答） ，然后停下来休息一段时间（在此期间，它应当从 barrier 退出），接着再登记到 barrier，重新开始工作。

Bucket 构造
bucket 也是一个用于多进程的同步 barrier。bucket 构造和 barrier 构造之间的区别是：在前者中，所有进程都被阻塞，直到另外一个（外部）进程决定释放它们，而释放是通过“清空 bucket”进行的。

使用 Bucket 的方法只是创建一个 bucket 构造；然后，每个需要在该构造上面同步的进程都可以调用这个 bucket 的 fallInto() 方法。fallInto() 是一个同步的方法，它维护一个内部变量，用该变量来跟踪当前（等候）的进程数量（也就是说，每有一个调用 fallInto() 方法的进程，计数器变量就加 1。）在计数增加之后，调用进程执行 wait()，这导致调用进程受阻塞。当外部进程调用 Bucket 的（也是同步的） flush() 方法时，就发送一个 notifyAll() ，唤醒所有受阻塞的线程。阻塞进程的最后计数将从这个调用中输出。

Barrier 是确定性的，而 Bucket 是非确定性的。可以保证同步到 Barrier 的进程得到重新安排，从而得以执行（在一个时间周期后，受阻时间长短等于组中最慢的进程的执行时间），同步到 Bucket 的线程受阻塞的时间是不确定的，时间长短取决于清除进程何时决定发出释放这些进程的调用。

在必须按照先后顺序处理一组进程时，Barrier 很有用。这就是说，每个进行到步骤 n 的进程都不能进行步骤 n+1，直到同组中的其他所有进程都已经完成它们的步骤 n。在每个进程都要完成自己分配的任务并且停在 bucket 中，以表明自己可以进行下一步，这种情况下，Barrier 很有用。清除进程可以周期性地清除这个 bucket （可能用某些工作调度算法），从而释放目前在 bucket 中的所有进程，开始下一组任务。

CREW 构造
并发读/排它写（Concurrent-Read-Exclusive-Write）构造，即 CREW 锁，允许多个并行阅读器访问共享资源，条件是：（1）“读”访问不会修改资源；（2）之前没有写入器正在访问资源。当写入器正在访问资源时，它对资源拥有排它权限：不管是阅读器还是写入器，都不允许访问资源。

CREW 锁的使用是为了消除争用风险（因为竞争的阅读器/写入器进程之间任意的交叉），并且由于允许多个阅读器进程并行执行而提高了性能。是否真的会有性能提升则取决于以下因素：以读模式访问资源的频率与以写模式访问资源的频率的比较、读操作和写操作的时间，以及在同一时间在冲突模式下试图访问共享资源的进程数量。

请参阅 JCSP 发行版附带的 Javadoc（在 参考资料中），以获得 CREW 锁的内部实现的精彩描述。

管理 CSProcess 实例
在 第 2 部分 中，我介绍了如何用 Parallel 构造把较低级别的“构造块”进程组合成更高级别的进程网络。虽然对于许多编程场景，这些描述都是合适的，但在这篇文章的示例中，我假设已经知道了需要创建的所有进程的全部细节。但是对于某些应用程序来说，可能会发现有必要根据只能在运行时才能计算的某些条件，动态地创建一个或多个进程，而且还应当能够管理它们。

JCSP.net 我在本文示例中使用的 JCSP 库实际上使用的是同一 JVM 中运行的线程，当然，JVM 可能正运行在单处理器或多处理器机器上。倘若您对是否有可能组合对跨许多 JVM 的进程进行通信和同步的分层网络感到怀疑，那么答案是肯定的！JCSP 库的叫作 JCSP.net 的一个变体可以让您精确地做到这点。使用 JCSP.net 编程的最大好处是：跨物理网络运行的虚拟通道看起来差不多就像您在本文中已经遇到过的本地的、单一 JVM 的通道一样，虽然很显然会更复杂一些。请参阅 参考资料，学习关于 JCSP.net 可用的商业版本的更多内容。

JCSP 为这类场景提供了一个叫作 ProcessManager 的类。这个类接受 CSProcess 实例作为输入参数，允许用以下两种不同的方法之一启动进程。如果在ProcessManager 上调用 run() 方法，那么 ProcessManager 将启动托管的进程，然后等候进程终止（被管理的进程在 ProcessManager 的线程上运行，所以，后者的运行被阻挡，直到托管的进程完成为止）。另一个选项是调用 ProcessManager 上的 start() 方法，这使托管的进程在独立的线程中启动，在这种情况下，ProcessManager 自己仍然继续运行。

管理并行优先级
我在 第 2 部分 中提到：Parallel 构造并行地运行构造函数中传递给它的数组中包含的所有 CSProcess 实例。但是在某些情况下，可能必须要为这些进程赋予不同的优先级。JCSP 提供了一个叫作 PriParallel 的类，可以为传递给它的进程加上优先级。

受控制的进程的优先级是由进程在数组中的位置索引决定的。在数组中，放在前面的进程拥有更高的优先级。注意，JCSP 以底层线程的优先级机制实现进程的优先级；所以优先级实际的工作方式取决于底层的 JVM 实现。

越来越多的构造！
迄今为止讨论的构造（从第 2 部分开始到现在这里）都是 JCSP 库的核心构造。可以用它们来解决普通的和高级的并发性问题，现在应当可以让您开始编写所喜爱（也没有错误）的多线程程序了。当然，在 JCSP 库中，这些问题只是冰山之一角。请考虑以下有趣的构造的应用，您也可以自己对它们进行研究：

• BlackHoleChannel 实现 ChannelOutput 接口，包含一个空的 write() 方法。可以把任意数量的数据写入这个通道。如果想把现有进程用在不同的环境中，而 不 再使用某些输出，那么 BlackHoleChannel 类是最有用的。因为不能一直留着某个输出通道不处理（害怕造成死锁），所以最好的选择就是让进程在 BlackHoleChannel 的实例上产生输出，而 BlackHoleChannel 则有效地充当存放所生成数据的透明无底洞。
  
  
• Paraplex 是一个进程，它将其输入通道集上的多个对象流转化到单一输出通道。等到每个输入通道上都有一些可用输入之后（在输入到达的时候就接受，没有要求或规定特定的顺序），就可以将这些输入打包成数组（数据的尺寸与输入通道的数量相同），然后把数据通过输出通道发送为单一输出。如果需要用表格的形式表现某些数据，那么 Paraplex 可能会很方便。例如，假设有一个三列的表，每列均用数字填充。前两列用前面已经介绍过的 JCSP 进程生成的数字填充：NumbersInt 为第一列生成从 0 开始的自然数序列，SquaresInt 为第二列生成对应的平方序列。一个即插即用的叫作 FibonacciInt 的 JCSP 进程（随 JCSP 库一道立即可用）可以用来为第三列生成斐波纳契数系列。
  
  可以容易地用一个组合了三个输入通道的 ParaplexInt 实例来处理这三个列。每个输入通道都要附着在前面提到过的三个进程中的一个的实例上。然后，ParaplexInt 的单一输出通道向 CSProcess 传送数据，后者则接着读取带有三个元素的数组，并在适当的格式化表格中输出它们。
  
  
• Deparaplex 是一个类，它和 Paraplex 类相反， 它把数据从单一输入通道 分离 到一组输出通道。所以，Deparaplex 类可能读取一个数组对象（尺寸为 n），把数组中的每个元素逐个输出到它的 n 个输出通道上。然后，Deparaplex 进程会一直等候，直到它生成的每个元素都被写入的通道接受为止。

请参阅 JCSP 库的下载 （在 参考资料 中），以获得这结构造的更多文档，包括用例。

CSP 的好处
CSP 是基于成熟的数学理论的并发编程范式。因此，CSP 提供了丰富的设计模式和工具集，可以防范常见的多线程缺陷，例如争用风险、死锁、活动锁和资源耗尽。因为所有这些数学上的完善性都构建到了 JCSP 库中，所以可以直接用它根据规定好的指导原则来编写应用程序。 （也就是说，不必非得理解理论才能利用它；虽然清楚的了解会更有优势！）。因为存在正式的针对 Java 的 CSP 模型，所以可以分析并正式地验证用 JCSP 构造构建的任何多线程 Java 应用程序。

正如前面所指出的，AOP 的许多好处也适应于基于 CSP 的程序。基于 CSP 的程序的主要好处是关注点的分享。可以使用 CSP 作为程序的基础（例如通过 JCSP 库），还可以确保进程之间干净的解耦，因为它们只能通过通道进行交互，不能通过直接的方法调用进行交互。它还确保可以完美地把数据和应用程序逻辑封装在通道接口之后的进程之中。所有的副作用都被限制在进程的边界之内，编程实体之间的交互都是显式公开的。在基于 JCSP 的程序中，没有隐藏的互交 —— 在网络的每一级上，所有的管道都是可见的。

CSP 的第二个好处是它的复合性质。进程可以组合，从而构成更复杂的进程（复杂的进程还可以再组合起来构成更加复杂的进程），很容易地随时间推移进行修改和扩展。所以，基于 CSP 的应用程序设计特别简单并且易于理解，并且在进行维护的时候也非常健壮。CSP 的复合性质也促进了更好的重用；正如在第 2 部分的编程示例中看到的，可以用大量不同的设置使用一个 JCSP 进程，如果需要的话，可以将不希望的输出重定向到黑洞中。

用 CSP 进行并发编程的最后一个好处对于构建分布式系统的开发人员来说特别明显。在本文中，我描述了实现并发性的不同选项（运行在单一进程中的多线程、运行在一个器上的多进程和运行在多个处理器上的多进程）。通常，这些并发机制中的每一个都要求使用完全不同的执行机制、编程接口和设计范式。而一旦用 CSP 开发应用程序，那么可以在不影响（至少不非常显著）应用程序设计或代码的情况下决定在哪个平台上运行应用程序，比如，是在多线程平台上，还是单一处理器上的多进程平台上，亦或是在分布处理器上运行的多进程平台上。

JCSP 和 java.util.concurrent
大多数 Java 程序员都知道，java.util.concurrent 包是作为 J2SE 1.5 类库的标准组成部分引入的。因为JCSP 库出现的时间比这个包加入 Java 平台的时间早，所以您可能想知道是否需要两者都用，或者说您想知道，既然已经适应了 java.util.concurrent，为什么还要费力地学习 JCSP。

java.util.concurrent 包实际上是 Doug Lea 的一个很不错的流行的 util.concurrent 库的重新整理。这个包的设计目的是提供一个强壮的、高性能的标准化工具集，简化 Java 平台上的并发 —— 而这个目的已经实现了！毫无疑问！ 如果 java.util.concurrent 包中的工具适合您的应用程序，那么请使用它们，您将得到回报。

Java 中的通信线程 JCSP 不是 Java 平台上惟一可用的 CSP 实现。Java 中的通信线程（CTJ） 是另一个流行的 CSP 实现，由 Twente 大学的 Gerald Hilderink 和 Andy Bakkers 开发。请参阅 参考资料，以获得 JCSP 和 CTJ 的详细比较，比如说，比较它们的哲学、相似与不同、性能和使用场景。

但是，正如我希望的，本文中的讨论已经显示出：基于 CSP 的技术（通过 JCSP 库） 表现出的机制超出了 java.util.concurrent 的范围。可以把系统构建成通信进程的网络，并用它们组合成网中之网，实现这一点的范式既自然又简单。这不仅提高了编写多线程应用程序的体验，而且提高了产品 品质。用 JCSP 构建系统会产生干净的接口，很少有会造成产品不好维护和技术变化这类隐藏的副作用。正式的验证（即正式地推断应用程序的安全性和活动属性）对于安全敏感和高价值的财务应用程序来说也是强大的资产。

在许多情况下，这两个包不是互相排斥的：有些 JCSP 的核心要素非常有望会在 java.util.concurrent 提供的原子的低级机制顶部重新实现，新实现的开支可能要比目前使用的标准监视器机制的开支更少。

第 3 部分的结束语
在这篇介绍适用于 Java 程序员的 CSP 的系列文章中，介绍了许多基础知识。在 第 1 部分 中，我介绍了 Java 语言目前支持的多线程编程的构造。还解释了这些构造的起源，讨论了它们与 Java 平台多线程编程的 4 个常见缺陷（争用风险、死锁、活动锁和资源耗尽）之间的关系。在对第一部分进行总结时，我解释了为什么在任意、大型、复杂的多线程应用程序中，很难应用正式的理论消除编程 bug 或证明它们不存在。我推荐使用 CSP 作为这个困境的备选项。

在 第 2 部分 中，我介绍了 CSP 理论和它最流行的一个基于 Java 的实现 —— JCSP 库。我用了几个实例演示了基本的 JCSP 构造（ 例如进程、通道和警卫等）的使用。

在最后这篇文章中，我介绍了 JCSP 中的高级主题，其中包括它与面向方面编程的相似性，以及它与 Java 平台的其他一些并发编程包的比较。我还演示了一些用来解决更复杂的同步问题的 JCSP 构造，简要讨论了用 JCSP.net 包进行分布式编程的可能性。

我希望我已经表达得够清楚，用 JCSP 编写多线程 Java 应用程序有许多优势。下次您会发现，在您自己考虑（也可能要在躲避）多线程应用程序设计时，您可能想转而采用 JCSP 库。JCSP 提供了非常简化的并发编程方法，生成的程序既能对最常见的多线程应用程序开发缺陷进行验证，还易于理解、调试和长远维护它们。

致谢
非常感谢 Peter Welch 教授在我编写这个文章系列期间给予的鼓励。他在百忙之中抽出时间非常细致地审阅了草稿，并提供了许多宝贵的提高此系列文章的质量和准确性的建议。如果文章中还存在错误，那都是由于我的原因！我在文章中使用的示例基于或来自 JCSP 库的 javadoc 中提供的示例，以及 JCSP Web 站点上提供的 Powerpoint 演示文稿。这两个来源提供了需要探索的大量信息。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• Nicholas Lesiecki 撰写的“使用面向 Aspect 的编程改进模块性” （developerWorks，2002 年 1 月）第一次介绍了 AOP 的好处。
  
  
• 请参阅 developerWorks 上为期一年的 AOP@Work 系列，并从其中突出强调的部分学习更多关于方面编程的内容。
  
  
• 并发性专家 Brian Goetz 在“Java 理论与实践: JDK 5.0 中更灵活、更具可伸缩性的锁定机制”（developerWorks，2004 年 10 月）这篇文章中解释了 java.util.concurrent 的一些优势与不足。
  
  
• Goetz 在“Java 理论与实践: 流行的原子” （developerWorks，2004 年 11 月）这篇文章中解释了 java.util.concurrent 中原子类的重要性。
  
  
• C.A.R. Hoare 撰写的“Communicating Sequential Processes”把通信顺序进程的并行复合作为一个基本的编程结构化方法引入进来介绍（Communications of the ACM Archive，1978）。
  
  
• 可以免费获得 PDF 格式的 C.A.R. Hoare 撰写的 关于 CSP 的书籍。
  
  
• Bill Roscoe 撰写的 Theory and Practice of Concurrency （Prentice Hall, 1997） 是关于并发性和 CS 主题的最新书籍。
  
  
• 牛津大学计算机实验室负责的 CSP Archive 是学习更多关于 CSP 内容的好地方，除此之外，还有 WoTUG homepage。
  
  
• JCSP home page 由英国坎特伯雷市肯特大学负责。
  
  
• 可以从 QuickStone 科技获得 Network Edition of JCSP。
  
  
• FDR2 （故障偏差求精，Failures-Divergence Refinement）是面向基于 CSP 的程序的几个商业化模型检测工具之一。
  
  
• Gerald Hilderink、Jan Broenink 和 Andre Bakkers 在“Communicating Threads for Java”（IOS Press，1999）这篇论文中描述了 JCSP 库的一个替代品。
  
  
• Peter Welch 教授和其他人合著的论文“Using Java for Parallel Computing -- JCSP versus CTJ” （IOS Press, 2000）比较了 JCSP 和 CTJ。
  
  
• CSP 可以使用 Java 语言实现，也可以使用其他语言实现： C++CSP 是针对 C++ 的实现，而 J#.Net 是针对 .Net 的实现。
  
  
• Occam-pi 是一个语言平台，它打算用 pi-calculus 的移动特性来扩展 occam 语言的 CSP 想法。请从 occam-pi homepage 了解这个前沿研究的更多信息。
  
  
• 在学习 occam 时，您可能还想调查 occam 编程器的各种扩展。
  
  
• 在 developerWorks Java 技术专区 中可以找到 Java 编程各方面的文章。
  
  
• 请参阅 Developer Bookstore，以获得技术书籍的完整清单，其中包括数百本 Java 相关主题的书籍。
  
  
• 还请参阅 Java 技术专区教程页，以获得 developerWorks 上免费的、以 Java 为重点的教程。
  

Abhijit Belapurkar
高级技术架构师, Infosys Technologies Limited
2005 年 7 月 07 日

在这篇由三部分构成的面向 Java 程序员的通信顺序进程 （CSP）介绍的第二期中，Abhijit Belapurkar 将介绍如何使用基于 Java 的 JCSP 库来编写能够确保没有并发问题（例如争用风险、 死锁、活动锁、资源耗尽）的 Java 应用程序。

CSP 是对并发对象之间的复杂交互进行建模的范式。使用 CSP 的主要优势之一是：对程序每一阶段所包含对象的行为进行精确地指定和验证。CSP 的理论和实践对于并发设计和编程领域有深远的影响。它是 occam 这样的编程语言的基础，对其他语言（例如 Ada）的设计也有影响。就像在本文 第 1 部分 简要讨论过的，由于适合在 Java 平台上进行安全、优雅的多线程编程，所以 CSP 对 Java 开发人员也是无价的。

在我的这篇由三部分组成的 Java 平台 CSP 编程介绍的第 2 部分中，我把重点放在 CSP 理论和实践上，特别是它在 Java 语言中多线程程序设计的应用。我将从 CSP 理论的概述开始介绍，然后介绍基于 Java 的 JCSP 库实现，JCSP 的核心是 CSP 。

CSP 基础
CSP 的基本构造是进程和进程之间各种形式的通信。CSP 中的每件事都是进程，甚至（子）进程网络也是进程。但是，在进程之间没有直接交互 —— 所有交互都通过 CSP 的同步对象（例如各级进程订阅的通信通道和事件边界）实现的。

CSP 进程 与典型的 Java 对象不同：封装在进程组件中的数据 和 操纵数据的算法都是私有的。也就是说，进程没有对外可以调用的方法（除了启动进程必须调用的方法之外），算法只能在进程自己的控制线程内执行。如果把这种方法与 Java 语言中的方法调用进行对比，就可以立即看出 CSP 是如何消除显式锁定的需求的：

不要错过本系列的其余部分! “适用于 Java 程序员的 CSP”是对通信顺序进程（Communicating Sequential Processes —— CSP）进行介绍的由三部分组成的一个系列。CSP 是并发编程的一个范式，它承认了并发编程的复杂性，却并没有把复杂性留给开发人员。请参阅本系列的其他部分： 第 2 部分：用 JCSP 进行并发编程 第 3 部分： JCSP 的高级主题

在 Java 语言中，在对象上调用的方法总是在调用者的线程中运行。但也有一个特殊的控制线程是通过系统中的多个对象进行工作的。对于大部分情况来说，对象没有自己的生命 —— 它们只是在运行线程调用它们的方法时才存在。因此，不同的执行线程可以在同一时间试图调用同一对象的同一方法，就像 第 1 部分所讨论的那样。显然，这种情况在 CSP 中永远不会发生。

通信通道和进程网络
进程间通信最简单的机制就是通过通道读写数据。CSP 中基本的通道构造是同步的（synchronous） 和 点对点的（point-to-point）；也就是说，它不包含内部缓冲，并且把一个进程连接到另外一个进程。从这个基本通道开始，有可能构建多个阅读器/写入器通道（即一对多、多对一和多对多）。

CSP 中的进程构成了复杂系统的基本构造块 —— 一个进程可以同一个或多个其他进程连接起来（全都设置成并行的），从而构成一个进程网络。可以把这个网络本身想像成一个进程，这个进程还可以递归地与其他进程、它们自己的网络或者其他类似东西组合在一起，形成一个为了最好地解决手上问题而设计的复杂排列的金字塔。

如果单独考虑，那么进程仅仅是一个独立的串行程序，它只与外部 I/O 设备交互。这个程序本身并不需要考虑在 I/O 通道另一端的进程是否存在或对方的性质。

CSP 理论已经在许多基于 Java 的框架中实现了，包括面向 Java 的通信顺序进程（Communicating Sequential Processes for Java，JCSP） 库。

关于 CSP 的更多内容 本文提供了对 CSP 复杂主题的一般性介绍。如果对于深入理论底层的数学机制有兴趣，那么请参阅 C.A.R. Hoare 的原文章以及他针对这一主题撰写的书。要想获得 CSP 理论的最新发展（这些年已经做了更新），请参阅 Bill Roscoe 撰写的书。要想获得广泛的参考来源，请参考牛津大学计算机实验室和 WoTUG 主页的 CSP 归档。还请参阅 参考资料，以获取所有这些参考和更多内容的链接。

JCSP 库
JCSP 库由英国坎特伯雷市肯特大学的 Peter Welch 教授和 Paul Austin 开发（请参阅 参考资料）。对于本文余下的大部分内容来说，我会把重点放在 CSP 概念在 JCSP 中的实现方式上。因为 Java 语言没有提供对 CSP 构造的自带支持，所以 JCSP 库内部使用 Java 语言 实际 支持的、自带的并发构造，例如 synchronized、wait 和 notify。为了帮助您正确地理解 JCSP 的工作方式，我将从这些 Java 构造的角度对 JCSP 库中某些类的内部实现进行了解释。

注意，后续章节中的示例基于或来自 JCSP 库的 Javadoc 文档，或者基于可以在 JCSP 主页上得到的演示文稿。

JCSP 中的进程
在 JCSP 中，进程实际上就是实现了 CSProcess 接口的类。清单 1 显示了这个接口：

package jcsp.lang;

public interface CSProcess
{
    public void run();
}

注意，CSProcess 接口看起来就像 Java 语言的 Runnable 接口，而且它也充当着类似的角色。虽然 JCSP 目前是用标准 Java API 实现的，但是并不需要这样，而且在未来可能真的不需要这样。出于这个原因，在 JCSP 中没有直接使用 Runnable 接口。

验证 JCSP 程序 Peter Welch 教授和其他人构建了一个正式的 CSP 模型，从而可以用 CSP 术语对多线程 Java 程序进行分析，并验证程序是否会造成导致争用风险、死锁和资源耗尽的 bug。因为 JCSP 库使用模型底部的监视器机制 （即 synchronized()、wait()、notify() 和 notifyAll()） ，所以基于 JCSP 的应用程序可以用各种软件工程工具进行验证，其中包括一些商业化支持的工具。请参阅 参考资料，学习关于 FDR2 的内容，这是一个针对基于 CSP 的程序的模型检测工具。

JCSP 定义了两个接口用于从通道读取对象和向通道写入对象。从通道读取对象的接口叫作 ChannelInput ，它只有一个方法，叫作 read()。如果进程调用一个实现 ChannelInput 接口的对象的这个方法，那么进程会阻塞，直到在通道另一端的进程实际向通道写入了一个对象。 一旦在通道上有对象可用，对象就被返回给调用进程。类似地，ChannelOutput 接口也只有一个方法，叫作 write(Object o)。如果进程调用 一个实现 ChannelOutput 接口的对象的这个方法，进程也会阻塞，直到通道接受对象。正如前面提到过的，最简单的通道类型没有缓冲，所以它在另一端（读取）的进程调用 read() 之前不会接受对象。

从现在开始，我将使用代码示例来演示这些和其他 JCSP 构造如何工作。在清单 2 中，可以看到一个非常简单的进程，它输出 1 到 100 之间的所有偶数：

import jcsp.lang.*;

public class SendEvenIntsProcess implements CSProcess 
{
    private ChannelOutput out;

    public SendEvenIntsProcess(ChannelOutput out)
    {
      this.out = out;
    }

    public void run()
    {
      for (int i = 2; i <= 100; i = i + 2)
      {
        out.write (new Integer (i));
      }
    }
}

与每一个写进程对应，必须有一个读进程。如果不存在这样的进程，则会造成 SendEvenIntsProcess 在 ChannelOutput 对象的 out 进行第一次写操作之后立即无限期阻塞。清单 3 演示了一个简单的读进程，该进程与清单 2 介绍的写进程对应：

import jcsp.lang.*;

public class ReadEvenIntsProcess implements CSProcess
{
    private ChannelInput in;
    public ReadEvenIntsProcess(ChannelInput in)
    {
      this.in = in;
    }

    public void run()
    {
      while (true)
      {
        Integer d = (Integer)in.read();
        System.out.println("Read: " + d.intValue());
      }
    }
}

JCSP 中的通道
到目前为止，我只有两个独立的进程。下一步就是使用一个用作共享同步机制的公共通道把它们联系在一起，然后从中剔除一个进程。channel 接口是 JCSP 的 ChannelInput 和 ChannelOutput 接口的子接口，是读取和写入对象的公共接口。这个接口有许多可能的实现，就像下面描述的一样：

• 类 One2OneChannel，顾名思义，实现了“单一写入器/单一阅读器”类型的通道。
  
  
• 类 One2AnyChannel 实现了“单一写入器/多阅读器”对象通道。（注意，这不是广播机制，实际上，为了从通道读取对象，多个阅读器要进行相互竞争；在指定时间只有一个阅读器能使用通道和写入器进行沟通。）
  
  
• 类 Any2OneChannel 实现了 “多写入器/单一阅读器”对象通道。同上面的情况一样，写入进程彼此竞争使用通道。在指定时间，只有阅读器和众多写入器中的一个在实际使用通道。
  
  
• 类 Any2AnyChannel 实现了“多写入器/多阅读器”对象通道。读取进程彼此竞争使用的通道，写入进程也一样。在指定时间只有一个阅读器和一个写入器在实际使用通道。

在清单 3 的示例中，我只有一个写入器进程和一个阅读器进程，所以 One2OneChannel 类就足够了。驱动器程序的示例代码如清单 4 所示：

import jcsp.lang.*;

public class DriverProgram
{
    public static void main(String[] args)
    {
      One2OneChannel chan = new One2OneChannel();
      new Parallel
      (
        new CSProcess[]
	    {
	      new SendEvenIntsProcess (chan),
	      new ReadEvenIntsProcess (chan)
	    }
      ).run ();
    }
}

正如代码表示的，我首先实例化一个新的 One2OneChannel 对象，然后把它传递给 SendEvenIntsProcess 和 ReadEventIntsProcess 进程的构造函数。这样做是因为 One2OneChannel 同时实现了两个接口 —— ChannelInput 和 ChannelOutput。

通道内部
因为通道在 JCSP 中是重要的概念，所以在进行下一步之前，要确定您确实理解了它们的工作方式。正如我在前面提到的，通道在默认情况下是非缓冲的，但是也可以把它们变成缓冲的。实现方式是：通道本身并不处理缓冲特性，而是把这个责任委托给其他类，其他类必须实现叫作 ChannelDataStore 的接口。JCSP 为这个接口提供了多个内置实现，其中包括以下几个实现：

• ZeroBuffer，对应默认的非缓冲特性。
  
  
• Buffer，为与之相关联的通道提供了一个阻塞的先进先出的缓冲语义。
  
  
• InfiniteBuffer，也提供先进先出语义，但是如果缓冲为空，那么可以将阅读器阻塞。写入器永远不会阻塞，因为缓冲可以无限扩展，或者至少到了底层内存系统设置的限制为止。

通道实战
考虑一个实际使用的通道示例。当我创建了如清单 4 所示的 One2OneChannel 实例时，我把它内部的 ChannelDatasource 设置成 ZeroBuffer 的一个新实例。ZeroBuffer 只能保存一个对象（或整数）。它有一个内部状态变量，该变量的起始值为 EMPTY，只要放进一个对象，该变量的值就变成 FULL 了。

当 SendEvenIntsProcess 进程在它的 out 通道上进行 write 操作时，会发生什么呢？One2OneChannel 类的 write() 方法是一个 synchronized() 方法。因此，发送方进程运行所在的线程（很快就会看到发送方进程和阅读器进程运行在独立的线程中）就会得到与这个通道实例相关联的监视器锁，并继续处理方法。在该方法中，业务的第一个顺序就是调用内部持有的 ZeroBuffer 实例的 put 方法，把对象（或者在这个示例中是整数）写到 ZeroBuffer 实例。这样就把缓冲的状态变成 FULL。这时，调用线程调用 wait，造成线程进入监视器的 等候集，后面进行的操作是释放监视器锁和阻塞线程。

稍后，阅读器线程调用通道上的 read 操作（这也是一个同步的方法，所以阅读器线程在继续处理之前必须得到监视器锁）。因为内部缓冲的状态是 FULL，所以可用数据将被返回，并发出一个 notify()。notify() 唤醒发送方线程，然后发送方线程退出监视器等候集，并重新申请监视器锁。

在反过来的场景中，如果阅读器线程调用通道上的 read 方法时，通道的内部缓冲状态是 EMPTY，那么阅读器线程就不得不 wait，在这种情况下，发送方线程要在把数据对象写入内部缓冲之后通知阅读器线程。

Parallel 构造
在 清单 4 中，您可能已经注意到驱动器程序引入了一个新类，叫作 Parallel。Parallel 类是由 JCSP 以预定义 CSProcess 的形式提供的，它接受一组独立的 CSProcess 实例，并“平行地”运行它们 （除了最后一个之外，所有进程都在独立的线程中运行；最后一个进程由 Parallel 对象在自己的控制线程中运行）。 Parallel 进程的 run 方法只有在所有的部件进程终止的时候才终止。所以 Parallel 进程是一种把多个独立进程组织起来的机制，它用通道（在驱动器程序中示例中）作为“线”把进程连在一起。

了解 Parallel 构造的另一个途径是说：它可以把小的、简单的组件组合成更高层次的进程。实际上，Parallel 允许通过迭代把前面迭代中创建的组件与新的组件连接起来，创建出任意复杂程度的完全连接的进程网络。生成的进程网络可以像一个 CSProcess 对象一样公开和使用。

Parallel 示例
JCSP 库提供了一组即插即用的组件，不过仅仅是出于教育的目的，正好适合我的目的：进入其中几个的内部实现，可以很好的表现如何在 JCSP 中组合成网络化的并发进程。我用下面的示例进程来表现 JCSP 中 Parallel 构造的内部工作方式：

• PlusInt 在两个输入流中都接受整数，把整数加在一起，然后把结果输出到输出流。
  
  
• Delta2Int 平行地把到达它的输入流的每个整数广播到它的两个输出通道。
  
  
• PrefixInt 在它的整数输入流之前加上一个（用户配置的）整数。（也就是说，在这个进程的输出通道上有整数可用之前，第一个输出是预先配置的整数。后面的输出才是从输入流得到的整数。）
  
  
• IntegrateInt 是一个用 Parallel 构造组合了前三个进程的进程。它的功能是输出来自它的输入通道的整数的中间汇总值。

IntegrateInt 类的 run 方法如清单 5 所示：

import jcsp.lang.*;

public class IntegrateInt implements CSProcess 
{
  private final ChannelInputInt in;
  private final ChannelOutputInt out;

  public IntegrateInt (ChannelInputInt in, ChannelOutputInt out)
  {
    this.in = in;
    this.out = out;
  }

  public void run()
  {
      One2OneChannelInt a = new One2OneChannelInt ();
      One2OneChannelInt b = new One2OneChannelInt ();
      One2OneChannelInt c = new One2OneChannelInt ();

      new Parallel 
      (
        new CSProcess[]
        {
          new PlusInt (in, c, a),
          new Delta2Int (a, out, b),
          new PrefixInt (0, b, c)
        }
      ).run ();
  }
}

注意，与 请单 4 中使用的通道相比，这个示例中使用了不同种类的通道。 IntegrateInt 类使用 ChannelInputInt 和 ChannelOutputInt 通道，顾名思义，可以用它们传递 int 类型的整数。相比之下，清单 4 中的驱动器程序使用了 ChannelInput 和 ChannelOutput，它们是 对象 通道，可以用来在通道中从发送方给接收方发送任意对象。出于这个原因，在清单 4 中传递 int 值之前，我不得不把 int 值包装成 Integer 对象。

在清单 5 中，还需要注意观察什么呢？实际上，PrefixInt 进程的第一个输出是 0，它是通过 PlusInt 进程添加到输入通道到达的第一个整数上的。这个结果被写入通道 a，它构成了 Delta2Int 进程的输入通道。Delta2Int 进程把整数结果写到 out （进程的整体输出通道）并把它发送到 PrefixInt 进程。然后 PrefixInt 进程把整数作为输入发送给 PlusInt 进程，并添加到流中的第二个整数，如此类推。

IntegrateInt 进程组成的图示如图 1 所示：

图 1. IntegrateInt 进程

网络中的网络
IntegrateInt 进程就是这样由三个小进程组成，它本身可以当作一个复合进程来用。JCSP 库提供了一个叫作 SquaresInt 的进程，顾名思义，它生成一个整数流，整数流是自然数 （1、2、3、4，等等）的平方。这个进程的代码如清单 6 所示：

public class SquaresInt implements CSProcess 
{
  private final ChannelOutputInt out;

  public SquaresInt (ChannelOutputInt out)
  {
    this.out = out;
  }

  public void run()
  {
      One2OneChannelInt a = new One2OneChannelInt ();
      One2OneChannelInt b = new One2OneChannelInt ();

      new Parallel 
      (
        new CSProcess[]
        {
          new NumbersInt (a),
          new IntegrateInt (a, b),
          new PairsInt (b, out)
        }
      ).run ();
  }
}

我可以肯定您已经注意到清单 6 显示的两个新进程。NumbersInt 是一个内置进程，它只是在其输出通道中输出从 0 开始的自然数。PairsInt 进程则把连续的一对输入值相加并输出结果。这两个新进程和 IntegrateInt 一起构成了 SquaresInt 进程，如图 2 中的图表所示：

图 2. SquaresInt 进程

SquaresInt 的工作方式
在进入下一部分之前，先来考虑 SquaresInt 进程的内部工作方式。在下面可以看到 SquaresInt 内部每个通道上的交通流向：

Channel "a":	[0, 1, 2, 3, 4, 5, 6, 7, 8, ...ad infinitum]
Channel "b":	[0, 1, 3, 6, 10, 15, 21, 28, 36, ...ad infinitum]
Channel "out":	[1, 4, 9, 16, 25, 36, 49, 64, 81 ...ad infinitum]

您有没有看这样的模式：写入通道 a 的整数造成它们也被写入通道 b，因此也写到通道 out？在第一次“滴答”当中，NumbersInt 进程把整数 0 写入通道 a。IntegrateInt 进程也把整数 0 （是当前汇总的值）写入通道 b。PairsInt 进程在这次滴答中什么都不产生，因为它需要处理两个输入。在第二次滴答中，NumbersInt 进程在它的输出通道上写入整数 1。这造成 IntegrateInt 进程把汇总值修改成 0+1=1，所以把整数 1 写入通道 b。

这时, PairsInt 有了两个整数输入可以处理 —— 整数 0 来自前一次滴答，整数 1 来自当前滴答。它把它们加在一起，并把输出 0+1=1 写到通道 out。请注意 1 是 1 的平方，所以我们现在可能是在正确的轨道上。继续把示例前进到下一个（第三个）滴答，NumbersInt 进程把把整数 2 写入通道 a。这使 IntegrateInt 进程把汇总值更新为 1 （前一个汇总值） + 2 （新值） = 3 并把这个整数写入通道 b。

PairsInt 进程看到最后两个整数是什么？它们是 1 （在前一次滴答期间） 和 3 （在当前滴答期间）。所以，进程把这两个整数加在一起，并把 1+3=4 写入通道 out。您会注意到 4 是 2 的平方，这意味着 SquaresInt 工作起来就像它应当工作的那样。实际上，应当继续运行这个程序到任意数量的滴答，这样就可以验证写入通道 out 的整数总是在序列中的下一个整数的平方。我在下一节精确地这一操作。

数学问题
就在您纳闷的时候，我想解释一下生成平方值的数学基础。假设在 NumbersInt 进程已经把整数输出到某个 n-1 的时候，您偷看到了箱子内部。IntegrateInt 进程最后生成（而且通过共享通道 b 放到 PairsInt 进程）的中间汇总会是 [1+2+3+...+(n-1)] = (n-1)(n-2)/2。

在下一次滴答期间，NumbersInt 会输出 n，这造成 IntegrateInt 进程的中间汇总增长为 (1+2+3+...+n) = n(n-1)/2。然后这个汇总会通过共享通道 b 传给 PairsInt 进程。 PairsInt 会把这两个数加在一起，生成 [(n-1)(n-2)/2 + n(n-1)/2] = [(n-2) + n](n-1)/2 = (2n-2)(n-1)/2 = (n-1)exp2。

接下来，NumbersInt 进程会产生(n+1)。与之对应，IntegrateInt 进程会把 n(n+1)/2 送到 PairsInt 进程。然后 PairsInt 会生成 [n(n-1)/2 + n(n+1)/2] = nexp2。针对所有的 n 对这进行通用化，就会按照期望的那样产生全部平方。

JCSP 中的确定性
以上示例演示了 CSP 的复合语言 —— 即如何用 Parallel 构造把细致的无状态的组件组成分层的网络。所有这类相互通信的平行进程的分层网络的卖点就是：它们是完全确定的。在这个上下文环境中 确定 意味着什么呢？它意味着这类分层网络的输出只取决于提供给它的输入，而不用考虑网络运行的运行时环境（JVM）的特性。也就是说，进程网络独立于 JVM 的调度策略，也独立于它所分布的多处理器。（我在这里假设的是个单一节点，但是，没有什么固有的东西会防碍把这个讨论引入物理上分布在多个节点上而在进程之间通过线路进行通信的进程网络上。）

确定性会是工具包中的强大工具，因为它可以让您清晰地推断出程序的行为，不必担心运行时环境对它可能产生的影响。同时，确定性不是并发性编程惟一可能的技术或必需的技术。因为下一个（也是最后一个）实例将显示，非确定性在 JSP 中也是同样强大的实用概念。

JCSP 中的非确定性
非确定是许多真实的应用程序的因子，在这些应用程序，可见的输出是某个功能或者事件发生的顺序。换句话说，当结果取决于设计的调度，而 不是 取决于事件时，就是非确定性在并发应用程序中发挥作用的地方了。您将会看到，JCSP 显式地处理这类问题。

例如，假设一个进程对于 下面要做什么 有许多备选项，每个备选项都有一个与之关联的 警卫（guard），警卫必须处于“就绪（ready）”状态，这样才能让备选项得以考虑。进程可以从可用的备选项（也就是就绪的）中选择一个选项；选择本身可能基于不同的策略，可能是任意选择、最高优先级选择或者公平选择。

事件选择策略
在 JCSP 的特定上下文中，提供了一个叫作 Guard 的抽象类，竞争进程选择的事件必须继续它。进程本身使用另一个预先提供的类，叫作 Alternative，这些警卫对象必须以对象数组的形式传递给它的构造函数。Alternative 类为三种事件选择策略提供了方法。

Alternative 类的 select() 方法对应着 任意选择 策略。select() 方法调用一直受阻塞，直到一个或多个警卫就绪为止（请记住，所有竞争的警卫对于 Alternative 类来说都是已知的）。其中一个就绪的警卫被随机选中，它的索引（在传递进去的警卫数组中）也被返回。

priSelect() 方法对应着 最高优先级 策略。也就是说，如果不止一个警卫就绪，则返回索引值最低的那个；这里面的假设是：在数组中传递给 Alternative 构造函数的警卫已经按照优先级顺序进行降序排序了。

最后，方法 fairSelect 是在多个就绪警卫中进行 公平 选择：在这个方法的连续调用中，在其他就绪而且可用的警卫没被选中之前，不会有某个就绪的警卫被选中两次。所以，如果警卫的总数是 n，那么在最坏的情况下，就绪的警卫没获得选中的次数不会连续超过 n 次。

如果进程不关心如何选择多个就绪警卫，那么任意选择策略最合适；如果进程想保证没有资源耗尽或者最差服务次数，例如在实时系统中，那么任意选择就不太适用了。在前面的情况下，推荐使用 fairSelect 方法，而在后面的情况下，用 priSelect() 方法最好。

警卫类型
大体来说，JCSP 提供了三类警卫：

• 通道警卫 总是对应着进程等候从中读取数据的通道。也就是说，只有在通道另一端的进程已经输出数据，而该数据还没有被进程输入的时候，警卫才就绪。
  
  
• 计时器警卫 总是和设置（绝对）超时对应。也就是说，如果超时，则计时器警卫就会就绪。
  
  
• 跳过警卫 总是就绪。

JCSP 中的通道警卫 可以是以下类型：AltingChannelInput/AltingChannelInputInt，只要在对应的通道中有了对象或整数数据，则这两个通道将就绪；或者 AltingChannelAccept，如果在通道中出现不可接受的“CALL”（这一点后面有更多介绍），则通道就会就绪。这些都是抽象类，它们拥有 One2One 和 Any2One 类型通道形式的具体实现。JCSP 中的计时器 警卫属于 CSTimer 类型，而 跳过警卫 则是以 Skip 类的形式提供的。

运作中的警卫
我用一个简单的示例，演示如何用 JCSP 警卫实现并发应用程序中的非确定性，借此总结对 JCSP 的介绍。假设您必须开发一个乘法（或者 倍增） 设计，读取的整数在输出通道以固定速率到达，可以用某个乘数乘以它们，然后把它们写入其输出通道。设备可以用一个初始乘数开始，但是这个乘数每 5 秒钟自动加倍。

这个故事中介绍的方法是这样的：系统中存在着第二个控制器进程，它能通过专用通道向设备发送 suspend operation 信号。这使设备中止自身，并把乘数的当前值通过第二个通道发送给控制器。

在中止的时候，设备只应当允许全部进入的整数不经变化地通过它的输出通道。控制器进程 —— 可能在用设备发送给它的乘数做了某些计算中的一种 —— 通过专用通道把一个新乘数发送回设备。（请注意：只要设备处于 中止 状态，就会被迫接受这个乘数。）

更新过的乘数插入到设备，并充当设备的唤醒信号。设备现在继续执行它的放大操作，用新更新的乘数乘上输入的整数。计时器这时也重置，所以新的乘数也在 5 秒之后被设置成加倍数值，如此类推。

图 3 中的图表说明了这个放大设备：

图 3. 放大设备

ScaleInt 进程
放大设备的源代码在清单 7 中显示。这个示例中的非确定性是因为：output 的值基于 in 和 inject 流的值（同时还基于这些值到达的顺序）。

import jcsp.lang.*;
import jcsp.plugNplay.ints.*;

public class ScaleInt implements CSProcess
{
  private int s;
  private final ChannelOutputInt out, factor;
  private final AltingChannelInputInt in, suspend, inject;

  public ScaleInt (int s, AltingChannelInputInt suspend, AltingChannelInputInt in, 
    ChannelOutputInt factor, AltingChannelInputInt inject, ChannelOutputInt out)
  {
    this.s = s;
	this.in = in;
	this.out = out;
	this.suspend = suspend;
	this.factor = factor;
	this.inject = inject;
  }

  public void run()
  {
	final long second = 1000;               // Java timings are in millisecs
	final long doubleInterval = 5*second;
	final CSTimer timer = new CSTimer ();

	final Alternative normalAlt = new Alternative (new Guard[] {suspend, timer, in});
	
	final int NORMAL_SUSPEND=0, NORMAL_TIMER=1, NORMAL_IN = 2;

	final Alternative suspendedAlt = new Alternative (new Guard[] {inject, in});
	
	final int SUSPENDED_INJECT=0, SUSPENDED_IN = 1;
	
	long timeout = timer.read () + doubleInterval;
	timer.setAlarm (timeout);

	while (true)
	{
	  switch (normalAlt.priSelect ())
	  {
		case NORMAL_SUSPEND:
		  suspend.read ();              // don't care what's sent
		  factor.write (s);             // reply with the crucial information
		  boolean suspended = true;
		  while (suspended)
		  {
		    switch (suspendedAlt.priSelect ())
			{
			  case SUSPENDED_INJECT:    // this is the resume signal as well
			    s = inject.read ();     // get the new scaling factor
				suspended = false;      // and resume normal operations
				timeout = timer.read () + doubleInterval;
				timer.setAlarm (timeout);
				break;
			  case SUSPENDED_IN:
			    out.write (in.read ());
				break;
			}
		  }
		  break;
		case NORMAL_TIMER:
		  timeout = timer.read () + doubleInterval;
		  timer.setAlarm (timeout);
		  s = s*2;
		  break;
		case NORMAL_IN:
		  out.write (s * in.read ());
		  break;
	  }
    }
  }
}

import jcsp.lang.*;
import jcsp.plugNplay.ints.*;

public class Controller implements CSProcess
{
  private long interval;
  private final ChannelOutputInt suspend, inject;
  private final ChannelInputInt factor;

  public Controller (long interval, ChannelOutputInt suspend, ChannelOutputInt inject, 
    ChannelInputInt factor)
  { 
    this.interval = interval;
    this.suspend = suspend;
    this.inject = inject;
    this.factor = factor;
  }

  public void run ()
  {
	int currFactor = 0;
	final CSTimer tim = new CSTimer ();
	long timeout = tim.read ();
	while (true)
	{
	  timeout += interval;
	  tim.after (timeout);        // blocks until timeout reached
	  suspend.write (0);          // suspend signal (value irrelevant)
	  currFactor = factor.read ();			
	  currFactor ++;              // compute new factor
	  inject.write (currFactor);  // inject new factor
	}
  }
}

import jcsp.lang.*;
import jcsp.plugNplay.ints.*;

public class DriverProgram
{
  public static void main(String args[])
  {
	try
	{
	  final One2OneChannelInt temp = new One2OneChannelInt ();
	  final One2OneChannelInt in = new One2OneChannelInt ();
	  final One2OneChannelInt suspend = new One2OneChannelInt ();
	  final One2OneChannelInt factor = new One2OneChannelInt ();
	  final One2OneChannelInt inject = new One2OneChannelInt ();
	  final One2OneChannelInt out = new One2OneChannelInt ();
		
	  new Parallel
	  (
		new CSProcess[]
		{
		  new NumbersInt (temp),
		  new FixedDelayInt (1000, temp, in),
		  new ScaleInt (2, suspend, in, factor, inject, out),
		  new Controller (6000, suspend, inject, factor),
		  new PrinterInt (out, "--> ", "\n")
		}
	  ).run ();
	}
	catch (Exception e)
	{
		e.printStackTrace();
	}
  }
}

上面的类 ScaleInt 对应着放大设备。正如前面提到的，这个类必须实现 CSProcess 接口。因为上面的代码演示了许多概念，所以我将逐个讨论它的不同方面。

两个备选项
在 ScaleInt 类中，我们感兴趣的第一个方法是 run()。在 run() 方法中，要做的第一件事是创建 Alternative 类的两个实例，每个都有一组不同的 Guard 对象。

第一个 Alternative 实例由变量 normalAlt 表示，它是为设备正常操作的时候使用的。与之关联的警卫列表如下所示：

• suspend 是 One2OneChannelInt 的实例。正如前面提到过的，One2OneChannelInt 实现了单一阅读器/写入器整数通道，通道是零缓冲、完全同步的。这是控制器进程向设备发送中止信号的通道。
  
  
• timer 是 CSTimer 的实例，它被设置成每 5 秒触发一次，每次触发时，设备会把乘数的当前值加倍。
  
  
• in 是 One2OneChannelInt 的实例，设备通过它接收输入的整数。

第二个 Alternative 实例由 suspendedAlt 表示，它是供设备在已经被 Controller 中止的情况下使用的。与之关联的警卫如下如示：

• inject 是 One2OneChannelInt 的实例，由控制器进程使用，用来向设备发送新的乘数（也充当唤醒信号）。
  
  
• in 是前面已经看到的 One2OneChannelInt 相同的实例；设备通过这个通道接收输入整数。

两个 Alternative 实例被用在不同的情况下等候警卫就绪，列表的顺序是隐式的优先级顺序。例如，如果 normalAlt 的 suspend 和 timer 警卫恰好同时就绪，那么和 suspend 警卫对应的事件首先被处理。

警卫就绪
下一个我们感兴趣的是在每个警卫就绪的时候，发生了什么。我首先研究 normalSelect，假设设备操作正常（也就是说，还没有被中止）：

• 如果控制器向设备发送了 suspend 信号，那么这个事件以最高优先级得到处理。作为响应，设备把乘数的当前值通过叫作 factor 的通道发送给控制器。然后将叫作 suspended 的内部标志设置为 true，然后进入循环，等候别人发送信号，以继续其操作。在循环内部，设备调用第二个 Alternative 实例上的 priSelect() 方法 （suspendedAlt）。
  
  这个 Alternative 实例包含两个警卫：第一个表示控制器向设备发送乘数的事件，第二个表示整数到达设备的输入通道。在前一种情况下，设备用从 inject 通道读取的值来更新乘数（保存在变量 s 中），并将 suspended 标志设置回 false （这样就保证了在下一次迭代时可以退出内部循环），用当前计时器的值作为基值重新设置闹钟。在后一种情况下，设备只是从它的输入通道读取整数，并把整数写入输出通道（也就是说，在设备中止时，不许使用乘数的要求）。
  
  
• 具有下一个优先级得到处理的事件是闹钟到期事件。这造成设备把当前乘数加倍，用当前计时器的值作为基值重新设置闹钟，然后返回，继续等候下一个事件。
  
  
• 第三个可能是事件是从设备的输入通道接收整数的事件。与之对应的是，设备读取整数，用当前乘数 s 乘上它，并将结果写入设备的输出通道。

Controller 类
下一个要考虑的类是 Controller 类。请记住，控制器类的任务是周期性地（大概是基于复杂的计算）向设备进程插入乘数值。在这个示例中，周期基础只是一个计时器，该计时器按照规律的、配置好的间隔到期。每次到期时，控制器就在 suspend 上写一个 0（也就是说，它将中止设备），并在叫作 factor 的输入通道上读取当前的乘数。

这时，控制器只是把这个值加一，然后通过一对一通道 （叫作 inject，专门用于为这个目的） 将它插回设备。这就通知设备继续工作的方式，这时计时器被重新设置成在适当间隔后到期。

DriverProgram 类
最后剩下的类是驱动器类 DriverProgram。这个类创建适当的通道和 CSProcess 实例数组。它用 JCSP 提供的类 NumbersInt 生成一系列自然数，通过temp 通道传递给另一个叫作 FixedDelayInt 的内置类。顾名思义，FixedDelayInt 将来自其输入通道的值在固定延迟（在示例代码中，该延迟是 1 秒）之后发送到它的输出通道。

这个自然数的流每隔一秒就被发送到 ScaleInt 进程的 in 通道。ScaleInt 进程的 out 通道的输出传递给 JCSP 提供的 PrinterInt 进程，然后该进程再接着把整数值输出到 System.out。

第 2 部分的结束语
在这个由三部分组成的介绍适用于 Java 程序员的 CSP 的系列文章的第 2 部分中，我解释并演示了并发编程中的 CSP 理论。然后是对 CSP 构造的概述，其中介绍了最流行的基于 Java 的 CSP 库 —— JCSP。由于 Java 语言没有对 CSP 构造提供自带的支持，所以 JCSP 库内部采 Java 支持 的自带构造，例如 synchronized()、wait() 和 notify()。为了帮助您正确地理解 JCSP 是如何工作的，我从 Java 构造的角度解释了一些 JCSP 类库的内部实现，然后在几个实际示例中演示了它们的用法。

这里所进行的讨论可以作为本系列最后一篇文章的绝好基础。在最后一篇文章中，我将解释 CSP 和 AOP 的相似性，并简要地对 CSP 解决并发性的方法和新的 java.util.concurrent 包解决并发性的方法进行比较，还将介绍许多用 JCSP 进行高级同步 的技术。

致谢
非常感谢 Peter Welch 教授在我编写这个文章系列期间给予的鼓励。他在百忙之中抽出时间非常细致地审阅了草稿，并提供了许多宝贵的提高系列质量和准确性的建议。文章中如果还存在错误的话，那都是由于我的原因！我在文章中使用的示例基于或来自 JCSP 库的 javadoc 中提供的示例，以及 JCSP Web 站点上提供的 Powerpoint 演示文稿。这两个来源提供了需要探索的大量信息。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• Brian Goetz 编写的由三部分组成的 “Threading lightly”是解决 Java 平台上同步问题的巧妙而系统的方法。（developerWorks，2001 年 7 月）
  
  
• Allen Holub 撰写的“如果我是国王：关于解决 Java编程语言线程问题的建议” （developerWorks，2000 年 10 月）是一篇启蒙性的、至今仍有意义的、关于 Java 平台多线程编程错误的概述。
  
  
• C.A.R. Hoare 开创性的论文“Communicating Sequential Processes”把通信顺序进程的并行组成作为一种基本的编程结构化方法提了出来（Communications of the ACM Archive，1978）。
  
  
• 可以免费获得 PDF 格式的 C.A.R. Hoare 撰写的 关于 CSP 的书籍。
  
  
• Bill Roscoe 撰写的 Theory and Practice of Concurrency （Prentice Hall, 1997） 是最关于并发性和 CS 主题的最新书籍。
  
  
• 牛津大学计算机实验室负责的 CSP Archive 是学习更多关于 CSP 内容的好地方，除此之外，还有 WoTUG homepage。
  
  
• Peter Welch 教授和 Jeremy Martin 合著的“Formal Analysis of Concurrent Java Systems” （IOS Press, 2000） 是在 Java 语言中实践 CSP 的良好起点。
  
  
• JCSP homepage 由英国坎特伯雷市肯特大学负责。
  
  
• FDR2 （故障偏差求精，Failures-Divergence Refinement） 是面向基于 CSP 的程序的几个商业化模型检测工具之一。
  
  
• CSP 的实现可用于 Java 语言之外的其他语言：C++CSP 是针对 C++ 的实现，而 J#.Net 是针对 .Net 的实现。
  
  
• Occam-pi 是一个语言平台，它期望用 pi-calculus 的移动特性扩展 occam 语言的 CSP 想法。请从 occam-pi homepage 学习这个尖端的研究。
  
  
• 在学习 occam 时，您可能还想调查 occam 编程器的各种扩展。
  
  
• 在 developerWorks Java 技术专区 可以找到 Java 编程各方面的文章。
  
  
• 请参阅 Developer Bookstore，以获得技术书籍的完整清单，其中包括数百本 Java 相关主题的书籍。
  
  
• 还请参阅 Java 技术专区教程页，以获得 developerWorks 上免费的、以 Java 为重点的教程。
  

Abhijit Belapurkar
高级技术架构师, Infosys Technologies Limited
2005 年 6 月 29 日

虽然使用 Java 语言进行多线程应用程序编程并不难掌握，但是许多开发人员都在为了正确地应用它们而挣扎。结果，多线程程序要比我们想像的更容易发生细微的错误，这导致一些开发人员为了避免使用多线程而不惜代价，即使在并发和并行能够很明显地产生最好的设计的时候，他们也不采用多线程。在这篇由三部分组成的系列文章中，developerWorks 的定期投稿者 Abhijit Belapurkar 为您铺设了一条有助于克服对多线程编程恐惧、感受它的好处的道路。文章从多线程编程最常见问题的概述开始，这些问题包括：竞争冒险（race hazard）、死锁、活动锁、资源耗尽（resource starvation），等等。

在 Java 平台上进行多线程编程是件让人望而生畏的事，这一点得到了广泛认可。实际上，一般的理论似乎是：最好把多线程编程留给 Java 高手。Sun Microsystems 通过（在 EJB 规范中—— 请参阅参考资料）把以下内容描述成 EJB 架构的目标之一，也间接地、更深入地讨论了这个观点：

应用程序开发人员不必理解低级事务和状态管理细节、不必理解多线程、连接池或者其他复杂的低级 API。

如果以这个观念为起点，那么您也就不会惊讶为什么许多 Java 开发人员要避开设计和开发多线程应用程序。但事实上，许多（即使不是大多数）企业级问题使用某种形式的多线程来解决最合适，而 EJB 和类似的框架并不像它们声称的那样，总是最容易的解决方案。

在这篇由三部分组成的系列文章中，我介绍了一个理论，该理论承认了并发编程的复杂性，并且没有试图隐藏这种复杂性，或者使它不那么难于学习和应用。通信顺序进程（Communicating Sequential Processes —— CSP） 是一个精确的并发数学理论，可以用来构建多线程应用程序，确保构建的程序中不出现并发的常见问题，而且更重要的是，这一点能够得到证实。

在介绍 CSP 理论和它基于 Java 语言的实现 —— JCSP 库 —— 之前，我希望能够确定我们有一个共同的讨论框架。我先从 Java 平台的并发编程技术概述开始，接着提供了多线程应用程序开发缺陷的深入概述，这些缺陷包括：竞争冒险、死锁、活动锁和资源耗尽等。最后，通过一些具体的讨论结束本文，这些讨论包括为什么 不能像您喜欢的那样验证多线程 Java 应用程序，并确定现有变通方法中您最偏爱的变通方法。

不要错过连载剩下的部分！ “面向 Java 程序员的 CSP”是由三部分组成的、介绍通信顺序进程（Communicating Sequential Processes —— CSP）的系列文章中的一篇。CSP 是并发编程的一个范式，它承认了并发编程的复杂性，却并没有把复杂性留给开发人员。请参阅本系列的其他部分： 第 2 部分：用 JCSP 进行并发编程 第 3 部分： JCSP 的高级主题

有了这些基础，就可以完全地体会 JCSP 的好处了。这是 Java 平台多线程编程的一个概念性和实践性的解决方案，我将在第 2 部分对其进行探讨，还将在 第 3 部分 探讨 Java 平台上更高级的 CSP 应用程序。

本文假设读者对于 Java 语言的并发编程有一般性的了解，虽然我在文章中也提供了关于这一主题的一个概述。请参阅 参考资料 一节，以获得更详细的信息。

Java 语言的并发编程
就其自身来说，并发编程是一种技术，提供了操作的同时执行，不论是在单一系统上还是分布在大量系统上。这类操作实际是一些指令顺序，例如单独某个顶级任务的子任务，这类操作能够并行执行，或者是作为线程，或者是作为进程。线程和进程之间的本质区别在于：进程通常是独立的（例如独立的地址空间），所以只能通过系统提供的进程间通信机制进行交互，而线程通常共享单一进程的状态信息，能够直接共享系统资源和内存中的对象。

可以使用下面两种方法之一，通过多个进程来实现并发。第一种方法是在同一个处理器上运行进程，由操作系统处理进程之间的上下文环境切换。（可以理解，这种切换要比同一进程内多线程之间的上下文环境切换更慢。）第二种方法是构建大规模的并行和复杂的分布式系统，在不同的物理处理器上运行多个进程。

从内建支持的角度来说，Java 语言通过线程提供并发编程；每个 JVM 都能支持许多线程同时执行。可以用以下两种方法之一在 Java 语言中创建线程：

• 继承 java.lang.Thread 类。在这种情况下，已经重写的子类的 run() 方法必须包含实现线程运行时行为的代码。要执行这个代码，需要实例化子类对象，然后调用对象的 start() 方法，这样就可以在内部执行 run() 方法了。
  
  
• 创建 Runnable 接口的定制实现。这个接口只包含一个 run() 方法，在这个方法中，要放置应用程序代码。要执行这个代码，需要实例化实现类的对象，然后在创建新 Thread 时，把对象作为构造函数的参数传入。然后调用新创建的线程对象的 start() 方法，开始执行控制的新线程。

线程安全性和同步
如果 Java 对象中的某个方法能够安全地运行在多线程环境中，那么就称该方法是 线程安全的。要获得这种安全性，必须有一种机制，通过该机制，运行同一方法的多个线程就能够同步其操作，这样，在访问相同的对象或代码行时，就会只允许一个线程被处理。这种同步要求线程使用叫作 信号 的对象彼此进行沟通。

有一种类型的信号叫作 互斥信号 或 互斥体。顾名思义，这个信号对象的拥有权是互斥的，也就是说，在任意指定时间，只有一个线程能够拥有互斥体。其他想获得所有权的线程会被阻塞，它们必须等待，直到拥有互斥体的线程释放互斥体。如果多个线程按顺序排队等候同一互斥体，那么在当前拥有者释放它的时候，只有一个等候线程能够得到它；其他线程将继续阻塞。

在 1970 年代初，C.A.R. Hoare 和其他人共同开发了一个叫作 监视器 的概念（请参阅 参考资料）。 一个 监视器 就是一个代码主体，它的访问受到互斥体的保护。任何想执行这个代码的线程，都必须在代码块顶部得到关联的互斥体，然后在底部再释放它。因为在指定时间只有一个线程能够拥有互斥体，所以这就有效地保证了只有拥有它的线程才能执行监视器的代码块。（受保护的代码不需要相邻 —— 例如，Java 语言中的每个对象都有一个与之关联的监视器。）

任何想在 Java 语言中进行线程编程的开发人员，都会立即把上面的内容当成 synchronized 关键字所带来的效果。可以确保包含在 synchronized 块中的 Java 代码在指定时间只被一个线程执行。在内部，可以由运行时将 synchronized 关键字转换成某一种情况：所有的竞争线程都试图获得与它们（指线程）正在操作的对象实例关联的那个（惟一的一个）互斥体。成功得到互斥体的线程将运行代码，然后在退出 synchronized 块时释放互斥体。

等候和通知
wait/notify 构造在 Java 语言的线程间通信机制中也扮演了重要的角色。基本的想法是：一个线程需要的某个条件可以由另外一个线程促成。这样，条件的 wait 就可以得到满足。一旦条件为真，那么引发条件的线程就会 notify 等候线程苏醒，并从中止的地方继续进行。

wait/notify 机制要比 synchronized 机制更难理解和判断。要想判断出使用 wait/notify 的方法的行为逻辑，就要求判断出使用它的所有方法的逻辑。一次判断一个方法，把该方法和其他方法隔离开，是对整体系统行为得出错误结论的可靠方式。显然，这样做的复杂性会随着要判断的方法的数量增长而迅速提高。

线程状态
我前面提到过，必须调用新创建的线程的 start() 方法来启动它的执行。但是，仅仅是调用 start() 方法并不意味着线程会立即开始运行。这个方法只是把线程的状态从 new 变成 runnable。只有在操作系统真正安排线程执行的时候，线程状态才会变成 running （从 runnable）。

典型的操作系统支持两种线程模型 —— 协作式和抢占式。在协作式 模型中，每个线程对于自己对 CPU 的控制权要保留多久、什么时候放弃有最终意见。在这个模型中，因为可能存在某个无赖线程占住控制权不放，所以其他线程可能永远无法得到运行。在 抢占式 模型中，操作系统本身采用基于时钟“滴答”的计时器，基于这个计时器，操作系统可以强制把控制权从一个线程转移到另外一个线程。在这种情况下，决定哪个线程会得到下一次控制权的调度策略就有可能基于各种指标，例如相对优先级、某个线程已经等待执行的时间长短，等等。

如果出于某些原因，处在 running 状态的线程需要等候某个资源（例如，等候设备的输入数据到达，或者等候某些条件已经设定的通知），或者在试图获得互斥体的时候被阻塞，因此线程决定睡眠，那么这时它可以进入 blocked 状态。当睡眠周期到期、预期输入到达，或者互斥体当前的拥有者将其释放并通知等候线程可以再次夺取互斥体时，阻塞的线程重新进入 runnable 状态。

当线程的 run() 方法完成时（或者正常返回，或者抛出 RuntimeException 这样的未检测到异常），线程将终止。这时，线程的状态是 dead。当线程死亡时，就不能通过再次调用它的 start() 方法来重新启动它，如果那么做，则会抛出 InvalidThreadStateException 异常。

四个常见缺陷
正如我已经展示过的，Java 语言中的多线程编程是通过语言支持的大量精心设计的构造实现的。另外，还设计了大量设计模式和指导原则，来帮助人们了解这种复杂性带来的许多缺陷。除此之外，多线程编程会很容易地在不经意间把细微的 bug 带进多线程代码，而且更重要的是，这类问题分析和调试起来非常困难。接下来要介绍的是用 Java 语言进行多线程编程时将会遇到（或者可能已经遇到过）的最常见问题的一个列表。

争用条件
据说 争用条件 存在于这样的系统中：多个线程之间存在对共享资源的竞争，而胜出者决定系统的行为。Allen Holub 在他撰写的文章 “programming Java threads in the real world” （请参阅 参考资料）提供了一个带有这样 bug 的简单的多线程程序示例。在冲突的访问请求之间进行不正确同步的另一个更可怕的后果是 数据崩溃，此时，共享的数据结构有一部分由一个线程更新，而另一部分由另一个线程更新。在这种情况下，系统的行为不是按照胜出线程的意图进行，系统根本不按照任何一个线程的意图行动，所以两个线程最后都将以失败告终。

死锁
死锁 的情况是指：线程由于等候某种条件变成真（例如资源可以使用），但是它等候的条件无法变成真，因为能够让条件变成真的线程在等候第一个线程“做某件事”。这样，两个线程都在等候对方先采取第一步，所以都无法做事。请参阅 Allen Holub 撰写的文章 （请参阅 参考资料），以获得在多线程 Java 代码中如何发生死锁的示例。

活动锁
活动锁 与 死锁 不同，它是在线程实际工作的时候发生的，但这时还没有完成工作。这通常是在两个线程交叉工作的时候发生，所以第一个线程做的工作被另一个线程取消。一个简单的示例就是：每个线程已经拥有了一个对象，同时需要另外一个线程拥有的另外一个对象。可以想像这样的情况：每个线程放下自己拥有的对象，捡起另外一个线程放下的对象。显然，这两个线程会永远都运行在上锁这一步操作上，结果是什么都做不成。（常见的真实示例就是，两个人在狭窄的走廊相遇。每个人都礼貌地让到另一边让对方先行，但却在相同的时间都让到同一边了，所以两个人还都没法通过。这种情况会持续一些时间，然后两个人都从这边闪到那边，结果还是一点进展也没有。）

资源耗尽
资源耗尽，又称为 线程耗尽，是 Java 语言的 wait/notify 原语无法保证 live-ness 的后果。Java 强制这些方法要拥有它们等候或通知的对象的锁。在某个线程上调用的 wait() 方法在开始等候之前必须释放监视器锁，然后在从方法返回并获得通知之后，必须再次重新获得锁。因此，Java 语言规范（请参阅 参考资料） 在锁本身之外，还描述了一套与每个对象相关的 等候集（wait set）。一旦线程释放了对象上的锁（在 wait 的调用之后），线程就会放在这个等候集上。

多数 JVM 实现把等候线程放在队列中。所以，如果在通知发生的时候，还有其他线程在等候监视器，那么就会把一个新线程放在队列尾部，而它并不是下一个获得锁的线程。所以，等到被通知线程实际得到监视器的时候，通知该线程的条件可能已经不再为真，所以它不得不再次 wait。这种情况可能无限持续下去，从而造成运算工作上浪费（因为要反复把该线程放入等候集和从中取出）和线程耗尽。

贪心哲学家的寓言
演示这种行为的原型示例是 Peter Welch 教授描述的“聪明人没有鸡肉”（请参阅 参考资料）。在这个场景中考虑的系统是一所由五位哲学家、一位厨师和一个食堂组成的学院。所有的哲学家（除了一位）都要想想（在代码示例中，考虑的时间是 3 秒）之后才去食堂取饭。而“贪心的”哲学家则不想把时间浪费在思考上 —— 相反，他一次又一次地回到食堂，企图拿到鸡肉来吃。

厨师按照一批四份的定量准备鸡肉，每准备好一份，就送到食堂。贪心的哲学家不断地去厨房，但他总是错过食物！事情是这样的：他第一次到的时候，时间太早，厨师还没开火。因此贪心的哲学家只好干等着（通过 wait() 方法调用）。在开饭的时候（通过 notify() 方法调用），贪心的哲学家再一次回到食堂排队等候。但是这次，在他前来等候的时候，他的四位同事已经到了，所以他在食堂队列中的位置在他们后面。他的同事把厨房送来的一批四份鸡肉全部拿走了，所以贪心的哲学家又要在一边等着了。 可怜（也可能是公平的） ，他永远处在这个循环之外。

验证的问题
一般来说，很难按照普通的规范对 Java 编程的多线程程序进行验证。同样，开发自动化工具对于常见的并发问题（例如死锁、活动锁和资源耗尽）进行完整而简单的分析也不太容易——特别是在任意 Java 程序中或者在缺乏并发的正式模型的时候。

更糟的是，并发性问题出了名的变化多端、难于跟踪。每个 Java 开发人员都曾经听说过（或者亲自编写过）这样的 Java 程序：经过严格分析，而且正常运行了相当一段时间，没有表现出潜在的死锁。然后突然有一天，问题发生了，结果弄得开发团队经历许多的不眠之夜来试图发现并修补根本原因。

一方面，多线程 Java 程序容易发生的错误非常不明显，有可能在任意什么时候发生。另一方面，完全有可能这些 bug 在程序中从不出现。问题取决于一些不可知的因素。多线程程序的复杂本质，使得人们很难有效地对其进行验证。没有一套现成的规则可以找出多线程代码中的这类问题，也无法确切地证明这些问题不存在，这些导致许多 Java 开发人员完全避开多线程应用程序的设计和开发，即使用并发和并行的方式对系统进行建模会非常棒，他们也不使用多线程。

确实想进行多线程编程的开发人员通常准备好了以下一个或两个解决方案（至少是一部分）：

• 长时间艰苦地测试代码，找出所有出现的并发性问题，诚心地希望到应用程序真正运行地时候已经发现并修复了所有这类问题。
  
  
• 大量运行设计模式和为多线程编程建立的指导原则。但是，这类指导原则只在整个系统都按照它们的规范设计的时候才有效，没有设计规则能够覆盖所有类型的系统。

虽然知道的人不多，但是对于编写（然后验证）正确的多线程应用程序这一问题，还有第三个选项。使用称为通信顺序进程（ Communicating Sequential Processes，CSP）的精确的线程同步的数学理论，可以在设计时最好地处理死锁和活动锁之类的问题。CSP 由 C.A.R. Hoare 与 20 世纪 70 年代后期设计，CSP 提供了有效的方法，证明用它的构造和工具构建的系统可以免除并发的常见问题。

第 1 部分的结束语
在这份面向 Java 程序员的 CSP 全面介绍的第一部分中，我把重点放在克服多线程应用程序开发常见问题的第一步上，即了解这些问题。我介绍了 Java 平台上目前支持的多线程编程构造，解释了它们的起源，讨论了这类程序可能会有的问题。我还解释了用正式理论在任意的、大型的和复杂的应用程序中清除这些问题（即竞争冒险、死锁、活动锁和资源耗尽）或者证明这些问题不存在的困难。

在 第 2 部分 中，有了这个基本框架在脑子里，我将介绍 CSP 和它基于 Java 的实现 —— JCSP 库。您会发现，CSP 是一个复杂的数学理论，有大量强大的应用程序 （我会在第 3 部分 将讨论一些更高级的程序），其中包括多线程编程常见问题的解决方法。

要想了解 JCSP 如何把 CSP 的精华提炼成一个好理解的 Java 构造框架，那么请您现在就跳转至 “第 2 部分：用 JCSP 进行并发编程”。

致谢
我非常感谢 Peter Welch 教授在我编写这个文章系列期间给予的鼓励。他在百忙之中抽出时间，非常细致地审阅了本文的草稿，并提供了许多宝贵的提高本系列质量和准确性的建议。文章中如果还存在错误，那么都是由于我的原因！我在文章中使用的示例基于或来自 JCSP 库的 javadoc 中提供的示例，以及 JCSP Web 站点上提供的 Powerpoint 演示文稿。这两个来源都提供了大量将探索的信息。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• Brian Goetz 撰写的由三部分组成的 “Threading lightly”系列是解决 Java 平台上同步问题的巧妙而系统的方法。（developerWorks，2001 年 7 月）。
  
  
• Brian 的 Java theory and practice 专栏定期介绍多线程编程。 “并发在一定程度上使一切变得简单 ”（developerWorks，2002 年 11 月）首次研究了 util.concurrent，这是一个广泛采用的用于 Java 平台的并发工具包。
  
  
• Allen Holub 编程了大量 Java 平台多线程编程的内容。他撰写的“Programming Java threads in the real world” （JavaWorld，1998 年 10 月）提供了线程问题的示例，例如争用条件和死锁。
  
  
• 还请参阅 Holub 有名的苛评“v“ （developerWorks，2000 年 10 月）。
  
  
• 英国坎特伯雷市肯特大学的 Peter Welch 教授设计了“Wot, no chickens?”问题，举例说明 Java 程序中的资源耗尽。
  
  
• C.A.R. Hoare 开创性的论文“Communicating Sequential Processes”将通信顺序进程的并行组合作为一种基本的编程构造方法进行介绍（Communications of the ACM Archive，1978）。
  
  
• Hoare 撰写的“Monitors:?an operating system structuring concept” （Communications of the ACM Archive,1974）第一次向全世界介绍了监视器的概念，他采用了非常有表现力的示例，包括单一资源调度器、有边界缓存、闹钟、缓冲池、磁头优化器，以及一个有问题的读取器和写入器版本。
  
  
• Enterprise JavaBeans 是若干个试图向 Java 程序员隐藏多线程编程复杂性的框架之一。
  
  
• 请参阅 Java Language Specification。
  
  
• 在 developerWorks 的 Java 技术专区 中，可以找到 Java 编程各方面的文章。
  
  
• 请参阅 Developer Bookstore，以获得技术书籍的完整清单，其中包括数百本 Java 相关主题 的书籍。
  
  
• 还请参阅 Java 技术专区教程页，从 developerWorks 获得免费的、以 Java 为重点的教程。
  

As junior engineers, we first sided with the proselytes of checked exceptions, but over the years, and after many, many catch blocks later, we have gradually converted to the order of the unchecked. Why? We have come to believe in a simple set of rules for dealing with error situations:

1. If it makes sense to handle the exception, do so
2. If you can't handle it, throw it
3. If you can't throw it, wrap it in an unchecked base exception and then throw it

But what about those exceptions that bubble all the way to the top, you ask? For those, we install a last line of defense to ensure error messages are always logged and the user is properly notified.

This article presents yet another framework for exception handling, which extends the enterprise-wide application session facility presented in "Create an Application-Wide User Session for J2EE" (JavaWorld, March 2005). J2EE applications that use this framework will:

1. Always present meaningful error messages to users
2. Log unhandled error situations once and only once
3. Correlate exceptions with unique request IDs in log files for high-precision debugging
4. Have a powerful, extensible, yet simple strategy for exception handling at all tiers

To forge the framework, we wield aspect-oriented programming (AOP), design patterns, and code generation using XDoclet.

You will find all the code in Resources along with a sample J2EE application that uses it. The source constitutes a complete framework named Rampart, which was developed for Copenhagen County, Denmark in the context of J2EE-based electronic healthcare records (EHR) applications.

Why do we need common error handling?
During a project's initial state, significant architecture decisions are made: How will software elements interact? Where will session state reside? What communication protocols will be used? And so on. More often than not, however, these decisions do not include error handling. Thus, some variant on the happy-go-lucky strategy is implemented, and, subsequently, every developer arbitrarily decides how errors are declared, categorized, modeled, and handled. As an engineer, you most likely recognize the results of this "strategy":

1. Swollen logs: Every catch block contains a log statement, leading to bloated and redundant log entries caused by polluted source code.
2. Redundant implementations: The same type of error has different representations, which complicates how it is handled.
3. Broken encapsulation: Exceptions from other components are declared as part of the method signature, breaking the clear division between interface and implementation.
4. Noncommittal exception declaration: The method signature is generalized to throw java.lang.Exception. This way, clients are ensured not to have the least clue about the method's error semantics.

A common excuse for not defining a strategy is that "Java already provides error handling." This is true, but the language also offers facilities for consistently declaring, signaling, propagating, and responding to errors. The language user is responsible for deciding how these services should be used in an actual project. Several decisions must be made, including:

1. To check or not to check: Should new exception classes be checked or unchecked?
2. Error consumers: Who needs to know when an unhandled error occurs, and who is responsible for logging and notifying operations staff?
3. Basic exception hierarchy: What kind of information should an exception carry and what semantics does the exception hierarchy reflect?
4. Propagation: Are nonhandled exceptions declared or transformed into other exception classes, and how are they propagated in a distributed environment?
5. Interpretation: How are unhandled exceptions turned into human readable, even multilingual messages?

Encapsulate rules in a framework, but hurry!
Our recipe for a common error-handling strategy builds on the following shortlist of ingredients:

1. Use unchecked exceptions: By using checked exceptions, clients are forced to take a position on errors they can rarely handle. Unchecked exceptions leave the client with a choice. When using third-party libraries, you don't control whether exceptions are modeled as checked or unchecked ones. In this case, you need unchecked wrapper exceptions to carry the checked ones. The biggest tradeoff in using only unchecked exceptions is that you can't force clients to handle them anymore. Yet, when declared as part of the interface, they remain a crucial element of the contract and continue to be part of Javadoc documentation.
2. Encapsulate error handling and install a handler on top of each tier: By having a safety net, you can focus on handling only exceptions relevant to business logic. The handler performs the safe touchdown for the remaining exceptions at the specific tier executing standardized steps: logging, system management notification, transformations, etc.
3. Model the exception hierarchy using a "simple living" approach: Don't automatically create new exception classes whenever new error types are discovered. Ask yourself if you are simply dealing with a variation of another type and if the client code is likely to explicitly catch it. Remember that exceptions are objects whose attributes can, at least to some extent, model the variation of different situations. Less than a handful of exception classes will most likely prove enough to satisfy a starting point, and only those that are likely to be handled need specialized attributes.
4. Give meaningful messages to end users: Unhandled exceptions represent unpredictable events and bugs. Tell this to the user and save the details for the technical staff.

Although needs and constraints, exception hierarchies, and notification mechanisms will differ across projects, many elements remain constant. So why not go whole hog and implement common policies in a framework? A framework followed by simple rules of usage is the best way to enforce a policy. Executable artifacts talk to developers, and it is easier to preach architectural principles with a jar file and some Javadoc than with whitepapers and slide shows.

However, you cannot ask the development team to postpone error handling until a policy and complementing framework support is ready. Error handling must already be determined when the first source file is created. A good place to start is by defining the fundamental exception hierarchy.

A basic exception hierarchy
Our first practical task is to define an exception hierarchy common enough to be used across projects. The base class for our own unchecked exceptions is UnrecoverableException, a name that, for historical reasons, remains slightly misleading. You might consider a better title for your own hierarchies.

When you want to get rid of a checked exception, one that, conceivably, clients will always be able to handle, WrappedException offers a simple, generic transport mechanism: wrap and throw. The WrappedException keeps the cause as an internal reference, which works well when the classes for the original exception are still available. When this is not the case, use SerializableException, which resembles WrappedException except that it can be used when no assumptions are made on available libraries at the client side.

Although we prefer and recommend unchecked exceptions, you might keep checked exceptions as an option. The InstrumentedException interface acts as an interface for both checked and unchecked exceptions that follow a certain pattern of attribute implementation. The interface allows exception consumers to consistently inspect the source—whether it inherits from a checked or an unchecked base.

The class diagram below shows our basic exception hierarchy.

At this point, we have a strategy and a set of exceptions that can be thrown. It is time to build the safety net.

The last line of defense
The article "Create an Application-Wide User Session" presented Rampart, a layered architecture consisting of an enterprise information system tier, a business logic tier made from stateless session beans, and a client tier with both Web and standalone J2SE clients. Exceptions can be thrown from all tiers in this architecture, and can either be handled on site or bubble up until they reach the end of the call chain. Then what? Both J2SE and J2EE application servers guard themselves against offensive behavior by catching stray Errors and RuntimeExceptions, and by dumping the stack trace to System.out, logging it, or performing some other default action. In any case, if a user is presented with any kind of output, mostly likely, it will prove absolutely meaningless, and, worse, the error will probably have disrupted program stability. We must install our own rampart to provide a more sound exception-handling mechanism for this last line of defense.

Consider Figure 2:

Exceptions may occur on the server side in the EJB (Enterprise JavaBeans) tier and in the Web tier, or on the standalone client. In the first case, exceptions stay in the VM from which they originated as they make their way up to the Web tier. This is where we install our top-level exception handler.

In the standalone case, exceptions eventually reach the rim of the EJB container and travel along the RMI (remote method invocation) connection to the client tier. Care must be taken not to send any exceptions belonging to classes that live only on the server side, e.g., from object-relational mapping frameworks or the like. The EJB exception handler handles this responsibility by using SerializableException as a vehicle. On the client side, a top-level Swing exception handler catches any stray errors and takes appropriate action.

Exception-handler framework
An exception handler in the Rampart framework is a class that implements the ExceptionHandler interface. This interface's only method takes two arguments: Throwable, to handle, and the current Thread. For convenience, the framework contains an implementation, ExceptionHandlerBase, which tastes Throwable and delegates handling to dedicated abstract methods for the flavors RuntimeException, Error, Throwable, and the Rampart-specific Unrecoverable. Subclasses then provide implementations for these methods and handle each situation differently.

The class diagram below shows the exception-handler hierarchy with its three default exception handlers.

Figure 3. Exception-handler hierarchy. Click on thumbnail to view full-sized image.

Some among The Order of the Unchecked believe that Sun should have added hooks into all containers in the J2EE architecture on a per-application basis. This would have allowed custom error-handling schemes, security, and more to be gracefully installed, without reliance on vendor-specific schemes and frameworks. Unfortunately, Sun failed to provide such mechanisms in the EJB specification; so, we pull out the AOP hammer from our toolbox and add exception handling as around-aspects. AspectWerkz, our chosen AOP framework, uses the following aspect for that task:

public class EJBExceptionHandler implements AroundAdvice {

   private ExceptionHandler handler;

   public EJBExceptionHandler() {
      handler = ConfigHelper.getEJBExceptionHandler();
   }

   public Object invoke(JoinPoint joinPoint) throws Throwable {

      Log log = LogFactory.getLog(joinPoint.getEnclosingStaticJoinPoint().getClass().getName());
      log.debug("EJB Exception Handler bean context aspect!!");
      try {
         return joinPoint.proceed();
      } catch (RuntimeException e) {
         handler.handle(Thread.currentThread(), e);
      } catch (Error e) {
         handler.handle(Thread.currentThread(), e);
      }
      return null;
   }
}


The actual handler is configurable and obtained through the ConfigHelper class. If a RuntimeException or Error is thrown during execution of the bean business logic, the handler will be asked to handle it.

The DefaultEJBExceptionHandler serializes the stack trace of any exception not originating from Sun's core packages into a dedicated SerializableException, which, on the plus side, allows the stack trace of exceptions whose classes don't exist on remote clients to be propagated over anyway. On the downside, the original exception is lost in translation.

EJB containers faithfully take any RuntimeException or Error and wrap it in a java.rmi.RemoteException, if the client is remote, and in a javax.ejb.EJBException, otherwise. In the interest of keeping causes precise and stack traces at a minimum, the framework peels off these transport exceptions inside client BusinessDelegates and rethrows the original.

A Rampart BusinessDelegate class exposes an EJB-agnostic interface to clients, while wrapping local and remote EJB interfaces internally. BusinessDelegate classes are generated via XDoclet from EJB implementation classes and follow the structure shown in Figure 4's UML diagram:

The BusinessDelegate class exposes all business methods from the source EJB implementation class and delegates to the LocalProxy class or the RemoteProxy class as appropriate. Internally, the two proxies handle EJB-specific exceptions and, hence, shield the calling BusinessDelegate from implementation details. The code below is a method from some LocalProxy class:

public java.lang.String someOtherMethod()  {
   try {
      return serviceInterface.someOtherMethod();
   } catch (EJBException e) {
      BusinessDelegateUtil.throwActualException(e);
   }
   return null; // Statement is never reached
}


The serviceInterface variable represents the EJB local interface. Any EJBException instances thrown by the container to indicate an unexpected error are caught and handled by the BusinessDelegateUtil class, in which the following action takes place:

public static void throwActualException(EJBException e) {
   doThrowActualException(e);
}

private static void doThrowActualException(Throwable actual) {
   boolean done = false;
   while(!done) {
      if(actual instanceof RemoteException) {
         actual = ((RemoteException)actual).detail;
      } else if (actual instanceof EJBException) {
         actual = ((EJBException)actual).getCausedByException();
      } else {
         done = true;
      }
   }
   if(actual instanceof RuntimeException) {
      throw (RuntimeException)actual;
   } else if (actual instanceof Error) {
      throw (Error)actual;
   }
}


The actual exception is extracted and rethrown to the top-level client exception handler. When the exception reaches the handler, the stack trace will be that of the original exception from the server containing the actual error. No superfluous client-side trace is added.

Swing exception handler
The JVM provides a default top-level exception handler for each control thread. When exercised, this handler dumps the stack trace of Error and RuntimeException instances onto System.err and kills the thread! This rather obstructive behavior is quite far from anything a user needs and not elegant from a debugging perspective. We want a mechanism that allows us to notify the user while retaining the stack trace and a unique request ID for later debugging. "Create an Application-Wide User Session for J2EE" describes how such a request ID becomes available at all tiers.

For J2SE versions up to 1.4, uncaught exceptions in Thread instances cause the owner ThreadGroup's uncaughtException() method to execute. A simple way to control exception handling in an application, then, is to simply extend the ThreadGroup class, overwrite the uncaughtException() method, and ensure all Thread instances start within an instance of the custom ThreadGroup class.

J2SE 5 provides an even sweeter mechanism by allowing the installation of an UncaughtExceptionHandler implementation on instances of the Thread class itself. The handler is used as a callback mechanism when uncaught exceptions reach the Thread instance's run method. We built the framework with J2SE 1.3+ compatibility in mind; hence we used the ThreadGroup inheritance approach:

private static class SwingThreadGroup extends ThreadGroup {

   private ExceptionHandler handler;

   public SwingThreadGroup(ExceptionHandler handler) {
      super("Swing ThreadGroup");
      this.handler = handler;
   }

   public void uncaughtException(Thread t, Throwable e) {
      handler.handle(t, e);
   }
}


The SwingThreadGroup class shown in the code snippet above overrides the uncaughtException() method and passes the current Thread instance and the thrown Throwable to the configured exception handler.

A little more magic is needed before we can claim control of all stray exceptions in the client tier. For the scheme to work, all threads must be associated with our specialized SwingThreadGroup instance. This is accomplished by spawning a new master Thread instance and passing the SwingThreadGroup instance with a Runnable implementation, which executes the entire main program. All Thread instances spawned from the body of this new master Thread instance automatically join the SwingThreadGroup instance and, hence, use our new exception handler when unchecked exceptions are thrown.

Figure 5. Swing exception handler class hierarchy. Click on thumbnail to view full-sized image.

The framework implements this logic in the SwingExceptionHandlerController convenience class shown in Figure 5. Applications provide an implementation of the SwingMain interface along with an exception handler to the controller. The controller must then be started, and the old main Thread can join the new one and wait for termination. The code below shows how the demo application that accompanies this article accomplishes that task. The method createAndShowGUI() constitutes the actual application body, which initializes Swing components and transfers control to the user.

public DemoApp() {
  
   SwingExceptionHandlerController.setHandler(new DefaultSwingExceptionHandler());
   SwingExceptionHandlerController.setMain(new SwingMain() {

      public Component getParentComponent() {
         return frame;
      }

      public void run() {
         createAndShowGUI();
      }
   });

   SwingExceptionHandlerController.start();
   SwingExceptionHandlerController.join();
}


The last line of defense is now in place for the Swing layer, but we still need to provide a meaningful message to the user. The demo application supplies a rather basic implementation that simply displays a dialog box with an internationalized message and the unique request ID as a support ticket. At the same time, the exception is logged via log4j along with the unique request ID. A more sophisticated error handler might send an email, SNMP message, or the like to technical support with the ID in it. The point is that both client and server logs can be filtered on the support ticket ID to allow precise pinpointing of errors on a per-request basis.

Figure 6 shows merged Swing client and J2EE server logs to provide the precise flow for the request with ID 1cffeb4:feb53del38:-7ff6, where an exception was thrown. Note that the stack trace contains only information from the server side, where the exception was thrown.

Figure 6. Log trace from both client and server with request ID and server stack trace. Click on thumbnail to view full-sized image.

While the infrastructure for adding exception handling to standalone J2SE applications is basic, things are different as we move to Web-based clients.

WAR exception handler
Web applications are among the fortunate components in the J2EE world to have their own explicit way of installing exception-handling capabilities. Through the web.xml deployment descriptor, exceptions and HTTP errors can be mapped to error pages in the shape of servlets or JavaServer Pages (JSP) pages. Consider the following fragment from a sample web.xml file:

<servlet>
   <servlet-name>ErrorHandlerServlet</servlet-name>
   <servlet-class>dk.rhos.fw.rampart.util.errorhandling.ErrorHandlerServlet</servlet-class>
</servlet>

<servlet-mapping>
   <servlet-name>ErrorHandlerServlet</servlet-name>
   <url-pattern>/errorhandler</url-pattern>
</servlet-mapping>

<error-page>
   <exception-type>java.lang.Throwable</exception-type>
   <location>/errorhandler</location>
</error-page>


These tags direct all uncaught exceptions to the URL /errorhandler, which in this case is mapped to the ErrorHandlerServlet class. The latter is a dedicated servlet whose sole raison d'etre is to act as a bridge between Web components and the exception-handling framework. When an uncaught exception from this Web application reaches the servlet container, a set of parameters with information about the exception will be added to the HttpServletRequest instance and passed to the ErrorHandlerServlet class's service method. The fragment below shows the service() method:

...
private static final String CONST_EXCEPTION = "javax.servlet.error.exception";
...

protected void service(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse)
   throws ServletException, IOException
{

   Throwable exception = (Throwable)httpServletRequest.getAttribute(CONST_EXCEPTION);

   ExceptionHandler handler = ConfigHelper.getWARExceptionHandler();
   handler.handle(Thread.currentThread(), exception);

   String responsePage = (String)ConfigHelper.getRequestContextFactory().
      getRequestContext().
      getAttribute(ExceptionConstants.CONST_RESPONSEPAGE);


   if(responsePage == null) {
      responsePage = "/error.jsp";
   }

   httpServletResponse.setStatus(HttpServletResponse.SC_OK);

   RequestDispatcher dispatcher = httpServletRequest.getRequestDispatcher(responsePage);
   try {
      dispatcher.include(httpServletRequest, httpServletResponse);
   } catch (Exception e) {
      log.error("Failed to dispatch error to responsePage " + responsePage, e);
   }
}


In the service() method, first, the actual exception from the HttpServletRequest instance is retrieved through the key javax.servlet.error.exception. Next, the exception handler instance is retrieved. From there on, the handler is invoked, and the HttpServletRequest instance is forwarded to the page specified by the key rampart.servlet.exception.responsepage.

The DefaultWARExceptionHandler class looks up an internationalized text based on the exception message and redirects output response to the JSP /error.jsp. This page is then free to display the message to the user, including the current request ID as a support ticket. A much more sophisticated mechanism can easily be implemented by simply extending or replacing this handler.

Wrap up
Often, exception handling is not handled stringently enough, thereby complicating debugging and error tracking, and, many times, disrupting the overall user experience. It is therefore crucial to have policies and frameworks in place before system development starts. Adding this aspect as an afterthought is doable, but time consuming and expensive.

This article has armed you with a starting point for defining an exception policy and introduced you to a simple, yet extensible, unchecked exception hierarchy. We have walked through business and client tiers of a sample J2EE architecture and shown how you can install top-level exception handlers for each tier to provide a last line of defense. The framework code has given you a way to precisely pinpoint errors on a per-user request basis through the unique request ID attached to exceptions and log entries.

So download the framework, try it out, modify it to your heart's delight, and get those exceptions under control.

HSQLDB is the leading SQL relational database engine written in Java. It has a JDBC driver and supports a rich subset of ANSI-92 SQL (BNF tree format) plus SQL 99 and 2003 enhancements. It offers a small (less than 100k in one version), fast database engine which offers both in-memory and disk-based tables. Embedded and server modes are available. Additionally, it includes tools such as a minimal web server, in-memory query and management tools (can be run as applets) and a number of demonstration examples.

The product is currently being used as a database and persistence engine in many Open Source Software projects and even in commercial projects and products. In it's current version it is extremely stable and reliable. It is best known for its small size, ability to execute completely in memory and its speed.

This feature-packed software is completely free under our licenses , based on the standard BSD license. Yes, that's right, completely free of cost or onerous restrictions and fully compatible with all major open source licenses. Java source code and extensive documentation always included!

Users please visit the Project Summary Page for more information and to submit Patches, Bugs, Feature Requests and communicate with the Project Team or view/browse/subscribe to one or more of our mailing lists.

Also visit our pages featuring HSQLDB for the Sharp Zaurus platform, a special version with a data entry and view interface.

Developers please visit the Developers Page and join our effort!

Our group was formed in 2001 and has as its charter the continuation of Thomas Mueller's closed Hypersonic SQL Project. We have actively developed and released six new versions of the database since April 2001. The latest release version features a wide range of new functionality and code rewrite. The project enjoys an overall ranking of 82 among all SourceForege projects (85,000) with over 380,000 downloads.

The last stable code from Thomas' project (Hypersonic SQL version 1.43) is also available for download at Thomas Mueller's Hypersonic SQL page at SourceForge.

13 Aug 2004
Updated 03 Aug 2004

The core of IBM® Cloudscape™ is the Apache Derby open source database. The Derby lightweight, pure Java™ technology-based embeddable architecture makes it the ideal database engine for deploying database-driven Java applications. With Derby, the database engine becomes part of the application so the user never has to install or manage it. This article highlights the Derby embeddable SQL database engine for Java technology and provides you with an overview of Derby technical features.

Prelude
Cloudscape is the original zero admin, embeddable, all java, relational database that entered the marketplace in 1996. In August 2004 IBM contributed Derby, a copy of its Cloudscape 10.0 relational database product, to the Apache Software Foundation (ASF) to help accelerate innovation around data-driven Java applications. IBM continues its Cloudscape commercial offering, which adds features to the core Derby engine.

Not surprisingly, the existence of two names side-by-side, Cloudscape and Derby, might cause some confusion. With that in mind, this section clarifies what is in the Apache Derby software and what is in the IBM Cloudscape product. We mention features you probably won't recognize yet; but, rest assured, we describe them later in this technical article.

This technical article uses "Derby" when referring to any feature that is part of the open source database engine, including:

• The core RDBMS engine.
• The embedded JDBC Driver.
• The Network Server.

The IBM Cloudscape product includes Derby without any modification whatsoever to the underlying source code. This technical article uses "Cloudscape" when referring to the features IBM adds to the core Derby engine, such as:

• IBM Technical Support.
• IBM DB2 UDB Universal JDBC Driver for use with the Derby Network Server.
• The IBM Cloudscape manuals and Cloudscape Information Center.
• Installers and sample databases that jump start developers who are new to Java and/or Derby.

At times, you might notice Derby and Cloudscape being used as synonyms, and you might see the core database engine referred to as Cloudscape, especially in other IBM developerWorks technical articles and when referring to older Cloudscape releases. We apologize for any confusion. Moving forward, think --Derby-- for the core database features and --IBM Cloudscape-- for the supported commercial release. And if you find yourself using the two terms synonymously, don't worry; we understand what you mean.

Introduction
Derby is a lightweight, embeddable relational engine in the form of a Java class library. Its native interface is Java Database Connectivity (JDBC), with Java-relational extensions. It implements the SQL92E standard as well as many SQL 99 extensions. The engine provides transactions and crash recovery, and allows multiple connections and multiple threads to use a connection. Derby can be easily embedded into any Java application program or server framework without compromising the Java-ness of the application because it is a Java class library. Derby's support for complex SQL transactions and JDBC allows your applications to migrate to other SQL databases, such as IBM DB2® Universal Database™ (UDB), when they need to grow.

The Derby Network Server provides multi-user connectivity to Derby databases within a single system or over a network. The Derby Network Server receives and replies to queries from clients using standard network protocol. Databases are accessed through the Derby Network Server using the IBM DB2 Universal JDBC Driver. (Not all Derby functionality is supported when using the Network Server. See the Server and Administration Guide for details.)

There are several technical aspects that differentiate Derby from other database systems:

• Derby is easy to administer. When embedded in a client application, a Derby system requires no administrative intervention.
• Derby is embeddable. Applications can embed the Database Management System (DBMS) engine in the application process, eliminating the need to manage a separate database process or service.
• Derby can run as a separate process, using the Network Server framework or a server framework of your choice.
• Derby is a pure Java class library: This is important to Java developers who are trying to maintain the advantages of Java technology, such as platform independence, ease of configuration, and ease of installation.
• Derby needs no proprietary Java Virtual Machine (JVM). Written entirely in the Java language, it runs with any certified JVM.
• The Derby DBMS engine is lightweight. It is about 2MB of class files, and it uses as little as 4MB of Java heap.
• Derby provides the ability to write stored procedures and functions in Java that can run in any tier of an application. Derby does not have a proprietary stored procedure language; it uses JDBC.

Derby is also like other relational database systems. Derby implements the SQL92E language standard and the JDBC API standard. It has transactions (commit and rollback), supports multiple connections with transactional isolation, and provides crash recovery. Like other databases, it allows multiple threads to share the same connection, and Derby implements many SQL99 features, with extensions for Java technology.

This unique combination of technical capabilities allows application developers to build data-driven applications that are pervasive (run anywhere), deployable (downloadable), manageable, extensible, and connectable. These technical features are discussed in this article, organized as shown below:

• General architecture
  • Embedded
  • Network Server
  • Easy Integration
  • Data Persistence
  • Flexibility
  • Programmer's application program interface (API)
  • JDBC drivers
  • CLI/ODBC driver
• Relational Database Management System (RDBMS) capabilities
• Security features
  • Signed Java class file archive (JAR) files
  • Encrypted databases
  • External user authentication
• Java extensions
  • Java functions
  • Using Java functions in triggers
  • Java stored procedures
  • Loading Java classes from the database
• IBM Cloudscape Features
• Summary

General architecture
Derby is a relational database management engine implemented as a Java class library. Applications access data managed by the Derby engine with the JDBC API.

Embedded
The database engine is embeddable. This means that rather than running as a separate process, the database engine software can be part of the application so that the application and the database engine run in the same JVM. When embedded, the application uses the JDBC API to access the database. The embedded JDBC driver transfers data to and from the database engine without the need for network communication. Whether or not it is embedded, the database engine supports multiple simultaneous connections and access from multiple application threads.

Figure 1. Derby embedded in an application

Network Server
It is also possible to deploy Derby as a traditional client/server database server. To accomplish this, Derby is embedded in a server framework. A server framework is simply a piece of software that can accept and process network communication. Derby includes a Network Server, but you can also run Derby in a server framework of your choice.

Figure 2. Derby acts as a client/server DBMS within a server framework

Easy Integration
It is just as easy to embed Derby inside a Java Web server, such as IBM WebSphere® Application Server. Figure 3 shows Derby embedded in a Java Web server, with clients accessing the database through Hypertext Transfer Protocol (HTTP ) requests to servlets.

Figure 3. Derby embedded in Web server

Data Persistence
Derby provides persistence of data by storing data in disk files. A Derby engine can manage one or more database files, but each database file can only be accessed by a single Derby engine. In a client/server configuration, the engine provides multi-user access to the databases under its control. All threads that access the database do so through the database engine.

Figure 4. Thread access to Derby

The data in the database disk files is stored in a portable format so that databases can be easily transported from machine to machine regardless of the CPU architecture of the machines. Derby can also handle data files on read-only media. These characteristics make it easy to download Derby applications together with their database or run them from a CD-ROM. The combination of portable database formats and the pure Java DBMS engine makes it possible to send a data-centric application anywhere, either on media or over a network.

Flexibility
Derby provides a great deal of flexibility for system designers. Each Derby instance can manage multiple databases, the databases can live on various media, and there's nothing to stop the application from connecting to other DBMS systems.

Figure 5. Flexible application architecture

Programmer's API
Applications access the database with the industry standard JDBC API. When a client application needs to store or retrieve data from the database, it submits a request through the JDBC API to the Derby engine (either over a network or directly to the embedded engine). The client program is not required to use any Derby-specific APIs; clients only use JDBC. The Derby driver is selected by supplying a Derby JDBC connection Uniform Resource Locator (URL), as shown in Listing 1.

Connection conn = DriverManager.getConnection("jdbc:derby:greetdb");
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT message FROM greetings");
while (rs.next())
{
    String greeting = rs.getString(1);
    System.out.println(greeting);
}
rs.close();
stmt.close();
conn.close();

Since the application is only using JDBC APIs, it is portable, and will run against JDBC-compliant databases from other vendors. This standards compliance enables a developer to write an application against Derby and deploy it against another DBMS.

When a client requests data from the DBMS, the JDBC driver copies the data from the database into the application. Modifications of that data in the application, intentional or unintentional, do not affect the data in the database until JDBC calls are used to send the changes back to the DBMS. Similarly, when a client stores data in the DBMS, it is copied out of the client and into the DBMS. Because Derby is transactional, complex data manipulations can be grouped together into transactions. Derby guarantees data consistency by ensuring that even after system failure, either all or none of the transaction will commit to the database file.

Figure 6. Objects copied from DBMS to application

More information about JDBC can be found at http://java.sun.com/jdbc.

JDBC drivers
To support the embedded architecture, Derby includes an embedded driver for accessing Derby from Java client programs. The embedded driver is used to communicate with Derby when it is running in the same JVM as the application program.

To support the client-server architecture, IBM Cloudscape includes the IBM DB2 UDB JDBC Universal Driver, which works with the Derby Network Server.

Both JDBC drivers are Type 4 drivers: pure Java on the client and connect directly to the database engine without any intermediate translation.

JDBC connection URLs to Derby databases all start with the prefix jdbc:derby:. The connection URL for an embedded database on drive e: might look like this: jdbc:derby:e:/db. The connection URL to a Network Server might look like this: jdbc:derby:net://localhost:1527/mydb.

Derby JDBC drivers support JDBC 2.0 and 3.0; they work with JVM 1.3.1 and beyond. The standard extensions for JNDI data sources, connection pooling, and XA are also provided. These features enable Derby to be a resource manager in a distributed J2EE system.

CLI/ODBC driver
The IBM DB2 CLI/ODBC driver for Derby (beta) is available for free download from IBM developerWorks. In addition to supporting standard ODBC clients, it also makes it possible to develop PHP/Perl and .NET applications over ODBC.

RDBMS capabilities
Derby implements the SQL92E language standard and many features of SQL99, with extensions for Java. SQL language support includes the following:

• Basic types: CHAR, DECIMAL, DOUBLE PRECISION, FLOAT, INTEGER, NUMERIC, REAL, SMALLINT.
• Datetime data types (from SQL92T): DATE, TIME, TIMESTAMP (with JDBC date/time escape syntax).
• Other types: BIGINT, VARCHAR, CHAR FOR BIT DATA, VARCHAR FOR BIT DATA, LONG VARCHAR, LONG VARCHAR FOR BIT DATA, BLOB, CLOB.
• Basic math operations: +,*,-,/,unary +,unary -.
• Basic comparisons: <,>,<=,>=,<>,=.
• Datetime literals
• Built-in functions: ABS or ABSVAL, CAST, LENGTH, concatenation (||), NULLIF and CASE expressions, CURRENT_DATE, CURRENT_ISOLATION, CURRENT_TIME, CURRENT_TIMESTAMP, CURRENT_USER, DATE, DAY, HOUR, IDENTITY_VAL_LOCAL, LOCATE, LCASE or LOWER, LTRIM, MINUTE, MOD, MONTH, RTRIM, SECOND, SESSION_USER, SQRT, SUBSTR, TIME, TIMESTAMP, UCASE or UPPER, USER, YEAR.
• Basic predicates: BETWEEN, LIKE, NULL
• Quantified predicates: IN, ALL, ANY/SOME, EXISTS
• CREATE and DROP SCHEMA
• CREATE and DROP TABLE
• Check constraints
• ALTER TABLE: ADD COLUMN and ADD/DROP CONSTRAINT
• CREATE and DROP VIEW
• Constraints: NOT NULL, UNIQUE, PRIMARY KEY, CHECK, FOREIGN KEY
• Cascade delete
• Column defaults
• Delimited identifiers
• Updatable cursors (through JDBC)
• Dynamic SQL (through JDBC)
• INSERT, UPDATE, and DELETE statements
• Positioned updates and deletes
• WHERE qualifications
• GROUP BY
• HAVING
• ORDER BY
• UNION and UNION ALL
• Subqueries as expressions (from SQL92F)
• Joins in the WHERE clause
• Joins (SQL92T): INNER, RIGHT OUTER, LEFT OUTER, named column join, condition join
• Aggregate functions (with DISTINCT): AVG, COUNT, MAX, MIN, SUM
• Select expressions
• SELECT *, SELECT table.* (SQL92T), SELECT DISTINCT, select expressions
• Named select columns
• SQLSTATE
• UNION in views (SQL92T)
• CAST (SQL92T)
• INSERT expressions (SQL92T): insert into T2 (COL) select col from T1
• VALUES expressions: select * from (values (1, 2)) as foo(x, y), etc.
• Triggers

Other traditional database features include:

• Cost-based query optimizer: join order, index selection,bulk fetching, join strategies (nested loop or hash), sort avoidance, lock escalation, subquery flattening, transitive closure, and many other query transformations. It uses a unique sampling technique that requires no intervention for statistical gathering, and also provides query plan overrides and statistics on actual query results.
• Multi-column B-Tree indexes
• Unlimited length rows, and the capability of "streaming" column values to the client
• Data import/export with fast-load and fast-create index
• Transaction commit and rollback
• Transactional isolation (serializable, repeatable read, read committed, or dirty read)
• Crash recovery
• Multiple concurrent connections
• Multi-threaded connections
• Row locking with escalation to table locks
• User and connection authentication: built-in SH3, application-defined, or through external user authentication systems (LDAP, JNDI)
• Diagnostics and consistency checks
• Online database backup
• Locales
• Database encryption
• Script tool, ij
• DDL examination tool, dblook
• Modify column to change its length or nullability
• Identity default for automatic sequence numbers for data

Security features
Derby includes security features for protecting database access using standard Java features, encrypting databases so they may be deployed to remote sites and for integrating them into existing user authentication schemes.

Java 2 Security Manager
Derby can be run under a Java 2 security manager. In addition to support policy files, Derby can detect digital signatures on JAR files. Before loading a class from a signed JAR file stored in the database, Derby will verify the JAR was signed with a X.509 certificate and verify the validity of the signature.

Encrypted databases
When a database is deployed to a remote or mobile location, it is not possible to use physical security to prevent unauthorized access to data. If the data files can be read, a sophisticated user could decode the information they contain. The only way to secure data in this environment is to encrypt it on disk. That way, simply being able to read the database files does not reveal the data.

Derby supports secure remote data database encryption. All data in such a database is decrypted by the database engine when read and re-encrypted when written back to disk. No data exists in clear-text form in the database files. Since the entire database is encrypted, the structure of the database schema is also hidden.

For an encrypted database to be usable, a boot password must be provided when the database is first started. This is a separate password from the usual database connection username and password (which must also be supplied to access the database). Without the boot password, the database will not start.

Database encryption is useful for applications that distribute databases to locations where physical security of the files cannot be guaranteed. For example, mobile databases on notebook computers can be stolen if the notebook computer is stolen. Applications that are installed on remote multi-user machines are subject to unauthorized access if the remote administrator does not appropriately protect the files.

Database encryption adds less than 10% performance overhead, and takes no additional disk space. It is based on the 1.2.1 version of the Java Cryptographic Extension (JCE). Data Encryption Standard (DES) is used as a default encryption method, or the user can configure which algorithm to use.

External user authentication
Derby also provides support for integrating into external user authentication schemes. Rather than maintaining an internal list of authorized users, Derby can be configured to check with an external authentication service. Lightweight Directory Access Protocol (LDAP) support is provided, and custom schemes are supported with user-defined Java Naming and Directory Interface (JNDI) classes.

Not having the user names and passwords maintained in the database means less administrative overhead (to transfer names into the database). This is especially important in deployed server applications, which must be deployed with as little administrative overhead as possible.

LDAP is an emerging Internet standard that provides an open directory access protocol running over TCP/IP. Windows NT ™ domain user authentication can be provided through LDAP by using the Netscape NT Synchronization Service.

Because Derby is an embedded system, it provides simple user authorization controls. Users can be restricted to read-only access or restricted from any access on a per-system or per-database level. This ensures only permitted, authenticated users access or modify a database.

Java extensions
Derby supports the following Java extensions:

• Java functions
• Using Java functions in triggers
• Java stored procedures
• Loading Java classes from the database

The examples in the following sections assume that the ADDRESS table exists in a database along with the ZIPMAP table that maps ZIP codes to cities. Listing 2 shows the schema for the tables.

CREATE TABLE address (name VARCHAR(60), street VARCHAR(255), zipcode INTEGER)
CREATE TABLE zipmap  (zipcode INTEGER, city VARCHAR(255))

Java functions
A Java function consists of Java code that is callable from SQL. A Java function can be invoked anywhere in a SQL statement that a SQL expression is allowed. It can also be invoked with the VALUES key word and it can be invoked inside a trigger.

For example, Listing 3 creates a function in the ZipMap class that looks up the name of a city given its ZIP code (error and exception-handling code are ommitted for brevity).

public class ZipMap
{    
    public static String cityFromZipFunc (int zipcode)
    {
        String city;
        Connection conn = DriverManager.getConnection("jdbc:default:connection");
        String query = "SELECT city FROM zipmap WHERE zipcode = ?";
        PreparedStatement ps = conn.prepareStatement(query);
        ps.setInt(1, zipcode);
        ResultSet rs = ps.executeQuery();
        if (!rs.next())
            city = "Unknown City";
        else
            city = rs.getString(1);
        rs.close();
        ps.close();
        conn.close();
        return city;
    }
}

The SQL statement that creates a function for this Java code is shown in Listing 4:

CREATE FUNCTION cityFromZip (zipcode INTEGER)
RETURNS VARCHAR(255)
LANGUAGE JAVA 
PARAMETER STYLE JAVA
READS SQL DATA
EXTERNAL NAME 'com.acme.sales.ZipMap.cityFromZipFunc'

Once the cityFromZip function has been created, it can be invoked using theVALUES keyword or by referencing it in the SQL statement as shown in Listing 5.

VALUES cityFromZip(94105)

SELECT name, street, cityFromZip(zipcode), zipcode 
FROM   address

SELECT * 
FROM   address 
WHERE  cityFromZip(zipcode)='San Francisco'

Using Java functions in triggers
A SQL trigger specifies the actions that should occur when a SQL statement inserts into, updates, or deletes from a table. A Java function can be used in a trigger, for example, to provide e-mail notification about updates, perform updates in other databases through JDBC, or anything that can be done using Java programming. Here's an example of a trigger that calls a Java function to send an e-mail alert when a new record is inserted into the ADDRESS table.

CREATE TRIGGER newaddress AFTER INSERT ON address
REFERENCING NEW as NEW
FOR EACH ROW MODE DB2SQL
    VALUES(sendEmailAlert(NEW.name)) 

Java stored procedures
A Java stored procedure consists of Java code that is callable from SQL, runs in the database server, and accesses the database.

Derby supports the CALL statement for invoking a Java stored procedure. Derby supplies JDBC OUT parameters so that values can be returned in parameters; this is done by having the Java parameter be an array of the type desired. For example, an int parameter would be declared as int[] and a String parameter would be declared as String[] so a value could be returned in it. If the stored procedure includes any OUT parameters, it needs to be invoked from a client application using the CallableStatement interface. If the stored procedure does not include any OUT parameters, it can also be invoked using CALL in a tool that executes dynamic SQL statements, such as the ij tool.

A Java stored procedure that looks up the name of a city given a ZIP code might look like this (again, error-and exception- handling code are omitted for brevity):

public class ZipMap
{    
    public static void cityFromZipSp (int zipcode, String[] outCity)
    {
        Connection conn = DriverManager.getConnection("jdbc:default:connection");
        String query = "SELECT city FROM zipmap WHERE zipcode = ?";
        PreparedStatement ps = conn.prepareStatement(query);
        ps.setInt(1, zipcode);
        ResultSet rs = ps.executeQuery();
        if (!rs.next())
            outCity[0] = "Unknown City";
        else
            outCity[0] = rs.getString(1);
        rs.close();
        ps.close();
        conn.close();
        return;
    }
}

The stored procedure would be created as shown in Listing 8:

CREATE PROCEDURE cityFromZip ( IN zipcode INTEGER, OUT city VARCHAR(255) )
PARAMETER STYLE JAVA
LANGUAGE JAVA 
READS SQL DATA
EXTERNAL NAME 'com.acme.sales.ZipMap.cityFromZipSp'

As mentioned above, if a stored procedure includes OUT parameters, a client application executes the stored procedure using the CallableStatement method, as shown in Listing 9.

  public static String callOutCity(int zipCode, Connection con)
  {
    String outCity = "";
    try
    {
      // prepare the CALL statement 
      String procName = "CITYFROMZIP";
      String sql = "CALL " + procName + "(?, ?)";
      CallableStatement callStmt = con.prepareCall(sql);

      // Set the input parameter to the zipcode
      callStmt.setInt(1, zipCode);

      // Register the output parameter
      callStmt.registerOutParameter(2, Types.CHAR);

      // call the stored procedure
      System.out.println();
      System.out.println("Call stored procedure named " + procName);
      callStmt.execute();

      // retrieve output parameters
      outCity = callStmt.getString(2);
      System.out.println("City name is "
                         + outCity);
    }
    catch (SQLException e)
    {
      System.out.println(e);
    }
    return(outCity);
  }

Loading Java classes from the database
Java stored procedures, functions, or other application logic can be stored in the database along with the data, and the database can be programmed to load the classes from there. This makes the database data and its logic into a single, self-contained application package. This simplifies application deployment, because it reduces the potential for problems with a user's class path. It is particularly useful when the classes stored in the database contain the logic for data types used in columns in the database -- the database will not be dependent on anything outside of it.

Storage and loading of application classes in the database is provided by two mechanisms: the ability to add, remove and replace JAR files in the database,and the ability to add these JAR files to the class path.

Once the application code has been added to the database, moving or copying the database ensures that the appropriate application logic is moved along with the data. This means that object data will never be separated from its methods.

IBM Cloudscape Features
The Derby software includes so many capabilities, what more could you possibly want?

The IBM Cloudscape commercial product ships Derby and additionally includes:

• Technical Support
• IBM DB2 UDB Universal JDBC Driver for use with the Derby Network Server
• The IBM Cloudscape manuals, including translated manuals
• The Cloudscape Information Center
• Translated error messages
• Features to jump start developers who are new to Java and/or Derby, including:
  • Product installers for Windows and Linux that install the Java Runtime Environment (JRE) and generate Windows batch files and UNIX scripts for setting the environment.
  • Sample databases.

Summary
In this article you learned about the fundamental architecture of Derby and how it can be embedded inside a client or a server application. You learned about the use of standard JDBC calls to manipulate the data. You received a summary of the security mechanisms available in Derby. You also learned how to take advantage of Java integration to create Java functions and stored procedures.

Derby provides developers with a small footprint, standards-based Java database that can be tightly embedded into any Java-based solution. With its combination of robust SQL features, support for Java technology, security, and embeddable, pure Java architecture, Derby is the data management product of choice for data-driven Java applications. The value that the IBM Cloudscape commercial offering adds makes it easier than ever for Java developers to deploy their Java-based solutions.

第一步：选择XML-RPC实现。
XML-RPC的一个很大优势就是 它是一个标准，并且各种开发环境下都有实现（酷），这是它能够轻松跨平台的原因。
javascript有3个实现。我看了一下最好的应该是jsolait（JavaScript o Lait）的实现了。因为他不仅仅是一个xml-rpc的实现，除此之外还有很多javascript库,详细内容请看这里（http://jsolait.net/）。
java的实现就更多了，我当然毫不犹豫地选择apache的。详细内容看这里（http://ws.apache.org/xmlrpc/）

第二步：建立服务。
用java建立xml-rpc有两种方式，一种是单独开个端口，一种是用servlet。我们客户端是用javascript，那么服务端用servlet是再好不过的了。
如何使用apache的xml-rpc，请详细看apache的资料。（大哥你不会连servlet也不会建吧，那你还是不要往下看了）。
代码如下：
这是一个sayHello的服务类：

public class HelloService {
 
 public String sayHello(String name){
  return "Hello: "+name+" !";
 }

}

下面是一个Math服务类：

public class MathService {
 public double add(Vector v){
  double a = Double.parseDouble((String)v.get(0));
  double b = Double.parseDouble((String)v.get(1));
  return a+b;
 }
 
 public double mult(Vector v){
  double a = Double.parseDouble((String)v.get(0));
  double b = Double.parseDouble((String)v.get(1));
  return a*b;
 }
}

接着是Servlet啦，作为RPC Server用的，这段代码比较经典，很多资料上都有。

public class RpcServer extends HttpServlet {
 protected void doPost(HttpServletRequest request,
   HttpServletResponse response) throws ServletException, IOException {
  XmlRpcServer xmlrpc = new XmlRpcServer();
  xmlrpc.addHandler("HelloService", new HelloService());
  xmlrpc.addHandler("MathService",new MathService());
  byte[] result = xmlrpc.execute(request.getInputStream());
  response.setContentType("text/xml");
  response.setContentLength(result.length);
  OutputStream out = response.getOutputStream();
  out.write(result);
  out.flush();
 }
}

主要是这三句：
XmlRpcServer xmlrpc = new XmlRpcServer();
xmlrpc.addHandler("HelloService", new HelloService());
xmlrpc.addHandler("MathService",new MathService());
一定要记牢Handler的名字，就是第一个参数，因为客户端就靠他来表示要调用的方法呢。

行了现在可以在web.xml中写入配置了：

 <servlet>
  <servlet-name>RpcServer</servlet-name>
  <servlet-class>org.mstar.rpc.RpcServer</servlet-class>
 </servlet>
 <servlet-mapping>
  <servlet-name>RpcServer</servlet-name>
  <url-pattern>/RpcServer</url-pattern>
 </servlet-mapping>

至此，服务端的工作已经完成，启动应用服务器就行了。

下面是javacript的实现，这也是难点（其实不难理解，只是没有中文材料）。
把jsolait的库下来以后解压缩，得到一些js文件，具体我就不说了。

建立一个html文件：

<html>
<head>
<title>XML-RPC</title>
<script type="text/javascript" src="./js/init.js"></script>
<script type="text/javascript" src="./js/lib/urllib.js"></script>
<script type="text/javascript" src="./js/lib/xml.js"></script>
<script type="text/javascript" src="./js/lib/xmlrpc.js"></script>
<script type="text/javascript" src="./js/hello.js"></script>
</head>
a:<input type="text" id="a" /><br>
b:<input type="text" id="b" /><br>
<input type="button" id="do1" value="a+b" onclick="add()"/>
<input type="button" id="do2" value="say" onclick="hello()"/>
<input type="text" id="result" />
</html>

注意到前面那一堆javascript的引用吗？就这么写吧。可别把hello.js当成solait的东西啦（看名字也知道啦），你是找不到的。这是我们自己写的：
hello.js

hello = function(){
 var xmlrpc=null;
 try{
     var xmlrpc = importModule("xmlrpc");
 }catch(e){
     reportException(e);
     throw "importing of xmlrpc module failed.";
 }
 var addr = "http://localhost:8080/Rpc/RpcServer";
 var methods = ["HelloService.sayHello"];
 var rslt;
 
 try{
        var service = new xmlrpc.ServiceProxy(addr, methods);
        rslt = service.HelloService.sayHello("MTY");
    }catch(e){
        var em;
        if(e.toTraceString){
            em = e.toTraceString();
        }else{
            em = e.message;
        }
        rslt = "Error trace: \n\n" + em;
    }
 document.getElementById("result").value=rslt;
}
add = function(){
 var xmlrpc=null;
 var a = document.getElementById("a").value;
 var b = document.getElementById("b").value;
 var params = new Array();
 params[0] = a;
 params[1] = b;
 try{
     var xmlrpc = importModule("xmlrpc");
 }catch(e){
     reportException(e);
     throw "importing of xmlrpc module failed.";
 }
 var addr = "http://localhost:8080/Rpc/RpcServer";
 var methods = ["HelloService.sayHello","MathService.add"];
 var rslt;
 
 try{
        var service = new xmlrpc.ServiceProxy(addr, methods);
        rslt = service.MathService.add(params);
    }catch(e){
        var em;
        if(e.toTraceString){
            em = e.toTraceString();
        }else{
            em = e.message;
        }
        rslt = "Error trace: \n\n" + em;
    }
 document.getElementById("result").value=rslt;
}

这个js文件中有两个函数，一个负责从sayhello，一个负责加法运算。
这里需要一些解释的地方：
1、
 var xmlrpc=null;
 try{
     var xmlrpc = importModule("xmlrpc");
 }catch(e){
     reportException(e);
     throw "importing of xmlrpc module failed.";
 }
这里是把xmlrpc模块引进来,你也就这么写吧，我也不知道为什么。
2、
 var addr = "http://localhost:8080/Rpc/RpcServer";
 var methods = ["HelloService.sayHello"];
定义服务地址和要用的方法名。规则大概你也能看懂：Handler名.方法名。这里的Handler名就是你在xmlrpcServer中注册名，就是我上面让你记住的那个。方法名就是那个类自己的方法名。注意，methods是一个数组，所以可以写多个方法，如第二个例子。var methods = ["HelloService.sayHello","MathService.add"];
3、
    try{
        var service = new xmlrpc.ServiceProxy(addr, methods);
        rslt = service.HelloService.sayHello("MTY");
    }catch(e){
        var em;
        if(e.toTraceString){
            em = e.toTraceString();
        }else{
            em = e.message;
        }
        rslt = "Error trace: \n\n" + em;
    }
通过new xmlrpc.ServiceProxy(addr, methods);得到服务代理。
然后调用服务的方法就行了，方法就是代理.Handler名.方法名（参数）。好像参数只能有一个，在第二个例子中我开始有两个参数a,b会发生错误。怎么办？没办法，在javascript用Array传参数，在java用Vector接参数（为什么用Vector，因为xml-rpc规范中的Array，apache使用Vector实现的，为什么javascript不用Vector，因为js没有Vector，且js的的Array是可变长的）。当然这就需要很多java端类型转换工作，js是弱类型的就不用转换了。

The New Holy Trinity

No, this isn't a religious post. It's about an approach to developing applications. I'm not the only one advocating this approach, and I'm not the first to write about some of the ideas here. What I want to do in this post though is put all the pieces together in one place and boil the approach down to its essence to give you a simple way of thinking about it. So here it is:

Dependency injection, annotations, and aspects are the three foundations on which the next generation of world-class POJO-based applications should be built.

At the centre of an application designed according to this principle are plain-old Java objects (POJOs). Each POJO should do one thing and one thing only. Each POJO should also know one thing and one thing only - how to do what it is that it does. This is the 'secret' that the the POJO hides from the rest of the application. So for example, a BankAccount POJO should know about the internal state of a bank account, and the operations that it supports. It should not know anything about the way any services it needs are created or deployed. It should not know anything about the authentication or authorization requirements that may be placed on it in a particular deployment scenario - or worse still, anything about the implementation of authenticaton and authorization services in the environment in which it is deployed. It should not know anything about account activity monitoring to detect potentially fradulent use. And so on.

I've written about this notion of a 1:1 mapping between distinct concepts in the design and constructs (types) in the implementation before in "AOP without the buzzwords" (this essay was also updated and expanded to form the introduction for our book, Eclipse AspectJ).

To use some old software engineering terms, what's at the centre of applications designed according to these principles are highly cohesive POJOs. These POJOs are very loosely coupled to the rest of the application. In particular, if you look at the three sides of the triangle in the illustration, you'll see that dependency injection ensures the POJO remains unaware of any of the details of how its dependencies are instantiated and configured. DI shields the POJO from this information. Aspects ensure the POJO remains unaware of any crosscutting concerns in the application (such as the account activity monitoring concern in the example above). Aspects are what enable the POJO to focus on doing just one thing and to do it well. Annotations provide additional metadata about the POJO that facilitate easy integration with external services (such as transaction services). They ensure that the POJO remains unaware of any of the details of such services. Annotations coupled with aspects can do much more than this though - they also support the creation of domain specific abstractions that easily bring back to the programmer Abelman and Sussman's often missing third tool in the war against software complexity: the creation of "little languages" (see my post "A Beautiful Language").

This leads me to a really important point about this trinity of DI, aspects, and annotations. The three techniques are mutually self-reinforcing, the whole is much greater than the sum of the parts.

Dependency injection can be used to configure aspects. This is important since when you're building an application using the 1:1 principle, some of the POJOs in the centre of the triangle will themselves be aspects (in a language like AspectJ, this is perfectly natural). Anecdotal evidence from a number of projects across a number of organizations suggests that maybe about 10% of your "POJOs" will be aspects. Dependency injection can also be guided by annotations. You see an example of this in the EJB 3.0 specification (you may recall my own thoughts on the suitability of the chosen annotation name in that spec "What's wrong with @Inject?", but that's not material to this discussion). Completing the circle, aspects can also be used to implement dependency injection scenarios. In general you're best leaving this job to an IoC container, but if you have DI requirements that go beyond the wiring of beans as they are instantiated by the container, aspects are a great solution. To give a couple of examples, in the Eclipse AspectJ book we use aspects to implement a 1:1 design for POJO persistence using Hibernate. We use dependency injection on a per-request basis to inject the Session object that DAOs use for communicating with Hibernate. A second example is the use of an annotation @SpringConfigured(beanName="XXX") on POJOs. It's easy to write an aspect (configured by DI to be BeanFactoryAware in Spring terms) that uses Spring to autowire any instance of an @SpringConfigured object when it is instantiated. This lets you separate instantiation and configuration (normally an IoC container like Spring does both for you) so that you can place instantiation under programmatic control, but still get configuration via DI.

Let's look at another really important way in which these techniques work together. Annotations on their own give you a way of specifying additional metadata for program elements. This is useful when you have tools or services that can understand those annotations and do something with them. Annotations coupled with aspects is a whole other ball game altogether. Aspects let you use annotations to easily implement declarative domain-specific languages (DSLs) as part of your application (or aspect library). This is a really big deal. Aspects can do this since they let you associate behaviour with join points relating to annotated elements. To give an example I've written about recently ("Making Concurrency a Little Bit Easier"), you can easily write a set of annotations that form a declarative DSL for concurrent applications (the domain of this DSL is concurrency). Another example I'll write about in my next post: after attending Gregor Hohpe's talk at TSS yesterday on event-driven architectures I quickly implemented an annotatation-based DSL ("@DSL") for simple event-driven applications. It took me less than an hour. That's pretty powerful (you can judge for yourself when you read the post). Annotations plus aspects let you write these @DSLs.

When you're using @DSLs like this in the construction of your application, you're going to want an aspect language that has rich support for join point matching based on annotations. There's a surprising amount to this, and you can see how AspectJ 5 handles it by reading the "Annotations" chapter of the AspectJ 5 Developer's Notebook.

There's another way in which the combination of aspects and annotations are self-reinforcing too. If you are using an annotation-driven tool or service for a particular deployment of your application, you may need to annotate your POJOs with annotations specific to that tool or service. If you don't want to tie your POJOs to that annotation set (see "When is a POJO not a POJO?") you can use the AspectJ 5 support for "declare annotation" to keep the annotations separate and maintain a loose coupling. You might also want to use declare annotation if a particular tool or service requires you to spread information you consider to be configuration information around your source code (in the form of annotations). Here an aspect using declare annotation can at least get that all back in one place for you.

If this all sounds a bit circular (DI of aspects, aspects to perform DI, annotations to control aspect behaviour, aspects to declare annotations,...) that's because it's meant too. The sides of the triangle all support each other and can be used together in many different ways to meet the needs of your particular situation. The whole is much greater than the sum of the parts.

In summary, I believe that dependency injection, annotations, and aspects are the three foundations on which the next generation of world-class POJO-based applications should be built. At the heart of such applications are POJOs that do one thing only and do it well. The triangle illustration provides a simple visual mnemonic to help you remember the principles. An application constructed according to these principles could be said to follow a "triangle design". You can even easily communicate your design intentions in good old ascii:

        /o\
	 -
	

In my previous blog post I found several reasons for using DTOs instead of using the domain model classes as transfer objects. I received some feedback and several people were saying that DTOs are a thing of the past and should be now considered an anti-pattern.

My main argument in favor of using DTOs was that they provide protection for the domain model and facilitate easier refactoring. The domain model needs to be protected from getting polluted with presentation related concerns. Refactoring would be easier if you could change the domain model classes without the client code being affected. This would be possible if the client was not dependent on the domain model classes directly. When using DTOs the dependency is not direct, the DTO classes provide some isolation. Effective refactoring is necessary in order to achieve a working domain model and not end up with an anemic one.

In this post I will discuss some other ways to protect the domain model and to facilitate effective refactoring. This time I am assuming that domain model classes are exposed to clients and DTOs are not used.

Avoid Anemic Setters

I learned the term "anemic setter" from the Spring forum's architecture discussions. An anemic setter is a setter that uses a primitive (or a String or some other JDK type) as it's parameter type and assigns the parameter value value to the domain object's field. In some cases anemic setters should be avoided. For example if your Customer object stores an address it probably should not expose setters for individually assigning the street address, the zip code and the country. Instead the address should be modeled as a separate Address object and the Customer should have a setter that takes the Address as a parameter. Or alternatively, the Address could be specified when the Customer is created. The latter is probably better if every Customer must have a valid Address. The Address class must also enforce that all it's component values are provided when instances of it are created.

This arrangement guarantees that the Customer state is never corrupted. A buggy or malicious client is not able to assign a partial address consisting of, for example, only the zip code. The anemic setters design relies that all clients, in all situations, use all three different setters when storing or modifying addresses.

The lack of anemic setters places some challenges for the data binding solution. A primitive binding framework might require that all fields coming from the UI (HTTP request or a Swing form) must be stored using anemic setters.

Domain Logic Only

The domain model should contain only logic from the core domain. Presentation logic should never find it's way to the domain model classes. So what is the proper place for presentation related functionality then? Here are two options:

• Create separate model classes (MVC models, form objects)

• Use AOP to ensure that domain model classes are only concerned with the core domain. Here is a great article about "next generation of world-class POJO-based applications".

Unusable Methods with a Distributed Environment

I discussed unusable methods in my previous blog entry. I haven't figured out how to avoid them. AOP magic comes to my mind again here... Does anyone have suggestions?

Evolving the Architecture

My recipe for success follows here.

Start simple and use the domain model throughout the the system, including the presentation and other types of clients. This way you will be enjoying the benefits of the domain model everywhere. Your client code will appear to be speaking the domain specific language.

After this you need to keep your eyes open all the time. Look at your domain model:

• Is it alive and rich with domain logic?

• Has the domain logic leaked out of the domain model?

• Has non-core functionality leaked into the domain model?

• Is refactoring painful and hurting domain model evolution because you are  worrying about breaking hard-to-change client code?

If these kind of signs are visible, it is time to refactor. Maybe some additional UI specific helper classes or model classes are necessary to host the presentation logic that was leaked into the domain classes. Or maybe you even
need to introduce command classes (or DTOs) to isolate the domain model in some troubled area. You need to be alert all the time to be able to react quickly. Even better, you can refactor the architecture before adding anything that would lead to a problematic design.、

我认为也不必过于死板的非得隔离domain model曾。model仅仅是一个数据载体，一般人不会在其中加入logic。但是有些时候persistent层的model要的数据和domain层要得数据不一致，我看到有些人在domain层的model中加入一些东西，这样这个model即可以用在persistent层也可以用在domain层。这样是很方便，但是破坏了结构。在这种情况下，不如在建立一个persistent层的model用户装载数据。当然如果domain层的model在不做改变的情况下就可以被persisitent层使用，那也不一定非得建立一个一模一样的persistent层的model（当然如果你愿意，我也不拦你）。

David Currie 将继续他的由三部分组成的系列文章，介绍 Java 2 企业版（J2EE）连接器架构（JCA）最新版本中的增强和变化。在本文中，他将介绍新的 JCA 1.5 工作管理合约，该合约允许资源适配器利用应用服务器的某些功能来调度和处理工作。在 JCA 的另一个增强 —— 事务流入 —— 的支持下，企业信息系统可以在自己的事务中执行这项工作。

JCA 1.5 是 J2EE 连接器体系结构的最新版本，它包含许多重要的改进和一些重要增强。本文是介绍这些变化的由三部分组成的系列文章的第 2 部分，建立在介绍的生命周期管理特性的第 1 部分的基础上，本文介绍的是 JCA 新的工作管理合约。该合约允许资源适配器为延迟执行或定期执行的工作创建计时器，并允许计时器使用应用服务器的线程同步或异步执行处理。本文将描述事务流入支持如何在资源适配器导入到服务器的事务中进行这种处理，以及资源适配器随后如何控制事务的完成。

如果想在现有资源适配器中使用这项功能，或者正在考虑编写新的 JCA 1.5 资源适配器，那么本文是一份必不可少的读物。如果要编写使用资源适配器的应用程序，想了解更多幕后的情况，那么本文也会吸引您。

让工作完成
在本系列的第 1 部分中，我们介绍了 ResourceAdapter 接口，它提供了一种机制，能够在应用服务器内部为资源适配器提供生命周期。您可能还记得 start 方法被用来传递一个叫做 BootstrapContext 的对象。上次我们介绍了这个对象，但是 BootstrapContext 接口的三个方法才是工作管理和事务流入合约的关键，如清单 1 所示：

public interface BootstrapContext {

    WorkManager getWorkManager();
    XATerminator getXATerminator();
    Timer createTimer() throws UnavailableException;

}

WorkManager 允许资源适配器对工作进行调度，在应用服务器线程上同步或异步执行调度。这个工作可以在资源导入的事务中执行，在这种情况下，XATerminator 有助于完成工作。Timer 负责延迟工作或定期工作的执行。本文将更深入地研究这三个类，并说明如何使用它们。

WorkManager 接口提供了三套处理工作的方法（doWork、 startWork 和 scheduleWork)，如清单 2 所示：

public interface WorkManager {
    
    void doWork(Work work) throws WorkException;
    void doWork(Work work, long startTimeout, ExecutionContext execContext,
            WorkListener workListener) throws WorkException;

    long startWork(Work work) throws WorkException;
    long startWork(Work work, long startTimeout, ExecutionContext execContext,
            WorkListener workListener) throws WorkException;

    void scheduleWork(Work work) throws WorkException;
    void scheduleWork(Work work, long startTimeout,
            ExecutionContext execContext, WorkListener workListener)
            throws WorkException;
    
}

每个方法接收的第一个参数，都是实现 Work 接口的对象的一个实例，如清单 3 所示：

public interface Work extends Runnable {

    void release();
    
}

Work 接口扩展了 Runnable 接口，您应当像直接进行 Java 线程编程时所做的那样，实现run 方法中执行的工作。您很快就会看到 release 方法发挥其作用的地方。

WorkManager 上的 doWork 方法可以让一些工作同步执行、一直受阻塞或者直到某些工作完成才执行。这看起来可能不是特别有用——这不就是直接调用 run 方法时发生的事情吗？并不完全如此。首先，它让应用程序服务器说明现在不是做这项工作的恰当时候。例如，如果在 ResourceAdapterstart 方法的范围内调用 doWork，那么您可能发现它将抛出 WorkRejectedException 异常。应当尽快从这个方法返回，如果可能的话，应当把工作安排成异步处理。

第二，如果应用服务器特别繁忙，那么它可能会推迟这项工作的启动。可以用第 2 个startTimeout 参数指明资源适配器准备为工作启动等候多长时间。如果应用服务器没能在这个时间内启动工作，那么就会抛出 WorkRejectedException 异常。WorkManager 接口定义了常量 IMMEDIATE 和 INDEFINITE，它们允许资源适配器指明自己根本不准备等候或者准备一直等候下去。

第三，正如下一节解释的，有可能让工作片断在资源适配器导入的事务上下文中执行，而不是在与当前线程关联的上下文中执行。这正是第 3 个参数的用途，该参数是一个可选的 ExecutionContext。

最后，使用 doWork 方法让应用服务器对资源适配器执行的工作拥有更多控制。在关闭应用服务器时，如果资源适配器夹在一个漫长的、复杂的操作中间，那么服务器不需要等待资源适配器完成，或者被清理干净。相反，服务器可以通过调用 Work 对象的 release 方法，给资源适配器发信号。然后资源适配器应当尽快完成处理。清单 4 显示了 release 方法使用的一个示例：

public class ExampleWork implements Work {

    private volatile boolean _released;

    void run() {
        for (int i = 0; i < 100; i++) {
            if (_released) break;
            // Do something
        }
    }

    void release() {
        _released = true;
    }
    
}

注意清单 4 中使用的关键字 volatile。在 run 方法正进行其处理的同时，会在一个独立的线程上调用 release 方法，volatile 修饰符确保 run 方法能够看到更新的字段。

doWork 方法也可能失败，抛出一个名称古怪的 WorkCompletedException 异常。这个异常是在将 run 方法分配给一个线程时抛出的，但这个异常或者是上下文设置失败，或者是通过抛出运行时异常退出方法。doWork 方法会提供一个错误代码，表示这些故障发生的路径，还把问题原因作为链接的异常提供。

为什么等待？
您已经看到 doWork 方法允许您在调用线程阻塞的同时执行工作。但是如果您不想等待 —— 也就是说，如果您不想同步执行工作，该怎么办呢？在 Java 2 平台标准版本（J2SE）环境中，可以使用多线程实现这一目标。但是，J2EE 规范让应用程序服务器使用 Java 2 安全管理器防止应用程序离开自己的线程。如果应用服务器的这部分功能是通过 EJB 池或 servlet 池来提供并发性，那么这样做是合理的。服务器也可能想把各种形式的上下文都关联到一个线程上，因为产生新线程时，上下文可能会丢失。最后，正如我以前讨论过的，不受服务器控制的线程会造成有序关机很难实现。

虽然可以通过使用安全策略，逐个案例地克服这个限制，但是 WorkManager 上的 startWork 和 scheduleWork 方法可以让资源适配器异步地处理工作，同时确保应用程序服务器仍然在控制之下。startWork 方法会一直等候，直到工作片断开始执行，但不用等到工作结束。所以，如果调用器需要知道工作是否已经得以执行，但是不需要等到工作完成，那么可以使用这种方法。相比之下，只要该工作调度被接受，scheduleWork 方法就立即返回。在这种情况下，并不能确保工作真的被执行。

清单 2 中的 WorkManager 方法的第 4 个参数（WorkListener）在用于这些异步方法时最有用。清单 5 显示了这个接口：

public interface WorkListener {

    void workAccepted(WorkEvent e);
    void workRejected(WorkEvent e);
    void workStarted(WorkEvent e);
    void workCompleted(WorkEvent e);
    
}

资源适配器能够有选择地传递一个监听器，当工作的项目通过接受、启动或完成这几个状态（失败的情况下则是拒绝）传递过来时，监听器会得到通知。在这个监听器已经完成其工作项目，或者出现故障要重新安排工作项目时，可以用它将通知发送给工作的发起者。WorkAdapter 类也包含在内，它提供了所有方法的默认实现，因此，子类只需覆盖自己感兴趣的方法即可。

WorkListener 的每个方法都采用 WorkEvent 对象作为参数，如清单 6 所示：

public class WorkEvent extends EventObject {

    ...

    public int getType() { ... }
    public Work getWork() { ... }
    public long getStartDuration() { ... }
    public WorkException getException() { ... }
 
}

除了通常的事件方法之外，WorkEvent 类还为这些类型的事件 （接受、拒绝、启动或完成）以及有问题的工作项目提供了存取器。这使您能够用一个（多线程的）监听器负责多个工作提交。还有一些方法可以返回启动工作所花费的时间，而且，在出现 workRejected 或 workCompleted 时，返回可能发生的对应的 WorkRejectedException 或 WorkCompletedException 异常。

图 1 显示了通过 Work 对象传递的状态。

图 1. Work 对象的状态

沿着图 1 的底部，有三种提交方法，从上到下的点线表示具体的方法返回的生命周期中的时间点。

可以推迟到明天的事为什么要现在做？
doWork、startWork 和 scheduleWork 方法可以都立即向 WorkManager 提交任务。在 WorkManager 执行提交之前，可能会发生延迟，但是调用者只能控制最大延迟（用启动超时）。那么如果想让任务晚些而不是立即处理，该怎么办呢？scheduleWork 方法只允许将工作安排到另一个线程，而不是安排到时间轴上的以后某个时间点上。

这正是 BootstrapContext 接口的第 3 个方法发挥其作用的地方。createTimer 方法使资源适配器能够得到 java.util.Timer 类的实例。这个类从 1.3 版开始就已经成为标准 Java 库的一部分，如清单 7 所示：

public class Timer  {
 
    public void schedule(TimerTask task, long delay) { ... }
    public void schedule(TimerTask task, Date time) { ... }

    public void schedule(TimerTask task, Date firstTime, long period) { ... }
    public void schedule(TimerTask task, long delay, long period) { ... }
    public void scheduleAtFixedRate(TimerTask task, Date firstTime, long period) { ... }
    public void scheduleAtFixedRate(TimerTask task, long delay, long period) { ... }

    public void cancel() { ... }
 
}

可以用 java.util.Timer 类的前两个方法把任务安排在指定延迟之后或指定日期和时间发生。余下的 4 个调度方法还有额外的 period 参数。可以用它们对那些初次运行之后需要按照常规间隔发生的事件进行调度，使用周期参数指定时间间隔。schedule 和 scheduleAtFixedRate 方法是不同的方法，因为这些操作的计时无法保证；像垃圾搜集这样的操作可能会造成任务推迟执行。如果任务被延迟，那么 schedule 方法在运行下一个任务之前仍然会等候一个完整的周期。但是，scheduleAtFixedRate 方法是在前一个任务 应当 运行的固定周期之后运行下一个任务。所以，如果任务之间的时间对您非常很重要，那么请使用 schedule。如果绝对时间或累积时间很重要，那么请使用 scheduleAtFixedRate。

每个 schedule 方法都采用一个扩展了 TimerTask 类的对象作为自己的第一个参数。同使用 Work 接口时一样，这个类扩展了 Runnable ，而且 Timer 会在适当的时间调用 run 方法。TimerTask 类有一个 cancel 方法，可以用它取消对任务的后续调用。或者，也可以调用 Timer 上的 cancel 方法来取消目前安排的所有任务。scheduledExecutionTime 方法允许 run 方法将当前实际调用时间和它应当被调用的时间进行比较。

虽然 TimerTask 的 run 方法是在新线程中调用 ，但是这个线程是 JVM 已经分配的线程，处于应用服务器的控制之外。如果您想让资源适配器进行严肃的处理，那么在这个时候，应当用 WorkManager 切换到应用服务器的线程。清单 8 显示的示例采用了这一良好实践来调度工作，从当前时间开始每分钟执行一次：

final WorkManager workManager = context.getWorkManager();
final Timer timer = context.createTimer();

timer.scheduleAtFixedRate(new TimerTask() {
    public void run() {
        workManager.scheduleWork(new ExampleWork());
    }
}, 0, 60 * 1000);

JCA WorkManager 和 Timer 的替代方案
正如前一小节提到过的，在 JCA 中，使用 Timer 有一个问题：执行 TimerTask 的线程不在应用服务器的控制之下。因为 Timer 是类而不是接口，而且线程实际是在类的构造函数中产生的， 所以应用服务器不能修改这种行为。允许应用服务器实现这一目的一个替代方案就是使用由 IBM 和 BEA 联合开发的 Timer and Work Manager for Application Servers 规范的接口（请参阅 参考资料） 。

在使用这个规范的接口时，会从 Java 名称与目录服务接口（JNDI）得到一个 TimerManager 实现。可以通过给管理器安排了一个 TimerListener 实现来返回一个 Timer （是一个commonj.timers.Timer 而不是 java.util.Timer）。在安排好的时间上会调用 TimerListener，可以用 Timer 执行诸如取消预定操作之类的操作。

顾名思义，这个规范还提供了 JCA 工作管理的一个替代。这里的接口与 JCA 的那些接口很相似，除了初始的 commmonj.work.WorkManager 是从 JNDI 得到的。这个合约提供的附加行为还包括：阻塞到一个或全部预定工作完成的能力、在远程 JVM 上执行可以序列化的工作的可能性。与 commonj Timer 一样，commonj WorkManager 的应用不限于资源适配器。任何服务器端 J2EE 组件都可以使用这项功能。

清单 9 显示了为了使用 commonj 的类而被重写的 清单 8 的示例：

final InitialContext context = new InitialContext();
final WorkManager workManager = (WorkManager) 
        context.lookup("java:comp/env/wm/MyWorkManager");
final TimerManager timerManager = (TimerManager)
	context.lookup("java:comp/env/timer/MyTimer");

timerManager.scheduleAtFixedRate(new TimerListener() {
    public void timerExpired(final Timer timer) {
        try {
            workManager.schedule(new ExampleCommonjWork());
        } catch (final WorkException exception) {
        }
    }
}, 0, 60 * 1000);

ExampleCommonjWork 类与 清单 4 的 ExampleWork 相同，此外，它还实现了 commonj Work 接口要求的额外的 isDaemon 方法。如果工作长期存在，那么该方法应当返回 true。

导入事务并完成事务
在 JCA 1.5 之前，应用服务器总是充当事务的协调者。应用程序负责器负责启动事务，而且在每个资源管理器通过 JCA 连接管理器登记了自己的 XAResource 之后，还通过一起提交或回滚所有资源来协调事务的完成。JCA 1.5 的事务流入合约允许企业信息系统（EIS）启动和完成事务，充当事务的协调者。这样 EIS 就能通过资源适配器把事务导入应用服务器，并在事务范围内在服务器上执行工作。例如，它可能使用 Supports 的容器管理器事务属性来调用消息驱动 bean（MDB）。这样，MDB 方法执行的工作，包括对其它 EJB 的调用，就会成为事务的一部分。

资源适配器通过第 3 个 ExecutionContext 参数导入事务，在 清单 2 中可以看到它被传递给 WorkManager。正如在清单 10 中可以看到的，这个类拥有设置事务 ID （XID） 和事务超时的方法：

public class ExecutionContext {

    public ExecutionContext() { ... }
    public void setXid(Xid xid) { ... }
    public Xid getXid() { ... }
    public void setTransactionTimeout(long timeout)
        throws NotSupportedException { ... }
    public long getTransactionTimeout() { ... }    
    
}

XID 惟一地标识事务，它由三部分构成：格式标识符、事务界定符和分支界定符。如果 EIS 还没有事务的 XID，那么就必须根据 XA 规范（请参阅 参考资料）构建一个 XID。然后应用服务器会在调用工作对象的 run 方法之前把这个事务与执行线程关联起来。

把事务导入应用服务器之后，接下来就由资源适配器负责把属于这个事务的事件通知给服务器。具体地说，它必须把事务完成通知给应用服务器。它是通过清单 11 中的 XATerminator 接口做到这一点的，可以从 BootstrapContext 中得到它的实现：

public interface XATerminator {

    void commit(Xid xid, boolean onePhase) throws XAException;
    void forget(Xid xid) throws XAException;
    int prepare(Xid xid) throws XAException;
    Xid[] recover(int flag) throws XAException;
    void rollback(Xid xid) throws XAException;
    
}

XATerminator 接口的方法与 XAResource 上的方法对应，只是在这个例子中，资源适配器需要调用应用程序服务器。典型情况下，如果事务中包含不止一个资源，那么资源适配器会调用 XATerminator 的 prepare 方法，传递与 ExecutionContext 中传递的 Xid 相同的 Xid。如果所有的资源都返回 XA_OK （或者 XA_RDONLY），那么资源适配器会接着调用 commit；否则就会调用 rollback。

结束语
本文介绍了如何用 WorkManager 接口对工作进行调度，以便在应用程序的控制下处理这些工作。您已经看到如何用 Timer 的实例在以后某个时间执行工作或定期执行工作，还了解了使用 JCA 提供的对象的 commonj 替代方案。您已经看到资源适配器如何在自己导入到应用服务器的事务中执行工作，并用 XATerminator 接口控制事务的完成。在本系列的第 3 篇也是最后一篇文章中，我将介绍 JCA 1.5 消息流入合约，它比较出名的地方是对消息驱动 bean 的支持。

本系列共三部分，在第一部分中，Java 开发人员 David Currie 介绍了 Java 2 Enterprise Edition (J2EE) Connector Architecture (JCA) 1.5 中所作的一些优化，它们可以加快现有或新外部资源适配器的运行速度。他还分析了一些使资源适配器焕发生机的新功能。若想提高现有资源适配器的性能或要加入新的功能，或者正在考虑编写新的 JCA 1.5 资源适配器，那么本系列是必不可少的。若要编写使用资源适配器的应用程序，并想知道更多的幕后情况，那么本系列也值得一读。

JCA 1.5 是 J2EE Connector Architecture 的最新版本，它包含了许多重要的增强和新增功能。讨论这些变化的系列文章分为三个部分，本文是第一部分，将介绍该版本中所作的一些优化，它们可以加快那些使用出站资源适配器的应用程序，特别是那些使用事务的应用程序的运行速度。然后介绍对生命周期管理契约所作的扩展，它们可以防止应用程序的连接断开，并使资源适配器焕发新生。这将为第 2、3 部分奠定基础。第 2 部分讨论新的工作管理和事务流入契约，第 3 部分探讨期待已久的消息流入契约，其更常见的叫法是消息驱动的 bean (MDB) 支持。

本文假定读者对 JCA 连接管理契约有一定的了解。原来 1.0 规范中的所有内容仍然适用，因此如果刚刚接触 JCA，建议先看一看 Willy Farrell 的入门教程（请参阅 参考资料）。

连接加快
JCA 规范的新版本不会使应用程序与后端系统之间的连接变得更快，但 JCA 1.5 引入了两组接口，可以加快使用连接的应用程序的运行。第一组接口解除了以前 JCA 版本中应用服务器管理连接句柄方式的限制。

许多读者都知道，J2EE 支持两种连接使用模式，本文称之为 get-use-close 和 cached-handle。对这些模式的进一步分析有助于理解 JCA 1.5 在这方面所带来的性能改善。

get-use-close
在 get-use-close 模式中，应用程序在需要新连接时，总是先获取新连接，然后使用，然后再关闭它，如清单 1 所示。（为清楚起见，本文没有在示例清单中加入异常处理逻辑。）

public class GetUseCloseEJB implements SessionBean {

    ...

    public void businessMethod() {

       InitialContext context = new InitialContext();
       DataSource dataSource = (DataSource)context.lookup("java:comp/env/jdbc/mydatasource");
       Connection connection = datasource.getConnection();

       ...

       connection.close();

    }

}

get-use-close 模式看起来效率不高，但是应用服务器实现的连接池可降低“获得”操作的成本。此外，因为应用程序只在需要时才保留连接，所以应用程序的不同实例或者部分可以重复使用该连接，从而降低了总的资源占用，如图 1 所示。

图 1. 使用中的 get-use-close 模式

如图 1 所示，每当 bean 方法调用 getConnection 时，连接管理器都会重复使用池中托管的连接，并只创建一个新连接句柄。当连接句柄通知连接管理器它已关闭时，托管的连接就被清除并返回池中。图 1 中的绿色线条表示托管连接与应用程序的这个实例相关联的时间。

cached-handle
在 cached-handle 模式中，应用程序在一开始是获得连接，然后在一个实例字段中缓存对它的引用，如清单 2 所示。

public class CachedHandleEJB implements SessionBean {

    private Connection _connection;

    ...

    public void ejbCreate() {

       InitialContext context = new InitialContext();
       DataSource dataSource = (DataSource)context.lookup("java:comp/env/jdbc/mydatasource");
       _connection = datasource.getConnection();

    }

    public void businessMethod() {

       ...

    }

}

应用程序开发人员通常都使用 cached-handle 方法，因为他们认为这样应用程序的性能会更好。但是因为 get-use-close 模式中连接池的作用，这两种使用模式的性能差别一般来说是很小的。尽管 cached-handle 模式可使业务方法中的逻辑更简单，但是需要额外的逻辑以便在钝化（passivation）时关闭连接，并在激活时重建连接。当容器毁坏 bean 时（如由于方法生成了一个运行时异常），还有可能留下打开的连接。

cached-handle 模式的最大问题是当 bean 或者 servlet 的一个实例使用该连接时，其他实例就不能使用它——因此连接数最多只会有实例那么多。如图 2 所示。

图 2. 使用中的 cached-handle 模式

从图 2 中可以看到，创建 EJB 时（从绿色线条开始），托管的连接与连接句柄关联，并且这个 bean 实例以外的任何其他对象都不能使用这个连接。（绿色线条无限延伸。）

针对这种情况，JCA 1.5 规范引入了两个新的接口，如清单 3 所示。

public interface DissociatableManagedConnection {

    void dissociateConnections() throws ResourceException;

}

public interface LazyAssociatableConnectionManager {

    void associateConnection(Object connection,
                             ManagedConnectionFactory mcf,
                             ConnectionRequestInfo cxReqInfo)
            throws ResourceException

}

解除关联
资源适配器的托管连接实现第一个接口—— 解除关联 接口——以向连接管理器表明适配器支持这种优化。当连接暂时超出范围时（即当 bean 或者 servlet 方法退出时），如果连接管理器支持这种优化的话，它就可以解除由应用程序使用的连接句柄与表示物理资源的托管连接的关联。这使托管连接可以返回连接池，为应用程序的其他部分所使用。

惰性关联
这种优化使用 惰性关联，而不是在下次调用方法时重新将连接句柄与托管连接关联。如果方法没有使用连接，或者它只调用连接句柄上不需要访问后端的简单方法，那么托管连接未必会从池中移出。相反，当连接句柄确定它不需要与一个托管连接重新关联时，它就可以将连接管理器强制转换为 LazyAssociatableConnectionManager 并调用 associateConnection 方法。该方法以连接句柄为第一个参数，然后是托管连接厂，以及对 allocateConnection 的第一次调用时传递的请求信息。然后连接管理器从池中找到另一个合适的托管连接，并使用这个托管连接的 associateConnection 方法将它与连接句柄关联。

图 3 显示了这种优化对 图 2 中的 cached-handle 用法的效果。

图 3. 惰性关联降低资源用量

图 3 中虚线箭头表示方法完成时 EJB 容器对连接管理器的通知。这时，托管的连接与连接句柄解除关联，只有当方法试图使用这个句柄时，托管连接才会重新关联。短的绿色线条显示托管连接现在绑定到 EJB 上，以缩短时间并可以在别的地方重新使用。

征募，还是不征募
大家都知道事务代价很高——特别是 XA（全局）事务。这使得让事务不执行非必需的工作变得很重要。JCA 1.5 中的另外两个新接口防止了 XAResource 对象的不必要征募。

我们现在来更详细地分析一下这种增强所针对的问题。假定取用 清单 1 中的 EJB，并用容器托管的事务部署它，将业务方法的事务属性设定为 RequiresNew。调用这个方法时便开始一个新的事务。创建连接时，连接管理器不知道如何使用它，因此它必须从关联的托管连接获得一个 XAResource，并在事务中征募它。连接可能只用于查询数据库或者根本不被使用。但是连接管理器必须征募连接，以备插入或者更新操作。这意味着，资源适配器至少必须进行开始、提交或者回滚，并结束流程返回后端。图 4 展示了这样的事务流程。

图 4. 急切事务征募

在图 4 中可以看到，获得连接后，XAResource 立即征募到了事务中（即接收一个开始流程）。这意味着当事务方法结束时，流程需要在资源处结束，即使方法没有在事务中使用连接。

如果在事务中涉及另一项资源，就会强制进行不必要的两阶段提交，导致额外的准备流程。这里的惟一可取之处是资源管理器仍然可以从准备调用中返回 XA_RDONLY （用于“read only”）以表明它实际没有做任何工作。事务管理器不需要在那个资源管理器处完成调用，并且如果在事务中只有一个资源管理器真正做了工作，那么事务管理器也许可以避免日志文件中的惰性写操作。

惰性征募
现在您应当认识到除非绝对需要，否则不要在事务中征募。JCA 1.5 规范提供了一个解决方案：惰性征募。清单 4 显示了支持这各种优化所引入的两个接口。

WebSphere 为 JCA 1.5 打下基础 IBM WebSphere 应用服务器 V5 用 JCA 1.0 的一个扩展克服了 cached-handle 连接模式的缺点，它称为 智能连接句柄（smart connection handle）。JCA 1.5 规范通过对清单 3 中的两个接口的修改吸取了这种扩展。 JCA 1.5 在其惰性征募支持中还采用了 WebSphere Application Server V5 的 延迟事务征募 扩展。 请阅读 developerWorks 中 Kevin Kelle 等人撰写的文章以了解更多的 WebSphere 扩展（请参阅 参考资料）。

public interface LazyEnlistableManagedConnection {

}

public interface LazyEnlistableConnectionManager {

    void lazyEnlist(ManagedConnection mc)
            throws ResourceException;

}

LazyEnlistableManagedConnection 接口是由托管连接实现的标记接口，用以向连接管理器表明在事务中创建新的连接或者在连接已经存在的情况下开始一个新的事务时，它不需要将托管连接急切征募到现有事务中。如果连接句柄准备执行应当是任一事务中的一部分的某些工作，并且它的托管连接还没有征募，那么应当确定连接管理器是否实施了 LazyEnlistableConnectionManager 接口。如果实施了，那么它应当调用传递托管连接的 lazyEnlist 方法。这个方法不返回任何结果，但是如果调用线程关联了一个事务，那么这时就征募托管连接的 XAResource。如果连接没有被征募，那么它需要在后面每一项工作之前再次调用 lazyEnlist，以检查在上次调用这个方法之后，是不是没有启动过事务。

图 5 显示了这个新的事件序列。

图 5. 惰性事务征募

在图 5 中可以看到，在获得连接时，XAResource 不再急切征募。相反，连接管理器会等待，直到连接用 lazyEnlist 调用表明它要完成一些事务工作时，才会征募 XAResource。

什么时候出现错误
JCA 规范的第一个版本提供了一种让资源适配器在连接出现严重错误时通知连接管理器的机制。这是 ConnectionEventListener 接口的 connectionErrorOccurred 方法。收到这个通知后，连接管理器就会毁环发送事件的托管连接，这样就不会再使用它。这些都是不错的。但是，如果到后端的连接丢失了，那么池中的许多托管连接也很有可能不能再使用。

针对这个问题，JCA 1.5 以 ValidatingManagedConnectionFactory 接口的方式引入了一种雅洁的解决方案，如清单 5 所示。

public interface ValidatingManagedConnectionFactory {

    Set getInvalidConnections(Set connectionSet)
            throws ResourceException;

}

由托管连接厂实现的 ValidatingManagedConnectionFactory 接口包含一个方法——getInvalidConnections——它以一组托管连接为参数，返回资源适配器认为无效的一个子集。资源适配器的验证可以采取任何形式，不过通常涉及到对后端的某种“ping”操作，以测试连接。然后连接管理器在资源适配器指示连接错误时调用这个方法，甚至定期调用该方法，以便从池中排除坏掉的连接。

开始和结束
最初的 JCA 版本为托管连接及其相关联的连接句柄提供了详细的生命周期模式，但是它没有为资源适配器提供这种概念。只有当创建了托管连接厂后，部署的资源适配器才知道它的存在。JCA 1.5 中引入的 ResourceAdapter 接口对此进行了纠正，如清单 6 所示。

public interface ResourceAdapter {

    void start(BootstrapContext ctx)
            throws ResourceAdapterInternalException;

    void stop();

    ...

}

资源适配器可以在其部署描述符（ra.xml）的 resourceadapter-class 元素中给出实现这个接口的类的名称。除了实现 ResourceAdapter 接口，这个类可以通过 JavaBean 样式支持某些属性。与托管连接厂一样，在部署描述符中可以声明这些属性及其默认值，如清单 7 所示。在安装了资源适配器后，应用服务器将允许管理员覆盖这些默认值。

<connector>
  ...
  <resourceadapter>
    <resourceadapter-class>
      example.ExampleResourceAdapterImpl
    </resourceadapter-class>
    <config-property>
      <config-property-name>ServerName</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
      <config-property-value>MyServer</config-property-value>
    </config-property>
    <config-property>
      <config-property-name>PortNumber</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
      <config-property-value>1976</config-property-value>
    </config-property>
  </resourceadapter>
  ...
</connector>

在启动时，应用服务器会创建在部署描述符中指定的类的一个实例，并设置管理员提供的属性。这个类必须根据这些属性实现一个 equals 方法，这样应用服务器就可以保证它不会创建一个以上同样的实例。然后会调用 start 方法，向它传递一个实现了 BootstrapContext 接口的对象。可以用这个对象创建计时器、调度其他线程上的工作和控制导入的事务，在本系列的第 2 部分中将更详细地讨论所有这些内容。这个方法将不会堵塞并会及时返回。

应用服务器通常会在关闭或者解除部署资源适配器之前，对资源适配器调用 stop 方法。JCA 1.5 规范描述了这个过程的两个阶段。首先，应用服务器保证依赖资源适配器的所有应用程序都已停止。这可保证程序线程不再使用资源适配器对象，并且所有事务都已完成。然后应用服务器调用 stop 方法。这时，资源适配器将执行一个有序的关闭（例如，释放网络和应用服务器资源，并将所有缓存的数据强行送回后端）。调用 stop 后，应用服务器将不会重新使用资源适配器实例。

为了保留向后兼容性，ManagedConnectionFactory 没有改变，但是如果希望外部资源可以利用资源适配器具有的功能，那么还要实现清单 8 所示的新的 ResourceAdapterAssociation 接口。

public interface ResourceAdapterAssociation {

    ResourceAdapter getResourceAdapter();
    void setResourceAdapter(ResourceAdapter ra)
            throws ResourceException;

}

构建了托管连接厂之后，应用服务器将调用 setResourceAdapter 方法以便将它与其资源适配器关联在一起。在托管连接厂的生命周期内这种关联将会固定下来。这种方法只调用一次。

结束语
本文展示了 JCA 1.5 为现有出站契约带来的四项增强功能。惰性关联和征募优化会提高使用连接的应用程序的性能，验证托管连接厂会改善对故障情况的处理。在资源适配器级别引入生命周期管理为资源适配器提供了多种有趣的新机会。本系列的第 2 部分将分析如何在这个基础上建立新的工作管理和事务流入契约。