全面理解COM+

咱們從各類媒體對Windows 2000的介紹能夠看到，在Windows 2000衆多新的功能和特性之中，對於開發人員來講，COM+是最值得關注的一個焦點。在Windows 2000的Beta版本中，咱們已經看到了COM+的面貌，也感覺到了COM+將帶給咱們程序設計和開發過程當中思路上的變化。本文旨在從技術的角度對COM+做一個基本的介紹，以便開發人員更好地瞭解COM+。

COM+並非COM的新版本，咱們能夠把它理解爲COM的新發展，或者爲COM更高層次上的應用。COM+的底層結構仍然以COM爲基礎，它幾乎包容了COM的全部內容。有一種說法這樣認爲，COM+是COM、DCOM和MTS(Microsoft Transaction Server)的集成，這種說法有必定的道理，由於COM+確實綜合了這些技術要素。但更重要的一點是，COM+倡導了一種新的概念，它把COM組件軟件提高到應用層而再也不是底層的軟件結構，它經過操做系統的各類支持，使組件對象模型創建在應用層上，把全部組件的底層細節留給操做系統，所以，COM+與操做系統的結合更加緊密，這也是COM+非得等到Windows 2000發佈才能面世的主要緣由。

咱們知道，COM是個開放的組件標準，它有很強的擴充和擴展能力，從COM到DCOM，再到MTS的發展過程也充分說明了這一點。對COM有使用經驗的讀者必定能夠感受到，雖然COM已經改變了Windows程序員的應用開發模式，把組件的概念融入到Windows應用中，可是因爲種種緣由，DCOM和MTS的許多優越性尚未爲廣大的Windows程序員所認識。MTS針對企業應用和Web應用的特色，在COM/DCOM的基礎上又添加了許多功能和特性，包括事務特性、安全模型、管理和配置等，MTS使COM成爲一個完整的組件體系結構。因爲歷史的緣由，COM、DCOM和MTS相互之間並不很融洽，難以造成統一的總體，不過，這種情況很快就要結束，由於COM+將把這三者有效地統一塊兒來，造成一個全新的、功能強大的組件體系結構，而且把DCOM和MTS的各類優點以更爲簡捷的方式帶給Windows 2000程序員和用戶。

本文分四個部分，第一部分介紹COM+的基本結構；第二部分介紹COM+提供的一些系統服務；第三部分講述COM+應用開發模型；第四部分介紹COM+的特性並做簡要總結。經過閱讀這些內容，讀者能夠看到，COM+將帶給咱們一些什麼樣的程序設計概念，它和Windows 2000將如何改變咱們的應用，如何改變應用的開發模式。

一.COM+基本結構

COM+再也不侷限於COM的組件技術，它更加註重於分佈式網絡應用的設計和實現，已經成爲Microsoft系統平臺策略和軟件發展策略的一部分。COM+繼承了COM幾乎所有的優點，同時又避免了COM實現方面的一些不足。COM+牢牢地與操做系統結合起來，經過系統服務爲應用程序提供全面的服務，這一部分介紹COM+的基本結構。

1.Windows DNA策略

在介紹COM+結構以前，咱們首先看看Microsoft推出的Windows DNA(Distributed interNet Application Architecture)策略，由於COM+將在DNA策略中扮演重要的角色。Windows DNA是Microsoft多年積累下來的技術精華集合起來而造成一個完整的、多層結構的企業應用整體方案，它使Windows真正成爲企業應用平臺。

熟悉MTS的讀者必定知道，Microsoft在MTS的基礎上提出了多層軟件結構的概念。從大的方面來說，一個企業應用或者分佈式應用能夠分爲表現層、業務層和數據層。表現層爲應用的客戶端部分，它負責與用戶進行交互；業務層構成了應用的業務邏輯規則，它是應用的核心，一般由一些MTS組件構成；數據層爲後臺數據庫，它既能夠位於專用的數據服務器，也能夠與業務層在同一臺服務器上。MTS主要位於中間層，它爲業務組件提供了一個運行和管理的統一環境。圖1(a)顯示了這種多層結構的技術組成模型。

Windows DNA是一個簡化了的三層結構，如圖1(b)所示。

 

 

     (a) 三層結構技術組成模型               (b) Windows DNA結構

圖1

在現有的系統平臺以及軟件開發工具條件下，爲了實現多層結構的企業應用，咱們必須使用各類分離的技術，開發人員要學習每一種軟件技術，包括使用Win32 API以及系統提供的一些服務。圖1(a)列出了某些可能用到的軟件或者技術，學習這些知識自己就不是一件輕鬆的事情，更況且要開發出優秀的應用程序來。在Windows平臺上使用過這些技術的程序員必定深有體會。

