可以使用 REST 设计 SOA 吗？答案

【问题标题】：Can a SOA be designed with REST?可以使用 REST 设计 SOA 吗？
【发布时间】：2012-05-16 12:50:49
【问题描述】：

我最近阅读了很多关于 SOA 的内容，但大部分内容都与 SOAP 相关，并且有很多属于 C#/Java 系统的“官僚”内容。老实说，我认为这样的官僚作风，特别是 SOAP，是一种痛苦。所以，我很好奇，可以用 REST 设计 SOA 吗？

现在通过 Ruby 应用程序，我将所有控制器都设为 RESTful。我的 Web 界面（表单等）向核心发出 GET/POST/PUT/DELETE 请求，这是一个 REST Web 服务。所有其他使用核心的系统都会向它发出 RESTful 请求。这是 SOA 吗？

【问题讨论】：

有没有人考虑过非基于 HTTP 的 REST 替代方案来进行服务内通信？在一个非常健谈的关键任务云平台中，REST 也有它的缺陷。它有效，但在通信方面可能会有下一次演变。想知道这里是否有人在该领域有一些意见。期待版主不喜欢这个评论，但我想我还是会试试的。 :)

标签： architecture soa

【解决方案1】：

关于 SOA 最重要的一点是软因素，例如让其他人使用您的服务，反之亦然，拥有一个 wsdl 链接，您可以从中构建一个易于使用的代理，这几乎是必不可少的。服务需要是可组合的......但您不需要编排、BPEL 或花哨的总线来执行此操作，当您开始使用 SOA 时，我不推荐它们。（事实上已经使用了这些，我认为没有它们你可以得到更好的结果，但你确实需要事件）

注意，像 WCF 这样的产品允许您创建一个公开 wsdl 的服务，但除了 SOAP 之外，您还可以使用 REST/Json 甚至更好的二进制 TCP 端点。这是理想的，因为您使用 SOAP 是为了简单起见并切换到二进制（这会在需要时将 REST 从水中吹走）。

在 SOAP 使用 WCF 构建高性能 SOA 系统的 8 年中，我从未注意到 SOAP 甚至存在。那是因为我主要使用 C# 工作，并且我们有一个很好的 SOAP 堆栈。大多数其他语言都有不是。

【讨论】：

【解决方案2】：

在高层次上，答案是肯定的，但不完全是。

SOA 需要从以下方面考虑系统

服务（定义明确的业务功能）
组件（离散的代码和/或数据结构）
流程（服务编排。一般使用 BPEL）

能够组合新的更高级别的服务或业务流程是良好 SOA 的基本特征。 XML、基于SOAP的Web Services及相关标准非常适合实现SOA。

SOA 也有一些公认的原则 - http://en.wikipedia.org/wiki/Service-oriented_architecture#Principles

标准化服务合同 - 服务遵守通信协议，由一个或多个服务描述文档共同定义。
服务松散耦合 - 服务保持一种关系，最大限度地减少依赖关系，并且只要求它们保持对彼此的了解。
服务抽象 – 除了服务合同中的描述之外，服务对外界隐藏了逻辑。
服务可重用性 - 将逻辑划分为旨在促进重用的服务。
服务自治 - 服务可以控制它们封装的逻辑。
服务粒度 - 在服务操作中提供最佳范围和正确粒度级别的业务功能的设计考虑。
服务无状态 - 服务通过在必要时推迟状态信息的管理来最大限度地减少资源消耗
服务可发现性 – 服务补充有通信元数据，通过这些元数据可以有效地发现和解释。
服务可组合性 - 服务是有效的组合参与者，无论组合的规模和复杂程度如何。

基于 SOA 的架构应具有服务定义。由于 RESTful Web 服务缺乏明确的服务定义（类似于 wsdl），因此基于 REST 的系统很难满足上述大部分原则。

要使用 REST 实现相同的目标，您需要拥有 RESTful Web 服务 + 编排（可能使用一些轻量级 ESB，例如 MuleESB 或 Camel）

另请参阅此资源 - From SOA to REST

添加此部分以澄清以下评论 -

需要编排来组合流程。这就是 SOA 的主要优势所在。

假设您有一个订单处理应用程序，其中包含以下操作 -

添加项目
加税
计算总计
placeOrder

最初，您创建了一个流程（使用 BPEL），它按顺序使用这些操作。您有使用此组合服务的客户。几个月后，一个新的客户来了，他有免税，那么你可以创建一个新的流程来跳过 addTax 操作，而不是编写新的服务。因此，您只需重用现有服务即可更快地实现业务功能。实际上有多种这样的服务。

因此，BPEL 或类似（ESB 或路由）技术对于 SOA 来说是必不可少的。没有业务用途，SOA 就不是真正的 SOA。

在我的个人博客上发帖 - http://blog.padmarag.com

还可以查看我遇到的这个新资源 - REST based SOA

【讨论】：

真的需要编排吗？我不明白这部分以及它如何使应用程序受益。另外，我不明白需要像 BPEL 这样的东西。
大多数 BPEL / ESB 解决方案不需要它，导致过度设计的解决方案性能很差。
我认为 REST 和 SOA 结合在一起的问题在于，它们都有自己的基本原则，不一定能很好地融合。没有什么可以阻止任何人使用 REST 服务来实现 SOA，如果它对您来说只不过是一个传输细节，但您将很难达到 HATEOS 或其他 REST 原则之类的东西。

【解决方案3】：

SOA 术语中的服务是解决特定业务问题的组件。 SOAP/WCF 与 SOA 的接口/交付部分更相关。也可以使用 REST 方法。服务合同、策略、版本控制和其他“标准”SOA 功能也可以通过 RESTful 服务实现。

主要的 RESTful 问题是它是针对 CRUD 的，因此它不是复杂逻辑实现的最佳选择。但是如果你的业务逻辑完全是 CRUD（或收敛到 CRUD），那应该没问题。

顺便说一句，微软似乎专门为 WCF 数据服务添加了操作来模拟带有 REST 的 SOAP。

【讨论】：

您能否举个例子说明您所说的“复杂逻辑实现”？