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 應向哪個方向發(fā)展才能實現新興的 Web 服務架構的標準化。在這部分中，他對于討論內容進行了一個簡要的概述。

正如標題所示，上周（4 月 11 日、12 日）在加利福尼亞的圣何塞舉行的 Web 服務專題研討會吸引了眾多有識之士共同關注這一我們稱為“Web 服務”的新興模式。巧的是我不僅有幸在研討會計劃委員會里任職，還主持了其中的一次會議（計劃委員會是審查所遞交的意見書并挑選由誰出席專題研討會的一個小組。）還由于這是我第一次以正式身份參加 W3C 活動，因此這的確是一次讓我大開眼界的經歷，讓我清楚地認識了 W3C 是如何完成其目標的。在“Web 服務內幕”的這部分中，我想與您分享一下以下報告及討論中的精彩片斷。

了解 W3C 的運作過程

首先，正像我在此以前沒有參加過這個專題研討會一樣，對于你們中那些尚不熟悉 W3C 運作過程的人來說，有必要作一個簡單的概述。在 W3C 開始標準化過程之前，他們先花一部分時間征求來自 W3C 成員公司的反饋意見和信息，主要是有關 W3C 該做什么及如何做的。這些研討會是這一過程中的一部分。

W3C 專題研討會的目的無外乎是集體討論那些可能最終發(fā)展成具有充分資格的 W3C 工作組或興趣組的主題。是工作組制定了那些我們喜歡稱作 W3C 推薦規(guī)則的實際規(guī)范。所以，要回答這樣一個簡單的問題：研討會期間是否會作出實質性的決定以推動 WSDL 或 UDDI 等的標準化，答案是否定的，盡管我們仔細深入地討論了如何、何時以及為何我們要去做那些事。

如何度過這兩天

首先，當然是這種場合不可或缺的閑談，然后就是參加主辦飯店為我們準備的精美午餐 -- 在這兒也要感謝 IBM 發(fā)起組織了整個活動。兩天中含括了許多聆聽及討論由對 Web 服務興趣濃厚的各個 W3C 成員公司遞交的報告書。然后就是辯論…… 我是指集體討論我們最先都想做些什么、誰應該做些什么事以及在發(fā)展的同時能對其他組織（如 OASIS）的哪些工作進行補充支持。為了能對事情的進行有個清楚的了解（也為了能讀一讀遞交上來的出色的意見書），您應查看一下研討會的官方網站（請參閱參考資料）并順著鏈接打開研討會項目。

我們討論了些什么

整個研討會圍繞著幾個不同的主題展開，迄今為止，這些主題已為我們中緊跟新興的 Web 服務體系結構發(fā)展的那些人所熟悉。

我們討論并確立了 Web 服務體系結構的三個不同的概念組件，且開始定義適合那些組件的要求與技術的堆棧。根據 IBM Emerging Technologies 的 VP -- Rod Smith 以及微軟的 XML 權威 Andrew Layman 的介紹，一個“Web 服務堆?！钡臉嬒腴_始形成。（請參閱圖 1）。

圖 1：Web 服務體系結構堆棧的概覽

我們討論了“描述”一種 Web 服務究竟意味著什么，并詳細地談到了 Web 服務描述語言 (WSDL)，關于 W3C 是否應該開始著手將 WSDL 標準化，或更通俗地說，W3C 是否應該開始將 Web 服務描述作為整體來進行標準化。組內多數人的意見是標準化 Web 服務描述的 W3C 工作組應該在短期內開始。工作組章程的確切細節(jié)仍有待決定。然而正如 SOAP 成為了 W3C XML 協議制定過程的核心部分一樣， WSDL 也理應成為那個過程中的核心部分。

圖 2: 服務描述堆棧

正如您能從圖 2 中看到的那樣， WSDL 致力于 IBM 定為 Web 服務描述堆棧的底下兩層。對于該堆棧的更高層的關注與注意也頗多。也就是能夠從所有被認為“可描述”的 Web 服務組件的方面來描述 Web 服務的特性，包括可靠性、能力、消息的先后順序以及對誰發(fā)了哪個消息及消息發(fā)送時間的編排等。達成的共識是我們需要一個單獨的、已定義的、可擴展的框架，在此基礎上能將所有這些分層堆積到服務描述堆棧中。盡管對于它最終將如何成形仍有些爭論，但 WSDL 始終是討論的中心，并且對于 WSDL 為何能夠成為并應該成為那項工作的基礎展開了一場非常好的辯論。

Tim Berbers Lee 以他對 Web 服務的前景的詳細描述，實際上是對“語義上的網絡”的現實化開始了此次研討會。討論的主題從有能力歸類、定性、并發(fā)掘不同實體論基礎上的 Web 服務，到演示如何將 WSDL 和 RDF 結合起來補充支持現有的基于 RDF 的基礎設備。

當兩方面產生沖突時

