Web服务内幕，第2部分: W3C Web服务专题研讨会的概述

申请免费试用、咨询电话：400-8352-114

Web服务内幕，第2部分: W3C Web服务专题研讨会的概述

James Snell (jasnell@us.ibm.com)

软件工程师，Emerging Technologies，IBM

2001 年 4 月

上周，Web 服务权威人士参加了 W3C 的第一次 Web 服务专题研讨会，目的为探索 W3C 应向哪个方向发展才能实现新兴的 Web 服务架构的标准化。在这部分中，他对于讨论内容进行了一个简要的概述。

正如标题所示，上周（4 月 11 日、12 日）在加利福尼亚的圣何塞举行的 Web 服务专题研讨会吸引了众多有识之士共同关注这一我们称为“Web 服务”的新兴模式。巧的是我不仅有幸在研讨会计划委员会里任职，还主持了其中的一次会议（计划委员会是审查所递交的意见书并挑选由谁出席专题研讨会的一个小组。）还由于这是我第一次以正式身份参加 W3C 活动，因此这的确是一次让我大开眼界的经历，让我清楚地认识了 W3C 是如何完成其目标的。在“Web 服务内幕”的这部分中，我想与您分享一下以下报告及讨论中的精彩片断。

了解 W3C 的运作过程

首先，正像我在此以前没有参加过这个专题研讨会一样，对于你们中那些尚不熟悉 W3C 运作过程的人来说，有必要作一个简单的概述。在 W3C 开始标准化过程之前，他们先花一部分时间征求来自 W3C 成员公司的反馈意见和信息，主要是有关 W3C 该做什么及如何做的。这些研讨会是这一过程中的一部分。

W3C 专题研讨会的目的无外乎是集体讨论那些可能最终发展成具有充分资格的 W3C 工作组或兴趣组的主题。是工作组制定了那些我们喜欢称作 W3C 推荐规则的实际规范。所以，要回答这样一个简单的问题：研讨会期间是否会作出实质性的决定以推动 WSDL 或 UDDI 等的标准化，答案是否定的，尽管我们仔细深入地讨论了如何、何时以及为何我们要去做那些事。

如何度过这两天

首先，当然是这种场合不可或缺的闲谈，然后就是参加主办饭店为我们准备的精美午餐 -- 在这儿也要感谢 IBM 发起组织了整个活动。两天中含括了许多聆听及讨论由对 Web 服务兴趣浓厚的各个 W3C 成员公司递交的报告书。然后就是辩论…… 我是指集体讨论我们最先都想做些什么、谁应该做些什么事以及在发展的同时能对其他组织（如 OASIS）的哪些工作进行补充支持。为了能对事情的进行有个清楚的了解（也为了能读一读递交上来的出色的意见书），您应查看一下研讨会的官方网站（请参阅参考资料）并顺着链接打开研讨会项目。

我们讨论了些什么

整个研讨会围绕着几个不同的主题展开，迄今为止，这些主题已为我们中紧跟新兴的 Web 服务体系结构发展的那些人所熟悉。

我们讨论并确立了 Web 服务体系结构的三个不同的概念组件，且开始定义适合那些组件的要求与技术的堆栈。根据 IBM Emerging Technologies 的 VP -- Rod Smith 以及微软的 XML 权威 Andrew Layman 的介绍，一个“Web 服务堆栈”的构想开始形成。（请参阅图 1）。

图 1：Web 服务体系结构堆栈的概览

我们讨论了“描述”一种 Web 服务究竟意味着什么，并详细地谈到了 Web 服务描述语言 (WSDL)，关于 W3C 是否应该开始着手将 WSDL 标准化，或更通俗地说，W3C 是否应该开始将 Web 服务描述作为整体来进行标准化。组内多数人的意见是标准化 Web 服务描述的 W3C 工作组应该在短期内开始。工作组章程的确切细节仍有待决定。然而正如 SOAP 成为了 W3C XML 协议制定过程的核心部分一样， WSDL 也理应成为那个过程中的核心部分。

图 2: 服务描述堆栈

正如您能从图 2 中看到的那样， WSDL 致力于 IBM 定为 Web 服务描述堆栈的底下两层。对于该堆栈的更高层的关注与注意也颇多。也就是能够从所有被认为“可描述”的 Web 服务组件的方面来描述 Web 服务的特性，包括可靠性、能力、消息的先后顺序以及对谁发了哪个消息及消息发送时间的编排等。达成的共识是我们需要一个单独的、已定义的、可扩展的框架，在此基础上能将所有这些分层堆积到服务描述堆栈中。尽管对于它最终将如何成形仍有些争论，但 WSDL 始终是讨论的中心，并且对于 WSDL 为何能够成为并应该成为那项工作的基础展开了一场非常好的辩论。

