IBM、Microsoft 和 Ariba 於 9 月份完成的 Web 服務描述語言 (WDSL) 的模式開發實際上只是增強 Web 服務體系結構嘗試的開始。130 家公司的通用描述、發現和集成 (UDDI) 的倡議，包括 WSDL 之後的團隊，是更基礎的部分。隨著情況的進展，已經有人在說：這些規范將如何開始產生實際的實現 -- 從 IBM 范圍廣闊的 AlphaWorks 工具到 Microsoft.Net 策略。來自 Web 服務中公司 stakeholder 的這批工具將首先出現在更大的框架中，並且通常是緊密地構建在那些框架中。
但是，在使格式適應當前應用之前無需等待集成的 WSDL 工具。只需萬維網聯盟的通用工具集 擴展樣式表變換語言 (XSLT)，WSDL 就可以做很多事。XSLT 無疑是 W3C 最成功的傑作之一。它有 30 多個獨立且嵌入產品中的實現。閱讀本文時，您應該熟悉 XSLT 和資源描述框架 (RDF)。
IT 僅用這個新的 XML 時髦詞語來試圖使 Web 更有魔力，就深受從有經驗的程序員到疲倦的 Web 管理員等用戶的喜愛。但最重要的是，它一直是用於測試大量 XML 結果的先驅工具。在規范上的墨跡未干之前，Eric van der Vlist 就使用 XSLT 將 XML 部分插入不知不覺的語法分析器。Rick Jeliffe 的由 XSLT 支持的 Schematron 提供了一種確認很多使用名稱空間的 XML 詞匯的方法，而 XML 模式仍然發展得緩慢。事實上，極其無恥的是，甚至有 XML 模式的 Schematron 確認器。在這種情緒下，我們將在本文中使用 XSLT 作為探測器來看一下實際的 WSDL。
探尋 WSDL 中的數據
Web 服務白頁和黃頁的開發人員以及服務供應商本身，都會對在各種報告和目錄格式中顯示 WSDL 描述的數據感興趣。XSLT 是用於這種數據抽取和報告的極佳工具。
在第一篇 WSDL 文章（請參閱 參考資料 ）中，我們給出了一個描述查詢認可特定產品的職業滑雪者的服務描述示例。該服務中的請求和響應用簡單對象訪問協議 (SOAP) 傳輸。 清單 1 是顯示在描述中指定的可用服務簡潔表的 XSLT 變換。這些服務的傳送和位置也被抽取出來。
即使對於這樣一個簡單用途，變換相當復雜。部分復雜性在於 WSDL 1.0 處理內容的方式。例如，關系是使用來自 XML 名稱空間的限定名稱表單的屬性指定的。然而，XSLT 1.0 不提供處理 XML 名稱空間范圍之外的名稱空間擴展的工具。這實際上已經在 XSLT 界作為對 XSLT 1.1 受歡迎的附加部分而討論過了，因為很多規范（WSDL、XML 模式和 XSLT 本身）都在內容中使用限定名稱。這些設施將使清單 1 簡單得多。
清單 1 ，模板 1.1 簡單地設置了 Html 樣板文件。接下來，是一些使用鍵的查詢表。不是所有的鍵都在清單中實際使用，但是我在清單中顯示表 1.1 到 1.4，以演示基本模式。鍵收集代表頂級 WSDL 組件的元素節點，按其名稱元素檢索。
查詢表 1.5 更為有趣。在後面的變換中，我們將列出在每一個端口的綁定期間指定的傳送。WSDL 在具有本地名 "binding" 的元素中指定這一點。查詢表 1.5 在每個 WSDL 綁定元素中捕獲該元素。
模板 1.2 輸出每個 WSDL 服務元素的表。它們中大多數都是普通的 XSLT。它使用 "pull" 模型（顯式循環並用 XPath 取值）而不是 "push" 模型（模板匹配）來以直接的方式剪切感興趣的數據。中央循環為服務元素中的每個端口輸出一行。在標號之後，從具有本地名稱 "address" 的元素顯示 location 屬性。請注意，只檢查本地名稱，因為 WSDL 指定兩種 "address" 元素類型：一種用於 SOAP，另一種用於 HTTP；另外，還允許我們的變換所支持的某些擴展。
接下來是使用 binding-uri 變量和依次使用 binding-local-name 的傳送。這兩個變量都在 xsl:for-each 中定義。在 binding-local-name 定義中，可以看到我所說的屬性中的限定名是什麼意思。要使端口綁定屬性的內容與相應的 WSDL 綁定元素匹配，必須除去名稱空間前綴，這由 substring-after() 函數完成。
binding-uri 變量使用 binding-local-name 作為到查詢表 1.5 的索引，如果您記起的話，該表將每個綁定的名稱映射成其特定於傳送的綁定元素的名稱空間 URL。在我們的示例中， binding-uri 最終將是 SOAP URI: http://schemas.XMLsoap.org/wsdl/soap/ 。回到第三個表單元中， binding-uri 被用作到查詢表 6 的索引，該表將名稱空間 URI 轉換成如 "SOAP" 這樣的描述字符串。
查詢表 1.6 值得仔細研究，因為它使用了高級 XSLT 技術。它使用獨特的名稱空間在樣式表中構建起查詢表。您可以在鍵的下面看到 x:ns-to-binding 元素。如果熟悉鍵，則您知道它們定義索引，而這些索引將在與 match 屬性中的模式匹配的原始源文檔中的節點上被構建。還不為人所知的是：每次用 XSLT document() 函數裝入附加源文檔時，還對它應用所有的鍵。變換結束標記之前的 xsl:variable 使用特殊的 document() 調用形式來將樣式表作為附加源文檔裝入。這樣，就索引了樣式表中與 ns-to-binding 匹配的節點。對於無需刪改源文檔或無需依賴附加文件而設置查詢表來說,這時一個非常有用的技術。您將在本文的後面再次看到對它的使用法。
在 Unix 命令行使用 4XSLT 應用程序（請參閱 參考資料）運行變換，如下所示：
[uogbuji@borgia wsdlxslt]$ 4xslt
http://uche.ogbuji.Net/articles/wsdl/endorsementservice.XML
http://uche.ogbuji.Net/articles/wsdl/wsdlservicesummary.xslt
如您所能看到的，我已經使原始 WSDL 源文件和清單 1 樣式表可以聯機獲得。有關詳細信息，請參閱“參考資料”一節。圖 1 顯示了該變換的輸出結果。
圖 1. 應用清單 1 中的樣式表之後得到的浏覽器視圖
應該很容易理解如何擴展該變換以從 WSDL 源抽取如消息部分等附加信息。下一節，我們將討論更復雜且側重點不同的 XSLT 變換用法。
從 WSDL 生成 RDF
在過去有關 WSDL 的文章中，我們討論了 WSDL 可能的 RDF 形式。與 RDF 一樣，WSDL 的全部內容都與描述有關，因此，我們指出 RDF 可能是 WSDL 的理想形式。幸運的是，既然 RDF 非常靈活，就有可能提出與 WSDL 原始格式差別不大的 RDF 兼容格式。現在，我們將看一看如何使變換自動化。
可以使用 清單 2 中的變換來將我們的 WSDL 樣本從第一篇文章轉換成在第二篇文章中作為示例給出的 RDF 版本。
首先要指出的是： 清單 1 中的變換更多地是使用 "pull" 模型（基於 xsl:for-each 指令）來顯示服務中的不同端口，而本樣式表幾乎全部基於 "push" 技術。具有仔細選擇匹配和適當方式的模板設置了執行路徑。大多數 XSLT 新手更習慣於 pull 技術，因為對於熟悉過程模型（例如 ECMAScript 的過程模型）的人來說，它們顯得更為自然。因此，以上變換可能需要多一點時間來理解，但是對於進行從一種 XML 格式轉換成另一種的非結構調整來說，它是很好的通用模型。
模板 2.1 開始進行處理。 xsl:copy 用來復制 wsdl:description 元素。第一個 xsl:apply-templates 復制其屬性。
第二個 xsl:apply-templates 試圖復制子元素，但是請留意，它不指定模式。如果看一下該清單的余下部分，您就會看到對於 WSDL wsdl:types ，這將由模板 2.7 匹配，該模板只遞歸地繼續復制那個元素下的所有子樹。而一旦到達 wsdl:description 的下一子節點，情況就會改變。 wsdl:message 匹配模板 2.4，該模板是為空過程。到目前為止的效果是：抑制除 wsdl:types 之外的所有 WSDL 元素子代。
第三個 xsl:apply-templates 作同樣的事，但卻指定 convert-to-rdf 方式。然後，處理器再次遇到 wsdl:types ，但是這次與作為空過程的另一個模板 2.6 匹配。然而，所有其它頂級 WSDL 元素由模板 2.2 處理 -- 它開始進行到 RDF 格式的轉換。當然，按要求將這部分輸出封裝在 rdf:RDF 元素中。
變換的其余部分主要是這些機制的繼續。還記得上一篇文章中所講的嗎：通過添加從初始 name 獲得的 rdf:ID 屬性來在頂級子代中轉換成 RDF。在模板 2.2 中通過顯示 xsl:attribute 來做到這一點。另外請注意，必須為頂級 WSDL 元素的每個屬性添加顯示名稱空間。這由以 convert-to-rdf 方式匹配屬性的模板 2.5 處理。請注意，它使用我們設置的查詢表，並且該表采用將樣式表作為源文檔裝入的技術。查詢表將名稱空間 URI 映射成在輸出中使用的前綴。
如模板 2.3 和 2.4 中，處理頂級 WSDL 元素子節點的方法略有不同。這些不同的方法是為了適應我們在 RDF 表示中所選擇的簡化，例如將 wsdl:message/wsdl:part 元素作為匿名資源以及將 @message 屬性轉換成 rdf:resource 屬性。
再次使用 4XSLT，對初始 WSDL 源文檔所作的該變換的輸出與上一篇文章中的 RDF 版本類似。即使對 RDF 格式的 WSDL 不感興趣，上面的樣式表也是多種 WSDL 調整的開始框架。
結束語
本質上，WSDL 非常簡單：只是聯機服務的描述。然而，因為 UUDI 以前所作的工作和打下的基礎，它注定要在多種應用中被使用。 Rich Site Summary (RSS) 系統就是簡單格式如何擁有廣泛用途的示例。本文所介紹的技術演示了幾種用 XSLT 變換處理 WSDL 的方法。
清單 1 對簡單的聯機報告和編目（特別是當您需要對變換進行簡單調整時）很有用。在這種情況下，輸出與輸入在結構上很少有類似之處，並且只選取用於輸出的材料較為合理。清單 2 中的 pull 方法對於在與 WSDL 相同的結構基礎中操作的變換是很有用的。例如，您可能要查看除去後綴名的 WSDL 文件，或者可能在 API 摘要的所有級別上抽取 WSDL 文檔元素。對於將 WSDL 關系重設為 XLinks 來說，它可能也有用。這樣的鏈接可能是內部的，當使用 WSDL 導入器來分解描述時，它們也可能是外部鏈接。更進一步，作為擴展設施，可以將鏈接處理成鏈接到 WSDL 導入設施之外的外部資源。這樣的變換看起來與清單 2 不會有太大不同。
希望本系列文章給出了 WSDL 的有用介紹並提供了一些工具來開始處理使用當前可用 XML 技術的格式。隨著 WSDL、UDDI 和其它這種技術的成熟和聚合，將有一個不斷改進的應用和服務供應商核心利用這樣的應用。某一天，這可能會使平滑集成 Web 服務的夢想向現實更靠近一步。