在我看來，我們討論的最有意思的主題之一就是將新興的 Web 服務體系結構與在 OASIS 組用 ebXML 進行的工作結合起來。我來作一個非常簡短、粗略的概括： ebXML 是一個終端對終端的協議堆棧以及在互聯網上用 XML 以及其它開放式標準技術開展電子商務的規(guī)范。我說的“終端對終端”是指 ebXML 本質上含有一個處理電子商務交易的各個方面的規(guī)范，從描述簡單服務端點定義（使用 WSDL 或其它一些機制），到描述交易的整個商業(yè)步驟的工作流程。ebXML 規(guī)范的范圍（預計于 2001 年 5 月中旬完成）覆蓋了眾多方面，其中有關可靠的消息傳遞、安全、事務處理、消息封裝、服務描述、服務能力描述、消息的先后順序、消息工作流程和編排、不同交易伙伴間的協議等，羅列不盡。

在許多方面， ebXML 就像是 Web 服務體系結構的堆積結果。這實際上是對的，這也就是為什么我們開始看到這兩個體系結構在力圖實現的目標以及實現的方法上產生的沖突與會合。例如， ebXML 需要一種在電線上來回傳輸基于 XML 的消息的方法。起先，他們想到了 SOAP （1.0 版），并決定不使用它。因此他們開發(fā)了自己的 XML 消息傳遞協議，它主要建立在將 XML 文檔填入獨立的多部件 MIME 部分的基礎上。然后，出現了帶附件的 SOAP 消息規(guī)范，它使用 SOAP 作為主要協議完成了完全相同的事情。 ebXML 工作組面臨著一個選擇 -- 或者繼續(xù)使用他們自己的 XML 消息傳遞規(guī)范，或者轉而采用帶附件的 SOAP 規(guī)范。兩個多月前，他們明智地決定采用帶附件的 SOAP 作為消息傳遞標準。

由于開發(fā)人員繼續(xù)沿著這條路開發(fā) Web 服務體系結構，所以類似的沖突仍有待解決。因而有個顯而易見的問題：既然 ebXML 已經做了所有這些事，為何不干脆使用 ebXML 呢？為何還要麻煩地定義另一個全新的體系結構呢？

這個問題曾多次在 Web 服務專題研討會上被提出來，答案很簡單：在那些重疊的區(qū)域，如在 XML 消息傳遞或服務發(fā)現區(qū)域，我們需要仔細觀察 ebXML （或者是其它地方設計的規(guī)范）是否能滿足我們所要作出行為的需要。如果是這樣，我們又如何將那些項目最有效地補充到 Web 服務體系結構中。有一件必須記住的重要事情，這個不斷發(fā)展中的體系結構尚未完成所有難點的定義。我們想要將重新構建體系結構的可能性降到最低。

另一個有關 ebXML 和 Web 服務的區(qū)別的重要事實是，它們是從兩個不同的優(yōu)勢點著手解決一個相同的問題的。 ebXML 是自上而下地解決 -- 先確定在互聯網上成功開展電子商務所必須達到的要求的全部范圍，然后著手實現滿足那些要求的規(guī)范。而 Web 服務架構則自下而上地解決 -- 先實現那些能滿足個別核心要求的規(guī)范（如簡單的 XML 消息傳遞和服務描述），然后在此基礎上逐步上升。

ebXML 和 Web 服務之間存在相互競爭嗎？從某些方面來說存在，而從另一些方面來說不存在。很多時候， ebXML 可以看作是一個 Web 服務架構的復雜實現，它使用一套特殊規(guī)范來解決一些困難的問題。如果您看出這整個的體系結構仍處于變化中，那么這些規(guī)范與通常被視為 Web 服務體系結構核心的規(guī)范（WSDL、UDDI等等）不同的這個事實也就沒有意義了。重要的是，人們正在做大量的工作，來保證這兩個體系結構能夠共存，實際上也是為了它們能相互添加一些有價值的層。例如， ebXML 服務倉庫的設計就允許它與 UDDI 服務注冊表共存、甚至集成。

總結

總結這次 Web 服務專題研討會，即 Web 服務的發(fā)展非常重要，且 W3C 應著手標準化該體系結構中的不同組件。我們都一致同意標準化服務描述應為這項工作中最重要的部分。這就意味著您應在不久的將來看到圍繞 WSDL 開展的一些活動。如果您是一個使用基于 WSDL 的工具的公司，我建議您特別注意活動的進行情況。

就 W3C 專題研討會對開發(fā)人員意味著什么來說，對于在此領域中試圖使用該技術在短期內實現實際應用的開發(fā)人員，我的建議是，開始熟悉 Web 服務體系結構的核心組件。如果您還沒有熟悉，那么就開始學習 SOAP, WSDL 和 UDDI。如果您是個 Java 開發(fā)人員，我建議您下載 IBM Web 服務工具包，開始試驗 Web 服務體系結構。

參考資料