为何要结合SOA和Restful接口?

日期: 2013-07-07 作者:Tom Nolle翻译:boxi 来源:TechTarget中国 英文

自面向服务架构(SOA)演进发展以来,SOA就一直被拿来跟Web模型“RESTful”接口进行对比。尽管它们之间的差异已经讨论了很多,但大多数的讨论都是晦涩难懂的,企业仍然报告说自己困惑于究竟哪一种模式相对而言更好。   大多数应用架构师都意识到,如果应用合适,开发实践反映了双方的目标和好处的话,在某些情况下,将表述性状态转移(REST)与SOA结合起来是有可能且有优势的。最大的问题是目标是否要开发一个自始至终的RESTful接口,同时满足大部分SOA目标,或者混合使用REST和SOA。

   SOA、REST分解   SOA是为了促进灵活、敏捷应用开发而采取的一种架构,该架构通过在一般的工作流……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

自面向服务架构(SOA)演进发展以来,SOA就一直被拿来跟Web模型“RESTful”接口进行对比。尽管它们之间的差异已经讨论了很多,但大多数的讨论都是晦涩难懂的,企业仍然报告说自己困惑于究竟哪一种模式相对而言更好。

  大多数应用架构师都意识到,如果应用合适,开发实践反映了双方的目标和好处的话,在某些情况下,将表述性状态转移(REST)与SOA结合起来是有可能且有优势的。最大的问题是目标是否要开发一个自始至终的RESTful接口,同时满足大部分SOA目标,或者混合使用REST和SOA。  

SOA、REST分解

  SOA是为了促进灵活、敏捷应用开发而采取的一种架构,该架构通过在一般的工作流管理模型中常见组件来实现。这些组件之间是一种松耦合的关系,意味着组件是通过发布/订购登记流程来定位的,而且使用了一种常见的对象访问机制来链接(一般是是SOAP),使用了某种定义语言(WSDL)来描述将用户和提供商连接在一起的特性和接口。该模型支持识别、安全和恢复流程的标准机制,在支持复杂的业务关键应用方面拥有丰富的功能。

  RESTful模式是为了简化用户通过浏览器访问而设置的。尽管这种超文本标记语言(HTML)先看后点的浏览方式已经扩展为允许在程序元素之间,而不仅仅是与用户之间进行更为结构化的信息交换(扩展标记语言XML),其基本的接口是一样的;组件仍是以统一资源定位(URL)的方式表示,并采用与互联网兼容的域名解析系统(DNS)进行解码。

  组件连接不仅仅是松散而已,如果用户本身在连接中的选择不是可视化的话这种关联根本就不存在。RESTful很容易开发和部署,它是轻量的,托管和维护的成本也很低廉,很适合典型的在线应用。

  创建REST/SOA共生应用的典型方法是在SOA应用前端添加一个Web服务器,这会令SOA应用为互联网做好准备,并让它们可以为浏览器/瘦客户端所访问。虽然SOA组合应用灵活性很高时这很好,但是瘦客户端、移动及Web访问重要性的不断增强,促使某些架构师开始寻求在应用之中运用更多的RESTful概念。  

RESTful SOA的关键

  对于应用架构师来说,创建RESTful SOA的关键是定义可表示流程元素/资源的对象。在REST中,每一个对象都是通过URL来表示的,对象用户负责将状态信息打包进每一条消息内,以便对象的处理总是无状态的。太复杂的对象,如那些表示多阶段流程的,按照RESTful的形式编码会很困难,其使用将会需要转换设计模式或者其他的适配机制。

  RESTful SOA的第二大问题是组合管理及流程绑定。企业对正规的(基于SOAP)SOA最大的反对声之一便是,这种等级的发现和绑定灵活性不足以适应复杂性。他们报告说大多数应用的组件是相对静态的,在组件动态引入的地方,它们往往表示的是由另一应用暴露的功能或者甚至是另一用户通过API来暴露的功能—具有讽刺意味的是,那往往是RESTful的!

  提供基于目录的组件发现过程给RESTful接口是有可能的,如果这种水平的动态性有必要的话,但是此类需求也许意味着在应用前端使用RESTful、在后端采用SOA/SOAP的混合型方案的合理性。  

解决问题

  有些应用架构师也许担心RESTful接口的安全问题。从严格意义上来说,双方均可以采用相同的加密选项,但是在SOA/SOAP中,开发者对安全有着更为显式的控制。然而,RESTful应用可授权安全连接,开发者就可以确保做到同样的控制了。有关是否采取安全措施的审计问题可通过测试对接口的不安全的HTTP调用来确保这种模式下的连接是不被允许的。

  协调和工作流线程有时候也会成为通过RESTful接口实现的SOA的考虑问题。当然,许多消息总线协议都会支持RESTful接口的使用(具体支持视消息总线和选定开发语言而定)。可能构成挑战的是,在组件失败导致事务失败时确保撤销过程可实现。

  REST中没有明确中介流程,也没有具体机制来确保已成功完成的给定的RESTful流程是否可逆,进行逆向时所需的信息要少很多。映射进RESTful消息,将其进行跨阶段传递以便可回溯失败,这个过程的建立相对容易,但是可能有必要开发这一能力而不是仅仅利用标准工具或能力。

  今天很大一部分的“服务”实现都是基于REST而非SOA/SOAP的,但是做关键任务应用时企业已经形成对正规SOA架构的信任。对于安全/身份管理、可组合性及合规性绝对关键的应用,想对其进行RESTful化的再造可能会很困难。不过对于一般的企业来说,真正的问题是目前的应用组件是否需要SOAP或者可以采用RESTful的方式访问。

  如果能用上REST,就有可能提供更快的部署方式,与客户、供应商以及移动员工的集成也更加简单,还可以为员工支持提供更加灵活的GUI调整。虽然连其支持者也承认REST并非完美解决方案,但是对于许多SOA应用来说,这是最好的解决方案。

翻译

boxi
boxi

相关推荐