写点什么

使用架构决策框架公平地比较 REST 和 WS-*:争论可以停止了吗?

  • 2008-05-11
  • 本文字数:1763 字

    阅读完需:约 6 分钟

去年,Olaf Zimmermann 及其 IBM 研究院同事开发了一个能促进企业应用开发的架构决策框架

在实践过程中,捕获架构决策对架构师来说依旧是一个挑战。已知的决策捕获抑制剂包括:项目发起人没兴趣、缺少时间和工具支持不足

他们提出了针对 3 个决策捕获步骤的概念框架:

  • 决策识别 —— 现实:决策识别仅仅基于个人经验,而且 [常常是] 临时性的。
  • 决策制定 —— 现实:决策制定者常常带有个人偏见……他们依赖于过去的经验……[或]……行业趋势。
  • 决策执行 —— 现实:训练、架构模板和代码互审是主要的决策执行方法。

通过给决策建模提供一个结构、积极主动的方法,他们意在:

通过决策依赖模型、决策驱动者目录和推荐的决策制定技术来改善决策制定质量

几周前,Cesare Pautasso、Olaf Zimmermann 和 Frank Leymann 在 WWW 2008 会议(在北京举行)上发表了一篇论文,详细比较了“ RESTful Web 服务大型 Web 服务(Big Web Service)”,对“制定正确架构决策”进行了深入探讨。

集成企业应用可以使用多种不同风格。这个选择……是一个重要架构决策。“大型”Web 服务技术栈(SOAP、WSDL、WS-Addressing、WS-ReliableMessaging、WSSecurity 等)提供了远程过程调用(RPC)和消息集成风格的互操作性。最近,另一种解决方案被提出来实现跨互联网的远程过程调用:所谓的 RESTful Web 服务。

分布式系统中关键的架构决策,如选择集成风格和技术,应该以每个备选方案的技术论据和具体交付能力的公平比较为基础。而 WS-* 与 REST 之争已经不幸地退化成了偏见和信仰的争论,这只能导致混乱和无法履行的期望。

在这篇论文中,[作者] 在架构原则和决策的基础上,采用了量化方法来比较这两种集成风格。

首先,作者详细地回顾了每种技术公认的优缺点: ### SOAP 和 WS-* 栈

除了它们公认的复杂性,SOAP 消息格式和 WSDL 接口定义语言作为能在异构中间件系统中提供互操作性的网关技术得到了广泛使用。

自相矛盾的是,这种由当今 WS-* 工具所提供的将已有软件组件方便地转化为 Web 服务的能力也会被滥用。这样,避免跨抽象级别的信息泄露就变得很重要。例如,在服务接口中出现服务实现的本地数据类型和语言结构就会引发互操作性问题。这个缺点可通过表述和强制某种设计和编码指南(如契约优先的开发)得到缓解。

REST

RESTful Web 服务的简单性是公认的,因为 REST 利用了现有众所周知的 W3C/IETF 标准(HTTP、XML、URI、MIME),这种必须的基础设施已经深入人心……这种轻量级的基础设施,使用极少的工具就能开发其中的服务,获取成本低廉且采用门槛很低。

[但是],关于公认的 RESTful Web 构建最佳实践存在一些混淆。高端 REST(Hi-REST)推荐已被制定,但是它们并不总被所谓的低端 REST(Lo-REST)实现遵守……[在实践中] 只有 2 个动词(幂等请求使用 GET,其他则使用 POST)被使用……[因为] 代理和防火墙可能不总是允许建立使用其他动词的 HTTP 连接……限制导致了一系列的替代方法(workaround),其中“真正的”动词要么使用一个特殊的 HTTP 头(X-HTTP-Method-Override)发送,要么就——如 Ruby on Rails——用一个隐藏框(——method)提交……

接下来,他们基于架构决策框架确定了一个比较方法。他们使用字面含义识别候选决策和替代决策。在使用 EST 和 WS-* 时,他们开发了几个记录架构决策的集成场景。他们为每种集成风格创建了一个决策模型,这使得他们能使用一些数据(如决策数量、每个决策的备选数量……)来客观的比较这两个模型。

