作者：獨孤九劍
email: mikaiyue@sina.com
日期：2001-7-4 19:50:40
[H3]MTS組件的創建過程[/H3]
				-- lostall([email]changming76@263.net[/email])
				
一個MTS組件的創建過程包含以下幾個步驟：
1。 一個客戶機為在MTS中注冊的COM對象調用CreateObject
2。 這個COM對象的注冊表設置表明它是一個MTS對象，所以創建交給MTS Executive(MTS執行者)
3。 COM運行時間將MTS Executive加載到MTS代理中，MTS代理是mts.exe
4。 MTS Executive加載COM DLL，并創建它的一個類廠實例。MTS還為這個類廠生成一個包裝程序
5。 然后MTS Executive創建Object Context(對象環境)和Context Wrapper(環境包裝)對象
    Context Wrapper實現真正務器對象請求的界面。
6。 MTS Executive將Context Wrapper對象指針返回客戶機。注意此時客戶機以為它創建一個
    組件對象實例，實際上并沒有創建對象。
7。 當客戶用得到的Context Wrapper對象指針調用組件的一個方法時，MTS Executive這時才從
    Object Context獲得類廠包裝程序，并真正的創建一個組件對象實例。客戶通過MTS執行者來
    調用組件對象實例的接口指針。
8。 MTS Executive調用COM組件的IObjectControl::Active函數以通知組件它已經被激活了，
    組件可以在這個時侯獲得它的Object Context指針。
9。 客戶方完成對組件的方法調用
10。組件對象根據方法調用的結果決定是提交還是中止，SetComplete or SetAbort。
11。MTS Executive調用組件的IObjectControl::Deactivate，并從Object Wrapper中刪除對
    象，把對象放入對象池中。注意客戶這時持有的組件接口指針并不為空，因為這個指針是
    MTS Executive對象指針，當然沒有釋放了。
12。當客戶再一次調用組件方法時，MTS Executive從對象池獲得一個對象，然后調用Active,
    然后在新的組件對象上完成方法調用。

如下圖所示：
http://comcamp.myrice.com/techarticles/images_1008/image1.jpg

注意：由上可見，客戶只有在調用了IObjectControl::Active之后，才標志真正得到了COM組
      件對象的指針，才能進行方法調用，在此之前都是假的。每次組件被激活都要重新得到
      IObjectContext指針，因為組件是從對象池取出來的，可能已經不是上一次用過的組件了。

其他：
1。 把組件加入到MTS時，可以選擇讓DLL在創建者進程中被激活。注意這個創建者進程不是指
　　遠程的客戶機程序，對WEB應用來說，MTS的客戶機是IIS。
2。 當調用一個軟件包里的某個組件時，這個軟件包內的所有DLL都將被加載。如果其中有個DLL
    加載失敗，則整個調用失敗。
3。 一個交給MTS管理的COM DLL可以只是個普通DLL，既它不繼承IObjectControl，在它的程序
    里也沒有利用IObjectContext，盡管它可以通過GetObjectContext()得到對象上下文。該
    組件仍然可以從MTS中獲得比如JIT(既時激活)的功能。
    而一個一開始就設計成MTS組件的DLL則會從IObjectControl繼承，并得到對象上下文指針，
    從而可以MTS的一些功能，比如事務管理等。
4。 一個MTS組件如果想能調試的話，需要把這個組件所在的軟件包的激活類型改為庫應用程序。
5。 MTS中的連接點問題。
    看看這樣的調用順序：
    a.創建組件
    b.Advise建立連接
    c.調用組件某個方法
    d.斷絕連接，釋放組件
    跟蹤發現，在調用Activate時連接點并未建立，而調用組件的方法一時連接點已經建立了。
    這說明了在真正調用組件的方法時組件才被創建，所以b沒有效果，所以當調用Activate時
    不能使用連接點。當調用Activate結束后，再真正的建立起連接關系。
    執行d釋放組件時，如果組件具有池特性的話，組件并沒有真的被釋放，而是放到了對象池中，
    下次再創建時就直接從池中取出。因為連接先于釋放斷掉，所以COM+調用Deactivate()時也不
    能再利用連接點了。
6。 COM+中每個軟件包都是個應用程序，都是一個進程。可以設置是否在空閑時也啟動服務器進程，
    或者閑置幾分鐘就關閉服務器進程。要注意的是，啟動一個服務器進程是非常慢的。可以在
    Component Service中改變應用程序的這一設置，觀察它的運行狀態，以及不斷的創建組件來
    體驗創建速度與服務器進程是否處于運行中的關系。可以發現，若服務器進程在運行，則創建
    非常快，否則很慢。

    MTS組件的用法與COM+中的相關部分幾乎是一樣的，也許有一些細節不同。有的書上說MTS2.0不
支持對象池特性，MTS組件只能是Aparment型的。我沒有試過，不過COM+中如果組件要支持對象池的
話，最好是	Free或Neutral型，因為可能會有不同線程類型的客戶來使用它，這樣效率較高。也有
的書上說必須不能是Aparment型，但我做的試驗似乎并非如此。另外組件的創建過程也不一樣，COM+
中重寫了COM基礎設施，包括CoCreateInstance。創建時COM+要先判斷組件是否在COM+目錄中注冊，
既是否在Component Service中加入到一個Application中。如果注冊了的話就啟動Dllhost.exe，并
在它里面創建組件。MTS顯然不會是這樣，估計是在組件的AppID中設置了代理為mts.exe，這才啟動
mts.exe作為代理。我覺得既然COM+已經出來了，MTS慢慢地也就要退出歷史舞臺了，所以一切都應以
COM+為準，MTS不管它也罷。

    [I]本文內容參考《微軟電子商務解決方案》一書[/I]