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

阅读数:189 2008 年 3 月 3 日

话题:Java社区DevOps语言 & 开发文化 & 方法

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