圖1(b)則要簡明得多，這是一個還沒有實現的結構模型，可是Microsoft正在朝這個方向努力。在表現層，咱們如今開發應用程序，要麼使用Win32 API開發客戶應用，要麼利用HTML或DHTML直接把瀏覽器用做客戶應用。在DNA結構中，FORMS+還只是一個技術框架，它將把Win32 GUI和Web API結合起來，並朝着DHTML的方向發展，咱們能夠從已經發布的Microsoft Internet Explorer 5的結構模型中看到FORMS+的一些端倪。在數據層，STORAGE+還只是一種提法，不過Microsft已經把數據庫接口從ODBC轉移到ADO和OLE DB上，這將最終促進數據層接口技術的統一。

在中間業務層，COM+已經成爲現實，它以系統服務的形式把原先散落的衆多技術綜合起來，並提供簡單的編程模型，以直接應用層的編程接口爲應用程序提供服務。COM+是DNA結構的核心，它將成爲企業應用或者分佈式應用的基本工具。伴隨着Windows 2000的面世，DNA結構也將逐漸清晰，最終帶給咱們一個全新的應用軟件模型。

2.COM+基本結構

COM+的基本結構並不複雜，簡單提及來，它把COM和MTS的編程模型結合起來，同時又增長了一些新的特性。

 

從COM的發展角度來看，COM最初做爲桌面操做系統平臺上的組件技術，主要爲OLE服務。可是隨着Windows NT與DCOM的發佈，COM經過底層的遠程支持使組件技術延伸到了分佈式應用領域，充分體現了COM的擴展能力以及組件結構模型的優點。MTS爲COM增添了許多新的內容，彌補了COM和DCOM的一些不足，它注重於服務器一端的組件管理和配置環境。COM+進一步把COM、DCOM和MTS統一塊兒來，造成真正適合於企業應用的組件技術。COM、DCOM、MTS以及COM+的結構關係如圖2所示。

 

 

圖2 COM+組成結構圖

COM+不只繼承了COM、DCOM和MTS的許多特性，同時也新增了一些服務，好比負載平衡、內存數據庫、事件模型、隊列服務等。COM+新增的服務爲COM+應用提供了很強的功能，創建在COM+基礎上的應用程序能夠直接利用這些服務而得到良好的企業應用特性，本文第二部分將重點介紹這些服務。

COM+還提供了一個比MTS更好的組件管理環境，如圖3所示。COM+管理程序(COM+ Explorer)也採用了MMC(Microsoft Management Console)標準界面。對應於MTS中的包(Package)，COM+稱之爲COM+應用(COM+ Application)，每個COM+應用也包括一個或多個COM+組件以及與應用有關的角色信息。經過COM+管理程序，咱們能夠設置COM+應用和COM+組件的屬性信息，好比組件的事務特性、安全特性等等。如圖4所示。

 

 

圖3 COM+管理程序運行示意圖

 

 

圖4 COM+組件的屬性配置示意圖

咱們知道，COM和MTS把組件的全部配置信息都保存在Windows的系統註冊表中，然而，COM+的作法有所不一樣，它把大多數的組件信息保存在一個新的數據庫中，稱爲COM+目錄(COM+ Catalog)。COM+目錄把COM和MTS的註冊模型統一塊兒來，並提供了一個專門針對組件的管理環境。咱們既能夠經過COM+管理程序檢查或設置COM+目錄信息，也能夠在程序中經過COM+提供的一組COM接口訪問COM+目錄信息。

 

COM+一方面提供了許多新的服務和一個一致的管理環境，另外一方面它支持說明性編程模型(declarative programming model)，也就是說，開發人員能夠按儘量通用的方式開發組件程序，把一些細節留到配置時刻再肯定。舉例來講，咱們開發一個COM+組件，它支持負載平衡特性，可是咱們在開發組件的時候，並不肯定它是否使用負載平衡特性，而把是否支持負載平衡特性留待配置時刻再做決定。有的應用可能會須要負載平衡特性，而有的應用可能並不須要，咱們能夠經過COM+管理程序配置組件的屬性來決定組件是否支持負載平衡特性。MTS安全模型其實是一個典型的說明性編程技術，它把組件的安全角色信息留到配置時刻再給出確切的定義，而非編程時刻。COM+繼承了MTS的安全模型。

利用COM+的服務和管理工具，以及隨後發佈的一些開發工具，開發一個COM+組件要比開發一個COM組件容易得多，由於COM+組件其實是創建在COM+系統服務基礎上的應用程序，咱們能夠避免底層繁瑣的細節處理。經過COM+系統服務，咱們在得到可靠性的同時，也使咱們的組件或者應用程序更趨於標準化，在更普遍的範圍內體現組件或者應用的多態性。

3.對象環境

COM+組件的可管理性和可配置性是如何得到的呢？如同MTS組件同樣，COM+爲每個對象提供了一個對象環境(Object Context)，COM+系統能夠在建立COM+對象的時候爲其分配一個環境對象，這種技術也被稱爲截取(intercept)，下面的步驟能夠進一步說明截取的概念：

