如何選擇適合的 Microsoft SOAP Toolkit 版本

編輯：關於C語言

前言

隨著 Web Services 技術的快速發展，微軟推出了多個版本的 SOAP Toolkit 供開發者建立基於 SOAP 的網路服務。面對 1.0 與 2.0 兩個主要版本，開發者常困惑於該選擇哪一版，以及如何平滑遷移。本文整理自微軟 MSDN 官方指引，針對不同開發階段提供具體建議，並詳細說明版本間的關鍵差異與遷移重點。

根據專案階段選擇版本

情況一：已規劃發布基於 SOAP Toolkit 1.0 的產品

若專案已進入後期，且確定採用 1.0 版本發布，建議直接使用 2000 年 12 月釋出的正式版 SOAP Toolkit 1.0，該版本在穩定性與執行效能上均有提升。若客戶端包含 .NET Framework 與 Visual Studio .NET Beta 1 使用者，亦須採用此版本。但應盡快規劃遷移至受微軟支援的 SOAP 架構——即 SOAP Toolkit 2.0（預計 2001 年秋季釋出，或隨 Visual Studio .NET 正式版推出）。若無法在現有服務中應用新版，需採取並行策略維護舊服務。

情況二：處於 Web Services 產品早期開發階段

若預計 2001 年秋季上市，需權衡風險：是採用 .NET 產品的 Beta 2 版發布，還是選擇 SOAP Toolkit 2.0？後者採網路發布模式，2001 年秋季前將持續更新。若服務代碼基於 .NET 技術，可獲得生產力與策略優勢，因 .NET 代表微軟對 SOAP 底層架構的長期投資。

情況三：處於技術評估階段

若仍在評估 Web Services 潛力，建議暫不使用任何版本的 SOAP Toolkit 開發服務。微軟的長期策略是透過 .NET 與 Visual Studio .NET 提供快速應用開發環境，等待這些產品成熟後再以最高效方式建立與使用 Web Services 為宜。

從 1.0 遷移至 2.0 的關鍵技術差異

程式碼轉換

ROPE.Proxy 客戶端代碼：遷移至 2.0 高層介面相對容易，唯一已知問題為 2.0 暫不支援客戶端憑證（最終版將支援），需移除使用 1.0 12 月版特性的代碼。
低層 ROPE.Packager 介面：2.0 提供更靈活的低層介面，但需重寫大部分或所有低層代碼。
ROPE.WireTransfer：2.0 架構允許插入不同連接器傳輸 SOAP 訊息，同樣需大幅重寫。
ISAPI 監聽器：1.0 的 ISAPI 監聽器與 2.0、VS.NET Beta 1 不相容。應改用 2.0 的 ASP 監聽器（ISAPI 將在最終版加入）。2.0 使用 WSML 檔案對應訊息名稱至 PROGID，單一監聽器即可支援多種服務，且 ASP 監聽器也需 WSML 檔案。
Glue 代碼移植：使用 ISAPI 監聽器的開發者需將 glue 代碼移植至自動生成的 interface.asp 中。

服務描述格式：SDL vs WSDL

SOAP Toolkit 1.0、.NET Framework 與 VS.NET Beta 1 使用舊版 SDL 描述服務；而 SOAP Toolkit 2.0、.NET Framework 與 VS.NET Beta 2 支援新版 WSDL。為支援要求 WSDL 合約的客戶，必須遷移至 2.0 或 .NET Beta 2。微軟正評估提供 SDL 轉 WSDL 編譯器的可行性，以便 2.0 客戶端存取 1.0 或 .NET Beta 1 建立的服務。

XML Schema 格式：XDR vs XSD

1.0 與 .NET Beta 1 基於 XDR Schema；2.0 與 .NET Beta 2 支援 W3C 提議的 XSD 格式。Schema 格式與服務描述相關：SDL 用 XDR，WSDL 用 XSD。僅影響手寫描述檔案的開發者，因兩版工具皆可自動生成服務描述。

字元編碼支援

1.0 版：以 Windows code page 1252 的 8 位元 ANSI 字元測試，預設 SOAP 訊息為 UTF-8 編碼（實際為 UTF-8 子集，與 ANSI 1252 無法區分）。
2.0 版：同時接受 UTF-8 與 UTF-16 編碼，舊客戶端程式可繼續運作。伺服器端將字串傳送至 UTF-16 的 BSTR 變數，若原代碼需 8 位元 ANSI，必須更新編碼至 UTF-16。