写点什么

使用架构决策框架公平地比较 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:091482
用户头像

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

关注

评论

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

情绪管理 - ABC理论

石云升

情绪控制 ABC理论 费斯汀格法则

如何基于 OAM 编写一个扩展 Trait?

钱王骞

云原生 k8s OAM

面向对象的三个基本特征(要素)

彭阿三

三要素 三个基本特征 封装、继承、多态

kubernetes简单入门(多图少字版)

绿星雪碧

Kubernetes 入门

中电标协提出并归口:《政务APP评价指标》团体标准开启制订工作

博睿数据

App 标准化 中电标协 政务信息化 博睿宏远

钩陈/ 好中文作业:巴别塔

ZoomQuiet大妈

写作 大妈 是也乎 IMHO 蟒营®

架构师训练营学习总结——框架设计【第二周】

王海

极客大学架构师训练营

Java | 原来 serialVersionUID 的用处在这里

YoungZY

Java

华硕灵珑II笔记本电脑——自由work不设限

最新动态

月薪 3W 的 Apple 微信编辑是这么发文章的 |如何发类似 Apple 微信公众号的文章效果

陈东泽 EuryChen

CSS 微信 大前端 apple 微信公众号

架构师训练营作业(第二周)

王海

极客大学架构师训练营

机器学习算法评估指标—2D语义分割

做技术BP的文案Gou

学习 2D 评估标准 语义分割

Java 序列化

CoderLi

Java 程序员 后端 序列化

Zookeeper Watcher 流程分析(结合源码)

CoderLi

Java zookeeper 源码分析 后端 Watcher

常用运筹学软件整理

张利东

2020年5月云主机性能评测报告

博睿数据

云计算 服务器 公有云 机房 云主机

2w字长文!手撸一套 Java 基础面试题

苹果看辽宁体育

Java 后端 Java25周年

Zookeeper-Access Control List(ACL)

CoderLi

Java zookeeper 源码分析 后端

iPad配置OpenVPN客户端

wong

ipad OpenVPN

重学 Java 设计模式:实战外观模式「基于SpringBoot开发门面模式中间件,统一控制接口白名单场景」

小傅哥

设计模式 小傅哥 重构 代码质量 代码坏味道

JAVA 中的 CAS

犀利豆

Java 并发 CAS

副业月赚 10 万的程序员是如何做销售的?

非著名程序员

程序员 独立开发者 程序人生 提升认知

ZooKeeper 数据模型:节点的特性与应用

CoderLi

zookeeper 源码分析 数据模型 节点

Zookeeper 序列化

CoderLi

Java zookeeper 源码分析 后端

下周要开始“卖桃者说”代班计划了

霍太稳@极客邦科技

日常

知乎Matisse图片库在Android10上拍照,预览问题

三爻

android

如何让程序员变得没朋友

四猿外

程序员 个人感悟 技术人生 经验分享

原创 | TDD工具集:JUnit、AssertJ和Mockito (二十一)编写测试-测试模板

编程道与术

Java 编程 TDD 单元测试 JUNI

原创下载 | TDD工具集原创开源代码免费下载!

编程道与术

Java 开源 TDD 下载 代码

游戏夜读 | 如何制作游戏?

game1night

自由是不是随心所欲?

Neco.W

个人成长 自由 控制

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