SOA可以用REST设计吗？

Question

我最近一直在阅读有关SOA的很多内容,但大多数内容都与SOAP相关,并且有许多属于C#/ Java系统的"官僚"内容.老实说,我认为这样的官僚主义,特别是SOAP,是一种痛苦的屁股.所以,我很好奇,SOA可以用REST设计吗？

现在,在Ruby应用程序中,我将所有控制器都设置为RESTful.我的Web界面(表单等)向核心发出GET/POST/PUT/DELETE请求,这是一个REST Web服务.使用该核心的所有其他系统都会向其发出RESTful请求.这是一个SOA吗？

Answer 1

在高级别,答案是肯定的,但不完全.

SOA需要考虑系统

• 服务(明确定义的业务功能)
• 组件(离散的代码片段和/或数据结构)
• 进程(服务编排.通常使用BPEL)

能够构建新的更高级别的服务或业务流程是良好SOA的基本特征.XML,基于SOAP的Web服务和相关标准非常适合实现SOA.

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

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

基于SOA的架构应该具有服务定义.由于RESTful Web服务缺少明确的服务定义(类似于wsdl),因此基于REST的系统很难满足上述大多数原则.

要使用REST实现相同的目标,您需要具有RESTful Web Services + Orchestration(可能使用一些轻量级ESB,如MuleESB或Camel)

另请参阅此资源 - 从SOA到REST

添加此部分作为以下评论的说明 -

编排流程需要编排.这就是SOA提供主要优势的原因.

假设你有一个订单处理应用程序,其操作如下 -

• 新增项目
• addTax
• calculateTotal
• 下订单

最初,您创建了一个按顺序使用这些操作的进程(使用BPEL).您有使用此组合服务的客户.几个月后,有一个新的客户来免税,然后你可以创建一个跳过addTax操作的新流程,而不是编写新服务.因此,只需重新使用现有服务,您就可以更快地实现业务功能.在实践中,有许多这样的服务.

因此,BPEL或类似(ESB或路由)技术对SOA至关重要.没有业务用途,SOA实际上不是SOA.

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

还要检查我遇到的这个新资源 - 基于REST的SOA

Answer 2

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

主要的RESTful问题是它以CRUD为目标,因此它不是复杂逻辑实现的最佳选择.但是,如果您的业务逻辑完全是CRUD(或收敛到CRUD),那么应该没问题.

顺便说一下,微软似乎特意将操作添加到WCF数据服务,以便用REST模拟SOAP.