Sanjiva Weerawarana访谈：揭秘REST/WS-*

InfoQ的Stefan Tikov对Sanjiva Weerawarana先生进行了一次访谈，Sanjiva先生在IBM研究院（IBM Research）工作了近8年之后创办了WSO2，另外他还是IBM Web Services平台的创办人之一。在此期间，他参与编写了许多Web Services规范，包括WSDL、BPEL4WS、WS-Addressing、WS-RF和WS-Eventing。他主持创建的IBM SOAP4J，在SOAP 1.1规范发布仅仅两天之后就进行了发布，后来成为Apache SOAP。他还不断架构和实现许多其他的产品，包括Apache Axis、Apache WSIF、IBM Web Services Gateway和BPEL4WS的一个实现IBM BPWS4J等，并且是IBM Web Services技术策略的主要领导者。

Sanjiva在IBM和Apache都已经参与开源软件多年。除了Apache Web Services项目之外，Sanjiva还是Apache Jakarta BSF的创办人，同时还致力于Apache Xalan的创建。他也是WSDL 2.0规范的编辑之一。

作为WS-*架构的远景提出者之一和坚定的倡导者，我们问了他关于WS-*平台以及他对Microsoft在标准化方面所起作用的看法。Sanjiva也借机向我们揭开了“WS-*和REST的神秘面纱”。

InfoQ：Sanjiva先生，您已经参与Web Services标准化这么长时间了，您对WS-*规范当前的状况有何评价？

Sanjiva Weerawarana（SW）：虽然它花费的时间比我们一开始设想的长了许多，但我认为WS-*平台的核心最终会很稳定、很可靠。我们还有一些滞留的标准化工作有待完成，但是整套工作规范是很稳定、可互操作的，足以用于产品部署。

我知道WS-*规范最大的问题在于缺少一个独立的规范，用来展示平台架构的主要组件。这使得人们会说：“哎呀，有100多个WS-*规范，我怎么可能知道什么是重要的什么是不重要的呢？！”Microsoft的WS-*平台所带来的：Indigo（WCF），将稍微解决这个问题，因为该平台有一组非常小的、但很清晰的规范，不过要消除不同公司的政治影响来创建富有竞争力的标准，将很费时间。

InfoQ：我个人感觉（可能稍微有点简单化了），Microsoft决定了如何架构，其他人就不得不遵循。如果不遵循WCF，就无法得到广泛的认可。你同意这种观点吗？

SW：我是IBM中将该平台定义成遵循WCF的少数人之一（还有MSFT团队）。核心的WS-*平台的确是WCF中的东西。除了WSO2之外，Microsoft是唯一实现了整个平台的公司。IBM和其他公司做起来都不像我们这么容易，因为他们有许多遗留的东西（JEE）要兼顾。（如果你读过我几天前写的博客文章，就会明白为什么注定要这么做。）

因此，是的，WCF本质上将在Windows平台上提供一个参考实现。我们给Java、C和脚本语言提供一个参考实现。

InfoQ：你对REST有什么评价？

SW：首先，REST已经明确地给Web提供了一个很好的架构基础。然而，别忘了一件关键的事：Web必须以人为中心——只有一侧Web交互是自动进行的。另一侧则有人类的用户在操纵软件，它允许有难以置信的疏忽和灵活性。

因此，问题在于REST是否给应用程序间的交互提供一种比WS-*更好的基础。

人们当然已经使用Web进行应用程序间的整合有很多年了。但那就是真正的REST吗？或者只是使用Web的基础结构？答案当然是后者：现实就是大多数的人们通过HTTP反复地传输XML文件，在更简单的情况下，用HTTP GET来发送数据并接收响应。这并不是REST，因为没有设计妥善的资源结构。

人们确实已经针对各种特定的问题，构建了真正REST风格的应用程序间整合系统。然而，如今的现实就是这样，只不过没有标准的方法来用REST解决这些问题。

因此我完全理解REST是构建可伸缩系统的一种很好的架构模型。但它是唯一的吗？我想不是。它足以解决应用程序间整合所需的一切问题吗？我也确定它不行；如果可以的话，那我们就不必在此谈论它了。

