David Chappell（来自于 Chappell & Associates，不要误以为是 Sonic/Oracle 的 David Chappell）在他的博客帖子里道出了他在 JavaOne 上主持的一个关于服务组件架构（Service Component Architecture，SCA）座谈会的感受。David 强调了 SCA 是两个事物的组合这一事实，也就是：
[…] 在 Java（和 C++）中创建面向服务组件的一种新编程模型，以及一种描述如何将组件装配进入组（被称为“组合”）的方法。“组合”既可以包含使用了 SCA 的新编程模型构建的组件，也可以包含使用了其他技术（如 Spring 和 BPEL）构建的组件。SCA 没有为这些其它的技术定义新编程模型，但是它描述了使用它们构建的组件如何成为“组合”一个部分的方法。
SCA 和 JBI（Java Business Integration）的相对价值，已经在之前InfoQ 的文章中讨论过了——现在有份关于它们关系的官方声明。在之前的帖子中，Chappell 认为SCA 是 Java EE 的威胁。IBM 和 BEA 是 SCA 的重要支持者，他们的 J2EE/Java EE 投资都将不会有严重的问题——但是正如 David 指出的，这就意味着不同的事情：
这其中需要注意的一点是：当厂商声称他们支持 SCA，只有当你问他们时，你才会知道他们说的意思。当 Oracle 这么说时，他们似乎是指技术的装配方面。 当 BEA 这么说时，他们似乎是指装配方面和 Java 组件模型，而未必是指 C++ 组件模型。当 IBM 这么说时，他们似乎是指当前 1.0 规范中几乎所有的内 容。当 Sun 这么说时——嗯，恐怕我也不知道他们真正指什么了。
来自 Google 的 Gregor Hohpe分享了他的感受：
这个编程模型与微软的 WCF 非常类似，它为所有类型的分布式系统通信提供了一套统一的 API。在微软的世界中，这可是个大事情， 公正地说确实如此。因此，有些令人惊讶的是厂商对于 SCA 编程模型的支持并不热心。甚至很多“官方”文档似乎对于规范方面不予重视。只有 IBM 和 BEA 是 在真正支持这两个方面，而其他的则公开声明他们并不关心编程模型。
同时，Hohpe 也质疑 SCA 是否有什么真正与 SOA 有关的东西：
我以前看规范的时候，我完全忽略了规范的假定：“组合”必须运行在单一厂商环境中。这个限制对我来说意味着 SCA 几乎与 SOA 没关系，SOA 必须处理异构且不被单一厂商控制的环境。
事实上，SCA 似乎在表达一个不同于典型“高级”的 SOA 方面的主题。尽管那不意味着它就不是一个可行的技术，但它避开了 SOA 相关标准是否真正可用的这一老生常谈的问题。
查看英文原文： The Future of SCA
译者简介：胡键，自 2000 年西安交通大学硕士毕业后一直从事软件开发。2002 年开始使用 Java，在项目开发中经常采用 OpenSource 工具，如 Ant、Maven、Hibernate、Struts 等，目前正在研究信息集成方面的规范和技术。可以通过 jianhgreat@hotmail.com 与他联系，或访问博客： http://foxgem.javaeye.com/ 。为 InfoQ 中文站贡献内容，请邮件至 china-editorial[at]infoq.com 。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论