導 讀：SOAP Toolkit 是微軟提供的快速開發網絡服務（Web Services）的工具包。本文提供了一些包括SOAP Toolkit 各個版本以及.NET 框架和Visual Studio.NET的資料，并告訴我們怎樣去選擇一個在現在和將來都非常適合你的微軟SOAP Toolkit 版本。


--------------------------------------------------------------------------------

翻譯整理：51dotnet.com（微軟.net技術網）

原文出處：http://msdn.microsoft.com/xml/general/soap1and2tech.asp

選擇1.0版本或2.0版本

在選擇SOAP Toolkit 版本前，請先在下邊的三個選項中選擇你自己是屬于哪一類情況：

1．你已經打算要發布一個基于微軟的SOAP Toolkit 1.0版本的網絡服務（Web Services）產品。
2．你還在創建一個網絡服務（Web Services）產品過程的早期。
3．你處于網絡服務（Web Services）技術的評估階段。

如果你是第一種情況，那么就不應該使用微軟SOAP Toolkit 1.0版本代碼樣本，它只會使你的工作停止（或減慢），你應該用12月份發布的微軟SOAP Toolkit 1.0版本，這個版本在穩定性和可執行性上都有所提高。如果你的一些服務客戶正在使用基于微軟的.NET 框架和Visual Studio.NET Beta 1客戶程序，你也需要使用12月份發布的產品。一旦你能這樣做，你就應該計劃轉移到微軟支持的SOAP框架——或者是為應用程序設計的微軟SOAP Toolkit 2.0版本，這個版本將于2001年秋季前或者在Visual Studio .NET和.NET框架正式發布前發布。當然，一旦它發布后而你卻不能將之運用到已存在服務中的話，你將需要在并行方案中轉移以維護你已存在的服務。使用同樣的標準來討論第二和第三種情況，你同樣要考慮是否要轉移到微軟的SOAP的Toolkit 2.0版本還是到.NET框架和Visual Studio .NET。

如果你是第二種情況，處于創建網絡服務（Web Services）產品過程的早期。你預期在2001年秋季將產品投放市場，你就需要決定是否能接受，與選擇SOAP Toolkit 2.0版本技術相比，選擇這些新的.NET產品的BETA 2版本去發布你的服務所要承擔的風險。微軟的SOAP Toolkit 2.0版本采用了網絡發布方式，你可以期望在2001年秋天以前得到多次更新。另外一個方面，如果你的服務代碼是基于.NET技術的話，你能得到生產力和戰略上的優勢，因為.NET技術代表了微軟的一個SOAP的下部結構的長期投資。

如果你是第三種情況，并且仍在評估網絡服務（Web Services）的潛力，那么你應該考慮不使用任何版本的SOAP Toolkit 去創造你的網絡服務（Web Services）。這是因為微軟為網絡服務（Web Services）而提供一個快速的軟件應用開發環境的長期戰略是.NET和Visual Studio .NET，而你能等待我們繼續我們的投資，使這些產品用最有效的生產方式去創建和使用網絡服務（Web Services）。

從1.0版本轉移到2.0版本

轉換你的代碼

微軟SOAP Toolkit 1.0版本的開發者很少碰到類似于移植基于ROPE.Proxy對象的客戶端代碼到高級的2.0版本接口這樣的問題。在這里僅僅眾所周知的問題是在2.0版本中暫時缺少對客戶端證書的支持——你需要去徹底除去那些使用12月份發布的1.0版本特性的代碼。客戶端證書將在最后發布的2.0 版本中被支持。

微軟的SOAP Toolkit 1.0版本的開發者通過客戶端代碼使用低層的ROPE. Packager接口和直接訪問SOAP消息的相關特性，將在2.0版本的低層接口中進一步改進這項任務的靈活性和程序可用性。同樣的，那些使用ROPE.WireTransfer的開發者將會發現一個改進后的2.0版本的體系框架，它允許插入不同的連接器去連接SOAP端點并在它們之間傳輸消息，就象不同協議的處理器一樣。不幸地，所有這些提高需要重寫大部分或所有的低層代碼。