(1)    組件對象經過說明性屬性(declarative attributes)指定它的一些基本要求；

(2)    當客戶程序調用CoCreateInstance函數時，COM+系統檢查客戶代碼是否運行在與對象類兼容的對象環境中；

(3)若是客戶代碼的運行環境與對象類所要求的兼容，那麼沒必要使用截取技術，直接建立對象並返回對象的接口引用；

(4)    若是不兼容，那麼CoCreateInstance函數切換到一個與對象類兼容的環境中，而後建立對象並返回一個代理對象；

(5)在之後的接口方法調用過程當中，代理對象在調用前和調用後都要作一些處理以便方法的運行環境可以知足對象的要求。

COM+引入了環境(context)的概念，它是指共享同一套運行要求的對象集合。因爲不一樣的對象類可能使用了不一樣的配置信息，因此一個進程一般包含一個或多個環境，這些環境的配置互不兼容。全部無配置信息的對象都駐留在調用方的環境中。每個環境都有一個對象，即對象環境，運行在此環境中的對象可經過CoGetObjectContext API函數獲得此對象環境，利用對象環境的IObjectContextInfo接口能夠訪問到環境的屬性信息。

COM+的對象引用即客戶擁有的對象接口指針與環境相關，因此咱們不能簡單地把對象引用從一個環境傳遞到另外一個環境。當客戶從一個環境調用到另外一個環境中的對象時，中間必須通過代理對象和存根代碼，由代理對象截取調用，負責進行環境切換，這個過程相似於COM的跨進程列集(marshaling)處理。如圖5所示。

 

 

圖5 跨環境調用示意圖

從圖5咱們能夠看出，環境與COM線程模型中的套間(apartment)很是相似，當對象引用(即對象接口指針)從一個環境傳遞到另外一個環境時，它也要通過列集(marshaling)處理，即調用CoMarshalInterface和CoUnmarshalInterface函數。這樣才能保證客戶代碼和對象分別在本身的環境中執行，對於支持事務特性、安全特性或其餘特殊要求的應用，這是很重要的。

雖然跨環境的調用必須通過代理和存根代碼，可是這並不意味着須要通過線程切換，這是環境與套間的重要區別。在跨套間調用過程當中，影響性能的主要因素在於線程切換，而不是參數列集(marshaling)和散集(unmarshaling)處理，所以跨環境調用比跨套間調用的效率可能要高得多。COM+引入了環境概念，但套間的概念仍然存在，二者的區別在於，套間是線程模型的基本單元，而環境則是列集機制的基本邊界。環境和套間沒有包含關係，一個環境中的對象能夠運行在不一樣的套間，此時跨套間調用也必須通過代理對象；一個套間中的對象也能夠包含多個環境對象，此時跨環境調用也必須通過代理對象。

從以上對COM+的介紹咱們能夠看出，COM+的底層結構仍然以COM爲基礎，但在應用方式上則更多地繼承了MTS的處理機制，包括MTS的對象環境、安全模型、配置管理等。但COM+並非對COM和MTS進行簡單的封裝，它也引入了許多新的內容，正是這些新特徵使得COM+更加適合於企業應用的組件對象模型，這些新特徵經過一組系統服務來體現，下一部分介紹這些系統服務。

二.COM+系統服務介紹

COM+的系統服務充分體現了COM+的特徵，經過這些系統服務，咱們能夠很容易地開發出多層結構的應用系統，由於這些系統服務自己已經知足了多層應用的一些基本要求。COM+以系統服務的形式爲應用提供了許多新特性，這有多方面的好處，首先，客戶或者組件程序能夠直接利用這些系統服務，避免了底層的細節處理，減小開發成本，下降代碼量，同時也減少了犯錯誤的可能性；其次，有一些系統服務涉及到較複雜的邏輯，可能要訪問底層的系統資源，應用層很難實現這些系統服務；另外，使用系統服務可加強可靠性，由於這些系統服務已經通過嚴格的測試，應用系統要得到一樣的可靠性須要很昂貴的代價。

COM+的系統服務有的從MTS繼承過來，有的是新增長的。這一部分重點對新增的一些系統服務做初步的介紹，包括隊列組件、負載平衡、內存數據庫和事件服務，最後介紹其餘一些在MTS中已經引入的、但COM+又加強了的系統服務，包括事務、對象池、安全模型以及管理特性。

1.COM+隊列組件

咱們知道，COM客戶與遠程組件之間的交互是基於RPC鏈接的，客戶鏈接到一個組件對象，請求指定的接口，而後經過接口指針執行同步調用。雖然COM也容許異步調用，但客戶與組件的生存期必須保持一致，調用必須在鏈接有效期範圍內進行。

