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的下一代開發工具中會有所改變，不過我們可以對這種開發模型有所認識，提前做好思想上的準備。
轉載于:https://www.cnblogs.com/syf/articles/931344.html
總結
- 上一篇： 在网上常听到说CEO CTO CIO C
- 下一篇： 多路隔离输出的车载辅助电源设计