Web 服务内幕,第 2 部分: W3C Web 服务专题研讨会的概述 | ||||
James Snell (jasnell@us.ibm.com) 上周,Web 服务权威人士参加了 W3C 的第一次 Web 服务专题研讨会,目的为探索 W3C 应向哪个方向发展才能实现新兴的 Web 服务架构的标准化。在这部分中,他对于讨论内容进行了一个简要的概述。 (请点击文章顶部或底部的讨论,参与有关这篇文章的讨论论坛。) 正如标题所示,上周(4 月 11 日、12 日)在加利福尼亚的圣何塞举行的 Web 服务专题研讨会吸引了众多有识之士共同关注这一我们称为“Web 服务”的新兴模式。巧的是我不仅有幸在研讨会计划委员会里任职,还主持了其中的一次会议(计划委员会是审查所递交的意见书并挑选由谁出席专题研讨会的一个小组。)还由于这是我第一次以正式身份参加 W3C 活动,因此这的确是一次让我大开眼界的经历,让我清楚地认识了 W3C 是如何完成其目标的。在“Web 服务内幕”的这部分中,我想与您分享一下以下报告及讨论中的精彩片断。 了解 W3C 的运作过程
W3C 专题研讨会的目的无外乎是集体讨论那些可能最终发展成具有充分资格的 W3C 工作组或兴趣组的主题。是工作组制定了那些我们喜欢称作 W3C 推荐规则的实际规范。所以,要回答这样一个简单的问题:研讨会期间是否会作出实质性的决定以推动 WSDL 或 UDDI 等的标准化,答案是否定的,尽管我们仔细深入地讨论了如何、何时以及为何我们要去做那些事。 如何度过这两天
我们讨论了些什么
我们讨论并确立了 Web 服务体系结构的三个不同的概念组件,且开始定义适合那些组件的要求与技术的堆栈。根据 IBM Emerging Technologies 的 VP -- Rod Smith 以及微软的 XML 权威 Andrew Layman 的介绍,一个“Web 服务堆栈”的构想开始形成。(请参阅图 1)。 我们讨论了“描述”一种 Web 服务究竟意味着什么,并详细地谈到了 Web 服务描述语言 (WSDL),关于 W3C 是否应该开始着手将 WSDL 标准化,或更通俗地说,W3C 是否应该开始将 Web 服务描述作为整体来进行标准化。组内多数人的意见是标准化 Web 服务描述的 W3C 工作组应该在短期内开始。工作组章程的确切细节仍有待决定。然而正如 SOAP 成为了 W3C XML 协议制定过程的核心部分一样, WSDL 也理应成为那个过程中的核心部分。 正如您能从图 2 中看到的那样, WSDL 致力于 IBM 定为 Web 服务描述堆栈的底下两层。对于该堆栈的更高层的关注与注意也颇多。也就是能够从所有被认为“可描述”的 Web 服务组件的方面来描述 Web 服务的特性,包括可靠性、能力、消息的先后顺序以及对谁发了哪个消息及消息发送时间的编排等。达成的共识是我们需要一个单独的、已定义的、可扩展的框架,在此基础上能将所有这些分层堆积到服务描述堆栈中。尽管对于它最终将如何成形仍有些争论,但 WSDL 始终是讨论的中心,并且对于 WSDL 为何能够成为并应该成为那项工作的基础展开了一场非常好的辩论。 Tim Berbers Lee 以他对 Web 服务的前景的详细描述,实际上是对“语义上的网络”的现实化开始了此次研讨会。讨论的主题从有能力归类、定性、并发掘不同实体论基础上的 Web 服务,到演示如何将 WSDL 和 RDF 结合起来补充支持现有的基于 RDF 的基础设备。 当两方面产生冲突时
在许多方面, 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 服务注册表共存、甚至集成。 总结
就 W3C 专题研讨会对开发人员意味着什么来说,对于在此领域中试图使用该技术在短期内实现实际应用的开发人员,我的建议是,开始熟悉 Web 服务体系结构的核心组件。如果您还没有熟悉,那么就开始学习 SOAP, WSDL 和 UDDI。如果您是个 Java 开发人员,我建议您下载 IBM Web 服务工具包,开始试验 Web 服务体系结构。 参考资料
关于作者
|
(c) Copyright IBM Corp. 2001, (c) Copyright IBM China 2001, All Right Reserved |
关于 IBM | 隐私条约 | 法律条款 | 联系 IBM |