来自 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
注册/登录 InfoQ 发表评论