Eric Newcomer ，在他的博客中，就 David Chappell 的最近围绕 SCA 的言论发表了评论。在 David 的博客中，他说道：
服务组件架构（SCA）不是特别简单的技术。只是阅读规范，很难弄清楚它。
这促使他撰写了非常棒的 SCA 白皮书介绍。另一方面，正如 David 之前提到的，有时很难让所有的 SCA 作者就 SCA 中哪些是重要的达成一致。但是，在他看来：
……创建 Java 组件的新的编程模型是 SCA 中最重要的部分。因为，它提供了一个更简单和更加面向服务的构建业务逻辑的方法，开发者可以使用它代替 EJB、JAX-WS，可能还包括 Java EE 5 中的其它部分。
David 认为，该 Java 编程模型没有得到它应得的重视，它在 SCA 中的重要性等同于.NET 中 WCF 的重要性：
正如微软的 Windows 通信基础（WCF）对由.NET 企业服务、.NET Remoting 和 ASPX 解决的问题提供了统一方法，SCA 编程模型涵盖了当前由 EJB、Java RMI 和 JAX-WS 解决的绝大多数有用场景。建构于 SCA 新的编程模型之上的业务逻辑仍能使用 JSP、JPA 和 Java EE 5 的其它方面——SCA 不会全部替换企业 Java API。
现在 Eric，作为代表 IONA 的 SCA 作者之一（也是 Eclipse SOA 工具平台成果的领导人），不同意 David 的观点。他认为服务装配模型才是关键，同时还认为与 WCF 进行比较未必合适：
WCF 宣布的时候，我就在 2003 年的 Tech Ed 会场。而且清楚地记得，听到一些与会开发者的反对之声，因为他们发现微软打算要求他们改变开发 Web 服务的方式。
在对 Eric 的帖子的回复中，David 澄清了他的一些言论：
……我认为，SCA 的装配模型也很重要；我只是认为它的 Java SCA 组件模型更重要。……定义组件应该如何装配到应用中当然有用，并且 SCA 的这部分看来得到了广泛的支持。尽管如此，正如你提到的 Windows 开发者的抱怨，这恰恰可以用来理解为什么 WCF 是个好东西，Java 企业开发者应该理解统一编程模型对面向服务应用的价值。
但是正如 Eric 随后指出的：
微软世界和 Java 世界之间的一个区别是，早已存在若干种创建服务的方法——一些方法比另一些更复杂，这是事实——但是我一直在说的一件事是，SCA Java 编程方法存在有将一个复杂性交换到另一的危险。我不确定 SCA 编程模型，与 JAX-WS 或 Spring 相比，会显著的降低复杂性。
那么问题仍然存在：SCA 最重要的方面是什么？答案可能仍是厂商特定的。但是如果是那种情况，为了全面认识SCA 的复杂性要做些什么呢？
查看英文原文： The Problem With SCA?
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论