修剪Java EE

作者 Charles Humble 译者 张龙 发布于 2009年4月15日

领域

企业架构,

语言 & 开发

主题

Java EE ,

Java ,

语言 ,

编程 ,

Enterprise Application Blocks

分享到

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

译者 张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。

相关厂商内容

保持某些系统的高可用性，是一些企业的重中之重，如何设计？

海量数据处理，海量视频分发，架构热点难点，尽在架构师峰会！

相关赞助商

ArchSummit全球架构师峰会报名启动！7折优惠，5月31日截止！