COM+ Web 服務:通過複選框路由到 XML Web Services(3) (微軟中國)

來源:互聯網
上載者:User
services|web|xml|複選框|微軟

SOAP 與 DCOM 的局限性和區別


.NET Remoting 的目的之一是提供豐富的分布式環境,使開發人員能夠在此環境中對序列化協議(格式化程式)和網路通訊協定(頻道)進行組合與匹配。.NET 架構 1.0 版本中的 COM+ Web 服務僅支援一種格式化程式 (SOAP) 和一種頻道 (HTTP)。這並不是說其他頻道和格式化程式不能使用 ServicedComponents 或 COM+,而是說沒有自動設定為這些備用頻道和格式化程式提供用戶端和伺服器端點。
目前已經有用各種語言編寫的大量 COM+ 組件。如果可以使用 COM+ Web 服務將所有這些組件啟用為 Web 服務,那就太好了。但正如使用 .NET 架構 1.0 版本一樣,並非所有現有的 COM 組件都可以使用 COM+ Web 服務。雖然多數具備類型庫的現有組件可以正常工作,但是此版本不支援某些組件,例如 Windows 指令碼組件 (WSC) 組件。某些複雜的類型庫(其介面具有多重繼承層級,或依賴於多個類型庫)可能無法正常工作。此外,由於類型庫轉換的局限性,只有類型庫中預設的介面才可以作為 Web 服務。
COM+ Web 服務並不是適用於所有現有非託管 COM+ 組件的完整解決方案。現有非託管 COM+ 組件中有一大部分是使用多種程式設計語言編寫而成的,由於不可能測試所有可能的類型庫(由支援 COM+ 的各種編譯器產生),因此某些非託管 COM+ 組件不能使用 COM+ Web 服務正確發布。COM+ Web 服務的目的之一就是最大程度減少做出這種評估所需的時間和精力。只需將非託管 COM+ 組件發布為 COM+ Web 服務,開發人員就可以迅速判斷是否可以將其用作 Web 服務。如果遇到問題,則可以通過若干替代方法來處理現有的非託管組件。這些替代方法包括編寫託管或非託管的封裝程式,這些封裝程式提供的相容介面發行就緒為 Web 服務。多數情況下,編寫這樣的封裝程式的工作量比重新編寫整個組件要少得多。這就儘可能減少了將現有的應用程式應用為 XML Web Services 所需的開發與測試工作。
使用非託管(Visual Basic 6.0 或 Visual C++)伺服器時,通常越早綁定託管用戶端應用程式和 SOAP,越能更好地工作。在某些情況下,如果將產生的中繼資料用作後期綁定的跨電腦遠程代理程式,它可能無法正常工作。
在通過 HTTP 使用 SOAP 格式化程式的情況下,仍然可以使用許多選項(取決於目標部署環境)。COM+ Web 服務為伺服器和 CAO 用戶端配置產生基於 XML 的遠程設定檔。(WKO 啟用的 URL 引用已嵌入產生的用戶端代理,因此不需要設定檔。)COM+ Web 服務產生直觀的功能性設定檔,可由使用者自訂以滿足任何通過 HTTP 的直接 SOAP 通訊所不能滿足的需求。可進行自訂的地區包括使用者身分識別驗證,如下例所示:
<?xml version="1.0" encoding="utf-8"?><configuration> <system.runtime.remoting>  <application>   <service>    <wellknown mode="SingleCall" type="SCTrans.SCTransSQL, SCTrans,       Version=0.0.0.0, Culture=neutral,       PublicKeyToken=9c6052078b454cee"       objectUri="SCTrans.SCTransSQL.soap" />    <activated type="SCTrans.SCTransSQL, SCTrans" />   </service>  </application> </system.runtime.remoting> <identity impersonate="true" /></configuration>

上例中添加的反白的行可以在啟用 COM+ 組件(通過 SOAP 調用)時使用使用者的身份標識。(預設情況下,IIS 虛擬根使用標準的 IIS 身分識別驗證。)這樣在使用 SOAP 時可以實現 COM+ 的分區(一種 COM+ Windows .NET Server 功能),從而可根據使用者的身份標識來實際調用不同的組件。
另一個可以自訂的地區包括用戶端啟用物件的生存期管理,如下例所示:
<?xml version="1.0" encoding="utf-8"?><configuration> <system.runtime.remoting>  <application>   <service>    <wellknown mode="SingleCall" type="SCTrans.SCTransSQL, SCTrans,       Version=0.0.0.0, Culture=neutral,       PublicKeyToken=9c6052078b454cee"       objectUri="SCTrans.SCTransSQL.soap" />    <activated type="SCTrans.SCTransSQL, SCTrans" />   </service>   <lifetime leaseTime="30S" renewOnCallTime="30S" />  </application> </system.runtime.remoting></configuration>

