程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> C語言 >> 關於C語言 >> 選擇一個微軟SOAP Toolkit

選擇一個微軟SOAP Toolkit

編輯:關於C語言

翻譯整理: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版本將會是一個移植的過程。


  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved