Web Profile 会将 Web 开发者吸引到“Enterprise Java”上么？

前一阵发布的最新版Enterprise Java 中有一项特色功能：基于功能的分析。首先发布的就是面向Web 开发者的 Web Profile ，但我们尚不确定单单凭借它本身是否能在群雄纷争的 Web 领域中占据一席之地。

正如 Web Profile 最终草案所述，其目标就是面向现代 Web 项目的众多开发者，为其提供一站式的支持，同时限制 Web 容器的资源占用量，既包括物理上的，也包括概念上的：

从完整性角度来说，Web Profile 提供了一站式的支持，包括展现层与状态管理（JavaServer Faces 与 JavaServer Pages），核心 Web 容器功能（Servlet）、业务逻辑（Enterprise JavaBeans Lite）、事务（Java Transaction API）、持久化（Java Persistence API）等等。 从简单性角度来说，Web Profile 省去了 Java EE 平台中的很多 Enterprise API。同时它还利用了 Servlet 规范（查看文档的 8.2 节）中新的插件特性以方便应用通过最少的配置使用扩展了 Servlet 容器的程序库。比如，像 Java API for Restful Web Services（JAX-RS）这种标准技术是完整的 Java EE 平台的一部分，但却不属于 Web Profile。尽管如此，我们可以通过新的插件特性将其“插入”到 Web 容器中而无需对应用的部署描述符 web.xml 做任何修改。

值得注意的是，Web Profile 并没有什么可选组件，要想实现符合 Web Profile 的解决方案就必须实现如下这些技术：

• Servlet 3.0
• JavaServer Pages（JSP）2.2
• Expression Language（EL）2.2
• Debugging Support for Other Languages（JSR-45）1.0
• Standard Tag Library for JavaServer Pages（JSTL）1.2
• JavaServer Faces（JSF）2.0
• Common Annotations for Java Platform（JSR-250）1.1
• Enterprise JavaBeans（EJB）3.1 Lite
• Java Transaction API（JTA）1.1
• Java Persistence API（JPA）2.0
• Bean Validation 1.0
• Managed Beans 1.0
• Interceptors 1.1
• JSR-299 1.0
• JSR-330 1.0

Java EE 与 Java SE 面临的一个共同问题是 Sun 没有能力向社区证明其“开放”平台的计划。这一点随着 Oracle 对其收购的不确定性而变得越来越扑朔迷离了。这一切顾虑都会牵绊组织在其平台上战略投资，在 JCP 的过程中这一切都通过投票结果彰显出来了。然而事实上，最重要的原因还是 Apache 软件基金会对 Java EE 6 规范投了“否决票”。

RedHat: EE6 规范的领导已经证实 EE6 TCK 将不会包含“使用领域的限制”，而这最初是由 Apache 针对另一个 JSR（即 SE TCK 协议）提出的。本来这是好事一桩，但在缺乏禁止这种使用领域限制的直观 JSPA 规则的情况下，我们仍对未来是否还会有类似情况的发生心生介怀。因此，今后对于提交的任何 JSR（无论是否是 Sun 提交的），我们都将要求规范领导对这方面描述清楚，并且在投票的时候将这一点考虑在内。

Intel Corp.:

在 EE6 JSR 进入最后投票的时刻，我们期望有这样一个声明：EE 6 TCK License 不会限制使用领域、除了规范本身要求的以外不会要求再去实现其他的东西、不会要求限制 JCP 规范使用领域的其他任何协议。

Apache 软件基金会：

Apache 一定会为投给 JSR-316“否定票”这一行为感到后悔，因为我们主张规范领导者（Sun Microsystems）在 Java SE TCK 协议上不要照搬 JSPA。我们认为那些不遵从信中所说以及违背管理规则的 JCP 成员无权领导 JSR。这并非针对目前为止专家组的技术水平和工作质量，如果不是因为 Sun 的自作主张，Apache 很可能会投“赞成票”的。

目前尚不确定哪些厂商打算实现 Web Profile，更不清楚何时实现了。VMWare 很可能通过 Springsource 达成这个目的——他们已经在dm Server issue tracker 上谈论这个话题了，然而他们还公开谈到了一些负面消息。比如说，Spring Framework 的联合创建者JürgenHöller 在QCon 的演讲中就表示 Spring 和 Java EE 6 并不看好 Web Profile ：

实现这个 Profile 并不太具吸引力。到目前为止我只知道有一个厂商打算实现该 Profile 但并非全部。

无独有偶，JBoss AS 的项目领导 Dimitris Andreadis 也表达了其对于“预定义 Web 配置”目的的担忧。

如你所知，我们可以根据实际需要的服务来裁减 JBoss AS 配置；对于 JBoss 来说这么做是没有任何问题的。现在提出了预定义的 Web 配置，这看起来更像是市场的需要而不是由技术决定的。功能和特性的移除要比添加容易的多。目前我们的全部精力都转到了更高的层次上：引入 JBoss Enterprise SOA Platform，它在 JBoss EAP 上增加了 JBoss ESB、JBoss jBPM 以及 JBoss Rules 功能。然而如果市场真的需要，或是 Java EE 6 Profile 发展的更好，我们还是有可能创建并支持 Web Platform bundle 的。

事实上，JBoss 已经宣布为其应用服务器创建一个Web Profile 原型了，尽管刚刚开始，但 JBoss Enterprise Web Platform 还是“通过企业级特性增强了 Java EE Web Profile“。

另一方面，Hibernate 的创始人 Gavin King 却坚信 Web Profile 的创建对于 Java 平台是件大好事，对于那些犹豫到底是选择缺乏某些特性的普通 Servlet 容器还是花费高昂代价采取完整 EE 的开发者来说 Web Profile 可以助其一臂之力。

Java EE Web Profile 定义了一个”更小“的容器，里面仅包含了大多数开发者确实需要的技术：Servlet、JPA、JTA、CDI、EJB Lite。这使得 EE 的实现更加容易，对市场的影响也是非常大的，届时会有更多的实现以及更短的发布周期。它彻底将众多开发者放弃 Java EE 的原因摒弃了。 更棒的是，CDI portable extension SPI 与 Java EE 环境的集成变得更加简单了。同时，由于某些 CDI 实现还运行在普通的 Servlet 容器如 Tomcat 中，因此 CDI 还可以作为将技术集成到这些环境中的基础。

同样，JBoss 前 CTO Sacha Labourey 也对 Web Profile 的未来充满了信心：

我非常欣喜地看到 JCP EC 最终投票批准了 Weld 和 EE6 ！ 终于完成了始于 EE5 的工作，毫无疑问，这将使得 EE6 成为最强大，同时也是最简单的 Java 运行环境的使用手段，当然要领先于布满了 XML 的 Spring 。此外，定义强大的 Web Profile 而无需考虑大多数遗留的 EE 规范（IIOP，还有人用么？）会给很多使用自定义 Tomcat 的团队带来一阵清新的空气。

InfoQ 的各位读者，你是如何看待 Web Profile 的呢？它会使 Java 平台成为 Web 开发的优秀解决方案么？

查看英文原文： Will the Web Profile make “Enterprise Java” Attractive to Web Developers?