我最近一直在阅读有关SOA的很多内容，但大多数内容都与SOAP相关，并且有许多属于C＃/ Java系统的“官僚”内容 . 老实说，我认为这种官僚主义，特别是SOAP，是屁股的痛苦 . 所以，我很好奇，SOA可以用REST设计吗？
现在，在Ruby应用程序中，我将所有控制器都设置为RESTful . 我的Web界面（表单等）向核心发出GET / POST / PUT / DELETE请求，这是一个REST Web服务 . 使用该核心的所有其他系统都会向其发出RESTful请求 . 这是一个SOA吗？
3 回答
在高级别，答案是肯定的，但不完全 .
SOA需要考虑系统
服务（明确定义的业务功能）
组件（离散的代码片段和/或数据结构）
进程（服务编排 . 通常使用BPEL）
能够构建新的更高级别的服务或业务流程是良好SOA的基本特征 . XML，基于SOAP的Web服务和相关标准非常适合实现SOA .
SOA也有一些公认的原则 - http://en.wikipedia.org/wiki/Service-oriented_architecture#Principles
标准化服务 Contract - 服务遵守通信协议，由一个或多个服务描述文档共同定义 .
服务松散耦合 - 服务维持一种最小化依赖关系的关系，并且只要求它们保持彼此的意识 .
服务抽象 - 除了服务 Contract 中的描述之外，服务隐藏了来自外部世界的逻辑 .
服务可重用性 - 逻辑分为服务，旨在促进重用 .
服务自治 - 服务可以控制它们封装的逻辑 .
服务粒度 - 一种设计考虑因素，用于在服务操作中提供业务功能的最佳范围和正确的粒度级别 .
服务无状态 - 服务通过在必要时推迟管理状态信息来最小化资源消耗
服务可发现性 - 服务补充了通信元数据，通过它可以有效地发现和解释它们 .
服务可组合性 - 服务是有效的组合参与者，无论组合的大小和复杂程度如何 .
基于SOA的架构应该具有服务定义 . 由于RESTful Web服务缺少明确的服务定义（类似于wsdl），因此基于REST的系统很难满足上述大多数原则 .
要使用REST实现相同的目标，您需要使用RESTful Web Services Orchestration（可能使用一些轻量级ESB，如MuleESB或Camel）
另请参阅此资源 - From SOA to REST
添加此部分作为以下评论的说明 -
编排流程需要编排 . 这就是SOA提供主要优势的原因 .
假设你有一个订单处理应用程序，其操作如下 -
addItem
addTax
calculateTotal
placeOrder
最初，您创建了一个按顺序使用这些操作的进程（使用BPEL） . 您有使用此组合服务的客户 . 几个月后，有一个新的客户来免税，然后你可以创建一个跳过addTax操作的新流程，而不是编写新服务 . 因此，只需重新使用现有服务，您就可以更快地实现业务功能 . 在实践中，有许多这样的服务 .
因此，BPEL或类似（ESB或路由）技术对SOA至关重要 . 没有业务用途，SOA实际上不是SOA .
Cross发布在我的个人博客上 - http://blog.padmarag.com
还检查我遇到的这个新资源 - REST based SOA
SOA术语中的服务是解决某个业务问题的组件 . SOAP / WCF与SOA的接口/交付部分更相关 . 也可以使用REST方法 . 服务 Contract ，策略，版本控制和其他“标准”SOA功能也可以使用RESTful服务实现 .
主要的RESTful问题是它以CRUD为目标，因此它不是复杂逻辑实现的最佳选择 . 但是，如果您的业务逻辑完全是CRUD（或收敛到CRUD），那么应该没问题 .
顺便说一下，微软似乎特意将操作添加到WCF数据服务，以便用REST模拟SOAP .
关于SOA最重要的是软因素，例如让其他人使用您的服务，反之亦然有一个wsdl链接，你可以从中 Build 一个易于使用的代理几乎是必不可少的 . 服务需要是可组合的..但是你不需要Orchestration，BPEL或花哨的总线来实现这一点，当你从SOA开始时我不会推荐它们 . （实际上已经使用了这些我认为没有它们你可以获得更好的结果，但你确实需要事件）
注意像WCF这样的产品允许你创建一个公开wsdl的服务，但除了SOAP你还可以使用REST / Json甚至更好的二进制TCP endpoints . 这是理想的，因为你使用SOAP来简化并切换到二进制（吹当你需要时，REST退出水面 .
对于使用WCF构建高性能SOA系统8年的SOAP，我从来没有注意到SOAP就在那里......那是因为我主要使用C＃而且我们有一个很好的SOAP堆栈......大多数其他语言都没有 .