COM+除了支持這種基於RPC鏈接的運行方式，它還支持另外一種運行模式，咱們稱爲基於消息的通信過程，它能夠有效地把客戶與組件的生存期分離開。這種模式經過COM+的隊列組件服務實現，圖6是隊列組件的基本模型結構。

 

 

圖6 隊列組件模型結構圖

 

隊列組件並無使用直接的RPC鏈接，而是採用了底層的消息系統MSMQ(Microsft Message Queue Server)。經過底層的隊列機制，客戶與組件的生存週期能夠被分離在不一樣的時間點上。客戶程序再也不直接調用組件對象，它利用消息機制與組件對象進行通信，即便組件對象並無運行，客戶程序仍然能夠執行操做。

COM+應用能夠以透明方式支持同步和異步兩種調用方式，當客戶和組件程序創建了鏈接以後，客戶以同步方式直接調用組件的方法；若是客戶與組件沒有創建直接的鏈接，那麼客戶以異步方式與組件進行通信。若是組件對象被標識爲「隊列化」，那麼它支持隊列方式運行，因而一個被稱爲「COM+記錄器」的代理對象自動把全部該組件的調用請求記錄到一個永久隊列中，該隊列被保存在客戶機上；之後當客戶機鏈接到網絡上，位於服務器上的「COM+播放器」從永久隊列中得到調用信息，執行真正的調用操做。隊列組件以透明的方式把同步和異步兩種程序運行方式統一在一個單一的編程模型中，因此COM+應用系統爲得到異步特性並不須要做額外的工做。咱們仍然能夠按一般的方式開發組件和客戶程序，可是因爲隊列方式的特殊性，因此組件必須知足兩個限制條件：第一，組件的接口成員函數只能有輸入參數，不能包含輸出參數，這些輸入參數將被傳遞到MSMQ消息中；第二，組件接口成員函數的返回值HRESULT的含義不能與應用相關，它不標識與應用有關的信息。

在隊列組件的異步交互過程當中，客戶程序建立一個組件對象，它實際上建立了一個記錄器代理對象，全部的調用都經過記錄器進行，記錄器把調用請求記錄下來，而後經過MSMQ傳遞到服務器組件，服務器上的播放器再執行這些方法調用。使用這種異步方法的難點在於，客戶程序如何得到返回信息，這包含幾種可能狀況以及解決辦法：第一，客戶並不關心執行結果；第二，咱們能夠用響應隊列來實現客戶程序；第三，客戶也能夠把本身的一些特徵信息傳遞給組件對象，以便組件對象以一樣異步的方式通知客戶應用。選擇什麼樣的解決方法取決於應用的須要，咱們能夠靈活使用各類技術。

隊列組件對於分佈式應用很是有意義，尤爲是在慢速網絡上運行的應用系統，這種機制能夠保證應用系統可以可靠地運行。在應用系統包含大量客戶節點但服務器數量又比較少的狀況下，客戶應用程序能夠把它們的請求放到隊列中，當服務器負載比較輕的時候再處理這些請求，所以隊列機制也從另外一個角度實現了應用系統的負載平衡以及可伸縮特性。

2.COM+事件模型

COM不只定義了客戶調用組件對象的通信過程，它也定義了反向的通信過程，這就是COM可鏈接對象(connectable object)機制。組件對象定義了出接口(outgoing interface)的全部特徵，客戶程序實現出接口，當客戶程序與對象創建鏈接以後，客戶經過鏈接點對象創建它與客戶端接收器對象之間的反向鏈接。實際上，這時的鏈接點對象成了接收器對象的客戶方。

COM的可鏈接對象有很大的優點，它的擴展能力很是強，幾乎老是能夠知足應用的須要。可是從實際應用的狀況來看，它也存在一些缺點，表如今如下幾個方面：第一，事件源和客戶方牢牢綁定在一塊兒，雙方程序代碼依賴於出接口的定義，咱們必須在編譯時刻知道對方的信息；第二，源對象須要編寫大量代碼來支持這種機制，尤爲是爲了支持多通道事件；第三，鏈接點接口的設計模式並無考慮到分佈式環境的特色，因此它在分佈式環境下並不頗有效。

COM+事件模型改進了COM的可鏈接對象機制，它採用了多通道的發佈/訂閱(multicasting publish/subscribe)事件機制，它容許多個客戶去「訂閱」事件，這些事件由各類組件對象「發佈」。COM+事件服務維護一個事件數據庫，數據庫包含各類事件、發佈者、訂閱者以及全部的訂閱信息。當發佈者激發事件時，COM+事件服務對事件數據庫中有關的訂閱信息進行檢查，而後通知對應的訂閱者。COM+事件模型基本結構如圖7所示。

 

 

圖7 COM+事件模型結構圖

COM+事件模型經過事件類來傳遞源對象的出接口事件信息，以便它能夠與客戶方的入接口事件方法相匹配，這種方式與COM可鏈接對象機制很相似，因此老式的COM組件和客戶程序能夠很方便地使用新的COM+事件模型。

