Java 理论与实践：让J2EE程序脱离容器
大多数项目不是属于 J2EE 应用程序就是属于 J2SE 应用程序。不过，有一些 J2EE 技术可以存在于 J2EE 容器之外，并且有些 J2SE 应用程序可以对它们加以利用。本月，Brian Goetz 分析如何在 J2SE 应用程序中使用某些 J2EE 服务。在大多数情况下，Java 应用程序要么是 J2EE 应用程序、要么是 J2SE 应用程序，并且在这一点上是泾渭分明的。J2EE 应用程序需要 J2EE 容器的服务，容器要实现一长串的 J2EE API，包括 Enterprise JavaBean (EJB)、JTA、JNDI、JMS、JCA 和 JMX。J2EE API 设计为协同工作；毕竟，J2EE 设计是从多年来数百人开发企业应用程序的经验中提取出的公共需求。像所有框架一样，J2EE API 的主要目的是“不重新发明轮子”。
有一些 API 属于 J2EE 规范的一部分，但是可以很容易地在 J2SE 应用程序中使用，如 JDBC、JSP 和 servlet，但是对于大多数 J2EE API，J2EE 是一个要么是要么不是的命题??大多数 J2EE API 需要全功能的 J2EE 容器。不过，有一些服务器应用程序开发为 J2SE 应用程序而非 J2EE 应用程序，这通常都有很好的理由。为什么这些应用程序的开发人员必须重新发明轮子呢？J2EE 中是否有部分内容可以容易地被 J2SE 应用程序借用来提供同样的优点呢？什么组件可以同时用于 J2EE 和 J2SE 应用程序的组件呢?
松散耦合
J2EE 的一个主要设计原理是 J2EE 应用程序可以松散地耦合??用组件组装，在组装或者部署应用程序时而不是在组件开发时定义或者改变这些组件的相互连接。J2EE 组件使用 JNDI 相互查找和查找所需要的资源，如 JDBC 和 JMS 连接。JMS 这样的技术鼓励松散耦合，允许灵活地为工作流程建模、容易分配处理任务、可伸缩性和容错性。很多 J2SE 服务器应用程序也可以从这些技术和原理中受益。
像 JDBC、JMS 和 JNDI 这样的 API 基本上是“中间件”??它们作为应用程序与不同的服务提供者之间的统一接口。几乎每一个数据库服务器都有 JDBC 驱动程序，有大量的免费数据库服务器，所以几乎每一个希望利用数据库的 Java 应用程序都可以容易地做到这一点。不过，对于 JMS 就不是这样了。消息队列服务器远没有数据库这样常见，特别是在小型商店中。但是有大量的应用程序可以通过使用消息队列而极大地受益。
Somnifugi JMS
消息队列是一个功能强大的范例，它用于构建健壮的、灵活的、松散耦合的、可伸缩的应用程序。有一些商业消息队列产品，如 WebSphere MQ、Sonic、Fiorano、JBossMQ 和 SpiritWave。就像 JDBC 对于数据库一样，JMS 是消息的中间件??它使得应用程序可以通过统一的接口访问不同的消息队列产品，这个接口提供了像 Connection、Topic 和Message 这样的抽象。
许多 J2SE 应用程序使用某种形式的消息队列，但是不使用 JMS??而是使用线程池、工作队列、任务管理器等。AWT 和 Swing 框架使用消息（事件）在模型与视图层之间通信，JavaBean 组件利用监听器支持一种基于主题的消息。消息队列提供了很多结构上的优点??它固有的松散耦合有利于采用灵活的、基于组件的方法，并提供了有助于简化设计和减少互连的天然抽象边界。一个附带的好处是，MQ 范例使得分布式的、可伸缩的和容错的设计变得更容易了，因为消息生产者和使用者不一定需要运行在同一 JVM 中，大多数生产者/使用者任务的本性是允许并发处理的。
在 JBoss 发行版的 jnpserver.jar JAR 文件中可以找到 JNP JNDI 服务器，它还依赖于 log4j 日志引擎。要使用它，必须配置 log4j，创建相应的 jndi.properties 文件（参见清单 1），并安排通过调用同一 JVM 或者另一个 JVM 中的 org.jnp.server.Main 的主入口点来启动服务器。访问 JNDI 名称空间的类文件在 JBoss 发行版的 jnpclient.jar JAR 文件中。
清单 1. JNPServer 的 jndi.properties
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactoryjava.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces# Uncomment this line only if the JNDI server is to run in another JVM;# otherwise, local JNDI requests will go over RMI#java.naming.provider.url=localhost
Java 管理扩展（JMX）
Java 管理扩展（Java Management Extensions，JMX）是一种管理组件和服务的生命周期的机制。JBoss 大量使用 JMX??JBoss 中的几乎所有组件都作为 JMX 服务提供。结果就是很容易配置一个只包括所需服务的应用程序。对于每一个组件服务，创建一个名为 MBean （托管的 bean）对象，它包含生命周期方法（start() 和 stop()）和公开属性的 getter 和 setter。清单 2 显示了描述一个简单 Web 容器服务的 MBean 接口：
清单 2. 简单 Web 容器服务的 MBean 接口
public interface WebServerMBean {// Lifecycle methodsvoid create() throws Exception;void start() throws Exception;void stop();void destroy();// Getter and setter for listener-port propertyint getPort();void setPort(int port);// Get the names of loaded Web applicationsString[] getWebApplications();}
JBoss 还包括一个 Web 应用程序（jmx-console），它可以查看当前装载到 JBoss 服务器中的 MBeans、检查它们当前的状态、并用浏览器读取和写入它们的属性。（JMX 参考实现还包括一个名为 HtmlAdapter 的 Web 应用程序。）
虽然 JMX 是为 J2EE 提供的，但是也可以在 J2SE 应用程序中容易地使用它。至少有两个免费的 JMX 实现，Sun 的参考实现和开放源代码 MX4J。编写一个 MBean 以描述一个组件是相当简单的??通常所要做的就是实现 start() 和stop() 方法。编写一个简单的装载一组 MBean 并启动它们的 JMS “容器”只需约 40 行代码。遵循 JMX 标准，不但得到使用 JMS 的好处，比如远程属性检查和操纵（这对于调试及管理都有好处），而且还可以更容易地编写可以轻易地同时运行在 J2SE 和 J2EE 环境中的组件。
结束语
虽然 J2EE 和 J2SE 是用于不同工作的不同工具，但是许多开发人员发现自己必须决定各种框架服务的“轻量级”和“重量级”实现，比如消息、配置或者管理。通过使用 J2EE 接口的较轻量级的实现，如 Somnifugi JMS，开发人员可以在短期内得到性能和易于使用的好处，同时又具有在将来需要时，可以容易地迁移到更重量级的解决方案的灵活性。
