级别： 初级 Robert McMillan (bob@filbert.net), 自由作家
2003 年 7 月 01 日 Sam Ruby 是 IBM Emerging Technologies Group 的成员，在过去三年里，他已经成为与 Web 服务有关的几个开放源码项目的关键人物，其中包括 Tomcat 和 IBM SOAP 堆栈。他还编写一些代码，提出自己的见解，从而为这个社团贡献自己的一份力量。他与 Bob McMillan 就一些主题进行过交流，涉及对开放源码的要求，Web 服务的未来以及 Web 日志的能力。
Sam Ruby 一直沉迷于开放源码。他是一位在 IBM 有 21 年工作经验的老员工，三年前，他所从事日常工作是将 PHP 与 Java 平台集成在一起，从那时起他开始对开放源码着迷。Ruby 以前并没有真正参与过开放源码的开发工作，但他一下就迷上了它，他在从事 Java-PHP 集成工作的同时提交一些修订程序。PHP 团队给予他对本团队源代码树的提交访问权时，他还毫不知情。他有些
受宠若惊了。很快，他的工作使他能够向 Apache 的 Tomcat 项目提交补丁，同样，Ruby 获得的认可再一次鼓舞了他。他很容易访问源代码和其他开发人员的修订程序，并且不久就得到了 Tomcat 提交访问权。“这与 IBM 内部竞争项目之间的那种协作不太一样，”他说，“这很快就让我上瘾了。”
Ruby 已经是 IBM SOAP 堆栈的中坚力量，从 Web 服务、开放源码到博客现象，他对这一切所具有的深刻而精辟的思想使他广为人知。developerWorks 的撰稿人 Robert McMillan 最近通过电话采访了 Sam，询问了他近期在 IBM Emerging Technology Group 的工作，并了解他对 Web 服务的想法。
developerWorks：您最终怎么会从事 Web 服务方面的工作？
Sam Ruby：我的职业主要是作为开发人员。我编写代码。我喜欢写代码。当我在 IBM 取得进步时，人们往往会在您获得提升时说，“你再也不用写代码了。”我不想那么做。我试着在体系结构方面做过一段时间。这是获得提升后理所当然的位置，但如果职位的变动让我不能再进行实际的编码工作，那么我会拒绝这种变动。
之后，我调到了 Emerging Technology 部门。当时的新兴技术是 Web 服务。因此我就潜心研究它。我为最初的 IBM SOAP 堆栈做了大量工作，IBM 后来把它捐赠给了 Apache。IBM 的 Soap4J 成了 Apache SOAP。此后它被改写成了 Apache Axis。[请参阅
参考资料以获得关于此事以及文中提到的其它项目和主题的链接。]
developerWorks：您是怎么说服 IBM 将这个代码捐赠给 Apache 的？
Ruby：这要从 SOAP 的初期说起。我们非常担心 Microsoft 会抢占这个标准 — 拿来然后对其进行扩展，接下来做些顺理成章的事。在 IBM 和 Microsoft 的竞争中我们吃过大亏，比如类似 OS/2 的事情。所以如果我们直接说：“好吧，有一个名叫 SOAP 的标准 — Microsoft 有他们的实现；我们有我们的实现”，猜猜人们会用谁的实现来测试互操作性？然后他们会说：“嗯，如果我们的不行，也许应该把它弄得和 Microsoft 的稍稍类似，这样大家的日子都会好过些。” 我们不希望处于这样的地位。
因此我们做了相反的决定：把它变成开放源码，可以这么说，“这是大家普遍使用的，并且就其本质而言它事实上是参考实现。”虽然它没有被冠以参考实现，但实际上确是如此。这是我们为使这一标准的实现被采用的可能性增加而运用的方法。我们的版本在当时绝对最符合 SOAP 规范，并且赢得了许多人的关注。
developerWorks：有许多新兴的 Web 服务标准和通过这些标准的组织，然后有这样一种实际的开发标准的开放源码方法。哪些标准出自哪里，哪些关于标准方面的工作值得关注，这似乎很容易使人困惑。对此，您怎么看？
Ruby：我想，对这个问题的简单回答是，我认为没有人知道它的未来方向。我们现在面临的是许多人存在竞争性的利益。没有人确切地知道关于未来的正确答案。但是，我们不象过去那样行事，并且说“让我们把它做成象 CORBA 那样的庞大标准吧”，为了获得实现，你必须同意它的各方面……我们正共同做的事情 — 不是 IBM 正在做的或 Microsoft 正在做的，而是整个业界正在做的 — 是有步骤地定义这个标准。所以您感到困惑。许多人支持相互对立的标准 — 其中一些标准有生命力，而有一些已经衰落。
在此过程中，业界 — 我不是专指 IBM 或任何别的组织 — 正在尝试在众多权威机构中获得承认，无论是 W3C 还是 OASIS，或是不经过任何标准机构仅仅在 Web 中发布一个 URL。
有些失败值得关注。Microsoft 最初提出 SOAP With Attachments，后来说那是一个失败，随后他们推出另一个名为 DIME 的东西，现在他们又说
那是一个失败，而最好的办法是在必要时返回到 SOAP With Attachments，但实际上要尽可能将数据放在 XML 信息集中。
由此，你所看到的是人们如何尝试某种标准，了解它是否有效，了解其他人是否热衷于该标准。我们还不知道在这些标准中，哪些能够在今后的五年里被使用。但是，一些基本的标准（象 SOAP 和 WSDL）似乎已获得众多追捧，看样子不会消失。
developerWorks：在开放源码领域 — 与企业联盟相反 — 标准的作用相对于有用的实现来说似乎往往屈居第二。
Ruby：我喜欢标准，但实际上我个人对
标准这个字眼的理解稍有不同。我把字典中的定义同你在各企业联盟中看到的定义加以比较。如果你查看字典的定义，它的基本意思是，“所有人都认同的东西。”当我谈到长度单位米，这是人们都认同的一个术语。这我不用多说什么。它实际上是一种国际标准，那有些酷。事实是我们都认同这是一米，或这是一码，或任何你想到的长度单位：那就是标准。由这种定义看来，PowerPoint 是一个标准。和人们谈论标准机构及类似东西不是一回事，但是，一般说来，如果你要表达某个东西，那么 PowerPoint 就是您表达这东西的一种方法。它是我喜欢的标准吗？不完全是。但是，它是人们知道的东西。当我说“PowerPoint”时，在你的脑海中会浮现出一个图像，这个图像正是我试图表达的。
developerWorks：如果回过头看 SOAP 的发展，它有没有什么事情曾让您惊讶？
Ruby：总体说来，SOAP 本身没有发展。当我参与进来时，SOAP 1.1 才刚刚提出。SOAP 1.2 实际上现在还没有提出。标准组织仍在研究和制定 SOAP 1.2。实质上，真正发展的是与 SOAP 相关的整个堆栈。最初，我对许多较高层的内容都心存疑虑。特别是，我原先认为 WSDL 过于强大。
developerWorks：什么改变了您对它的看法？
Ruby：为了帮助使这些成为标准，我所做的事情实际上是我主持了第一届 SOAP 构建器互操作会议，并从那以后参加了几乎所有的会议。在会议上，我们向其他人发送消息。其他人是否收到消息，如果收到，在他们作出应答后，我们是否真正理解返回的这一应答？
大多数问题都出乎我的预料；问题出在对参数的命名上。实际上，对于实现而言，采用定义要简单得多，定义说明，“正确形成的定义就应该是这个样子”，然后从这个定义生成正确的代码。如果您不尝试在定义上更正式些的话，那么就会首先看到这类参数命名的问题。
developerWorks：在对待 REST 方面，您似乎站在一个有趣的立场上。您在过去谈论它时说过，您个人提倡给 Web 服务增加一些约束。您当时说这话要表达什么意思？
Ruby：我这话是针对一个长期批评 Web 服务的具体某个人说的，他强烈表明我们所需要的是由 REST 提供的约束。这个人是 Mark Baker。他强烈主张采用 HTTP 时遇到的那种体系结构约束 — 也就是 GET 和 POST 及最少数量的动词。有些论据
说明这样做有一定的正确性。
我认为它们 [REST 和 Web 服务] 实际上可以很好地结合起来。你实际上可以说，“我希望使用 REST 描述如何访问对象”，然后用 SOAP 描述如何表示这些对象。
有趣的是，REST 是
Representational State Transfer（可表示状态传送）的缩写，而 REST 根本没有说明的一点是如何实际表示状态，尽管事实上其名称如此。相反，简单对象访问协议（Simple Object Access Protocol，SOAP）并不描述访问对象所用的任何方法；它只描述如何表示状态以及如何进行传送。
这样，这两组人并不相互交流，而是只谈对方的过去。如果你真的结合二者的最佳思想，就可以得到一个可扩展的、模块化的、松散耦合的系统。
developerWorks：在这场争论中，您似乎处于中间立场。您有没有觉得没有人赞成您这种观点？
Ruby：很遗憾，赞同的人比我所希望的还要少。我希望有更多的人支持我这种观点。大多数人采取了漠不关心，或者直接走向了这两个极端的一端。他们完全不听任何解释。
developerWorks：您认为为什么会这样？将一样东西放在一个范例中是不是更简单些？
Ruby：我不确定是否应对此加以推测。我认为主要原因是人们没有花时间真正研究其中的一些问题。每个人只有数量有限的时间用来学习，且他们也许对这一领域不太感兴趣。因此，他们看别人使用哪种方法，便简单地假定其他人都是怪异的。在某种程度上，我们都是这么做的。这恰好是我研究的领域，不过我肯定有其它领域是我没有进行正确研究的。
developerWorks：随着人们开始更认真地对待 Web 服务的使用，并开始将这些技术用于实践，您认为这种情况会改变吗？
Ruby：我认为，抛开我们所看到的核心之争不谈，XML 作为一种表示要来回发送的数据的方法，其价值越来越受到人们的重视。XML 是人们多年来一直在使用的专门术语和技术 — 甚至比 Web 服务出现得还要早。事实上这是第一步。
developerWorks：您认为对 Web 服务的发展最重要的是什么？是那些必需的特定标准吗？
Ruby：唔，标准发展的速度超过实现并不会产生问题。我们有太多的标准。而且还将创建更多的标准。但我不认为问题的解决办法是要有更多的标准。
就工具而言，我认为，我们要努力的方向是提供更多能够更方便、更好地处理 XML 的工具：使 XML 直观且一目了然的工具，也许就是指 XML 是透明的。
developerWorks：您说更多的标准不是必要的。您认为标准的增长会使人们对何去何从感到困惑吗？
Ruby：标准的增长可能是有些令人困惑。但是，我们发现许多较高层的标准针对的是较小的市场，在那里确实需要一种协议，并且它需要成为一种公共协议，但这不是将普遍被采用的标准。我们希望 SOAP 将被普遍采用，当你从堆栈的 UDDI 和 BPEL（业务流程之类的东西）向上移动时，你将发现这在许多特定的小环境中很有意义，在那些小环境中，这恰恰就是正确答案。也许在有些地方人们会说，“我不需要它”。这也没有问题。
developerWorks：我想问您，您现在正在开发什么软件？
Ruby：我现在没有从事太多 Web 服务方面的工作。我现在研究最多的是 Web 日志。我在研究它的同时正试图弄清如何添加其它一些功能。大约一、两个月前，我用 Python 将代码重写了一遍。
developerWorks：刈⒌氖?Web 日志的哪些应用？
Ruby：Web 日志让我非常感兴趣。当我说我沉迷于开放源码时，我指的是我所发现的那种协作，我公布一个问题，几分钟内就有答案，而这不需要我和某个人事先达成某种约定。这只是某人和我对同样的事情感兴趣，而我们只不过试着互相帮助罢了。
我在 Web 日志这一领域发现了同样令我沉迷的这一性质。我只需把某个问题公布出去，说，“我对这有兴趣，”就会有人说，“喔，我对它也很感兴趣，”然后他们就会评论我的 Web 日志，或评论他们的 Web 日志。人们接受这种方式的联系。
在开放源码领域，许多协作都是围绕非常具体的东西建立起来的，譬如一段代码。成员之间的结合并不是那么紧密。我想过很多原因，但还是不清楚是什么魔力让这种方法能够奏效。理论上，在 Web 日志中做的事情，在新闻组中也可以做。
developerWorks：但在 Web 日志中，主题都与您有关，而不是别的什么东西。
Ruby：但是，在 Web 日志上，我不必担心范围。它只是我感兴趣的东西。在我 Web 日志的左边有一篇文章，题目是“Manufacturing Serendipity”。它讨论这一现象。例如，有一次我刚好在波士顿，我注意到外面下雪了。由于这已是年终，所以我写到这件事情，而这被 Miguel de Icaza 看到了，我当时还不是非常了解他。根据这件事，他在我开会时给我发封电子邮件，说，“哦，你在波士顿呀。也许我们可以一起吃顿饭。”
自从我创建了 Web 日志，发生的这类趣事都快让我应接不暇了。你在给我打电话之前就知道了关于我的很多事情，因为你能在 Web 日志读到一些内容。现在我在接受您的采访，但正是由于我利用 Web 日志做了些额外事情，才使这次采访更为容易了。我不清楚这有什么切实的好处，但我相信我们有办法可以把它集成到业务过程中，或集成到对客户真正有价值的事情中。
我的意思是，传真改变了企业运营的方式。电话改变了企业运营的方式。在过去几年里，我目睹了即时消息改变了人们做事的方式。看一下会议吧，人们在会议上面对面地聚在一起。他们在开会的同时，可能给会议之外的人发送即时消息；与会者之间也可能相互传递即时消息。你会发现，当一个人谈话时，其他人不会打搅他，或者他们可能听到某些内容而有所感触，而他们确实需要认真对待这些念头。
developerWorks：那么您认为 IBM 的产品有怎样的应用前景呢？
Ruby：在我所在的 Emerging Technology 部门，我们的工作是找出您所提出的这个问题的答案，而我可以回答您的最诚实的答案只能是：我目前还不知道。我确信有很多 IBM 产品需要改变。我的确相信会出现基于这一技术的产品。
参考资料
关于作者  | 
| | Robert McMillan 是居住在旧金山的自由作家。他为
Wired News、New Scientist、Linux Magazine和
Network World撰稿，并曾担任
LinuxWorld.com的首任主编。可以通过
bob@filbert.net与 Robert 联系。
|
对本文的评价
| 