COM+事件模型用中心服務和中心管理的方式把發佈者與訂閱者之間的依賴關係分離開，它用事件類做爲發佈者和訂閱者之間的中間對象，發佈者必須經過事件類發佈信息。事件類是由COM+事件服務提供的對象，它實現了事件接口，因此對於發佈者來講，它扮演了訂閱者的角色。當發佈者要激發事件時，它建立一個事件類對象，調用相應的事件方法，而後釋放對象的接口。COM+事件服務會決定如何通知訂閱者，決定何時通知訂閱者。如同隊列組件情形同樣，發佈者和訂閱者的生存時間能夠被分離，從這個意義上講，全部事件接口函數只能包含輸入參數。

訂閱者訂閱事件也很方便，它只要經過COM+事件服務建立一個訂閱對象，並註冊到事件數據庫中，之後它就會接收到來自發布者的事件通知。

COM+事件系統不只僅爲應用程序提供事件服務，它也爲操做系統的內部實現提供事件服務，好比，它也用來實現Windows 2000的底層系統事件通知服務(SENS)，包括用戶登陸事件、網絡鏈接事件等等，咱們能夠建立和註冊一個訂閱對象來接收這些系統事件。這是COM+事件系統的一個應用，固然接收這種系統事件必須符合必定的安全策略。

3.負載平衡

負載平衡是分佈式應用的一種高層次需求，若是沒有很好的工具支持，那麼實現負載平衡須要付出很大的代價。咱們可使用DCOM和MTS的配置特性實現靜態負載平衡，可是要實現真正的動態負載平衡並不容易，咱們很難根據當前系統的負載狀態把對象建立請求傳遞到負載最輕的機器上，咱們必須編寫大量的代碼來間接支持這種特性。

COM+提供了一個負載平衡服務，它能夠以透明方式實現動態負載平衡。可是爲了使組件支持負載平衡，首先咱們必須定義一個應用羣集(application cluster)，應用羣集是指一組已經安裝了服務器端組件的機器(至多可達8臺機器)，而後咱們把一臺機器配置成負載平衡路由器(router)，負載平衡路由器會把對象的建立請求傳遞到應用羣集中的某一臺機器上。

COM+負載平衡以NT系統服務的形式運行在路由器機器上，當路由器的SCM(Service Control Manager)接收到遠程建立對象請求時，它把請求傳遞到負載最輕的機器上。實現負載平衡的一個難點是如何肯定應用羣集中的哪臺機器是負載最輕的。COM+負載平衡引擎使用缺省的負載平衡算法，它根據每臺機器上每一個對象實例的方法調用的響應時間做爲參考值計算出負載平衡參數，這種算法不必定是最佳算法，但對於大多數應用已經足夠了。COM+也容許應用程序使用自定義的負載平衡引擎。

COM+負載平衡應用模型中對象建立過程如圖8所示。

 

 

圖8 負載平衡模式下對象建立示意圖

 

客戶程序仍然能夠按一般的方式建立遠程對象，在CoCreateInstanceEx函數中指定路由器機器名，當建立成功以後，它獲得的對象實例運行在當前負載最輕的服務器上。路由器檢查COM+目錄，看請求建立的組件對象是否支持負載平衡，若是是，則它根據路由算法，把建立請求路由到負載最輕的服務器上。而後，應用羣集中的服務器接收到建立請求以後，它就建立對象，並把對象引用直接返回給客戶機。所以，一旦對象已經被成功建立，那麼客戶與對象之間的鏈接是直接進行的，而沒必要再經過路由器。

COM+應用程序的負載平衡特性並不須要編寫代碼來支持，客戶程序和組件程序均可以按一般的方式實現。所以，得到負載平衡特性不是一種程序設計和開發的行爲，而是一種配置行爲，經過配置實現分佈式應用程序的負載平衡。固然咱們在編寫負載平衡組件時，要避免使用與當前機器環境相關的信息，好比當前機器的名字或者依賴與本地機器上某個路徑下的某個文件，等等。

4.內存數據庫(IMDB)

COM+的內存數據庫(In Memory Database)服務是一個全新的服務，它用於保存應用的非永久狀態信息。咱們知道，對於以數據爲中心的應用軟件，爲了提升系統的運行效率，它應該儘量讓更多的數據駐留在內存中，尤爲是客戶程序頻繁訪問的數據信息。IMDB是一個駐留在內存中的支持事務特性的數據庫系統，它能夠爲COM+應用程序提供快速的數據訪問。

