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 。