SCA 相对于 Spring 的优势？答案

【问题标题】：Advantages of SCA over Spring?SCA 相对于 Spring 的优势？
【发布时间】：2011-04-19 16:25:21
【问题描述】：

我有使用 Spring 开发 Java Web 应用程序的经验，但在 SOA 领域没有那么多经验。我正在阅读有关 SCA- SCA4J - http://www.service-conduit.org/user-guide.pdf - 其中很多内容似乎与 Spring 非常相似。

我试图了解 SCA 在哪些情况下有用，但仍然不了解 SCA 提供的与使用 Spring 独立版本相比有哪些功能/优势。

我发现了这篇旧博文 - http://rajith.2rlabs.com/2007/08/05/sca-vs-spring-a-reply-to-dans-post/ - 但从 SOA 行话中我发现没有什么特别突出的。

如果有人能给出更适合 Spring 开发人员的解释（在 SOA 术语/方法学领域非常年轻），我将不胜感激。

谢谢

【问题讨论】：

我推荐你阅读 SOA 专家 Udi Dahan 关于 SOA 概念的文章：feedproxy.google.com/~r/UdiDahan-TheSoftwareSimplist/~3/…

标签： java spring soa sca

【解决方案1】：

我对 Spring 不是最了解，但我对 SCA 非常熟悉，因为我曾在 IBM 的 WebSphere Integration Developer IDE 中使用过它，并且它部署到的环境：WebSphere Enterprise Service Bus 和 WebSphere Process Server。

这确实与抽象和允许开发人员专注于最重要的事情——业务逻辑的想法有关。我们都熟悉面向对象编程的概念以及该抽象如何更好地代表“现实世界”。然后是 Web 服务和面向服务的架构方法。 Web 服务通过减少对逻辑背后的语言的依赖，进一步抽象了我们的逻辑。现在 C++ 或 .Net 或 Java 甚至 RPG 或 COBOL 或任何可能在我们的 Web 服务背后的东西。我们可以让语言和系统以一种不依赖于 CORBA 和库之类的方式相互交流。

SCA（服务组件架构）试图将 SOA 提升到一个新的水平。它试图抽象用于与另一个系统或服务通信的协议和地址。原因如下：使用 Web 服务时，作为开发人员，您仍然需要使用协议并编写或挂钩大量样板代码。你必须知道你是http还是https。您必须知道您是（在 Java 世界中）JAX-RPC、JAX-WS 2.0、JAX-WS 2.1、JAX-WS 2.2 还是 JAX-RS（基于 REST）。您需要知道您使用的是 JSON、XML 还是 SOAP，如果是 SOAP，它是 1.0、1.1 还是 1.2？有时你甚至必须知道你的应用服务器的供应商是如何实现某些东西的（你不应该，但它可能是这样的）。然后，如果您希望您的 Web 服务与另一个服务通信，会发生什么情况。但是第二项服务恰好是基于消息传递的。这是否意味着 JMS？ MQ？ MQ 上的 JMS？其他？那么纯粹的 HTTP POST 和 GET 呢？

这就是 SCA 的用武之地。SCA 尝试抽象您的服务的端点，并对开发人员隐藏协议实现。当您需要一个服务时，您只需通过 SCA API 查找它，然后调用该服务（我认为该方法是执行？至少它在 IBM 的 SCA 扩展中）。但无论如何......现在您不必知道您正在与之通信的服务是 JAX-WS 2.1 或 REST 甚至 MQ。您不必知道您使用的是 SOAP/HTTP 或 JSON/XML 或 SOAP/JMS 等。 SCA 向您隐藏这一切。它允许您将不同实现的服务相互连接，以便它们都可以通过一个通用的“服务接口”相互通信。

您可以想象，这是在现有抽象技术之上的另一层抽象和技术。但是亲眼所见，我相信它是值得研究的。我知道 IBM 和 Apache（我认为目前还没有想到的其他人）致力于提出 SCA 标准。（实际上，IBM 的 SCA 版本现在建立在 Apache 提出的开放标准之上。希望其他支持 SCA 的供应商也这样做。）

我认为值得花时间看看。它可以帮助您关注的不是基于协议的服务集成，而是服务的业务逻辑，这才是它们真正带来的价值。

【讨论】：

感谢您的回复 - 我仍然不清楚。所以在功能层面上——SCA 并没有真正为 Spring 带来任何东西，但允许您使用 SOA 术语/概念构建系统？我只是想了解 SCA 在什么情况下真正为开发人员提供价值/功能，还是更适合 SOA 架构师？您提到了 Web 服务所需的样板代码量，SCA 在这里提供价值吗？（在使用 Spring Web Services 时，我从来没有编写过太多样板代码）。
SCA 的“最佳点”是协议的抽象。使用 Spring，您可以抽象类的实现。因此，您可以将对 JMS 消息服务的调用替换为对 SOAP/HTTP Web 服务的调用。但是你仍然需要编写 how 来调用服务，即。你将不得不处理协议。使用 SCA，您有“一个实现”，即，在 Spring 中，您将调用 SCA 绑定到服务。现在，如果服务从 SOAP/HTTP 更改为 REST 或 JMS，则无关紧要。您仍然只能使用 SCA 调用它。这更有意义吗？
我想我现在明白了一点；因此，如果您的所有服务都在您的 SCA 架构中定义，如果服务协议从 SOAP 更改为 REST，因为所有内容都在这个附加的 SCA 层中包装/抽象 - 所有调用此服务的组件都与协议更改隔离 - 您只需要更改 SCA 运行时中的绑定/配置...？
你明白了。这就是它背后的想法。您，开发人员，应该与“样板”协议逻辑隔离并专注于编写您的业务逻辑。所以 Spring 和 SCA 并没有真正竞争。它们只是解决不同的问题，因此可以相互配合使用。
@Bruce_Wayne - 这样做了。请在那里查看我的答案，看看是否有帮助。

【解决方案2】：

SCA 正在通过 OASIS (Assembly Specification) 进行标准化，因此您可以从不同的实现中进行选择（例如 Apache Tuscany 或 Fabric3）。

SCA 根据以下基本构建块定义应用程序：

接口：定义可用操作
组件：根据它提供哪些“服务”、它需要哪些“引用”以及它公开哪些可配置“属性”来描述一个实现工件
binding：声明服务或引用使用的通信协议
策略：捕获服务、引用或实现的非功能性需求

为了构建 SOA 应用程序，这些实体的具体“类型”被组合成组合。例如：

接口：WSDL 端口类型，Java 接口
组件实现：Java类、BPEL流程、Python、Spring
绑定：JMS、Web 服务、RMI/IIOP
政策：交易、安全

此外，SCA 定义了统一的客户端 API 以同步和异步调用组件（包括单向）。对于 Java，这包括基于注解的引用注入。

结合这些功能，您可以轻松地从异构技术创建分布式应用程序，并通过添加或交换绑定、实现、接口或策略技术来发展它们。

【讨论】：

虽然您已经提到 SCA 与 Spring 的不同之处，但您没有明确强调它们。例如，您提到了策略，但没有强调 Spring 和 SCA 如何允许创建策略的哲学差异。

【解决方案3】：

与 SCA 相比，与基本 Spring 相比，Spring Integration (http://www.springsource.org/spring-integration) 值得一看，因为 Spring Integration 提供了一个非常好的框架，可以透明地将远程组件连接在一起。

【讨论】：