Dan Diephouse谈Atom、AtomPub、REST和Web服务

个人简介 Dan Diephouse是一名企业架构师和开源开发者。他是XFire，即现在的Apache孵化项目CXF(又称作：XFire 2.0)的创始人。同时，也是其它一些开源项目的提交者，包括Apache Abdera、XmlSchema和Jettison。现任职于MuleSource，专注于构建并帮助他人构建开源Web服务/SOA解决方案。

   

1. 我是Stefan Tilkov。我在旧金山参加Qcon,现在我要采访的是Dan Diephouse。Dan，很高兴请到您，您能给我们简单介绍一下您自己和您的工作吗？

我现在为MuleSource工作，某种意义上讲它是开源ESB Mule总部，我的工作包括各个方面。其中一个主要领域是专注于Web服务以及我们对它的支持。WS-*是我们支持的一个方面，你们中有些人正是通过它开始了解我的。最初我发起了XFire SOAP Web服务项目（现在被称为Apache CXF），因而我正致力于将它们与Mule进行集成，并使之简化与SOAP、WSDL、WS-*之间的整合。同时我也非常关心让Mule支持 Restful，并使它对REST的支持尽可能简单。实际上，Mule的支持POJO的独特架构使它很容易将各种类似这样的协议映射到资源。因此我对此非常热衷，比如加入对Atom发布协议的支持。我为之工作的Mule Abdera连接器就是这样一个项目，它能帮助你实现各种整合场景。我工作的另一方面就是参加像Qcon这样的各种优秀的会议，就像现在一样让我激动不已，还有就是和开发者交流以及开发新项目，这些项目将来会对外宣布。

   

2. 从CXF开始，您现在在Web服务领域有什么进展呢，来自WS-*世界的一些有趣刺激的新东西会不会对您有所帮助呢？

是的，CXF。再补充一点，它开始于Codehaus的XFire项目，现在已经逐渐发展壮大。围绕这个项目有了一个很大的开发者社区。我们属于 Apache，现在已发布了多个2.x版本了，2.x版本的工作重点是支持SOAP 1.1，1.2，WSDL，WS-Addressing，WS Policy，WS Security和WS Reliable Messaging。目前一些手头的工作重点是支持某些对集成来说非常重要的新标准，比如WS Security Policy，WS Trust和WS Security Conversation。另一些则集中在对JAX-WS 2.1的支持，它给JAX-WS API添加了诸如WS-Addressing等额外特性，该API简化了开发者的工作。总的来说，JAX-WS无疑是Java开发者的福音，因为它真正做到了标准化、为每个人简化了所有的事情。所以我非常期待看到这个标准的进展，以便在以后能为人们进一步简化工作。

   

3. 您提到您现在从事Atom开发并且是Abdera项目的提交者。您能跟大家简单介绍一下背景吗？给那些不知道AtomPub的观众说明下Abdera是什么，有什么更多消息分享给大家？

Atom开始是仅用于博客领域的联合格式。它源于对RSS feed以及各规范间不一致的失望，于是一群聪明人联合起来制定了Atom协议。Atom格式基本上是一个叫作“feed”的东西，它包含一个条目集合。举个具体例子，每个条目代表了一个博客条目，但广义上一个条目可以代表任意资源或者任意一块信息。最重要的是，每个Atom feed或Atom条目都包含一个ID、一个时间、一个摘要或某种格式的内容，这样做的目的是为了让所有人都能理解它。这样，如果我有一个feed，那么每个人就能都知道其中的公共元素，解释方式并从中提取某些信息。如何把这些东西应用到博客非常明显，但实际上这对于领域或者商业应用也十分有用。如此我就能把任意类型的微内容都放到一个Atom feed里。比如，我能用Atom feed描述一个雇员信息；也可以有一个雇员集合的feed，每个条目代表一个雇员。它们都包含一个雇员元数据XML片断，最酷的是所有程序都能理解这个 feed，你只需订阅它就行了。这样，当有新雇员时，你就能得到通知。你还可以在此基础上应用各种搜索协议（如查询字符串），来搜索员工数据库，而这一切仅仅只用到HTTP。

   

4. Atom发布协议又如何跟这些结合起来呢？

Atom发布协议的重点在于简化创建资源，编辑资源，删除资源，聚合资源等一系列过程。这样我个人就能通过发布协议抓取单个条目，用HTTP PUT方法来编辑它，并将它PUT到一个URL，用这个新条目来代替旧条目。我能将一个条目POST到一个集合，这将为我创建一个新条目并将其加入 feed中。我也能DELETE单个条目，因为每个条目都是由URL所引用的，只需简单的一个HTTP DELETE操作即可。

   

5. Atom发布协议给普通REST带来了哪些附加价值？因为这听起来好像是一个Restful标准协议的完美描述。

是的，这正是Atom的一个优点：它是一个标准的Restful协议，因此一定程度上使你避免了再去构建你自己的协议，同时也使你免于把事情搞砸，其中原由在于它设计得非常漂亮。它真正突出之处在于通用的Atom格式，这是一种思想：我能通过内容小节或摘要小节向任何人提供有用的信息而不用让他们知道我的微格式以及藏在背后的数据。

   

6. 那么它是对WS-*的增强吗？您对设计应用有什么建议呢？您是用Atom、Web服务，还是两者都用呢？

你肯定可以两者都用，对于你的应用场景来说它们可能是正好互补的。其中一方并不排斥另一方的使用。有时候你可能只需要Atom而不需要WS-*。Atom 为你提供了操作模型的所有必要条件。回到雇员的这个例子，你可以向集合添加雇员、删除雇员、更新雇员信息和联系方式。但是其他情况下，Atom由于某些限制可能会显得能力不济，这时你可以考虑使用自己的Restful协议或甚至采用WS-*。

   

7. 哪些东西是Atom联合、Atom发布协议或restful HTTP普遍缺失而WS-*规范独有的呢？

在使用Atom发布协议时我遇到了一系列的限制，这当然不是说Atom发布协议不好；只是在某些场合下现在还不宜使用。其中一个就是对层级建模，在 AtomPub里给各种层级建模显得有点高深隐讳。如，我有一个条目可能对顾客进行了建模，但是顾客又跟定单有关系。我怎么在一个条目里对定单建模以达到独立编辑定单或创建新定单的目的呢？有的人建议继续在这个条目里使用Atom集合元素，这虽然也能把事情搞定，但不是一种很自然的表达方式。

另一个限制是没有用于批量更新的方法，这一点普遍达成了共识。GData尝试制定一个标准化的方案，但是关于这种模型的适用性引来了激烈的争论。某些高性能应用就不适合使用AtomPub模型，因为你总是得有一个关联的Atom条目，而且可能会延迟，只能发送极为简单的消息。

   

8. 您还能想到其它的限制吗？

当然的确还有一些：对于那些高唱“只用HTTP（just use HTTP）”的信徒来说，安全问题显然是他们还做得不够彻底的地方，我感觉这一方面WS-*的支持者们走在了他们前面。我们有WS Trust这样的协议来保证令牌的互换，在Restful方面还没有出现对应的机制，所以会出现像CardSpace这样实际上是依赖于WS Trust的产品，宣扬REST的人们最终依赖了WS-*的方案，这实在有一点讽刺的意味。还有一个问题是如果你的应用不具有时序模型，或者你的应用并不能通过Atom标准模型里的摘要、更新时间等元素而获得好处的话，Atom发布或Atom feed模型可能并不会给你的应用带来收益。这种情况下我认为Atom并不能给你带来什么好处，你可以用自己的Restful协议，如果WS-*适合也可以用它。另外，基于HTTP的事务也是限制之一：有好几种方法来处理，但它们都没有被包含进Atom Pub模型，所以这也是值得你去考虑的问题。

   

9. 那么，哪些例子适合用AtomPub呢，有什么好的用例跟大家分享呢？

AtomPub在很多业务应用中都能派上用场。最简单的例子就是目录信息，不管它是顾客信息，还是雇员信息、联系人数据库或者日历事件。你基本能用它对各种信息进行操纵，只要这些信息适合用某种集合形式表达，不论是java集合，还是.NET集合或者对应的Ruby形式，像这一类型的东西都可以很方便地抽象成Atom集合。我想到的一个用例就是用来它存储事件，无论是业务级事件还是应用级事件。比如你可能需要监听来自应用的错误，你也可能想订阅关于它们的 feed，或者你想监听特定的业务事件比如“因为某某原因，所以拒绝贷款”，并且只是想查看或者得到某种异步消息以知道发生了什么事情。围绕于此已有一些进展，我知道James Strachan在用Atom Pub来对队列进行建模方面做了一些工作，这十分有意思并且应用到了一些消息系统上。我认为这一成果在为某些系统建构Restful桥或队列上能发挥一定的作用。这是我能想到的一些很有意思的主要应用领域，肯定还会有更多例子，我十分确信。

   

10. 您提到了GData，能给我们简单介绍一下它的背景吗？

GData是Google一直在开发的“协议”，“GData”即“Google data”，它试图成为一个简单的应用标准协议，在一定程度上涉及了几个不同的领域。其中一个就是它试图在Atom和RSS之上将Atom进行抽象化，并支持使用这两种协议描述模型。对外部用户来说，一个重要的用途是它的查询语法。这样他们可以真正地按他们自己的方式查询他们想要规范化的那些feeds和页面信息。我所说的规范化实际上是规范到这个标准上以供所有服务使用。你可以和google日历，google表格进行交互，我猜测还有 GoogleBase（他们的搜索引擎），以及各种使用Gdata的googel应用，这初步展现了Atom Pub模型的威力。让我们回到Gdata关注的重点这个话题上，它对Atom Pub做得不够好的地方进行了语义补充，例如如何处理版本及两个人同时写入一个资源时的策略，它给出了一个优化的并发模型，还定义了一些有关会话的机制。他们还定义了一些共同的feed元素，比如数据点或地理点，以及如何在feed里对此进行表达。还有一些零碎的方面。在AtomPub之上，它还定义了一系列Atom Pub缺少的东西，能帮助你构建应用或是提供一些你可能会想用到的额外结构。

   

11. 有什么开源形式的Atom软件吗？它的意义何在？

我从事的Abdera项目就是一个Apache孵化项目。另一个java实现叫做Propono， rollerweblogger使用的就是它，在python领域有Amplee，还有一个相应的Ruby版本我一时想不起名字了。虽然一直有人在提.NET的实现但我还并没有看到一个好的例子。不过Atom最棒的是，或者说Atom Pub最棒的是，它只使用HTTP。因此你可以用你最喜欢的HTTP库进行POST、PUT、DELETE和GET。这是一个好的开始。

   

12. 我们已经谈到很多关于Atom的话题了。总的来讲您对REST vs WS-*的争论是怎么看的？您知道我不得不见人就问这个问题。

这是一个有趣的问题。我很喜欢REST模型，我认为它是一个很好的构建服务的模型，我所认识的人真的非常喜欢它的简单性，尽管现在我们已经开始看到更多REST相关的标准和额外的东西，比如以它为基础的Open Search，但是相对而言现在要学的东西比以前更多了。但是我喜欢它的简单性，喜欢这种统一接口，以及我能用同一个客户端来操纵资源的事实，还有能够跨所有东西的普遍性，我想当你构架大规模应用的时候它会帮你把事情变得更简单。当然还有一些需要改进的地方，其中一个就是描述语言。WADL已经有了一些基础，但对于如何跟资源进行交互还没有找到一个能被统一接受的方式。

实际上我并没有很多的要求，我不是要把Atom变成另一个SOAP，但当我开始使用资源的时候，我至少要知道都有哪些媒体类型，对吧？比如我能理解 image/png媒体类型，我也能理解text/plain媒体类型，但还有一些媒体类型是我不能理解的，因此我需要一种方式来找出服务是用的什么媒体类型，并且在我需要时能将这些媒体类型映射到各种描述语言上。这样我能使用我自己定制的XML媒体类型以及相关的模式。Atom Pub离这个目标已经很近了。它描述了你在服务中能够使用的媒体类型，但它没有提供任何发现媒体类型的功能，所以如果我们能缝合这个缺陷，我相信我们能够实现更多有趣的机器对机器的交互。

我之前提到安全问题，我觉得这里还大有文章可做。有一些关于如何对GET请求和响应签名，以及怎样在REST中使用WS Security的争论，到底会怎么发展目前还是比较有看头的。但是大体上，你只需看看现在的互联网，我们已经（用REST）实现了很多的应用。肯定也有很多应用不适合Restful模型，这时你不必使用它，不适合的就不使用。除此以外，我认为REST应该是你默认的选择和出发点。

   

13. 您认为现在对REST的工具支持达到了怎样一个水平，足够了吗，您现在还需要更多吗？

我不认为足够了。我们已经有了一些工具。我拥有WS-*背景，所以我能以很短的时间做一些.NET和java的整合，但用java构建一个Restful 服务，就需要更多的时间了。有很多的方法可以来实现这个目的，但所有这些方法目前都还不够简单。我一直关注JSR 311规范，到现在为止我对它非常满意，它已经进行了一些这方面的工作。你可以很容易地编写一个restful服务。但是我想可能在客户端我们还需要更多的工作。我的意思是，看看咱们的java库，甚至没有一个像样点的的HTTP客户端。幸好我们还有Apache的工具可用，但这些工具也还是不够清晰。我也在关注Restlet的发展；他们在客户端做出了一些很好的东西，当然Atom Pub同样会很好地帮助你构建Restful服务。