BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Jean-Jacques Dubray 关注 3 他的粉丝 ,译者 胡键 关注 0 他的粉丝 发布于 2008年5月12日. 估计阅读时间: 6 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

去年,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?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

挺中庸滴哈 by Xiang Ran

而WS-* 与REST之争已经不幸地退化成了偏见和信仰的争论,这只能导致混乱和无法履行的期望。
这句说滴让偶感受太深老。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT