修剪 Java EE

Java EE 平台成功的一个重要原因就是其广泛的覆盖面，但其涵盖的众多 API 和技术也是广大开发者和厂商所面临的一个难题。对于想要构建 Java EE 应用服务器的新厂商来说，整个规范使其很难介入该领域；而对于 Java EE 新手来说，为数众多的 API 和缩写词也使其茫茫然不知所措。这也是导致 Java EE 如此复杂的一个重要原因，同时一些新手会觉得 Java EE 并不适合开发简单的系统，比如基本的 CRUD Web 应用，他们总觉得 Java EE 是用来开发复杂系统的。鉴于此，Java EE 6 的一个目标就是通过 3 种不同的技术来解决这些问题——配置（profile）修剪（pruning）及扩展（extensibility）。

Profile 可以是 Java EE 平台技术的一部分，也可以是额外的 JCP 技术（并不属于基础的 Java EE 平台），抑或两者兼而有之。它们能给厂商带来很多好处，因为其可以降低厂商开发 Java EE 兼容产品的门槛，同时对 Java EE 平台新手也能起到帮助作用。随着 Profile 概念的逐步规范化，Java EE 引入了第一个 Java EE profile——Web Profile，InfoQ之前的文章对此进行过详细的报道。

与此同时，Java EE 6 API 的移除工作也被提到了议事日程，所谓API 移除，意即对于厂商和开发者来说，这些API 的重要程度相对比较低，我们称其为修剪。该过程由几个步骤组成：首先在发布包中将其声明为候选者，同时在Javadoc 中也将其标识出来；然后根据社区的反馈来决定是否在下一个发布中将其放到可选组件中。

对Java EE 6 早期草案的审阅提出了两个修剪项。第一个是JAX-RPC[即 JSR 101 ，Java APIs for XML-Based RPC]，它定义了通过 RPC 来访问 SOAP web services 的客户端 API，同时也定义了实现 web service 端点的技术。JAX-RPC 存在很多局限性，最明显的就是 JAX-RPC 服务端点和处理器既不支持 web service 注解，也不支持注入。随着 Java EE 5 的发布，其 API 已经被 JAX-WS 所替代。第二个是 JAXR[即 JSR 93 ，Java API for XML Registries]，它提供了一种标准的方式来访问不同类型的 XML Registry 以进行绑定、部署及探测 web service，同时还包含了对 ebXML Registry 和 UDDI Registry v2.0 规范的绑定。尽管 JAXR 的替代者尚未出现，但其使用上却存在着很多限制。

对 Java EE 6 公开草案的审阅又增加了两个 API 修剪项。已经被 Java Persistence API[以前作为 JSR 220 ，Enterprise JavaBeans 3.0 的一部分] 成功取代的 EJB 2.x Container Managed Persistence 以及 Java EE Application Deployment[ JSR 88 ]，后者定义了部署工具的运行环境和 Java EE 应用服务器所提供的插件组件之间的接口。理论上凭借该 API，我们可以使用相同的部署工具将任何 Java EE 应用部署到任何 Java EE 兼容的环境中，但遗憾的是，厂商对其的支持实在是太弱了。

与 JSR 88 类似，专家组也在考虑移除 Java EE Management[ JSR 77 ]，它向管理工具提供了 API 以查询 Java EE 应用服务器的当前状态、部署的应用等等。使用这些 API 构建的服务器管理工具可以跨厂商运行，这样就可以切换应用服务器而无需改变管理工具和过程，还可以管理多个 Java EE 服务器所构成的网络，而网络中可以包含多个厂商实现。与 JSR-88 一样，厂商对该 API 的支持力度也很弱。

随着 API 的裁剪，专家组希望减少那些使用量少的 API，转而提供更多的扩展点。我们应该可以使用这些接口和插件点轻松创建平台的扩展技术，同时保持很好的集成性，这么做也会使规范本身重获新生。

查看英文原文： Pruning The Deadwood from Java EE