来自 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
暂无签名
腾讯云云原生提质增效实践精选集 2024
《2024腾讯云云原生提质增效实践精选集》出炉，5大热门技术领域，13个行业精选标杆案例，痛点到解决方案全...
评论