InfoQ：虽然外面的确有许多非REST的Web用法，我看不出这会降低它的价值。你是否认同，一个REST风格的Web应用程序，无论是应用程序到应用程序，还是应用程序到浏览器，都比非REST的应用程序更好？

SW：不，我从来没有授予它这样的权利！“更好”是什么意思？你是要我认同说，使用一个固定的接口，并把所有的交互语义理解都移到媒介类型（media types），这么做对于所有的场景都更好吗？不，我不这么认为。必定有一些很适合的情况（例如Web），但是在其他情况下并非都是那么好。

构建一个分布式的系统并不仅仅只有一种方法。REST是一种，SOA是另一种，分布式的对象和RPC也是。任何人认为REST是唯一的方法都是天真的（或者是REST的盲从者（RESTafarian）！）

InfoQ：我不认为REST是构建分布式应用的唯一真正的方法，我也不知道“REST盲从者”会这么认为。我确信使用Web（和HTTP）的最好方法是遵循它的架构。我明确提问的是关于Web应用程序，而不是分布式应用程序。

SW：我假设你认同网络银行（Internet Banking）是一个非常流行的Web应用程序，对吧？那么这些是REST风格的吗？当然不是！它们使用cookies，它们的底层没有资源结构等等——它们所做的实际上就是有效地使用HTTP、HTML和CSS（有时候还有XML）。Google地图又如何呢——它是REST风格的吗？你能给我不同分辨率下的每一个地图块的一个URI吗？POX怎么样呢——人们已经使用了多年——大部分也不是REST的。

现实就是，许多真正成功的Web应用程序都不是REST的。这样不好吗？我不觉得——他们只是在利用TimBL和其他人发明的东西去很好地完成工作，并做得很棒。他们没有遵循REST规则，这重要吗？只是对于REST盲从者来说很重要；那些应用程序运行得很好，可以伸缩，用户们喜欢——谁会说它们错了呢？

因此，不，我完全不能接受“REST风格的应用程序从根本上来说更好”的说法。

InfoQ：您认为Web Services在哪些方面解决得比较好？

SW：Web Services解决了两个关键的方面：一个是提供了一套交互的标准，以一种支持业务需求的方式。也就是说，假如你正在订购一台飞机用的引擎，Pratt&Whitney公司会接受来自波音公司只是通过包含HTTP基本验证的HTTPS连接传过来的订单吗？我想不会。在那些情况下，你会想让授权人在信息上签字，并且适当地加密，以确保不会被篡改。此外，你绝对希望该消息就只传一次——波音公司没有地方随便放置引擎。我可以继续——但那是Web Services解决的问题——提供一套标准，一个应用程序与另一个应用程序会话时可以互用的协议，同时确保安全性、可靠性及其他服务的业务级品质。

因此，WS-*在做的基本上就是采用人们已经使用多年的POX交互风格，并针对如何以标准的方式实现某些业务需求增加了一些约定。

理论上来说，REST可以用来实现所有这一切，但现实是那些功能并不是现有的标准，这意味着你基本上需要个别地（case-by-case）创建那些功能，这也是在WS-*出现之前，POX过去的情形。

InfoQ：WS-*规范努力把这一点构建到平台中，而REST拥护者则最喜欢在应用程序级别上来完成？

SW：是的——的确，因为他们不会尝试，比如用可互操作的方式实现消息级的安全性。无论我正在使用哪个应用程序，都可以用REST用同样的方式给消息签名吗？不行，因为还没有这样的标准；你必须询问对方他们想要如何签名。

REST拥护者会说，你不需要WSDL，因为世界是自描述的。啊？在REST中，如果接收方理解我发送的内容类型，数据就是“自描述”的。但并不是每块数据都有内容类型；因此双方都必须认可要使用的类型！在浏览器领域中，这种事情还相对容易，因为你在一端有一个聪明的操作人员。在整合领域中，关于你将发送什么东西给我，一定有声明和协议，否则我们就不谈。