作者接着继续比较了原则、概念和技术。他们的发现包括:

在原则层次,两种方法有相似的量化特征。在概念层次,在为 WS-* Web 服务决策时,必须制定的架构决策更少,而备选方案更多。

在技术层次,必须制定的决策数目相同,但是在构建 RESTful Web 服务时必须要考虑的备选方案更少。

特别地,作者说明:

这样,就从量化的观点认识了 REST 公认的简单性。[但是],据我们的经验,对于 RESTful 服务非常容易做出的决策会导致显著的开发努力和技术风险,如设计严格的资源规范和它们的 URI 寻址模式。

作者总结说:

……灵活地使用 RESTful 服务,特别是跨互联网的集成(以 Mashup 的方式),对于生命跨度更长和具有高级 QoS 需求的专业企业应用,优先使用 WS-* Web 服务。

查看英文原文 A Fair Comparison of REST and WS-* using an Architectural Decision Framework: is the Debate Over?

2008-05-11 03:091811
用户头像

发布了 255 篇内容, 共 67.2 次阅读, 收获喜欢 10 次。

关注

评论

发布
暂无评论
发现更多内容

《程序员的数学》笔记

Rex

读书笔记

【快点查查】微信小程序使用流程

tomatocc

无需代码!通过 Dataway 配置一个带有分页查询的接口

哈库纳

spring springboot Dataway Hasor

码农远程办公指北

大伟

Vol.5 Go初探,新手必看!

pyfn2030

编程语言 新手指南

那些会阻碍程序员成长的细节[1]

MavenTalker

程序员 职业规划

艺术生,我劝你Mac

zhoo299

Mac CG 艺术

系统服务化构建-两方OAuth

图南日晟

微服务 软件工程 身份认证 架构设计

代码简洁之路 [持续更新]

hq

Java 大前端 编程习惯

从 0 到 1 搭建技术中台之技术文化篇

伴鱼技术团队

企业文化 技术管理

原创 | 使用JUnit、AssertJ和Mockito编写单元测试和实践TDD (十)在项目中准备测试环境

编程道与术

Java 编程 软件测试 TDD 单元测试

说到做到

Yukun

拖延症

Wi-Fi p2p & ap 共存

贾献华

wifi p2p ap

Vol.6 几个数据库相关的词

pyfn2030

数据库 大数据 新手指南

Dataway 4.1.5 以上版本升级指南

哈库纳

string StringBoot Dataway Hasor

如何用一台电脑制作一部动画短片?

zhoo299

动画 CG

Vol.2 谷歌不只有搜索

pyfn2030

谷歌Google

Dataway 配置数据接口时和前端进行参数对接

哈库纳

Spring Boot DataQL Dataway Hasor

AB 测试平台的设计与实现

伴鱼技术团队

架构 系统设计 后端 A/B

ARTS-WEEK01

子路无倦

ARTS 打卡计划

Gartner 【RPA市场竞争格局】:中国厂商首次进入国际视野

人称T客

自己常用的一些快捷键 windows10

halapano

Windows技巧

使用SpreadJS 开发在线问卷系统,构筑CCP(云数据采集)平台

葡萄城技术团队

数据挖掘 大数据 SpreadJS CCP

完美兼容老项目!Dataway 4.1.6 返回结构的全面控制

哈库纳

spring Spring Boot Dataway Hasor

Vol.4 了解一下渗透测试

pyfn2030

黑客 网络安全

计算机的时间

伴鱼技术团队

分布式 服务器 技术交流

Vol.3 人工智能这么热,你必须知道一点儿!

pyfn2030

人工智能

绝了!Dataway让Spring Boot不再需要Controller、Service、DAO、Mapper

哈库纳

StringBoot DataQL

Dataway 整合 Swagger2,让 API 管理更顺畅

哈库纳

Spring Boot DataQL Dataway Hasor

Anaconda与虚拟环境

halapano

Python virtualenv Anaconda

免费领课的活动你错过了么?

池建强

极客时间

使用架构决策框架公平地比较REST和WS-*:争论可以停止了吗?_SOA_Jean-Jacques Dubray_InfoQ精选文章