IMDB的基本功能在於優化數據查詢和數據獲取，它能夠裝載後臺數據庫系統中的數據表，也能夠裝載應用程序的非永久數據信息。使用IMDB的最典型的例子是Web應用，它把客戶頻繁訪問的數據信息放在IMDB中，以便成百上千的客戶獲得快速的響應。由於物理內存容量愈來愈大(在機器上安裝2GB物理內存已經成爲現實)，而且價格愈來愈便宜，因此經過IMDB，咱們只要增長物理內存就能夠提升系統的響應速度，並且把頻繁訪問的數據從數據層移到業務層能夠有效地減小網絡流量。圖9給出了基於IMDB的Web應用基本結構。

 

 

圖9 基於IMDB的Web應用結構示意圖

IMDB的接口爲OLE DB和ADO，因此組件對象能夠經過這些標準接口訪問IMDB。因爲IMDB是內存中的數據庫，因此IMDB只對本機器上的COM+組件有效，也就是說，IMDB不支持分佈式概念，而且多個IMDB機器不能裝入同一個數據表，若是多個組件要共享IMDB中的信息，那麼這些組件必須運行在同一臺機器上。

IMDB以NT系統服務的形式運行在服務器上，在服務啓動時，IMDB從後臺數據庫中把全部指定的數據表裝入到共享內存中。IMDB以整個數據表爲單位裝載數據，若是內存不夠，裝不下整個表，那麼IMDB會產生錯誤。組件對象經過進程內代理對象訪問IMDB中的數據表。由於IMDB爲了使數據訪問儘量快速，它並無實現SQL查詢處理器，因此咱們不能使用SQL命令訪問IMDB數據，只能經過標準的ISAM技術訪問IMDB數據，也就是說咱們必須經過索引訪問數據。

IMDB不只能夠把數據表緩衝起來，它也能夠管理應用系統的非永久狀態信息，若是運行在同一臺機器上的不一樣組件須要共享大量的信息，那麼選擇IMDB是一個理想的解決方案。

5.對其餘服務的加強

前面介紹的幾個系統服務是COM+針對分佈式應用新增長的服務，這些服務以及其餘一些原先在MTS中已經提供的服務合起來構成了COM+的底層服務體系。咱們知道，COM已經提供了組件對象與客戶程序之間的基本通信過程，包括對象建立、跨進程機制、接口管理等等，而COM+提供的底層服務則着眼於一些高層次的應用需求，特別是構建大型軟件系統或者分佈式軟件系統須要支持的一些特性。下面對COM+在MTS基礎上加強的一些服務做一簡要說明。

(1)    事務特性。

事務容許組件能夠把一組獨立的操做造成一個總體操做，事務操做要麼成功，要麼失敗。COM+仍然支持MTS的事務語義，經過SetAbort或SetComplete完成事務操做。COM+還支持其餘的事務操做模式，若是一個對象被標爲「AuotAbort」，那麼在事務操做過程當中，若發生異常，則系統自動調用SetAbort。一樣地，若是一個對象被標爲「AutoComplete」，那麼在每個方法調用以後，除非此方法顯式調用了SetAbort，不然系統會自動調用SetComplete。並且COM+還支持BYOT(Bring Your Own Transaction)，即容許COM+組件參與非MTS事務處理環境管理的事務。

(2)    安全性。

COM+的安全模型仍然沿用了MTS的基於角色的安全模型，根據用戶的角色訪問應用的有關功能模塊。這種安全模型須要開發人員與管理人員協同完成，在開發階段，開發人員負責定義各類角色，而且在實現組件功能時，只容許指定角色的用戶才能夠執行這些功能；在配置階段，管理員負責爲全部的角色指定有關的用戶賬號。COM+擴充了MTS安全模型，它容許開發人員和管理員指定到方法一級的安全控制，在MTS安全模型中，咱們只能在MTS包一級指定安全角色。經過COM+對象環境信息，COM+的安全模型更爲細緻，好比，它容許開發人員控制每個接口、或者每個方法如何扮演客戶，等等。

(3)    COM+對象池。

對象池是指把對象的實例保留在內存中，以便當客戶請求建立對象時能夠立刻用到這些對象。對象池如同IMDB同樣，徹底是出於效率考慮的緣由，用來創建大型的應用系統。對象池的概念在MTS 2.0中已經被引入了，由於MTS組件的IObjectControl接口的三個成員函數Activate、Deactivate和CanBePooled用於對象池的管理。可是MTS 2.0實際上並無支持對象池，也就是說，無論對象是否支持對象池緩存操做，它的IObjectControl::CanBePooled函數永遠不會被調用到。COM+繼承了MTS對象池的概念，而且真正實現了對象池的功能。

(4)    管理服務。