REST拥护者应该看一下“WSDL 2.0的HTTP绑定”——它们的确提供了一种非常简洁的方法来描述REST（和非REST）风格的HTTP Services。WADL的许多思想取自WSDL 2.0，并且除了NIH之外，我想不出他们为什么不使用和改进WSDL 2.0的理由。

当然，第二个方面就是Web Services不仅可以通过HTTP，还可以通过其他的传输协议进行实现。哇！我曾经因为把“传输”与HTTP相提并论而触犯天条！但是真的，WS-*可以通过SMTP、XMPP、JMS和各种其他的协议进行工作。是的，REST也可以通过其他的协议实现，但是HTTP是唯一被设计为以REST风格正确地工作的转换协议。

InfoQ：你显然十分在意HTTP是一个应用程序协议（application protocol），或者转换协议（transfer protocol），而不是传输协议（transport protocol）。当SOAP/WS-*层被放在它的顶部时，它的许多功能都没有用到——比如缓存、标准的标识符、等幂（idempotent）和安全的方法。你是否认同这样的说法：如果我只需要支持HTTP，当我使用WS-*时就会失去某些东西？

SW：从某种程度上来说，是这样。我绝对相信有些HTTP的主要特性作为转换协议会非常有用。目前大量的WS-*中间件在如何最佳地利用那些特性方面还做的很不够。如果你看一下WSDL 2.0，就会发现我们已经挑出了等幂且安全的方面。缓存仍然也可以完全地得到支持。让我把标识符的话题留到以后，因为你专门问的是WS-Addressing。

作为第一个进行SOAP实现（Apache SOAP）的人，我对于WS-*应该被如何实现方面的几个错误决定负有全责。（如果你观看了“我在Google上所做的讲话”，就会了解到更多这方面的信息。）第一代WS-*堆栈（stacks）大多数沿用Apache SOAP。之后Apache Axis出现了，并且定义了一堆新的东西（handler等等），大家（包括JAX-RPC&MSFT）接踵而至。现在Apache Axis2正在定义一整套新的东西（策略驱动架构、模块、分离上下文等等），我们再一次被别人复制。因此，你看到的是人们正变成在考虑WS-*如何适应Web。我们已经适应了吗？还没有，但是我们正在努力地改进。

WS-*的诸多批评来自于继续把SOAP当作分布式对象通信机制的人们。SOAP 1.1的确有那些特性（通过SOAP-RPC和SOAP编码），但是SOAP 1.2已经完全没有那些特性。WSDL也一样——1.1内建了PRC，但2.0中却丝毫没有。

WS-*实现也是这样——人们看着旧式的WS-*实现，说“啊，它只是通过XML的RPC而已”。看一下WSO2 WSAS（Apache Axis2版权所有）或者Microsoft的WCF，会看到它们压根不靠RPC过日子。事实上，在Axis2和WSAS中，根本没有构建任何RPC的概念。我在Google的谈话中深入讲述了这个方面。

InfoQ：你认为REST与WS-*的观点能够统一吗？

SW：真正的问题是，面向资源的架构和面向服务的架构是否一回事。我断定它们不是一回事：鉴于分布式的系统问题，人们可以用任一种方法和结果截然不同的一些工件来发展成解决方案。真正的REST应用程序是面向资源的。WS-*用来实现面向服务的架构。因此这不是谁对谁错的问题，而是它们根本就不同。REST拥护者正在努力实现的一项伟大的行销妙计是：WS-*很复杂，而REST则很简单。这真是胡扯——如果你真正试过用REST去构建人们通过WS-*构建的系统时，就不会只是用“复杂”来下定论了。

同时，许多场景的交互并不需要所有的WS-*。这就是交叉点之所在——新的堆栈如WSO2 WSAS和Apache Axis2，它们本质上通过WSDL 2.0驱动，对于POX风格的服务以及HTTP GET提供完整的支持。最终的系统不一定是REST风格的，但是它们与REST提供的一样有简单化的优势。并且最好的部分在于我们设计编程模型和基础结构的方法，人们可以一次编写一项服务，并提供一个POX绑定，一个GET绑定，一个SOAP/WS-*绑定，甚至一个JSON绑定，却一行代码都不用写。

