COM+ Web 服務：通過復選框路由到 XML Web Services （轉）10
2024-09-05 20:55:49
供稿：網友
另一個可以自定義的區域包括客戶端激活對象的生存期管理，如下例所示：
<?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： 如果您正在開發托管代碼客戶端，可與 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 名字對象時，將會引發以下步驟：
進行檢查，查看是否存在以前為此 url 生成的代理。如果存在，則再次使用。（跳到步驟 4。）
如果不存在，則從 url 檢索 wsdl 并生成 c# 代理程序。這實質上與 soapsuds.exe 命令行實用程序（.net 框架 sdk 所附帶的）使用的邏輯相同。
c# 程序被編譯為 dll 并以與 url 相匹配的名稱命名（非法字符轉換為文件名中可接受的字符）。
然后，生成的代理用于通過 .net remoting (wko) 與 wsdl 中指定的遠程服務器通信。
這些代理生成并保存在以下文件夾中：
c:/windows/system32/com/soapassembly
在客戶端激活的情況中，客戶端代理導入客戶端計算機上所必需的已導出的 com+ 應用程序。此應用程序的導出/導入將從服務器帶來客戶端激活所必需的已簽名的元數據程序集。導入過程還生成配置文件，并放入 soapassembly 目錄中。通?？蛻舳伺渲梦募捎靡韵赂袷剑?br>
<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 的簡單途徑。
