Java EE 6 规范领导者寻求公众对 Web Profile 选项的反馈

Roberto Chinnici 是 Java EE 6（ JSR 316 ）规范的联合领导者，他在最近的博文中谈到了Java EE 6 规范Web Profile 的两个最主要的候选项，并向JSR 316 专家小组提出了应该在这两个选项中选择哪个作为前进方向的问题，为此，他也正在寻求公众的反馈。Infoq 借此机会对这两个Web Profile 选项作了剖析，并在这里给大家提供此分析的具体内容。

Java EE 6 规范提出的新概念之一就是 profiles， Infoq 在另一篇文章中对其做过更详细的描述。Java EE 6 规范很可能只会有一个 profile，那就是 Web Profile，这主要取决于时间和资源的限制。但 Chinnici 将它看作一个优点：

profile 的推动理念之一是避免大而重的模型，使得平台的交付系统可以允许更小的焦点社区在他们定义的 profile 内容上稳步前进。自然，它从一开始就尽可能地实现高解耦性，从而将 profiles 推入各个 JSR 中，使它们在各自的时间轴上固定下来。这样说吧，我们原先提议定义一个 Web profile 作为 Java EE 6 JSR 的一部分原因是：第一，在推动 profiles 概念时，有一个用例在手总比没有强得多；第二，我们坚信，市场和开发社区对 EE 平台上以 web 为中心的 profile 会很有兴趣。另外，应用 Web Profile 的 EG 邮件数量和深度也足以证明了我们的第一个理由。

Chinnici 以表格的形式介绍了这两个 Web Profile 选项，并且针对每个选项，他都列出了相关的组件技术。同时，他也列出 Java EE 6 规范完整的技术栈作为比较参考：

(A) (B) Full platform Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250 Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250 Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250 EJB 3.1 (Lite)
JTA 1.1
JPA 2.0
JSF 2.0 *
Web Beans 1.0 * EJB 3.1
JTA 1.1
JPA 2.0
JSF 2.0
Web Beans 1.0 JAX-RS 1.0
Connectors 1.6
JAX-WS 2.2
JAXB 2.2
JSR-109 1.2
JSR-181 1.1
JMS 1.1
JAF 1.1
JavaMail 1.4
JSR-115
JSR-196
JSR-88 1.2
JSR-77 1.1
JAX-RPC1.1
JAXR 1.0

Chinnici 还指出，是否将提案 B 中标 * 的两项技术包含到 EE6 中仍存在着争议。提案 B 中的"EJB 3.1 Lite"，指的是 EJB 3.1 中一个被提议的功能子集。目前，它仍有待于 EJB 3.1（ JSR 318 ）专家小组的接受。

Java EE 6 规范的另一特点是具备可扩展性，这在 Web Profile 的讨论中扮演着重要的角色 ：

[…] 在 Web 层，可扩展性是指以非常简单的编程模式利用第三方框架的能力。开发者在添加他们喜欢的 web 框架所传递的每条指令的 context listeners, filters, servlets 和 servlet mappings 时，将不再需要手工编辑 web.xml 文件的任何描述符。更准确地说，加入第三方 jar 包到 Web 应用程序时，所有这些元素的添加将会自动触发，开发者无须介入任何手工劳动。我们期望这项特点能满足所有诸如 JSF，Struts 和 Spring MVC 的主流 Web 框架的需求；满足类似 JRuby 在 Rails 和 Grails 上的脚本解决方案的需求；以及满足遵循 JAX-WS 2.0/JSR-109 模型的 WS-* web 服务和参考 JAX-RS 1.0 编写的 RESTful web 服务的需求。这里还要重点指出的是，一个技术是否基于 JCP 标准并不能够决定其是否具备可扩展性。

Chinnici 指出，Web Profile 的目的在于成为一个基础规范，而不是包罗万象的技术清单——厂家可以向 Web Profile 兼容的 Java EE 6 实现自由添加新的扩展组件，这将弥补近来应用服务器尝试提供模块化底层构架的不足。Chinnici 说他期待一个试验阶段，在这个阶段中，他希望多家厂商能够互相结合各自融合了 Java EE 6 规范和 Web Profile 基础的产品，并能将它们推向市场以测试类似产品的市场定位。而后，如果一个或多个类似的功能集逐渐形成流行，那么这些受欢迎的功能集就可以作为新一轮 Java EE 6 规范 Profile 的开发基础。

目前，对于那些包含了所有组件技术的 profile 的技术间交互的需求，也将囊括于 Java EE 6 规范中－例如，JTA 和 servlets 之间的交互将应用于 Web profile B 选项，而非 Web profile A 选项，这是因为 JTA 不是 A 选项的一部分。Chinnici 为此给出的理由是：

[…] 一方面，我们认为 Java EE 的需求为独立技术添加了重要的价值，事实可以证明这一点，很多 servlet 容器都是以兼容 Java EE 要求的方式来实现 JTA；同时，提出该需求将有助于确保目标 profiles 应用程序在整体平台上工作。总而言之，这些都使得 profiles 远不仅仅是独立的已测试过的技术的集合，因为这些技术将以有趣的方式互相绑定，和他们独立工作相比，互相绑定可以提供更多功能。

最后需要提出的是兼容性问题。Chinnici 指出，任何需要 Web Profile 结合其他一些 Java EE 6 规范的组件（如 JAXB 2.2）的应用程序，都将无法在纯 Web Profile 上运行。解决此问题的办法是，提供完整的 Java EE 6 的 profile，因为任何能够在 Java EE 6 子集上运行的应用程序，自然也可以运行于整个技术集之上。

分析至此，您更喜欢哪个 Web Profile 呢？选项 A，还是选项 B？

查看英文原文： Java EE 6 Spec Lead Requests Community Feedback on Web Profile Options