对我而言，这就是前进的方式——采用两个领域中最好的，把它们揉合在一起，而不是触犯任何一方的信仰。

InfoQ：我认为WS-*架构仍然必须实现REST/HTTP的那些特性。例如，对我而言，WS-Addressing似乎像个非常不好的对URL的重复发明——它仍然没有获得一些认可。

SW：所以让我们回头看看我们为什么必须创建WS-Addressing。我们创建了端点引用（Endpoint References），因为当你与服务有业务交互时，该交互的状态就不只是URI——还有可能需要传播业务上下文，比如你必须用哪种验证协议与服务会话。例如，我可能需要发送一个Kerberos Ticket，或者一个SAML标记，或者使用Cardspace验证。换句话说，我需要能够给你URI，再加入一些策略信息，告诉你那些额外的信息。

现在，人们当然可以用URI给任何信息进行编码。理论上来说，编码会带来一条无限长的Turing带。然而，URI对于客户端是不透明的——因此你无法把客户端需要知道的任何东西放在那里。这意味着策略信息不能放进那里。

引用属性当然可以直接用URI进行编码。我们对此争论过很多，但还是决定不这么做，因为在业务上下文中，引用属性（基本上为cookie）可能很大，并且有结构。虽然理论上仍然可能把任何东西编码到URI中，但是又大、又长且又难看的URI并不是人们喜欢的东西，也不是特别有REST风格甚至有用的东西。

甚至对于Web而言，URI是否就足够了呢？不，当然不够——cookie又如何？如今，我可以用URI把我正在与我的银行帐户交互的状态转发给其他人吗？不行，因为有些交互状态保存在cookie中，它们不是URI的一部分。是的，人们真的可以利用URI重写那些不允许客户端记住任何状态的信息，而不是重写cookie。

因此，如果我需要发送给你关于端点的信息，它由一些你需要理解的数据组成，并且有些你需要发送回给我，以便我知道你在说什么，那么，就没有办法避免创建一些超出URI的东西。

但是，只要有可能，我都尽量只用URI。也就是说，如果没有需要发送的元数据，并且如果任何状态都可以保存为URI本身的一部分，为什么不呢？然后就只是一个简单的端点引用了，它有一个很适合Web的好属性。

回来说说合并的可能性：但有一个共同点，那也是人们已经在Web中进行了多年的事情：利用HTTP到处移动XML。这根本不是REST风格，但是它恰当地使用了Web的功能。这必定是件好事，并且如果有人不需要所有额外的安全性和可靠性等等的话。那么WS-*提供的这种简单的POX（plain-old-xml）交互就足够了！因此应用程序开发人员应该在软件中寻找的东西就是对这两种架构风格又好又简洁的支持。

InfoQ：我知道一套软件如何能够同时支持WSDL/SOAP/WS-*和POX/HTTP，因为它们两个都是类似的非REST风格。但是不会真的是两种架构风格吧？

SW：第一问题是：需要什么样的中间件来实现REST风格的系统？都不用？我指的是servlets/php scripts/asp等等。全部需要吗？还是REST需要发展为REST-*，来做一个更加完整的平台，给像消息级安全性这样的东西定义一些常用的约定/标准/协议？

我不知道这些问题的答案。我所能告诉你的是我们也正在努力寻找答案。我认同说，马上去完成WS-*和POX很容易，了解是否有些中间件适合SOA和ROA风格可就难多了。这才使得研究这些东西变得很有趣！

InfoQ：非常感谢！

查看原文链接: Interview with Sanjiva Weerawarana: Debunking REST/WS-* Myths 译者简介：俞黎敏（网名：阿敏总司令），技术顾问，自由撰稿人，开源爱好者，曾经参与Spring中文论坛组织Spring 2.0 Reference中文版的技术审校和满江红开源组织Seam 1.2.1 Reference的中文翻译工作；另外他还翻译了《CSS: The Missing Manual》、《Java Persistence with Hibernate》等书籍，并担任 CSDN、CJSDN、Dev2Dev、Matrix、JavaWorldTW等技术网站Java论坛版主。他的博客是： http://YuLimin.JavaEye.com。