在本文第一部分咱們已經看到了COM+管理程序，它代替了MTS管理程序(MTS Explorer)和DCOM配置程序(DCOMCNFG.EXE)。對於多層結構應用，COM+管理程序是個不可缺乏的工具，應用系統的安全特性以及事務特性等基本配置都須要經過管理程序實現。因爲MMC界面操做簡單、直觀，因此管理員無須學習其餘的管理工具，就能夠配置全部的應用系統。並且COM+管理程序支持腳本語言，所以，開發人員和管理員能夠建立一些腳本代碼以便實現管理工做的自動化。COM+還引入了一個新的「ApplID」，它是一個128位GUID，標識一個與一組屬性值相聯繫的CLSID。經過「ApplID」，管理員能夠爲應用配置和維護多個版本。

這一部分重點討論了COM+的各個系統服務，尤爲是COM+新增長的幾個系統服務，這些系統服務使COM+更加適合於分佈式應用的開發。有些系統服務並不須要COM+應用經過編程來得到，好比負載平衡和隊列組件服務等；而有的服務則能夠簡化編程模型，好比事件服務；其餘有一些服務能夠用來提升系統的性能，好比內存數據庫、對象池等。

三.COM+應用開發

在介紹了COM+的基本概念以及系統服務以後，第三部分咱們討論COM+應用開發的一些問題。首先咱們討論從COM轉向COM+對於應用開發模式帶來的變化，而後介紹基於屬性的C++編程語言。

1.應用開發支持

COM規範的一個重要特徵是它定義的COM接口與開發語言無關，所以咱們能夠在各類開發語言中實現COM對象或者使用COM對象，事實也確實如此。可是，咱們能夠發現，雖然COM與C++的二進制結構最爲接近，但咱們在C++語言中實現COM對象並不輕鬆，編寫一個C++類與實現一個COM對象有很大的差異，即便使用了MFC或者ATL這樣的類庫或模板庫，咱們仍須要學習COM的一些底層知識，不然難以編寫出正確無誤的組件程序。

 

用過Visual Basic 6.0的讀者必定有這樣的體會，在VB6中編寫自動化(Automation)組件很是簡單，只要按常規的方法編寫「Class Module」便可實現COM組件。Vb6編譯器承擔了全部的底層細節處理任務，對於程序員而言只是一些「Class Module」。雖然這種開發模式限制了程序員的控制能力，但對於大多數狀況，VB6不失爲一個快速實現COM組件的開發環境。

COM+推出以後，它的開發模式也將有一些轉變，尤爲對於Visual C++程序員，在編譯時刻程序員能夠在代碼中使用一些說明性的語句來設置COM+組件的屬性，好比CLSID、ProgID、線程模型以及雙接口等，若是不指定這些屬性，編譯器將使用缺省值。之前咱們爲了使COM組件支持某些非缺省的特性，咱們必須經過編寫代碼來實現這些特性，因此程序員必定要對各類特性瞭解得很是清楚纔可以編寫出正確的代碼來，這也是實現COM組件的一個難點。COM+一方面與操做系統緊密結合，另外一方面從開發的角度來說，COM+將進一步與編譯器結合，它將擴展C++的一些語法，使得咱們能夠在代碼中描述COM+特性，而後由編譯器直接提供這些特性的支持，從而減小程序員的工做量，提升COM+組件的生產效率。

在代碼中利用說明性的語句指示編譯器產生與COM+組件有關的元數據(metadata)，COM+運行系統將利用這些元數據管理COM+組件。從某種意義上講，咱們能夠認爲元數據是一些類型庫信息，因此，實際上支持COM+組件的C++開發系統將把IDL/ODL的語法與C++語法結合起來。後面講到基於屬性的編程模型時咱們將會看到這種狀況。

全面支持COM+組件的開發工具要等到Windows 2000發佈以後，在Visual Studio的下一個版本中才可能實現。做爲一種兼容的方案，在如今的Visual C++版本中，編譯器仍然只支持原先的C++語法，當它在預處理過程當中，碰到說明性的描述信息時，它把這些屬性信息交給屬性分析器去處理，屬性分析器是一個編譯擴展模塊，它把屬性信息轉換成C++代碼，而後送回編譯器，編譯器再把這些源代碼編譯到目標代碼中。屬性分析器產生的其餘一些信息，好比類型信息，也被編入最終代碼。編譯器的結構如圖10所示。

 

 

圖10 COM+組件編譯過程示意圖

2.基於屬性的C++編程語言

基於屬性的編程模型將直接把COM+組件的屬性信息寫到C++源代碼中，指導編譯器產生COM+組件，這樣可使程序員沒必要編寫底層的處理代碼，由於這些代碼對於幾乎全部的組件都差很少，所以讓開發工具直接產生這些代碼可避免重複勞動。這種方式比MFC的宏以及ATL的模板類更爲直接。

屬性並無影響基本的C++語義，而且屬性的語法也比較簡單。屬性能夠用在任何說明性的語句前面，好比C++類的聲明、變量的聲明均可以在其前面用方括號指定其屬性。須要注意的是，一般咱們不在類型或者實例定義語句中指定屬性信息。下面的代碼說明了屬性的用法：

 

