SCA的未来

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等，目前正在研究信息集成方面的规范和技术。可以通过 [email protected]与他联系，或访问博客： http://foxgem.javaeye.com/。为InfoQ中文站贡献内容，请邮件至 china-editorial[at]infoq.com。