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

  • Hartmut Wilms
  • 胡键

2007 年 10 月 21 日

话题: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

SOA微软架构