Sun会把SCA集成到Java EE规范中吗？

就在Java社区围绕支持SCA还是JBI展开争论的时候，种种迹象表明，它们两者都可能被正式合并到Java EE 6 中（详情请阅读我们早期的报导SCA变得对Java EE更加友好）。

围绕着更好的在Java EE和SCA产品之间进行互操作，目前已经有一些规范和正在进行的工作，但是使之成为官方的规范又是另一码事。

最近Jeff Anderson记录了一些他与资深Sun公司工程师Peter Walker进行的谈话。Peter Walker是JSR 208（Java业务集成）规范的负责人之一。该规范关注于正式地将SCA集成到Java EE。

这段谈话发生在JavaOne 2008大会上的SCA讨论会之后，Peter对Jeff的关于Sun是否会支持SCA的回答非常有趣：

我又一次试图迫使他对为什么Sun不想考虑SCA作出解释，我当然没有看见Sun提供了任何与之相当的技术。他的回应是，Sun当然愿意对它（SCA）敞开大门，但是它们的用户根本没有要求那样做……

而后在Jeff的文章JavaWorld 2008 SCA集锦（The Highlights of SCA at JavaWorld 2008）里包含了如下有趣的观点：

恕我直言，与JCP世界（例如Jax-WS、Jax -RS、JBI等技术）中与之相当的技术相比，SCA是一种更好的技术。SCA的发展过程是一个真正的社区过程，同时获得了各独立软件供应商和专业服务组织的支持。我们都听到过关于Sun对Java EE世界专制统治的抱怨…… 

在这个博客的另一部分，针对David Chapelle的关于由不同编程模型引起的Java社区内可能的摩擦的看法，Jeff表达了他的观点：

首先，Java已经有了大量的编程模型；Spring明确地说明了它有它自己的组件模型。更不要提那些使用脚本语言（例如jRuby）组件工作的人所使用的编程模型与采用核心Java平台语言组件工作的人所用的有多么大的不同。Java平台的一个核心特性就是提供差异性。微软似乎喜欢一种方式、一个平台、一个模型，很不幸这种方式不得不忍受迅速过时的痛苦，并且（这种方式）与那些真正需要使用这些东西的人（如开发者）毫无关系。

以及

其次，SCA编程模型是一个POJO编程模型，它基于注释、XML配置文件以及依赖注入。所以，其难以一帆风顺的被采用也或多或少是一种担心吧？当然这因为它是一种了不起的编程模型，但是DI的美妙之处在于代码只需要付出极少的代价就可以被方便地插入到各种不同的容器中，而完全不需考虑其支持的模型，只要它是一个POJO（或POPO）。所以，我认为对这个迥然不同的编程模型的这种巨大担心纯粹是庸人自扰。

以下来自Peter的评论鼓励Jeff到Tuscany邮件列表发表一个公开信，征集各种与SCA的应用相关的建议或者事例，或者对Sun采用SCA的个人观点：

Peter的评论：

告诉我更多使用者的要求，我到现在还没听到。并且我要再一次指出JBI和SCA并不冲突。

你怎么想？
不同的编程模型真的会引发原本统一的Java社区的摩擦吗？

现实世界的应用事例和社区成员的意见会使Sun把SCA加入到Java EE 6规范中吗？

查看英文原文：Sun会把SCA集成到Java EE规范中吗？