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

作者 Dionysios G. Synodinos 译者 张龙 发布于 2010年1月11日

领域

运维 & 基础架构,

企业架构,

语言 & 开发

主题

应用服务器 ,

Web框架 ,

Java ,

Enterprise Application Blocks

标签

Java EE

前一阵发布的最新版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?

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

1. 返回顶部

   apache就是IBM的枪手

   发表人 Zhang Gavin

   IBM负责装火药，apache负责放炮

   回复

• 更早的 >