在 web.config 檔案中添加的反白的行,將此 IIS VRoot 中的用戶端啟用物件的生存期從 6 分鐘更改為 30 秒。如果把 wellknown 元素的 SingleCall 屬性更改為 Singleton,則啟用行為會更改為將所有傳入的方法調用都路由到一個組件,而不是原來的對於每個方法調用都啟用一個新組件。
.NET Remoting(類似 .NET 架構的其餘部分)支援記憶體回收,而不支援引用計數。這意味著在某些情況下,使用 COM+ Web 服務和 DCOM 時,非託管事務 COM+ 組件的行為方式將有所不同。對於通過 WKO 單一調用發布的事務方法,調用 SetComplete 或選擇自動完成(通過選擇組件方法屬性頁面的“返回此方法時自動停用該對象”複選框)是極其重要的,這是因為組件在進行記憶體回收前不能被釋放。使用 DCOM 時,引用計數通常會導致在釋放組件時提交或放棄事務,即使此法則被忽略。移動到 COM+ Web 服務環境時,在記憶體回收環境中,事務逾時之前這是不能保證的。如果調用 SetComplete 失敗或將方法配置為自動完成失敗,則證明其自身的間歇無法提交事務,因為組件被作為記憶體回收之前事務已逾時。

設計時應注意的事項


在 COM+ Web 服務中,如果選擇了 Uses SOAP 複選框(使用元件服務管理工具),將在 IIS 虛擬根上提供兩種不同的啟用模型:WKO 和 CAO。哪一種模型更好?使用者應該使用哪一種呢?
WKO 單一調用啟用模型看起來似乎頗為費事。每種方法調用都需要建立一個新組件,完成方法調用後,再將組件發送到記憶體回收器。但是,如果特別注重效能並且只能使用 WKO 處理業務時,緩衝的 ServicedComponents 或緩衝的非託管 C++ 組件可以大大緩解單一調用啟用的過程。使用緩衝的組件時,WKO 啟用將從緩衝池中檢索對象,完成調用,然後將對象返回到緩衝池。此協議的無狀態性質和緩衝池的使用提高了增加擴充性的可能。在不緩衝對象的 WKO 單一調用中,對象的生命期僅限於調用過程。
另一方面,CAO 提供了伺服器上單一啟用的效能優勢,還可以與某個組件的單一執行個體繼續進行通訊。通過從用戶端向伺服器進行多方法調用可以避免啟用的缺點。如果伺服器組件( ServicedComponent 或非託管 C++ 組件)被緩衝,則將從緩衝池中檢索對象,然後在完成方法調用時將對象返回到緩衝池。如果對象沒有被緩衝,則對象生命期取決於 web.config 檔案中指定的租用生命期,或由組件自身編程設定。生命期是很重要的,因為直到生命期到期時記憶體回收行程才會為組件釋放記憶體。在高容量的 CAO 配置中,這會影響開發人員的某些設計決定。

更進一步


如果您只是希望發布或使用應用了 COM+ Web 服務的 Web 服務,您可以到此為止。但是,如果您希望自訂、擴充或簡單瞭解使用的流程,請繼續閱讀下面的內容。下面的資訊不是使用此項功能所必需的,但是如果您希望手動擴充一些功能,這些資訊可能會非常有用。COM+ Web 服務是一個簡單的封裝程式,通過由 .NET Remoting 提供的一套相當豐富的服務,開發人員或管理員可以輕鬆地對其進行擴充。

伺服器 IIS 虛擬根


為使用此功能,並沒有在 .NET Remoting 中添加隱藏掛鈎,而是編寫了 COM+ 代碼以進行必要配置,將 COM+ 端點發布為 IIS 虛擬根。在伺服器上,這包括向伺服器建立物理目錄作為虛擬根,以及產生 web.config 檔案,以便通過 Remoting 來訪問組件。如果是非託管組件(Visual C++ 或 Visual Basic 6.0),也會組建代理程式中繼資料,以便 Remoting 可以訪問組件。如果 Windows XP 系統目錄是 c:\windows,則伺服器設定檔和產生的所有中繼資料都將儲存在以下分類樹中:
C:\windows\system32\com\SoapVRoots\ vrootname當在伺服器上發布 SOAP 端點時,以下產生的檔案將被放入此目錄中:
  • web.config: VRoot 的基本 Remoting 設定檔,包含許多選項,可供開發人員或系統管理員添加或編輯,以調整 Remoting 的效能和安全性。
  • default.disco: 如果您正在開發Managed 程式碼用戶端,可與 Visual Studio .NET 一起使用此檔案,來產生對發行的 Web 服務的引用。如果您的業務夥伴希望在企業外連網上開發自己的用戶端,這會特別有用。
  • default.aspx: 簡單的 Microsoft ASP.NET 頁,可以將每一組件發布為超連結。

上述所有檔案都是預設產生的。如果您希望刪除其中某些功能,只需編輯或刪除相應的檔案。(但是,如果刪除了 web.config 檔案,來自 IIS 虛擬根的所有 SOAP 發布都會停止。)
所有產生的中繼資料都被放入以下目錄以及 GAC 中:
C:\windows\system32\com\SoapVRoots\ vrootname\bin
在 .NET Remoting 中,bin 目錄是一個很特殊的位置。當 HTTP 要求進入 IIS 時,將在此目錄中搜尋程式集,因此在許多情況下,bin 目錄中的發布是唯一必要的步驟。但是,在發布 SOAP 端點時,產生的程式集也被放入 GAC,這是因為虛擬根的程式集解決方案的範圍僅限於 bin 目錄和 GAC。如果您的代碼在同一台電腦上從一個虛擬根向另一個傳遞引用,除非程式集在 GAC 中,否則目標虛擬根中的引用解決方案將會失敗。如果您正在使用所產生的用於非託管 Visual Basic 6.0 或 Visual C++ 組件的中繼資料,如果沒有傳遞引用,則可以從 GAC 中刪除所產生的程式集。
此版本的 .NET 架構需要特別注意的一點是:如果載入了程式集,並且使用 System.Reflection 來訪問組件檔,則檔案將在記憶體中鎖定,直到進程結束。動態產生 WSDL 以便組建代理程式時,將使用反射,因此對於將由用戶端進程訪問的活動 IIS 虛擬根來說,可以鎖定組件檔。這在運營環境中不會產生問題,但是對於經常更改組件的開發人員來說,應該牢記這一點。
如果您正在使用帶有 COM+ Web 服務的 ServicedComponents,此時也需要將程式集放在 GAC 中,除非您最初將程式集放在了 bin 目錄中,並且運行了針對該目錄中程式集的 regsvcs.exe。如果已經載入 Microsoft .NET 架構 SDK,您可以使用 gacutil.exe 命令列公用程式,將 ServicedComponent 放入 GAC 中;如果安裝了內建 .NET 架構的 Windows .NET Server,或者在 Windows XP 電腦上載入了可重新分發的 .NET 架構,可以使用 Microsoft .NET 架構配置使用者介面(可從 Administrative Tools 菜單訪問),將程式集添加到 GAC 中。
此外,使用 Windows XP 或 Windows .NET Server 時,請確保已安裝並配置了 IIS,以提供 ASP.NET 應用程式服務。這些設定對於提供使用 SOAP 所必需的動態內容是必需的。

產生的代理程式組件緩衝


對於要通過 .NET Remoting 發布為 SOAP 端點的非託管 COM+ 組件,需要組建代理程式,使非託管組件可用於 .NET 架構。這可以通過編程執行與 tlbimp.exe(用於將非託管 COM+ 類型庫轉換為代理中繼資料程式集的 .NET 架構 SDK 工具)相同的步驟來完成。但是,要通過 SOAP 成功啟用用戶端,用戶端和伺服器電腦必須共用相同加強式名稱的簽名中繼資料代理。因此,當產生用於非託管 COM+ 組件的託管代理程式組件時,還會產生加強式名稱關鍵字,並用於簽名代理程式組件。
加強式名稱關鍵字只能產生一次,並且在非託管 COM+ 組件中沒有加強式名稱關鍵字的概念。也就是說,如果多次組建代理程式,則可以建立不同的加強式名稱關鍵字。這會為同一非託管 COM+ 組件建立不同的託管標識,要避免這種情況,請將所有為非託管 COM+ 組件產生的代理程式組件寫入以下 SoapCache 目錄中:
C:\windows\system32\com\SoapCache\ componentdirectory\ proxymetdata.dll
其中 componentdirectory 的格式應為:
ATLTrans.dll_40960_2001_6_27_15_4_16
目錄名是根據檔案名稱、檔案大小以及上次編譯的日期和時間建立的。此方案基於以下假設:如果重新編譯非託管 COM+ 組件,則需要產生新的代理。而這又是基於以下假設:如果要對代碼做出更改,只能在運營環境中重新編譯代碼。
由於存在 SoapCache 目錄,所以如果在同一電腦的不同虛擬根發布了相同的非託管組件,而不是組建代理程式程式集,則位於緩衝中的非託管組件將被重新使用。這是為了確保組件的加強式名稱簽名(以及由此產生的標識)可以通過虛擬根共用。
如果將 SOAP 啟用的非託管 COM+ 組件作為伺服器應用程式匯出,然後匯入到其他伺服器,緩衝的代理中繼資料將被一起帶走,因此不同的伺服器可以共用相同的非託管程式集的同一託管標識。此外,如果使用者要產生或編寫並簽名自己的代理,只需將中繼資料放入相應的緩衝目錄中,當伺服器上發生 SOAP 發布時就會使用此中繼資料。這裡應用的基本規則是,為避免不必要地擴散用於同一非託管組件的已簽名的代理,如果緩衝中存在可替代的檔案則不產生程式集。

用戶端配置


用戶端的配置工作也是必需的,最簡單的情況(至少從使用者的工作量來說)就是本文給出的第一個程式樣本:
set SoapObj =    GetObject("soap:wsdl=http://www.xmethods.net/sd                   /TemperatureService.wsdl")WScript.Echo "Fairbanks  氣溫 = " & SoapObj.getTemp("99707")

當處理 WSDL Moniker時,將會引發以下步驟:
  1. 進行檢查,查看是否存在以前為此 URL 產生的代理。如果存在,則再次使用。(跳到步驟 4。)
  2. 如果不存在,則從 URL 檢索 WSDL 並產生 C# 代理程式。這實質上與 soapsuds.exe 命令列公用程式(.NET 架構 SDK 所附帶的)使用的邏輯相同。
  3. C# 程式被編譯為 DLL 並以與 URL 相匹配的名稱命名(非法字元轉換為檔案名稱中可接受的字元)。
  4. 然後,產生的代理用於通過 .NET Remoting (WKO) 與 WSDL 中指定的遠程伺服器通訊。

這些代理產生並儲存在以下檔案夾中:
C:\windows\system32\com\SoapAssembly在用戶端啟用的情況中,用戶端代理匯入用戶端電腦上所必需的已匯出的 COM+ 應用程式。此應用程式的匯出/匯入將從伺服器帶來用戶端啟用所必需的已簽名的中繼資料程式集。匯入處理程序還組建組態檔案,並放入 SoapAssembly 目錄中。通常用戶端設定檔採用以下格式:
<configuration> <system.runtime.remoting>  <application>   <client url="http://MyServer/VB6Soap">    <activated type="VB6SoapSoapLib.CalcClass, VB6SoapSoapLib"/>   </client>  </application> </system.runtime.remoting></configuration>

COM+ Web 服務在啟用組件前讀取此設定檔,這樣便可以通過修改或替換此設定檔,在用戶端電腦上潛在更改啟用模型。 一切才剛剛開始
COM+ Web 服務的設計目的是簡化結合 .NET Remoting 和 COM+ 服務(Windows XP 和 Windows .NET Server 系列均包含此服務)的過程。它只是為了簡化常見的任務,並非包含所有的選項或涵蓋使用者可能遇到的各種情況。與使用嚮導在 Visual Studio .NET 中建立程式類似,某些進階的任務留給使用者自行解決。為了使使用者可以擴充,產生的項目很少被完全刪除。此外,XML 類用於編輯產生的設定檔,如果已經存在設定檔,則會在該檔案中添加或刪除節點,以反映來自元件服務管理工具或 Microsoft COM+ 管理 SDK 的更改。COM+ Web 服務的設計使使用者可以輕鬆地擴充或自訂已經產生的內容。
總之,COM+ Web 服務為現有的 Visual Basic 和 Visual C++ COM+ 組件,以及在 Visual Basic .NET 和 C# 中編寫的新託管的 ServicedComponents,提供了一條實現 XML Web Services 和 SOAP 的簡單途徑

相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。