Tim Berbers Lee 以他对 Web 服务的前景的详细描述，实际上是对“语义上的网络”的现实化开始了此次研讨会。讨论的主题从有能力归类、定性、并发掘不同实体论基础上的 Web 服务，到演示如何将 WSDL 和 RDF 结合起来补充支持现有的基于 RDF 的基础设备。

当两方面产生冲突时

在我看来，我们讨论的最有意思的主题之一就是将新兴的 Web 服务体系结构与在 OASIS 组用 ebXML 进行的工作结合起来。我来作一个非常简短、粗略的概括： ebXML 是一个终端对终端的协议堆栈以及在互联网上用 XML 以及其它开放式标准技术开展电子商务的规范。我说的“终端对终端”是指 ebXML 本质上含有一个处理电子商务交易的各个方面的规范，从描述简单服务端点定义（使用 WSDL 或其它一些机制），到描述交易的整个商业步骤的工作流程。ebXML 规范的范围（预计于 2001 年 5 月中旬完成）覆盖了众多方面，其中有关可靠的消息传递、安全、事务处理、消息封装、服务描述、服务能力描述、消息的先后顺序、消息工作流程和编排、不同交易伙伴间的协议等，罗列不尽。

在许多方面， ebXML 就像是 Web 服务体系结构的堆积结果。这实际上是对的，这也就是为什么我们开始看到这两个体系结构在力图实现的目标以及实现的方法上产生的冲突与会合。例如， ebXML 需要一种在电线上来回传输基于 XML 的消息的方法。起先，他们想到了 SOAP （1.0 版），并决定不使用它。因此他们开发了自己的 XML 消息传递协议，它主要建立在将 XML 文档填入独立的多部件 MIME 部分的基础上。然后，出现了带附件的 SOAP 消息规范，它使用 SOAP 作为主要协议完成了完全相同的事情。 ebXML 工作组面临着一个选择 -- 或者继续使用他们自己的 XML 消息传递规范，或者转而采用带附件的 SOAP 规范。两个多月前，他们明智地决定采用带附件的 SOAP 作为消息传递标准。

由于开发人员继续沿着这条路开发 Web 服务体系结构，所以类似的冲突仍有待解决。因而有个显而易见的问题：既然 ebXML 已经做了所有这些事，为何不干脆使用 ebXML 呢？为何还要麻烦地定义另一个全新的体系结构呢？

这个问题曾多次在 Web 服务专题研讨会上被提出来，答案很简单：在那些重叠的区域，如在 XML 消息传递或服务发现区域，我们需要仔细观察 ebXML （或者是其它地方设计的规范）是否能满足我们所要作出行为的需要。如果是这样，我们又如何将那些项目最有效地补充到 Web 服务体系结构中。有一件必须记住的重要事情，这个不断发展中的体系结构尚未完成所有难点的定义。我们想要将重新构建体系结构的可能性降到最低。

另一个有关 ebXML 和 Web 服务的区别的重要事实是，它们是从两个不同的优势点着手解决一个相同的问题的。 ebXML 是自上而下地解决 -- 先确定在互联网上成功开展电子商务所必须达到的要求的全部范围，然后着手实现满足那些要求的规范。而 Web 服务架构则自下而上地解决 -- 先实现那些能满足个别核心要求的规范（如简单的 XML 消息传递和服务描述），然后在此基础上逐步上升。

ebXML 和 Web 服务之间存在相互竞争吗？从某些方面来说存在，而从另一些方面来说不存在。很多时候， ebXML 可以看作是一个 Web 服务架构的复杂实现，它使用一套特殊规范来解决一些困难的问题。如果您看出这整个的体系结构仍处于变化中，那么这些规范与通常被视为 Web 服务体系结构核心的规范（WSDL、UDDI等等）不同的这个事实也就没有意义了。重要的是，人们正在做大量的工作，来保证这两个体系结构能够共存，实际上也是为了它们能相互添加一些有价值的层。例如， ebXML 服务仓库的设计就允许它与 UDDI 服务注册表共存、甚至集成。

总结

总结这次 Web 服务专题研讨会，即 Web 服务的发展非常重要，且 W3C 应着手标准化该体系结构中的不同组件。我们都一致同意标准化服务描述应为这项工作中最重要的部分。这就意味着您应在不久的将来看到围绕 WSDL 开展的一些活动。如果您是一个使用基于 WSDL 的工具的公司，我建议您特别注意活动的进行情况。

就 W3C 专题研讨会对开发人员意味着什么来说，对于在此领域中试图使用该技术在短期内实现实际应用的开发人员，我的建议是，开始熟悉 Web 服务体系结构的核心组件。如果您还没有熟悉，那么就开始学习 SOAP, WSDL 和 UDDI。如果您是个 Java 开发人员，我建议您下载 IBM Web 服务工具包，开始试验 Web 服务体系结构。

参考资料