就在 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 规范中吗？
暂无签名
中国卓越技术团队访谈录（2022 年第二季）
本迷你书精选了微软 Edge、蚂蚁可信原生、明源云、文因互联、Babylon.js 等技术团队在技术落地、团队建...
评论