BT

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

Internet比REST更基本吗?

| 作者 Mark Little 关注 14 他的粉丝 ,译者 戴垚 关注 0 他的粉丝 发布于 2007年12月25日. 估计阅读时间: 8 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

正当一些人认为争论已经陷入僵局已结束的时候,Ganesh Prasad又提出是存在一些比REST更基本(并更好)的东西,这无疑是给争论来了个火上浇油。正如他所讲,这个争论已经来来回回进行了好几轮了:

尽管我喜欢REST,也把它当作是SOA的一个很优雅的模型,但每天都听到它比基于SOAP的Web Services模型怎么怎么好,确实有些厌烦。事实上,厌烦到我要学同样的方式对REST支持者做这种令人不舒服的姿态。

然后,他列举了一些REST支持者们用来做论据的核心思想:

REST充分利用了现有最具伸缩性的应用(Web)的特性,不是吗?REST与Web根本不冲突,它们一起工作的很好,不是吗?HTTP是一个应用协议,而不止是一个传输协议,不是吗?URI是定位资源的最自然的方式,HTTP的标准动词是暴露使用资源可以做什么的最自然方式,超文本链接也是把这些连接起来以使整个系统成为一个状态机的最自然途径,难道不是吗?

然而,在他的观点里,随着Internet的成熟并更加具有扩展性,它比REST的扩展性更好也更具弹性。使用Internet模型(“它只是在智能网络中负责节点之间的消息传递”)会使你:

……Internet的哲学是“傻瓜网络,智能端点”(当然请记住,这个网络不是真“傻”,而是故意只做些弹性包裹传递而把聪明藏了起来)。而被Internet用来传送包裹的协议,当然就是Internet协议(IP)。

而当你要添加新功能的时候,它简单得就像:

只用创建你自己的端对端协议并使用IP包承载你的消息有效负荷完成节点间的通信。你不用向任何“中间人”咨询或协商。事实上根本没有什么中间环节。

当Ganesh谈到TCP在Internet中的角色时(UDP再一次被遗忘在历史的垃圾箱中),低级的的通信协议和更高级的应用协议栈的区别就显得清楚了:

TCP在端点被解释。这就是为什么计算机上的网络软件都叫做TCP协议栈的原因。每一个连接到IP网络的计算机都可以叫做端点,只要一个IP地址就可以定位。端点负责处理IP消息的内部信息,而Internet(即IP网络)完全不知道什么是sockets和端口号。这些概念都是由在它之上的协议创建和使用的。Internet具有的扩展性和层次架构使得在不影响弹性包路由能力的基础上可以进行一个更复杂的网络抽象操作。

当然这个讨论和一直有关于REST,SOA,WS-*和面向消息的架构的讨论有些相似,因为达到松散耦合和伸缩性的核心原理是一样的:在服务端点后隐藏尽可能多的东西。为了证明Internet在变更需求时是多么的具有弹性和灵活,Ganesh谈到了IPSec,并问(修辞性地)是否添加了IPSec就对Internet做了大的改动:

……他们只是创建了另一个称为ESP(Encapsulating Security Payload)的端到端协议和能够解释协议的端点。即他们在TCP和IP之间添加了一层新的协议。

在进一步参考“即使在电信领域Internet也打败了电信网络”的时候,Ganesh继续解释了为什么REST(和Web)并不比其他的分布式计算架构更优越。

Internet是一个分散创新的平台。(见鬼,你们这些在大家面前晃来晃去的REST支持者们用的万维网就是一个在Internet上创新的例子。HTTP不就是一个端到端的协议,不是吗?)

但WS-*哪里去了?到目前为止只讨论了Internet VS REST(事实上是Web),而没有Web Services或SOAP。然而,在SOAP-RPC被遗忘了一阵儿之后,Ganesh清楚地表示他对SOAP消息的定义是“带有WS-Addressing头的SOAP消息”,因为就像一个IP包,WS-Addressing的使用同样给了你的消息能够独立路由的能力。然后他通过一些漂亮的图帮助阐述了这种关联性

现在想象一个消息传输架构,它只能路由SOAP消息……我们如何进行创新并在此之上建立更高级的功能呢?唉,当然是学Internet的模型啦。为每一个新功能创建一个协议并把协议数据嵌入到SOAP消息里面(尤其是SOAP的头部)。不需要把它们放在TCP协议栈里,因为可靠性传输,安全,事务等等都是正交无关的。可以把它们放到SOAP的头部作为同一层存在...

通过这种方式,我们最后得出的一点是“一个松散耦合的服务生态系统需要象管道一样随意装配”。当然这并不足以创建基于SOA的应用(象其他有些人一样,Ganesh好像SOA),这时XML成了救世主。Web Services画上了等号

那么现在请使用一种XML模式定义语言和你选择的词汇(为银行,保险或航空业)来定义文档契约,把对应的XML文档象我们谈到过的一样嵌入到SOAP消息体中,并保证消息的生产者和消费者都只依赖于那些文档契约。这样就可以了!松散耦合的组件!面向服务的架构!

假如真的象在现实世界的标准中真的那么简单,你得到的也只是一些一般的要点。但如果真的那么容易,有一个明显的问题就是:为什么我们还没有做到呢?Ganesh认为这背后有六个原因:

  1. 现有的SOAP-RPC:“即使在今天,还有一种思潮说使用WSDL就意味着RPC,但我对于被包装的document/literal风格感到满意,它让我们远离了喧嚣的RPC encoding”。
  2. 除了HTTP之外,SOAP缺少绑定相关的标准
  3. 需要穿越防火墙的隧道,这和SOAP/HTTP缺省绑定有关。“我们需要为SOAP自己指定一个端口,并使防火墙对此端口开放。不要因为我们喜欢80端口就一直使用HTTP。”
  4. “集中消息代理软件提供商还在假装接受SOAP/WS-*的远景(‘我们在标准委员会里!’),但其实他们还在以中间件谋生,而不是端点软件。”
  5. 业界还在被未开放源码的WS-*协议栈所统治。
  6. 事实上,很多重要的WS-*规范(事务、安全、可靠性等)最近才成熟(不论是被使用的,还是开发了5年的)。

最后,他相信SOA只有两种可行的途径,就是REST和“采用智能端点的SOAP消息传输处理”,而其中REST并不占明显的优势。

查看英文原文:http://www.infoq.com/news/2007/12/rest-ws-payback
译者简介:戴垚,2000年计算机硕士毕业后一直从事软件开发管理工作,目前在一家大型外企担任开发部门经理。关心软件技术和相关工具的动态,深信技术的使用应以创造价值为根本。目前致力于SOA的研究,希望能对业已复杂的企业环境有所帮助。参与InfoQ中文站内容建设,请邮件至china-editorial@infoq.com

 

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的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通知我

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

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

讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT