COM+ Web 服務(wù)：通過復(fù)選框路由到 XML Web Services （轉(zhuǎn)）10
2024-09-05 20:55:49
供稿：網(wǎng)友
另一個可以自定義的區(qū)域包括客戶端激活對象的生存期管理，如下例所示：
<?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，則激活行為會更改為將所有傳入的方法調(diào)用都路由到一個組件，而不是原來的對于每個方法調(diào)用都激活一個新組件。
.net remoting（類似 .net 框架的其余部分）支持垃圾回收，而不支持引用計(jì)數(shù)。這意味著在某些情況下，使用 com+ web 服務(wù)和 dcom 時，非托管事務(wù) com+ 組件的行為方式將有所不同。對于通過 wko 單一調(diào)用發(fā)布的事務(wù)方法，調(diào)用 setcomplete 或選擇自動完成（通過選擇組件方法屬性頁的“返回此方法時自動停用該對象”復(fù)選框）是極其重要的，這是因?yàn)榻M件在進(jìn)行垃圾回收前不能被釋放。使用 dcom 時，引用計(jì)數(shù)通常會導(dǎo)致在釋放組件時提交或放棄事務(wù)，即使此法則被忽略。移動到 com+ web 服務(wù)環(huán)境時，在垃圾回收環(huán)境中，事務(wù)超時之前這是不能保證的。如果調(diào)用 setcomplete 失敗或?qū)⒎椒ㄅ渲脼樽詣油瓿墒。瑒t證明其自身的間歇無法提交事務(wù)，因?yàn)榻M件被作為垃圾回收之前事務(wù)已超時。
設(shè)計(jì)時應(yīng)注意的事項(xiàng)
在 com+ web 服務(wù)中，如果選擇了 uses soap 復(fù)選框（使用組件服務(wù)管理工具），將在 iis 虛擬根上提供兩種不同的激活模型：wko 和 cao。哪一種模型更好？用戶應(yīng)該使用哪一種呢？
wko 單一調(diào)用激活模型看起來似乎頗為費(fèi)事。每種方法調(diào)用都需要創(chuàng)建一個新組件，完成方法調(diào)用后，再將組件發(fā)送到內(nèi)存回收器。但是，如果特別注重性能并且只能使用 wko 處理業(yè)務(wù)時，緩沖的 servicedcomponents 或緩沖的非托管 c++ 組件可以大大緩解單一調(diào)用激活的過程。使用緩沖的組件時，wko 激活將從緩沖池中檢索對象，完成調(diào)用，然后將對象返回到緩沖池。此協(xié)議的無狀態(tài)性質(zhì)和緩沖池的使用提高了增加擴(kuò)展性的可能。在不緩沖對象的 wko 單一調(diào)用中，對象的生命期僅限于調(diào)用過程。
另一方面，cao 提供了服務(wù)器上單一激活的性能優(yōu)勢，還可以與某個組件的單一實(shí)例繼續(xù)進(jìn)行通信。通過從客戶端向服務(wù)器進(jìn)行多方法調(diào)用可以避免激活的缺點(diǎn)。如果服務(wù)器組件（servicedcomponent 或非托管 c++ 組件）被緩沖，則將從緩沖池中檢索對象，然后在完成方法調(diào)用時將對象返回到緩沖池。如果對象沒有被緩沖，則對象生命期取決于 web.config 文件中指定的租用生命期，或由組件自身編程設(shè)置。生命期是很重要的，因?yàn)橹钡缴诘狡跁r垃圾回收器才會為組件釋放內(nèi)存。在高容量的 cao 配置中，這會影響開發(fā)人員的某些設(shè)計(jì)決定。
更進(jìn)一步
如果您只是希望發(fā)布或使用應(yīng)用了 com+ web 服務(wù)的 web 服務(wù)，您可以到此為止。但是，如果您希望自定義、擴(kuò)展或簡單了解使用的流程，請繼續(xù)閱讀下面的內(nèi)容。下面的信息不是使用此項(xiàng)功能所必需的，但是如果您希望手動擴(kuò)展一些功能，這些信息可能會非常有用。com+ web 服務(wù)是一個簡單的包裝程序，通過由 .net remoting 提供的一套相當(dāng)豐富的服務(wù)，開發(fā)人員或管理員可以輕松地對其進(jìn)行擴(kuò)展。
服務(wù)器 iis 虛擬根
為使用此功能，并沒有在 .net remoting 中添加隱藏掛鉤，而是編寫了 com+ 代碼以進(jìn)行必要配置，將 com+ 端點(diǎn)發(fā)布為 iis 虛擬根。在服務(wù)器上，這包括向服務(wù)器創(chuàng)建物理目錄作為虛擬根，以及生成 web.config 文件，以便通過 remoting 來訪問組件。如果是非托管組件（visual c++ 或 visual basic 6.0），也會生成代理元數(shù)據(jù)，以便 remoting 可以訪問組件。如果 windows xp 系統(tǒng)目錄是 c:/windows，則服務(wù)器配置文件和生成的所有元數(shù)據(jù)都將存儲在以下目錄樹中：
c:/windows/system32/com/soapvroots/vrootname
當(dāng)在服務(wù)器上發(fā)布 soap 端點(diǎn)時，以下生成的文件將被放入此目錄中：
web.config： vroot 的基本 remoting 配置文件，包含許多選項(xiàng)，可供開發(fā)人員或系統(tǒng)管理員添加或編輯，以調(diào)整 remoting 的性能和安全性。
default.disco： 如果您正在開發(fā)托管代碼客戶端，可與 visual studio .net 一起使用此文件，來生成對已發(fā)布的 web 服務(wù)的引用。如果您的業(yè)務(wù)伙伴希望在企業(yè)外聯(lián)網(wǎng)上開發(fā)自己的客戶端，這會特別有用。
default.aspx： 簡單的 microsoft asp.net 頁，可以將每一組件發(fā)布為超鏈接。
上述所有文件都是默認(rèn)生成的。如果您希望刪除其中某些功能，只需編輯或刪除相應(yīng)的文件。（但是，如果刪除了 web.config 文件，來自 iis 虛擬根的所有 soap 發(fā)布都會停止。）
所有生成的元數(shù)據(jù)都被放入以下目錄以及 gac 中：
c:/windows/system32/com/soapvroots/vrootname/bin
在 .net remoting 中，bin 目錄是一個很特殊的位置。當(dāng) http 請求進(jìn)入 iis 時，將在此目錄中搜索程序集，因此在許多情況下，bin 目錄中的發(fā)布是唯一必要的步驟。但是，在發(fā)布 soap 端點(diǎn)時，生成的程序集也被放入 gac，這是因?yàn)樘摂M根的程序集解決方案的范圍僅限于 bin 目錄和 gac。如果您的代碼在同一臺計(jì)算機(jī)上從一個虛擬根向另一個傳遞引用，除非程序集在 gac 中，否則目標(biāo)虛擬根中的引用解決方案將會失敗。如果您正在使用所生成的用于非托管 visual basic 6.0 或 visual c++ 組件的元數(shù)據(jù)，如果沒有傳遞引用，則可以從 gac 中刪除所生成的程序集。
此版本的 .net 框架需要特別注意的一點(diǎn)是：如果加載了程序集，并且使用 system.reflection 來訪問程序集文件，則文件將在內(nèi)存中鎖定，直到進(jìn)程結(jié)束。動態(tài)生成 wsdl 以便生成代理時，將使用反射，因此對于將由客戶端進(jìn)程訪問的活動 iis 虛擬根來說，可以鎖定程序集文件。這在運(yùn)營環(huán)境中不會產(chǎn)生問題，但是對于經(jīng)常更改組件的開發(fā)人員來說，應(yīng)該牢記這一點(diǎn)。
如果您正在使用帶有 com+ web 服務(wù)的 servicedcomponents，此時也需要將程序集放在 gac 中，除非您最初將程序集放在了 bin 目錄中，并且運(yùn)行了針對該目錄中程序集的 regsvcs.exe。如果已經(jīng)加載 microsoft .net 框架 sdk，您可以使用 gacutil.exe 命令行實(shí)用程序，將 servicedcomponent 放入 gac 中；如果安裝了內(nèi)置 .net 框架的 windows .net server，或者在 windows xp 計(jì)算機(jī)上加載了可重新分發(fā)的 .net 框架，可以使用 microsoft .net 框架配置用戶界面（可從 administrative tools 菜單訪問），將程序集添加到 gac 中。
此外，使用 windows xp 或 windows .net server 時，請確保已安裝并配置了 iis，以提供 asp.net 應(yīng)用程序服務(wù)。這些設(shè)置對于提供使用 soap 所必需的動態(tài)內(nèi)容是必需的。
生成的代理程序集緩存
對于要通過 .net remoting 發(fā)布為 soap 端點(diǎn)的非托管 com+ 組件，需要生成代理，使非托管組件可用于 .net 框架。這可以通過編程執(zhí)行與 tlbimp.exe（用于將非托管 com+ 類型庫轉(zhuǎn)換為代理元數(shù)據(jù)程序集的 .net 框架 sdk 工具）相同的步驟來完成。但是，要通過 soap 成功激活客戶端，客戶端和服務(wù)器計(jì)算機(jī)必須共享相同加強(qiáng)名稱的簽名元數(shù)據(jù)代理。因此，當(dāng)生成用于非托管 com+ 組件的托管代理程序集時，還會生成加強(qiáng)名稱關(guān)鍵字，并用于簽名代理程序集。
加強(qiáng)名稱關(guān)鍵字只能生成一次，并且在非托管 com+ 組件中沒有加強(qiáng)名稱關(guān)鍵字的概念。也就是說，如果多次生成代理，則可以創(chuàng)建不同的加強(qiáng)名稱關(guān)鍵字。這會為同一非托管 com+ 組件創(chuàng)建不同的托管標(biāo)識，要避免這種情況，請將所有為非托管 com+ 組件生成的代理程序集寫入以下 soapcache 目錄中：
c:/windows/system32/com/soapcache/componentdirectory/proxymetdata.dll
其中 componentdirectory 的格式應(yīng)為：
atltrans.dll_40960_2001_6_27_15_4_16
目錄名是根據(jù)文件名、文件大小以及上次編譯的日期和時間創(chuàng)建的。此方案基于以下假設(shè)：如果重新編譯非托管 com+ 組件，則需要生成新的代理。而這又是基于以下假設(shè)：如果要對代碼做出更改，只能在運(yùn)營環(huán)境中重新編譯代碼。
由于存在 soapcache 目錄，所以如果在同一計(jì)算機(jī)的不同虛擬根發(fā)布了相同的非托管組件，而不是生成代理程序集，則位于緩存中的非托管組件將被重新使用。這是為了確保組件的加強(qiáng)名稱簽名（以及由此生成的標(biāo)識）可以通過虛擬根共享。
如果將 soap 啟用的非托管 com+ 組件作為服務(wù)器應(yīng)用程序?qū)С觯缓髮?dǎo)入到其他服務(wù)器，緩存的代理元數(shù)據(jù)將被一起帶走，因此不同的服務(wù)器可以共享相同的非托管程序集的同一托管標(biāo)識。此外，如果用戶要生成或編寫并簽名自己的代理，只需將元數(shù)據(jù)放入相應(yīng)的緩存目錄中，當(dāng)服務(wù)器上發(fā)生 soap 發(fā)布時就會使用此元數(shù)據(jù)。這里應(yīng)用的基本規(guī)則是，為避免不必要地?cái)U(kuò)散用于同一非托管組件的已簽名的代理，如果緩存中存在可替代的文件則不生成程序集。
客戶端配置
客戶端的配置工作也是必需的，最簡單的情況（至少從用戶的工作量來說）就是本文給出的第一個程序示例：
set soapobj =
getobject("soap:wsdl=http://www.xmethods.net/sd
/temperatureservice.wsdl")
wscript.echo "fairbanks 氣溫 = " & soapobj.gettemp("99707")
當(dāng)處理 wsdl 名字對象時，將會引發(fā)以下步驟：
進(jìn)行檢查，查看是否存在以前為此 url 生成的代理。如果存在，則再次使用。（跳到步驟 4。）
如果不存在，則從 url 檢索 wsdl 并生成 c# 代理程序。這實(shí)質(zhì)上與 soapsuds.exe 命令行實(shí)用程序（.net 框架 sdk 所附帶的）使用的邏輯相同。
c# 程序被編譯為 dll 并以與 url 相匹配的名稱命名（非法字符轉(zhuǎn)換為文件名中可接受的字符）。
然后，生成的代理用于通過 .net remoting (wko) 與 wsdl 中指定的遠(yuǎn)程服務(wù)器通信。
這些代理生成并保存在以下文件夾中：
c:/windows/system32/com/soapassembly
在客戶端激活的情況中，客戶端代理導(dǎo)入客戶端計(jì)算機(jī)上所必需的已導(dǎo)出的 com+ 應(yīng)用程序。此應(yīng)用程序的導(dǎo)出/導(dǎo)入將從服務(wù)器帶來客戶端激活所必需的已簽名的元數(shù)據(jù)程序集。導(dǎo)入過程還生成配置文件，并放入 soapassembly 目錄中。通常客戶端配置文件采用以下格式：
<configuration>
<system.runtime.remoting>
<application>
<client url="http://myserver/vb6soap">
<activated type="vb6soapsoaplib.calcclass, vb6soapsoaplib"/>
</client>
</application>
</system.runtime.remoting>
</configuration>
com+ web 服務(wù)在激活組件前讀取此配置文件，這樣便可以通過修改或替換此配置文件，在客戶端計(jì)算機(jī)上潛在更改激活模型。
一切才剛剛開始
com+ web 服務(wù)的設(shè)計(jì)目的是簡化結(jié)合 .net remoting 和 com+ 服務(wù)（windows xp 和 windows .net server 系列均包含此服務(wù)）的過程。它只是為了簡化常見的任務(wù)，并非包含所有的選項(xiàng)或涵蓋用戶可能遇到的各種情況。與使用向?qū)г?visual studio .net 中創(chuàng)建程序類似，某些高級的任務(wù)留給用戶自行解決。為了使用戶可以擴(kuò)展，生成的項(xiàng)目很少被完全刪除。此外，xml 類用于編輯生成的配置文件，如果已經(jīng)存在配置文件，則會在該文件中添加或刪除節(jié)點(diǎn)，以反映來自組件服務(wù)管理工具或 microsoft com+ 管理 sdk 的更改。com+ web 服務(wù)的設(shè)計(jì)使用戶可以輕松地?cái)U(kuò)展或自定義已經(jīng)生成的內(nèi)容。
總之，com+ web 服務(wù)為現(xiàn)有的 visual basic 和 visual c++ com+ 組件，以及在 visual basic .net 和 c# 中編寫的新托管的 servicedcomponents，提供了一條實(shí)現(xiàn) xml web services 和 soap 的簡單途徑。
