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 。
评论