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规范提出的新概念之一就是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？
108
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