[
    uuid("346bf467-3467- d211-23c6-000000000000"),
    helpstring("IMyInterface Interface"),
]
interface IMyInterface : IUnknown
{
    HRESULT Func1 ( [in] long, [out,retval] long* );
    HRESULT Func2 ( [in] long, [out,retval] long* );
};
[
    coclass,
    progid("MyComp.MyObj.1"),
    uuid("346bf468-3467- d211-23c6-000000000000"),
    helpstring("MyObj Class")
]
class CMyObj : public IMyInterface
{
public:
    CMyObj ();
    //IMyInterface
public:
    HRESULT Func1 ( [in] long, [out,retval] long* );
    HRESULT Func2 ( [in] long, [out,retval] long* );
……
};

 

若是讀者熟悉IDL或者ODL語法，那麼對上面例子中的屬性描述必定很是清楚。Visual C++的屬性分析器分析屬性關鍵字，併產生相應的C++源代碼(其實是ATL代碼)。下表列出了屬性分析器支持的一些經常使用屬性關鍵字。

 

表1 經常使用屬性關鍵字列表

屬性關鍵字	說明
coclass	加入COM特性支持，產生相應的IDL文件。
dual	把一個接口標記爲雙接口，支持兩種訪問方式：vtable或者IDispatch。
emitidl	指示後續全部的屬性信息都被寫到IDL文件中。
id	指定自動化接口中方法的分發ID(DISPID)。
in/out	指定參數的傳遞方向。
progid	指定組件的ProgID。
retval	指示此參數爲方法的返回值。
threading	指定組件的線程模型。
uuid	指定類、類型庫或者接口的GUID標識。
module	指定組件程序的信息，包括程序類型、文件名、類型庫GUID、版本等信息。

 

基於屬性的編程模型爲Visual C++程序員開發COM+組件提供了捷徑，它避免了MFC繁雜的宏定義和ATL晦澀的模板類。屬性編程模型還包括其餘一些語義或語法，好比事件定義、對象構造等，咱們將能夠在新版本的Visual C++或者COM+ SDK中看到這些變化。

四.總結

雖然COM+仍然以COM和MTS爲底層基礎，可是因爲它定位的緣由，因此COM+新增長的內容較多。與COM相比較，COM+與Windows操做系統結合得更爲緊密，反過來，Windows操做系統也更加依賴於COM+；與MTS相比較，COM+更加適合於分佈式應用的開發，它提供了許多大型分佈式應用系統纔可能用到的一些功能。從目前計算機硬件以及Windows操做系統的發展趨勢來看，COM+有可能成爲推進Windows 2000操做系統的一個重要技術支柱，同時COM+和Windows 2000聯合起來使得企業應用直接進入分佈式應用領域，這是咱們目前已經能夠感受獲得的一個發展方向。

如下列出COM+的幾個主要特性：

(1)    真正的異步通信。COM+底層提供了隊列組件服務，這使客戶和組件有可能在不一樣的時間點上協同工做，COM+應用無須增長代碼就能夠得到這樣的特性。

(2)    事件服務。新的事件機制使事件源和事件接收方實現事件功能更加靈活，利用系統服務簡化了事件模型，避免了COM可鏈接對象機制的瑣碎細節。

(3)    可伸縮性。COM+的可伸縮性來源於多個方面，動態負載平衡以及內存數據庫、對象池等系統服務都爲COM+的可伸縮性提供了技術基礎，COM+的可伸縮性原理上與多層結構的可伸縮特性一致。

(4)    繼承並發展了MTS的特性。從COM到MTS是一個概念上的飛躍，但實現上還欠成熟，COM+則完善並實現了MTS的許多概念和特性。

(5)    可管理和可配置性。管理和配置是應用系統開發完成後的行爲，在軟件維護成本不斷增長的今天，COM+應用將有助於軟件廠商和用戶減小這方面的投入。

(6)    易於開發。COM+應用開發的複雜性和難易程度將決定COM+的成功與否，雖然COM+開發模型比之前的COM組件開發更爲簡化，但真正提升開發效率仍須要藉助於一些優秀的開發工具。

COM+標誌着Microsoft的組件技術達到了一個新的高度，它再也不侷限於一臺機器上的桌面系統，它把目標指向了更爲廣闊的企業內部網，甚至Internet國際互連網絡。COM+與多層結構模型以及Windows操做系統爲企業應用或Web應用提供了一套完整的解決方案。

本文寫在Windows 2000和COM+發佈以前，最終COM+的面貌和功能可能會有所取捨。因爲種種緣由，第二部分介紹的系統服務在最終發佈的Windows 2000中不必定所有實現，但之後的版本必定會逐步實現全部這些服務；第三部分介紹的開發方式可能在Microsoft的下一代開發工具中會有所改變，不過咱們能夠對這種開發模型有所認識，提早作好思想上的準備。