那些使用ISAPI 監聽器的微軟SOAP Toolkit 1.0版本的開發者不會發現其和2.0版本、Visual Studio .NET BETA1版本有相同之處。你現在應該使用2.0版本中的ASP監聽器，而 ISAPI監聽器最終將包括在最后的版本中。微軟SOAP Toolkit 2.0版本中的網絡服務元語言(WSML)文件達到了類似于微軟SOAP Toolkit 1.0版本的ISAPI 監聽器使用的.SOD文件把消息名字映射到PROGID的目的。這種機制可以使單個的、普通的監聽器為多種服務所使用；不象1.0版本的ASP監聽器，如果使用2.0版本的ASP監聽器也需要WSML文件。

另外，那些使用ISAPI監聽器的微軟SOAP Toolkit 1.0版本開發者需要移植glue代碼，把它們添加到自動生成的interface. Asp中。

服務描述格式

微軟SOAP Toolkit 1.0版本、.NET框架和Visual Studio.NET Beta 1是以舊的服務描述語言（SDL）來描述網絡服務（Web Services）的功能的。微軟SOAP Toolkit 2.0版本、.NET框架和Visual Studio.NET Beta 2版本支持新的WSDL服務描述格式。為了一個能支持那些要求WSDL合同的客戶的服務，你需要移植到微軟SOAP Toolkit 2.0版本或.NET框架和Visual Studio.NET Beta 2。在變遷的過程中，你需要去支持客戶期望的SDL或WSDL服務合同，微軟正在評估提供一個SDL到WSDL的“編譯器”的可行性。這個編譯器將允許使用微軟SOAP Toolkit 2.0版本客戶端去訪問使用SOAP Toolkit 1.0版本或.NET框架和Visual Studio.NET創建的服務。如果這能幫助你移植到微軟SOAP Toolkit 1.0版本，請訪問如下地址news://msnews.microsoft.com/microsoft.public.xml.soapsdk.

XML Schema格式

微軟SOAP Toolkit 1.0版本，.NET框架和Visual Studio.NET Beta 1是以舊的XML-DATA REDUCED（XDR）Schema格式為基礎的。微軟SOAP Toolkit 2.0版本或.NET框架和Visual Studio.NET Beta 2版本支持新的被W3C所提議的XML Schema定義（XSD）格式。

Schema格式是和服務描述相關的，在這里使用XDR定義SDL，而WSDL使用XSD。特別的是，XML原始的數據類型或被輸入或輸出參數類型的使用者定義Schema，必須在期望的XDR或XSD格式中指定。由于兩個Toolkit 都可以用工具去生成服務描述，這僅僅對那些手寫代碼文件的開發者重要。

只要是SOAP Toolkit 1.0版本所支持的XML原始數據類型，微軟SOAP Toolkit 2.0版本都支持。同樣的，這些普通的原始數據類型映射了與之相對應的COM變量類型。

字符設置

用Windows code page 1252中的字符串變量編制的8位 ANSI字符來測試微軟SOAP Toolkit 1.0版本。因為SOAP Toolkit 1.0版本信息序列化沒有在XML聲明中指定字符編碼，缺省的SOAP信息是UTF-8編碼(包括所有信息中的字符串變量)。實際上SOAP Toolkit 1.0版本是使用了UTF-8字符串編碼（包括UTF-8字符的子集），而UTF-8編碼與在Windows code page 1252中的8位ANSI編碼是不能區別的。

SOAP Toolkit 2.0版本則可以同時接受UTF-8和UTF-16字符串編碼，因此你使用SOAP Toolkit 1.0編寫的使用Windows code page 1252中的8位ANSI編碼的客戶端程序在SOAP Toolkit 2.0版本中能夠繼續使用。

在SOAP Toolkit 2.0版本中的服務器端信息發送代碼將會傳送字符串到UTF-16碼制的BSTR變量中。如果你的服務器端代碼要求有8位的ANSI編碼去編寫，你將需要移植到SOAP Toolkit 2.0版本，它將更新你的編碼到UTF-16碼制。

總結

我們希望幾乎每一個人都能馬上開始使用微軟的SOAP Toolkit 2.0版本，用來建立網絡服務（Web Services）。隨著開發者的支持，一個具有特色的擴展集和一個設計完美的體系結構的微軟SOAP Toolkit 2.0版本已經為取代微軟SOAP Toolkit 1.0版本作好準備。

我們知道，一些人還不能馬上方便地從SOAP Toolkit 1.0版本轉換過來，并且采用微軟SOAP Toolkit 2.0版本將會是一個移植的過程。