一场微软该不该支持SCA的辩论

作者 Hartmut Wilms译者 胡键 发布于 2007年10月21日 下午10时51分

社区

SOA

主题

SOA平台

标签

服务组件架构,

微软,

标准化

来自Chappell & Associates的David Chappell通过论证“微软不该支持SCA”开启了一场关于SCA的辩论。

服务组件架构（SCA）最初由一组厂商（包括IBM、Oracle、BEA和SAP）创建，于2007年3月被移交给OASIS。SCA定义了用于在面向服务架构中开发和组合服务的编程和装配模型。服务（或组件），可以用Java或任何支持SCA编程模型的其它语言开发，即任何其绑定被SCA规范指定的语言。

SCA编程模型由微软的竞争对手定义，他们控制规范，并且（按照Chappell的说法）他们主要关注代码的可移植性而非互操作性。唯一被SCA支持的.NET语言是C++，它在.NET的世界中并没有扮演重要角色。即使微软会设计一个C#或VB.NET绑定，在可移植性方面也不会有任何斩获，因为两种语言一定是在同种微软平台。此外，微软已经提供了一个类似的编程模型：Windows通信基础（Windows Communication Foundation）。

首先，明白SCA是纯粹关于可移植性的这一点非常重要——它与互操作性没有一点关系。为了连接横跨厂商边界的应用，SCA依赖标准的Web服务，除此之外没有加入任何新鲜的东西。[……] 因此，微软不支持SCA决不会影响任何人去连接运行于不同厂商平台之上的应用。

由服务组件定义语言（SCDL）定义的装配模型同样也没有加入互操作性：

这门语言并没有定义太多的东西。并且，因为所有在单一的SCDL定义的组合体内的组件必须运行于同一厂商的基础设施上，缺少微软的支持并不会影响任何人去定义包含两者（即Java和.NET组件）SCA组合体。即使微软支持SCDL，这也是不可能的。

SCA对可移植性的关注是主要原因，为什么微软和任何用户都不会从微软拥抱SCA中获益：

既定的竞争现实，微软今天支持SCA就象10年前可能拥抱EJB一样。即使该公司仍想要这么做，对于微软来说那儿没有多少东西可拥抱的。鉴于SCA完全关注可移植性而非互操作性，它所支持的编程语言集合，SCDL的右派天性，微软对于这一正在浮现的技术的支持几乎对用户没有任何益处。

Stefan Tilkov表示同意，并且甚至提出这样的问题“考虑他[David Chappell]的论点之后，这整件事是否值得努力”。Stefan在其跟贴中表示“互操作性显然在可移植性之上”，同时他对SCA的成功表示怀疑：

对我来说，可移植、跨平台装配模型和编程模型没有机会成功——对我们的行业来说有太多的协议了。[……]对CORBA来说仿佛也不存在明显的厂商优势……不知何故这也从来没有让MSFT加入。

William Vambenepe回应说尽管SCA不支持互操作性，但它“不只是用于代码可移植性”。从IT管理的观点，他看到了SCA的优势：

在一个对应用和服务管理有用的粒度级别，它是一个机器可读的组合应用的逻辑描述。我可以将其用在我的应用基础设施上，以更好地理解关系和依赖。它将应用世界的概念带入到了一个更高的抽象级别（比servlet、bean、row等更抽象），在其中我可以更实际使一些任务自动化，例如策略迁移、自动故障转移、影响分析，等等。

根据Vambenepe的说法，微软将可能在这一点上从对SCA的支持中受益匪浅。他认为微软努力支持SCA将使他舒心不少，“例如，所有的管理厂商可以有效地管理那些包含了同时运行在微软和Oracle之上的组件的组合应用”。Don Box正寻求支持SCA论点 ，他并没有被Vambenepe的论点说服。

看到SCA将如何影响SOA市场以及微软最终将如何回应这场辩论是非常有趣的事情。10月3日，InfoQ发布了对SCA标准成员和用户进行的SCA访谈 ，谈及了一些SCA辩论的问题并更深入地对SCA的角色和未来进行了审视和理解。

查看英文原文：The SCA Debate

1. 返回顶部

   MS志不在此

   2007年10月22日 下午7时26分 发表人 SG soft

   SCA是一个不错的架构，其中，对数据实体的抽象SDO是个不错的想法，.BET世界做了一些类似的工作，但看上去并不完善，相反，Spring.NET等这样的开源组件，倒是很多代码有着SCA的影子。

   回复

2. 返回顶部

   不见兔子不撒鹰

   2007年10月23日 上午3时32分 发表人 Alex Xu

   该不该是很难辨出结果的。看不到甜头，MS是很不会加入的。

   回复

• 更早的 >