COM+(转载)
我們從各種媒體對Windows 2000的介紹可以看到,在Windows 2000眾多新的功能和特性之中,對于開發(fā)人員來說,COM+是最值得關(guān)注的一個(gè)焦點(diǎn)。在Windows 2000的Beta版本中,我們已經(jīng)看到了COM+的面貌,也感受到了COM+將帶給我們程序設(shè)計(jì)和開發(fā)過程中思路上的變化。本文旨在從技術(shù)的角度對COM+作一個(gè)基本的介紹,以便開發(fā)人員更好地了解COM+。
COM+并不是COM的新版本,我們可以把它理解為COM的新發(fā)展,或者為COM更高層次上的應(yīng)用。COM+的底層結(jié)構(gòu)仍然以COM為基礎(chǔ),它幾乎包容了COM的所有內(nèi)容。有一種說法這樣認(rèn)為,COM+是COM、DCOM和MTS(Microsoft Transaction Server)的集成,這種說法有一定的道理,因?yàn)?/span>COM+確實(shí)綜合了這些技術(shù)要素。但更重要的一點(diǎn)是,COM+倡導(dǎo)了一種新的概念,它把COM組件軟件提升到應(yīng)用層而不再是底層的軟件結(jié)構(gòu),它通過操作系統(tǒng)的各種支持,使組件對象模型建立在應(yīng)用層上,把所有組件的底層細(xì)節(jié)留給操作系統(tǒng),因此,COM+與操作系統(tǒng)的結(jié)合更加緊密,這也是COM+非得等到Windows 2000發(fā)布才能面世的主要原因。
我們知道,COM是個(gè)開放的組件標(biāo)準(zhǔn),它有很強(qiáng)的擴(kuò)充和擴(kuò)展能力,從COM到DCOM,再到MTS的發(fā)展過程也充分說明了這一點(diǎn)。對COM有使用經(jīng)驗(yàn)的讀者一定可以感覺到,雖然COM已經(jīng)改變了Windows程序員的應(yīng)用開發(fā)模式,把組件的概念融入到Windows應(yīng)用中,但是由于種種原因,DCOM和MTS的許多優(yōu)越性還沒有為廣大的Windows程序員所認(rèn)識。MTS針對企業(yè)應(yīng)用和Web應(yīng)用的特點(diǎn),在COM/DCOM的基礎(chǔ)上又添加了許多功能和特性,包括事務(wù)特性、安全模型、管理和配置等,MTS使COM成為一個(gè)完整的組件體系結(jié)構(gòu)。由于歷史的原因,COM、DCOM和MTS相互之間并不很融洽,難以形成統(tǒng)一的整體,不過,這種狀況很快就要結(jié)束,因?yàn)?/span>COM+將把這三者有效地統(tǒng)一起來,形成一個(gè)全新的、功能強(qiáng)大的組件體系結(jié)構(gòu),并且把DCOM和MTS的各種優(yōu)勢以更為簡捷的方式帶給Windows 2000程序員和用戶。
本文分四個(gè)部分,第一部分介紹COM+的基本結(jié)構(gòu);第二部分介紹COM+提供的一些系統(tǒng)服務(wù);第三部分講述COM+應(yīng)用開發(fā)模型;第四部分介紹COM+的特性并作簡要總結(jié)。通過閱讀這些內(nèi)容,讀者可以看到,COM+將帶給我們一些什么樣的程序設(shè)計(jì)概念,它和Windows 2000將如何改變我們的應(yīng)用,如何改變應(yīng)用的開發(fā)模式。
一.COM+基本結(jié)構(gòu)
COM+不再局限于COM的組件技術(shù),它更加注重于分布式網(wǎng)絡(luò)應(yīng)用的設(shè)計(jì)和實(shí)現(xiàn),已經(jīng)成為Microsoft系統(tǒng)平臺策略和軟件發(fā)展策略的一部分。COM+繼承了COM幾乎全部的優(yōu)勢,同時(shí)又避免了COM實(shí)現(xiàn)方面的一些不足。COM+緊緊地與操作系統(tǒng)結(jié)合起來,通過系統(tǒng)服務(wù)為應(yīng)用程序提供全面的服務(wù),這一部分介紹COM+的基本結(jié)構(gòu)。
1.Windows DNA策略
在介紹COM+結(jié)構(gòu)之前,我們首先看看Microsoft推出的Windows DNA(Distributed interNet Application Architecture)策略,因?yàn)?/span>COM+將在DNA策略中扮演重要的角色。Windows DNA是Microsoft多年積累下來的技術(shù)精華集合起來而形成一個(gè)完整的、多層結(jié)構(gòu)的企業(yè)應(yīng)用總體方案,它使Windows真正成為企業(yè)應(yīng)用平臺。
熟悉MTS的讀者一定知道,Microsoft在MTS的基礎(chǔ)上提出了多層軟件結(jié)構(gòu)的概念。從大的方面來講,一個(gè)企業(yè)應(yīng)用或者分布式應(yīng)用可以分為表現(xiàn)層、業(yè)務(wù)層和數(shù)據(jù)層。表現(xiàn)層為應(yīng)用的客戶端部分,它負(fù)責(zé)與用戶進(jìn)行交互;業(yè)務(wù)層構(gòu)成了應(yīng)用的業(yè)務(wù)邏輯規(guī)則,它是應(yīng)用的核心,通常由一些MTS組件構(gòu)成;數(shù)據(jù)層為后臺數(shù)據(jù)庫,它既可以位于專用的數(shù)據(jù)服務(wù)器,也可以與業(yè)務(wù)層在同一臺服務(wù)器上。MTS主要位于中間層,它為業(yè)務(wù)組件提供了一個(gè)運(yùn)行和管理的統(tǒng)一環(huán)境。圖1(a)顯示了這種多層結(jié)構(gòu)的技術(shù)組成模型。
Windows DNA是一個(gè)簡化了的三層結(jié)構(gòu),如圖1(b)所示。
? ???(a) 三層結(jié)構(gòu)技術(shù)組成模型 ??????????????(b) Windows DNA結(jié)構(gòu)
圖1
在現(xiàn)有的系統(tǒng)平臺以及軟件開發(fā)工具條件下,為了實(shí)現(xiàn)多層結(jié)構(gòu)的企業(yè)應(yīng)用,我們必須使用各種分離的技術(shù),開發(fā)人員要學(xué)習(xí)每一種軟件技術(shù),包括使用Win32 API以及系統(tǒng)提供的一些服務(wù)。圖1(a)列出了某些可能用到的軟件或者技術(shù),學(xué)習(xí)這些知識本身就不是一件輕松的事情,更何況要開發(fā)出優(yōu)秀的應(yīng)用程序來。在Windows平臺上使用過這些技術(shù)的程序員一定深有體會。
圖1(b)則要簡明得多,這是一個(gè)尚未實(shí)現(xiàn)的結(jié)構(gòu)模型,但是Microsoft正在朝這個(gè)方向努力。在表現(xiàn)層,我們現(xiàn)在開發(fā)應(yīng)用程序,要么使用Win32 API開發(fā)客戶應(yīng)用,要么利用HTML或DHTML直接把瀏覽器用作客戶應(yīng)用。在DNA結(jié)構(gòu)中,FORMS+還只是一個(gè)技術(shù)框架,它將把Win32 GUI和Web API結(jié)合起來,并朝著DHTML的方向發(fā)展,我們可以從已經(jīng)發(fā)布的Microsoft Internet Explorer 5的結(jié)構(gòu)模型中看到FORMS+的一些端倪。在數(shù)據(jù)層,STORAGE+還只是一種提法,不過Microsft已經(jīng)把數(shù)據(jù)庫接口從ODBC轉(zhuǎn)移到ADO和OLE DB上,這將最終促進(jìn)數(shù)據(jù)層接口技術(shù)的統(tǒng)一。
在中間業(yè)務(wù)層,COM+已經(jīng)成為現(xiàn)實(shí),它以系統(tǒng)服務(wù)的形式把原先散落的眾多技術(shù)綜合起來,并提供簡單的編程模型,以直接應(yīng)用層的編程接口為應(yīng)用程序提供服務(wù)。COM+是DNA結(jié)構(gòu)的核心,它將成為企業(yè)應(yīng)用或者分布式應(yīng)用的基本工具。伴隨著Windows 2000的面世,DNA結(jié)構(gòu)也將逐漸清晰,最終帶給我們一個(gè)全新的應(yīng)用軟件模型。
2.COM+基本結(jié)構(gòu)
COM+的基本結(jié)構(gòu)并不復(fù)雜,簡單說起來,它把COM和MTS的編程模型結(jié)合起來,同時(shí)又增加了一些新的特性。
從COM的發(fā)展角度來看,COM最初作為桌面操作系統(tǒng)平臺上的組件技術(shù),主要為OLE服務(wù)。但是隨著Windows NT與DCOM的發(fā)布,COM通過底層的遠(yuǎn)程支持使組件技術(shù)延伸到了分布式應(yīng)用領(lǐng)域,充分體現(xiàn)了COM的擴(kuò)展能力以及組件結(jié)構(gòu)模型的優(yōu)勢。MTS為COM增添了許多新的內(nèi)容,彌補(bǔ)了COM和DCOM的一些不足,它注重于服務(wù)器一端的組件管理和配置環(huán)境。COM+進(jìn)一步把COM、DCOM和MTS統(tǒng)一起來,形成真正適合于企業(yè)應(yīng)用的組件技術(shù)。COM、DCOM、MTS以及COM+的結(jié)構(gòu)關(guān)系如圖2所示。
圖2 COM+組成結(jié)構(gòu)圖
COM+不僅繼承了COM、DCOM和MTS的許多特性,同時(shí)也新增了一些服務(wù),比如負(fù)載平衡、內(nèi)存數(shù)據(jù)庫、事件模型、隊(duì)列服務(wù)等。COM+新增的服務(wù)為COM+應(yīng)用提供了很強(qiáng)的功能,建立在COM+基礎(chǔ)上的應(yīng)用程序可以直接利用這些服務(wù)而獲得良好的企業(yè)應(yīng)用特性,本文第二部分將重點(diǎn)介紹這些服務(wù)。
COM+還提供了一個(gè)比MTS更好的組件管理環(huán)境,如圖3所示。COM+管理程序(COM+ Explorer)也采用了MMC(Microsoft Management Console)標(biāo)準(zhǔn)界面。對應(yīng)于MTS中的包(Package),COM+稱之為COM+應(yīng)用(COM+ Application),每一個(gè)COM+應(yīng)用也包括一個(gè)或多個(gè)COM+組件以及與應(yīng)用有關(guān)的角色信息。通過COM+管理程序,我們可以設(shè)置COM+應(yīng)用和COM+組件的屬性信息,比如組件的事務(wù)特性、安全特性等等。如圖4所示。
圖3 COM+管理程序運(yùn)行示意圖
圖4 COM+組件的屬性配置示意圖
我們知道,COM和MTS把組件的所有配置信息都保存在Windows的系統(tǒng)注冊表中,然而,COM+的做法有所不同,它把大多數(shù)的組件信息保存在一個(gè)新的數(shù)據(jù)庫中,稱為COM+目錄(COM+ Catalog)。COM+目錄把COM和MTS的注冊模型統(tǒng)一起來,并提供了一個(gè)專門針對組件的管理環(huán)境。我們既可以通過COM+管理程序檢查或設(shè)置COM+目錄信息,也可以在程序中通過COM+提供的一組COM接口訪問COM+目錄信息。
COM+一方面提供了許多新的服務(wù)和一個(gè)一致的管理環(huán)境,另一方面它支持說明性編程模型(declarative programming model),也就是說,開發(fā)人員可以按盡可能通用的方式開發(fā)組件程序,把一些細(xì)節(jié)留到配置時(shí)刻再確定。舉例來說,我們開發(fā)一個(gè)COM+組件,它支持負(fù)載平衡特性,但是我們在開發(fā)組件的時(shí)候,并不確定它是否使用負(fù)載平衡特性,而把是否支持負(fù)載平衡特性留待配置時(shí)刻再作決定。有的應(yīng)用可能會需要負(fù)載平衡特性,而有的應(yīng)用可能并不需要,我們可以通過COM+管理程序配置組件的屬性來決定組件是否支持負(fù)載平衡特性。MTS安全模型實(shí)際上是一個(gè)典型的說明性編程技術(shù),它把組件的安全角色信息留到配置時(shí)刻再給出確切的定義,而非編程時(shí)刻。COM+繼承了MTS的安全模型。
利用COM+的服務(wù)和管理工具,以及隨后發(fā)布的一些開發(fā)工具,開發(fā)一個(gè)COM+組件要比開發(fā)一個(gè)COM組件容易得多,因?yàn)?/span>COM+組件實(shí)際上是建立在COM+系統(tǒng)服務(wù)基礎(chǔ)上的應(yīng)用程序,我們可以避免底層繁瑣的細(xì)節(jié)處理。通過COM+系統(tǒng)服務(wù),我們在獲得可靠性的同時(shí),也使我們的組件或者應(yīng)用程序更趨于標(biāo)準(zhǔn)化,在更廣泛的范圍內(nèi)體現(xiàn)組件或者應(yīng)用的多態(tài)性。
3.對象環(huán)境
COM+組件的可管理性和可配置性是如何獲得的呢?如同MTS組件一樣,COM+為每一個(gè)對象提供了一個(gè)對象環(huán)境(Object Context),COM+系統(tǒng)可以在創(chuàng)建COM+對象的時(shí)候?yàn)槠浞峙湟粋€(gè)環(huán)境對象,這種技術(shù)也被稱為截取(intercept),下面的步驟可以進(jìn)一步說明截取的概念:
(1)??? 組件對象通過說明性屬性(declarative attributes)指定它的一些基本要求;
(2)??? 當(dāng)客戶程序調(diào)用CoCreateInstance函數(shù)時(shí),COM+系統(tǒng)檢查客戶代碼是否運(yùn)行在與對象類兼容的對象環(huán)境中;
(3)如果客戶代碼的運(yùn)行環(huán)境與對象類所要求的兼容,那么不必使用截取技術(shù),直接創(chuàng)建對象并返回對象的接口引用;
(4)??? 如果不兼容,那么CoCreateInstance函數(shù)切換到一個(gè)與對象類兼容的環(huán)境中,然后創(chuàng)建對象并返回一個(gè)代理對象;
(5)在以后的接口方法調(diào)用過程中,代理對象在調(diào)用前和調(diào)用后都要做一些處理以便方法的運(yùn)行環(huán)境能夠滿足對象的要求。
COM+引入了環(huán)境(context)的概念,它是指共享同一套運(yùn)行要求的對象集合。由于不同的對象類可能使用了不同的配置信息,所以一個(gè)進(jìn)程通常包含一個(gè)或多個(gè)環(huán)境,這些環(huán)境的配置互不兼容。所有無配置信息的對象都駐留在調(diào)用方的環(huán)境中。每一個(gè)環(huán)境都有一個(gè)對象,即對象環(huán)境,運(yùn)行在此環(huán)境中的對象可通過CoGetObjectContext API函數(shù)得到此對象環(huán)境,利用對象環(huán)境的IObjectContextInfo接口可以訪問到環(huán)境的屬性信息。
COM+的對象引用即客戶擁有的對象接口指針與環(huán)境相關(guān),所以我們不能簡單地把對象引用從一個(gè)環(huán)境傳遞到另一個(gè)環(huán)境。當(dāng)客戶從一個(gè)環(huán)境調(diào)用到另一個(gè)環(huán)境中的對象時(shí),中間必須經(jīng)過代理對象和存根代碼,由代理對象截取調(diào)用,負(fù)責(zé)進(jìn)行環(huán)境切換,這個(gè)過程類似于COM的跨進(jìn)程列集(marshaling)處理。如圖5所示。
圖5 跨環(huán)境調(diào)用示意圖
從圖5我們可以看出,環(huán)境與COM線程模型中的套間(apartment)非常類似,當(dāng)對象引用(即對象接口指針)從一個(gè)環(huán)境傳遞到另一個(gè)環(huán)境時(shí),它也要經(jīng)過列集(marshaling)處理,即調(diào)用CoMarshalInterface和CoUnmarshalInterface函數(shù)。這樣才能保證客戶代碼和對象分別在自己的環(huán)境中執(zhí)行,對于支持事務(wù)特性、安全特性或其他特殊要求的應(yīng)用,這是很重要的。
雖然跨環(huán)境的調(diào)用必須經(jīng)過代理和存根代碼,但是這并不意味著需要經(jīng)過線程切換,這是環(huán)境與套間的重要區(qū)別。在跨套間調(diào)用過程中,影響性能的主要因素在于線程切換,而不是參數(shù)列集(marshaling)和散集(unmarshaling)處理,因此跨環(huán)境調(diào)用比跨套間調(diào)用的效率可能要高得多。COM+引入了環(huán)境概念,但套間的概念仍然存在,兩者的區(qū)別在于,套間是線程模型的基本單元,而環(huán)境則是列集機(jī)制的基本邊界。環(huán)境和套間沒有包含關(guān)系,一個(gè)環(huán)境中的對象可以運(yùn)行在不同的套間,此時(shí)跨套間調(diào)用也必須經(jīng)過代理對象;一個(gè)套間中的對象也可以包含多個(gè)環(huán)境對象,此時(shí)跨環(huán)境調(diào)用也必須經(jīng)過代理對象。
從以上對COM+的介紹我們可以看出,COM+的底層結(jié)構(gòu)仍然以COM為基礎(chǔ),但在應(yīng)用方式上則更多地繼承了MTS的處理機(jī)制,包括MTS的對象環(huán)境、安全模型、配置管理等。但COM+并不是對COM和MTS進(jìn)行簡單的封裝,它也引入了許多新的內(nèi)容,正是這些新特征使得COM+更加適合于企業(yè)應(yīng)用的組件對象模型,這些新特征通過一組系統(tǒng)服務(wù)來體現(xiàn),下一部分介紹這些系統(tǒng)服務(wù)。
二.COM+系統(tǒng)服務(wù)介紹
COM+的系統(tǒng)服務(wù)充分體現(xiàn)了COM+的特征,通過這些系統(tǒng)服務(wù),我們可以很容易地開發(fā)出多層結(jié)構(gòu)的應(yīng)用系統(tǒng),因?yàn)檫@些系統(tǒng)服務(wù)本身已經(jīng)滿足了多層應(yīng)用的一些基本要求。COM+以系統(tǒng)服務(wù)的形式為應(yīng)用提供了許多新特性,這有多方面的好處,首先,客戶或者組件程序可以直接利用這些系統(tǒng)服務(wù),避免了底層的細(xì)節(jié)處理,減少開發(fā)成本,降低代碼量,同時(shí)也減小了犯錯誤的可能性;其次,有一些系統(tǒng)服務(wù)涉及到較復(fù)雜的邏輯,可能要訪問底層的系統(tǒng)資源,應(yīng)用層很難實(shí)現(xiàn)這些系統(tǒng)服務(wù);另外,使用系統(tǒng)服務(wù)可增強(qiáng)可靠性,因?yàn)檫@些系統(tǒng)服務(wù)已經(jīng)經(jīng)過嚴(yán)格的測試,應(yīng)用系統(tǒng)要獲得同樣的可靠性需要很昂貴的代價(jià)。
COM+的系統(tǒng)服務(wù)有的從MTS繼承過來,有的是新增加的。這一部分重點(diǎn)對新增的一些系統(tǒng)服務(wù)作初步的介紹,包括隊(duì)列組件、負(fù)載平衡、內(nèi)存數(shù)據(jù)庫和事件服務(wù),最后介紹其他一些在MTS中已經(jīng)引入的、但COM+又增強(qiáng)了的系統(tǒng)服務(wù),包括事務(wù)、對象池、安全模型以及管理特性。
1.COM+隊(duì)列組件
我們知道,COM客戶與遠(yuǎn)程組件之間的交互是基于RPC連接的,客戶連接到一個(gè)組件對象,請求指定的接口,然后通過接口指針執(zhí)行同步調(diào)用。雖然COM也允許異步調(diào)用,但客戶與組件的生存期必須保持一致,調(diào)用必須在連接有效期范圍內(nèi)進(jìn)行。
COM+除了支持這種基于RPC連接的運(yùn)行方式,它還支持另一種運(yùn)行模式,我們稱為基于消息的通訊過程,它可以有效地把客戶與組件的生存期分離開。這種模式通過COM+的隊(duì)列組件服務(wù)實(shí)現(xiàn),圖6是隊(duì)列組件的基本模型結(jié)構(gòu)。
圖6 隊(duì)列組件模型結(jié)構(gòu)圖
隊(duì)列組件并沒有使用直接的RPC連接,而是采用了底層的消息系統(tǒng)MSMQ(Microsft Message Queue Server)。通過底層的隊(duì)列機(jī)制,客戶與組件的生存周期可以被分離在不同的時(shí)間點(diǎn)上。客戶程序不再直接調(diào)用組件對象,它利用消息機(jī)制與組件對象進(jìn)行通訊,即使組件對象并沒有運(yùn)行,客戶程序仍然可以執(zhí)行操作。
COM+應(yīng)用可以以透明方式支持同步和異步兩種調(diào)用方式,當(dāng)客戶和組件程序建立了連接之后,客戶以同步方式直接調(diào)用組件的方法;如果客戶與組件沒有建立直接的連接,那么客戶以異步方式與組件進(jìn)行通訊。如果組件對象被標(biāo)識為“隊(duì)列化”,那么它支持隊(duì)列方式運(yùn)行,于是一個(gè)被稱為“COM+記錄器”的代理對象自動把所有該組件的調(diào)用請求記錄到一個(gè)永久隊(duì)列中,該隊(duì)列被保存在客戶機(jī)上;以后當(dāng)客戶機(jī)連接到網(wǎng)絡(luò)上,位于服務(wù)器上的“COM+播放器”從永久隊(duì)列中獲得調(diào)用信息,執(zhí)行真正的調(diào)用操作。隊(duì)列組件以透明的方式把同步和異步兩種程序運(yùn)行方式統(tǒng)一在一個(gè)單一的編程模型中,所以COM+應(yīng)用系統(tǒng)為獲得異步特性并不需要作額外的工作。我們?nèi)匀豢梢园赐ǔ5姆绞介_發(fā)組件和客戶程序,但是由于隊(duì)列方式的特殊性,所以組件必須滿足兩個(gè)限制條件:第一,組件的接口成員函數(shù)只能有輸入?yún)?shù),不能包含輸出參數(shù),這些輸入?yún)?shù)將被傳遞到MSMQ消息中;第二,組件接口成員函數(shù)的返回值HRESULT的含義不能與應(yīng)用相關(guān),它不標(biāo)識與應(yīng)用有關(guān)的信息。
在隊(duì)列組件的異步交互過程中,客戶程序創(chuàng)建一個(gè)組件對象,它實(shí)際上創(chuàng)建了一個(gè)記錄器代理對象,所有的調(diào)用都通過記錄器進(jìn)行,記錄器把調(diào)用請求記錄下來,然后通過MSMQ傳遞到服務(wù)器組件,服務(wù)器上的播放器再執(zhí)行這些方法調(diào)用。使用這種異步方法的難點(diǎn)在于,客戶程序如何獲得返回信息,這包含幾種可能情況以及解決辦法:第一,客戶并不關(guān)心執(zhí)行結(jié)果;第二,我們可以用響應(yīng)隊(duì)列來實(shí)現(xiàn)客戶程序;第三,客戶也可以把自己的一些特征信息傳遞給組件對象,以便組件對象以同樣異步的方式通知客戶應(yīng)用。選擇什么樣的解決方法取決于應(yīng)用的需要,我們可以靈活使用各種技術(shù)。
隊(duì)列組件對于分布式應(yīng)用非常有意義,尤其是在慢速網(wǎng)絡(luò)上運(yùn)行的應(yīng)用系統(tǒng),這種機(jī)制可以保證應(yīng)用系統(tǒng)能夠可靠地運(yùn)行。在應(yīng)用系統(tǒng)包含大量客戶節(jié)點(diǎn)但服務(wù)器數(shù)量又比較少的情況下,客戶應(yīng)用程序可以把它們的請求放到隊(duì)列中,當(dāng)服務(wù)器負(fù)載比較輕的時(shí)候再處理這些請求,因此隊(duì)列機(jī)制也從另一個(gè)角度實(shí)現(xiàn)了應(yīng)用系統(tǒng)的負(fù)載平衡以及可伸縮特性。
2.COM+事件模型
COM不僅定義了客戶調(diào)用組件對象的通訊過程,它也定義了反向的通訊過程,這就是COM可連接對象(connectable object)機(jī)制。組件對象定義了出接口(outgoing interface)的所有特征,客戶程序?qū)崿F(xiàn)出接口,當(dāng)客戶程序與對象建立連接之后,客戶通過連接點(diǎn)對象建立它與客戶端接收器對象之間的反向連接。實(shí)際上,這時(shí)的連接點(diǎn)對象成了接收器對象的客戶方。
COM的可連接對象有很大的優(yōu)勢,它的擴(kuò)展能力非常強(qiáng),幾乎總是可以滿足應(yīng)用的需要。但是從實(shí)際應(yīng)用的情況來看,它也存在一些缺點(diǎn),表現(xiàn)在以下幾個(gè)方面:第一,事件源和客戶方緊緊綁定在一起,雙方程序代碼依賴于出接口的定義,我們必須在編譯時(shí)刻知道對方的信息;第二,源對象需要編寫大量代碼來支持這種機(jī)制,尤其是為了支持多通道事件;第三,連接點(diǎn)接口的設(shè)計(jì)模式并沒有考慮到分布式環(huán)境的特點(diǎn),所以它在分布式環(huán)境下并不很有效。
COM+事件模型改進(jìn)了COM的可連接對象機(jī)制,它采用了多通道的發(fā)布/訂閱(multicasting publish/subscribe)事件機(jī)制,它允許多個(gè)客戶去“訂閱”事件,這些事件由各種組件對象“發(fā)布”。COM+事件服務(wù)維護(hù)一個(gè)事件數(shù)據(jù)庫,數(shù)據(jù)庫包含各種事件、發(fā)布者、訂閱者以及所有的訂閱信息。當(dāng)發(fā)布者激發(fā)事件時(shí),COM+事件服務(wù)對事件數(shù)據(jù)庫中有關(guān)的訂閱信息進(jìn)行檢查,然后通知對應(yīng)的訂閱者。COM+事件模型基本結(jié)構(gòu)如圖7所示。
圖7 COM+事件模型結(jié)構(gòu)圖
COM+事件模型通過事件類來傳遞源對象的出接口事件信息,以便它可以與客戶方的入接口事件方法相匹配,這種方式與COM可連接對象機(jī)制很類似,所以老式的COM組件和客戶程序可以很方便地使用新的COM+事件模型。
COM+事件模型用中心服務(wù)和中心管理的方式把發(fā)布者與訂閱者之間的依賴關(guān)系分離開,它用事件類作為發(fā)布者和訂閱者之間的中間對象,發(fā)布者必須通過事件類發(fā)布信息。事件類是由COM+事件服務(wù)提供的對象,它實(shí)現(xiàn)了事件接口,所以對于發(fā)布者來說,它扮演了訂閱者的角色。當(dāng)發(fā)布者要激發(fā)事件時(shí),它創(chuàng)建一個(gè)事件類對象,調(diào)用相應(yīng)的事件方法,然后釋放對象的接口。COM+事件服務(wù)會決定如何通知訂閱者,決定什么時(shí)候通知訂閱者。如同隊(duì)列組件情形一樣,發(fā)布者和訂閱者的生存時(shí)間可以被分離,從這個(gè)意義上講,所有事件接口函數(shù)只能包含輸入?yún)?shù)。
訂閱者訂閱事件也很方便,它只要通過COM+事件服務(wù)創(chuàng)建一個(gè)訂閱對象,并注冊到事件數(shù)據(jù)庫中,以后它就會接收到來自發(fā)布者的事件通知。
COM+事件系統(tǒng)不僅僅為應(yīng)用程序提供事件服務(wù),它也為操作系統(tǒng)的內(nèi)部實(shí)現(xiàn)提供事件服務(wù),比如,它也用來實(shí)現(xiàn)Windows 2000的底層系統(tǒng)事件通知服務(wù)(SENS),包括用戶登錄事件、網(wǎng)絡(luò)連接事件等等,我們可以創(chuàng)建和注冊一個(gè)訂閱對象來接收這些系統(tǒng)事件。這是COM+事件系統(tǒng)的一個(gè)應(yīng)用,當(dāng)然接收這種系統(tǒng)事件必須符合一定的安全策略。
3.負(fù)載平衡
負(fù)載平衡是分布式應(yīng)用的一種高層次需求,如果沒有很好的工具支持,那么實(shí)現(xiàn)負(fù)載平衡需要付出很大的代價(jià)。我們可以使用DCOM和MTS的配置特性實(shí)現(xiàn)靜態(tài)負(fù)載平衡,但是要實(shí)現(xiàn)真正的動態(tài)負(fù)載平衡并不容易,我們很難根據(jù)當(dāng)前系統(tǒng)的負(fù)載狀態(tài)把對象創(chuàng)建請求傳遞到負(fù)載最輕的機(jī)器上,我們必須編寫大量的代碼來間接支持這種特性。
COM+提供了一個(gè)負(fù)載平衡服務(wù),它可以以透明方式實(shí)現(xiàn)動態(tài)負(fù)載平衡。但是為了使組件支持負(fù)載平衡,首先我們必須定義一個(gè)應(yīng)用群集(application cluster),應(yīng)用群集是指一組已經(jīng)安裝了服務(wù)器端組件的機(jī)器(至多可達(dá)8臺機(jī)器),然后我們把一臺機(jī)器配置成負(fù)載平衡路由器(router),負(fù)載平衡路由器會把對象的創(chuàng)建請求傳遞到應(yīng)用群集中的某一臺機(jī)器上。
COM+負(fù)載平衡以NT系統(tǒng)服務(wù)的形式運(yùn)行在路由器機(jī)器上,當(dāng)路由器的SCM(Service Control Manager)接收到遠(yuǎn)程創(chuàng)建對象請求時(shí),它把請求傳遞到負(fù)載最輕的機(jī)器上。實(shí)現(xiàn)負(fù)載平衡的一個(gè)難點(diǎn)是如何確定應(yīng)用群集中的哪臺機(jī)器是負(fù)載最輕的。COM+負(fù)載平衡引擎使用缺省的負(fù)載平衡算法,它根據(jù)每臺機(jī)器上每個(gè)對象實(shí)例的方法調(diào)用的響應(yīng)時(shí)間作為參考值計(jì)算出負(fù)載平衡參數(shù),這種算法不一定是最佳算法,但對于大多數(shù)應(yīng)用已經(jīng)足夠了。COM+也允許應(yīng)用程序使用自定義的負(fù)載平衡引擎。
COM+負(fù)載平衡應(yīng)用模型中對象創(chuàng)建過程如圖8所示。
圖8 負(fù)載平衡模式下對象創(chuàng)建示意圖
客戶程序仍然可以按通常的方式創(chuàng)建遠(yuǎn)程對象,在CoCreateInstanceEx函數(shù)中指定路由器機(jī)器名,當(dāng)創(chuàng)建成功之后,它得到的對象實(shí)例運(yùn)行在當(dāng)前負(fù)載最輕的服務(wù)器上。路由器檢查COM+目錄,看請求創(chuàng)建的組件對象是否支持負(fù)載平衡,如果是,則它根據(jù)路由算法,把創(chuàng)建請求路由到負(fù)載最輕的服務(wù)器上。然后,應(yīng)用群集中的服務(wù)器接收到創(chuàng)建請求之后,它就創(chuàng)建對象,并把對象引用直接返回給客戶機(jī)。因此,一旦對象已經(jīng)被成功創(chuàng)建,那么客戶與對象之間的連接是直接進(jìn)行的,而不必再通過路由器。
COM+應(yīng)用程序的負(fù)載平衡特性并不需要編寫代碼來支持,客戶程序和組件程序都可以按通常的方式實(shí)現(xiàn)。因此,獲得負(fù)載平衡特性不是一種程序設(shè)計(jì)和開發(fā)的行為,而是一種配置行為,通過配置實(shí)現(xiàn)分布式應(yīng)用程序的負(fù)載平衡。當(dāng)然我們在編寫負(fù)載平衡組件時(shí),要避免使用與當(dāng)前機(jī)器環(huán)境相關(guān)的信息,比如當(dāng)前機(jī)器的名字或者依賴與本地機(jī)器上某個(gè)路徑下的某個(gè)文件,等等。
4.內(nèi)存數(shù)據(jù)庫(IMDB)
COM+的內(nèi)存數(shù)據(jù)庫(In Memory Database)服務(wù)是一個(gè)全新的服務(wù),它用于保存應(yīng)用的非永久狀態(tài)信息。我們知道,對于以數(shù)據(jù)為中心的應(yīng)用軟件,為了提高系統(tǒng)的運(yùn)行效率,它應(yīng)該盡可能讓更多的數(shù)據(jù)駐留在內(nèi)存中,尤其是客戶程序頻繁訪問的數(shù)據(jù)信息。IMDB是一個(gè)駐留在內(nèi)存中的支持事務(wù)特性的數(shù)據(jù)庫系統(tǒng),它可以為COM+應(yīng)用程序提供快速的數(shù)據(jù)訪問。
IMDB的基本功能在于優(yōu)化數(shù)據(jù)查詢和數(shù)據(jù)獲取,它可以裝載后臺數(shù)據(jù)庫系統(tǒng)中的數(shù)據(jù)表,也可以裝載應(yīng)用程序的非永久數(shù)據(jù)信息。使用IMDB的最典型的例子是Web應(yīng)用,它把客戶頻繁訪問的數(shù)據(jù)信息放在IMDB中,以便成百上千的客戶得到快速的響應(yīng)。因?yàn)槲锢韮?nèi)存容量越來越大(在機(jī)器上安裝2GB物理內(nèi)存已經(jīng)成為現(xiàn)實(shí)),并且價(jià)格越來越便宜,所以通過IMDB,我們只要增加物理內(nèi)存就可以提高系統(tǒng)的響應(yīng)速度,而且把頻繁訪問的數(shù)據(jù)從數(shù)據(jù)層移到業(yè)務(wù)層可以有效地減少網(wǎng)絡(luò)流量。圖9給出了基于IMDB的Web應(yīng)用基本結(jié)構(gòu)。
圖9 基于IMDB的Web應(yīng)用結(jié)構(gòu)示意圖
IMDB的接口為OLE DB和ADO,所以組件對象可以通過這些標(biāo)準(zhǔn)接口訪問IMDB。由于IMDB是內(nèi)存中的數(shù)據(jù)庫,所以IMDB只對本機(jī)器上的COM+組件有效,也就是說,IMDB不支持分布式概念,并且多個(gè)IMDB機(jī)器不能裝入同一個(gè)數(shù)據(jù)表,如果多個(gè)組件要共享IMDB中的信息,那么這些組件必須運(yùn)行在同一臺機(jī)器上。
IMDB以NT系統(tǒng)服務(wù)的形式運(yùn)行在服務(wù)器上,在服務(wù)啟動時(shí),IMDB從后臺數(shù)據(jù)庫中把所有指定的數(shù)據(jù)表裝入到共享內(nèi)存中。IMDB以整個(gè)數(shù)據(jù)表為單位裝載數(shù)據(jù),如果內(nèi)存不夠,裝不下整個(gè)表,那么IMDB會產(chǎn)生錯誤。組件對象通過進(jìn)程內(nèi)代理對象訪問IMDB中的數(shù)據(jù)表。因?yàn)?/span>IMDB為了使數(shù)據(jù)訪問盡可能快速,它并沒有實(shí)現(xiàn)SQL查詢處理器,所以我們不能使用SQL命令訪問IMDB數(shù)據(jù),只能通過標(biāo)準(zhǔn)的ISAM技術(shù)訪問IMDB數(shù)據(jù),也就是說我們必須通過索引訪問數(shù)據(jù)。
IMDB不僅可以把數(shù)據(jù)表緩沖起來,它也可以管理應(yīng)用系統(tǒng)的非永久狀態(tài)信息,如果運(yùn)行在同一臺機(jī)器上的不同組件需要共享大量的信息,那么選擇IMDB是一個(gè)理想的解決方案。
5.對其他服務(wù)的增強(qiáng)
前面介紹的幾個(gè)系統(tǒng)服務(wù)是COM+針對分布式應(yīng)用新增加的服務(wù),這些服務(wù)以及其他一些原先在MTS中已經(jīng)提供的服務(wù)合起來構(gòu)成了COM+的底層服務(wù)體系。我們知道,COM已經(jīng)提供了組件對象與客戶程序之間的基本通訊過程,包括對象創(chuàng)建、跨進(jìn)程機(jī)制、接口管理等等,而COM+提供的底層服務(wù)則著眼于一些高層次的應(yīng)用需求,特別是構(gòu)建大型軟件系統(tǒng)或者分布式軟件系統(tǒng)需要支持的一些特性。下面對COM+在MTS基礎(chǔ)上增強(qiáng)的一些服務(wù)作一簡要說明。
(1)??? 事務(wù)特性。
事務(wù)允許組件可以把一組獨(dú)立的操作形成一個(gè)整體操作,事務(wù)操作要么成功,要么失敗。COM+仍然支持MTS的事務(wù)語義,通過SetAbort或SetComplete完成事務(wù)操作。COM+還支持其他的事務(wù)操作模式,如果一個(gè)對象被標(biāo)為“AuotAbort”,那么在事務(wù)操作過程中,若發(fā)生異常,則系統(tǒng)自動調(diào)用SetAbort。同樣地,如果一個(gè)對象被標(biāo)為“AutoComplete”,那么在每一個(gè)方法調(diào)用之后,除非此方法顯式調(diào)用了SetAbort,否則系統(tǒng)會自動調(diào)用SetComplete。而且COM+還支持BYOT(Bring Your Own Transaction),即允許COM+組件參與非MTS事務(wù)處理環(huán)境管理的事務(wù)。
(2)??? 安全性。
COM+的安全模型仍然沿用了MTS的基于角色的安全模型,根據(jù)用戶的角色訪問應(yīng)用的有關(guān)功能模塊。這種安全模型需要開發(fā)人員與管理人員協(xié)同完成,在開發(fā)階段,開發(fā)人員負(fù)責(zé)定義各種角色,并且在實(shí)現(xiàn)組件功能時(shí),只允許指定角色的用戶才可以執(zhí)行這些功能;在配置階段,管理員負(fù)責(zé)為所有的角色指定有關(guān)的用戶帳號。COM+擴(kuò)充了MTS安全模型,它允許開發(fā)人員和管理員指定到方法一級的安全控制,在MTS安全模型中,我們只能在MTS包一級指定安全角色。通過COM+對象環(huán)境信息,COM+的安全模型更為細(xì)致,比如,它允許開發(fā)人員控制每一個(gè)接口、或者每一個(gè)方法如何扮演客戶,等等。
(3)??? COM+對象池。
對象池是指把對象的實(shí)例保留在內(nèi)存中,以便當(dāng)客戶請求創(chuàng)建對象時(shí)可以馬上用到這些對象。對象池如同IMDB一樣,完全是出于效率考慮的原因,用來建立大型的應(yīng)用系統(tǒng)。對象池的概念在MTS 2.0中已經(jīng)被引入了,因?yàn)?/span>MTS組件的IObjectControl接口的三個(gè)成員函數(shù)Activate、Deactivate和CanBePooled用于對象池的管理。但是MTS 2.0實(shí)際上并沒有支持對象池,也就是說,不管對象是否支持對象池緩存操作,它的IObjectControl::CanBePooled函數(shù)永遠(yuǎn)不會被調(diào)用到。COM+繼承了MTS對象池的概念,并且真正實(shí)現(xiàn)了對象池的功能。
(4)??? 管理服務(wù)。
在本文第一部分我們已經(jīng)看到了COM+管理程序,它代替了MTS管理程序(MTS Explorer)和DCOM配置程序(DCOMCNFG.EXE)。對于多層結(jié)構(gòu)應(yīng)用,COM+管理程序是個(gè)不可缺少的工具,應(yīng)用系統(tǒng)的安全特性以及事務(wù)特性等基本配置都需要通過管理程序?qū)崿F(xiàn)。由于MMC界面操作簡單、直觀,所以管理員無須學(xué)習(xí)其他的管理工具,就可以配置所有的應(yīng)用系統(tǒng)。而且COM+管理程序支持腳本語言,因此,開發(fā)人員和管理員可以創(chuàng)建一些腳本代碼以便實(shí)現(xiàn)管理工作的自動化。COM+還引入了一個(gè)新的“ApplID”,它是一個(gè)128位GUID,標(biāo)識一個(gè)與一組屬性值相聯(lián)系的CLSID。通過“ApplID”,管理員可以為應(yīng)用配置和維護(hù)多個(gè)版本。
這一部分重點(diǎn)討論了COM+的各個(gè)系統(tǒng)服務(wù),尤其是COM+新增加的幾個(gè)系統(tǒng)服務(wù),這些系統(tǒng)服務(wù)使COM+更加適合于分布式應(yīng)用的開發(fā)。有些系統(tǒng)服務(wù)并不需要COM+應(yīng)用通過編程來獲得,比如負(fù)載平衡和隊(duì)列組件服務(wù)等;而有的服務(wù)則可以簡化編程模型,比如事件服務(wù);其他有一些服務(wù)可以用來提高系統(tǒng)的性能,比如內(nèi)存數(shù)據(jù)庫、對象池等。
三.COM+應(yīng)用開發(fā)
在介紹了COM+的基本概念以及系統(tǒng)服務(wù)之后,第三部分我們討論COM+應(yīng)用開發(fā)的一些問題。首先我們討論從COM轉(zhuǎn)向COM+對于應(yīng)用開發(fā)模式帶來的變化,然后介紹基于屬性的C++編程語言。
1.應(yīng)用開發(fā)支持
COM規(guī)范的一個(gè)重要特征是它定義的COM接口與開發(fā)語言無關(guān),因此我們可以在各種開發(fā)語言中實(shí)現(xiàn)COM對象或者使用COM對象,事實(shí)也確實(shí)如此。但是,我們可以發(fā)現(xiàn),雖然COM與C++的二進(jìn)制結(jié)構(gòu)最為接近,但我們在C++語言中實(shí)現(xiàn)COM對象并不輕松,編寫一個(gè)C++類與實(shí)現(xiàn)一個(gè)COM對象有很大的差別,即使使用了MFC或者ATL這樣的類庫或模板庫,我們?nèi)孕枰獙W(xué)習(xí)COM的一些底層知識,否則難以編寫出正確無誤的組件程序。
用過Visual Basic 6.0的讀者一定有這樣的體會,在VB6中編寫自動化(Automation)組件非常簡單,只要按常規(guī)的方法編寫“Class Module”即可實(shí)現(xiàn)COM組件。Vb6編譯器承擔(dān)了所有的底層細(xì)節(jié)處理任務(wù),對于程序員而言只是一些“Class Module”。雖然這種開發(fā)模式限制了程序員的控制能力,但對于大多數(shù)情況,VB6不失為一個(gè)快速實(shí)現(xiàn)COM組件的開發(fā)環(huán)境。
COM+推出之后,它的開發(fā)模式也將有一些轉(zhuǎn)變,尤其對于Visual C++程序員,在編譯時(shí)刻程序員可以在代碼中使用一些說明性的語句來設(shè)置COM+組件的屬性,比如CLSID、ProgID、線程模型以及雙接口等,如果不指定這些屬性,編譯器將使用缺省值。以前我們?yōu)榱耸?/span>COM組件支持某些非缺省的特性,我們必須通過編寫代碼來實(shí)現(xiàn)這些特性,所以程序員一定要對各種特性了解得非常清楚才能夠編寫出正確的代碼來,這也是實(shí)現(xiàn)COM組件的一個(gè)難點(diǎn)。COM+一方面與操作系統(tǒng)緊密結(jié)合,另一方面從開發(fā)的角度來講,COM+將進(jìn)一步與編譯器結(jié)合,它將擴(kuò)展C++的一些語法,使得我們可以在代碼中描述COM+特性,然后由編譯器直接提供這些特性的支持,從而減少程序員的工作量,提高COM+組件的生產(chǎn)效率。
在代碼中利用說明性的語句指示編譯器產(chǎn)生與COM+組件有關(guān)的元數(shù)據(jù)(metadata),COM+運(yùn)行系統(tǒng)將利用這些元數(shù)據(jù)管理COM+組件。從某種意義上講,我們可以認(rèn)為元數(shù)據(jù)是一些類型庫信息,所以,實(shí)際上支持COM+組件的C++開發(fā)系統(tǒng)將把IDL/ODL的語法與C++語法結(jié)合起來。后面講到基于屬性的編程模型時(shí)我們將會看到這種情況。
全面支持COM+組件的開發(fā)工具要等到Windows 2000發(fā)布之后,在Visual Studio的下一個(gè)版本中才可能實(shí)現(xiàn)。作為一種兼容的方案,在現(xiàn)在的Visual C++版本中,編譯器仍然只支持原先的C++語法,當(dāng)它在預(yù)處理過程中,碰到說明性的描述信息時(shí),它把這些屬性信息交給屬性分析器去處理,屬性分析器是一個(gè)編譯擴(kuò)展模塊,它把屬性信息轉(zhuǎn)換成C++代碼,然后送回編譯器,編譯器再把這些源代碼編譯到目標(biāo)代碼中。屬性分析器產(chǎn)生的其他一些信息,比如類型信息,也被編入最終代碼。編譯器的結(jié)構(gòu)如圖10所示。
圖10 COM+組件編譯過程示意圖
2.基于屬性的C++編程語言
基于屬性的編程模型將直接把COM+組件的屬性信息寫到C++源代碼中,指導(dǎo)編譯器產(chǎn)生COM+組件,這樣可以使程序員不必編寫底層的處理代碼,因?yàn)檫@些代碼對于幾乎所有的組件都差不多,因此讓開發(fā)工具直接產(chǎn)生這些代碼可避免重復(fù)勞動。這種方式比MFC的宏以及ATL的模板類更為直接。
屬性并沒有影響基本的C++語義,并且屬性的語法也比較簡單。屬性可以用在任何說明性的語句前面,比如C++類的聲明、變量的聲明都可以在其前面用方括號指定其屬性。需要注意的是,通常我們不在類型或者實(shí)例定義語句中指定屬性信息。下面的代碼說明了屬性的用法:
[????????????????
???????? ???????? 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++的屬性分析器分析屬性關(guān)鍵字,并產(chǎn)生相應(yīng)的C++源代碼(實(shí)際上是ATL代碼)。下表列出了屬性分析器支持的一些常用屬性關(guān)鍵字。
表1 常用屬性關(guān)鍵字列表
| 屬性關(guān)鍵字 | 說明 |
| coclass | 加入COM特性支持,產(chǎn)生相應(yīng)的IDL文件。 |
| dual | 把一個(gè)接口標(biāo)記為雙接口,支持兩種訪問方式:vtable或者IDispatch。 |
| emitidl | 指示后續(xù)所有的屬性信息都被寫到IDL文件中。 |
| id | 指定自動化接口中方法的分發(fā)ID(DISPID)。 |
| in/out | 指定參數(shù)的傳遞方向。 |
| progid | 指定組件的ProgID。 |
| retval | 指示此參數(shù)為方法的返回值。 |
| threading | 指定組件的線程模型。 |
| uuid | 指定類、類型庫或者接口的GUID標(biāo)識。 |
| module | 指定組件程序的信息,包括程序類型、文件名、類型庫GUID、版本等信息。 |
基于屬性的編程模型為Visual C++程序員開發(fā)COM+組件提供了捷徑,它避免了MFC繁雜的宏定義和ATL晦澀的模板類。屬性編程模型還包括其他一些語義或語法,比如事件定義、對象構(gòu)造等,我們將可以在新版本的Visual C++或者COM+ SDK中看到這些變化。
四.總結(jié)
雖然COM+仍然以COM和MTS為底層基礎(chǔ),但是由于它定位的原因,所以COM+新增加的內(nèi)容較多。與COM相比較,COM+與Windows操作系統(tǒng)結(jié)合得更為緊密,反過來,Windows操作系統(tǒng)也更加依賴于COM+;與MTS相比較,COM+更加適合于分布式應(yīng)用的開發(fā),它提供了許多大型分布式應(yīng)用系統(tǒng)才可能用到的一些功能。從目前計(jì)算機(jī)硬件以及Windows操作系統(tǒng)的發(fā)展趨勢來看,COM+有可能成為推動Windows 2000操作系統(tǒng)的一個(gè)重要技術(shù)支柱,同時(shí)COM+和Windows 2000聯(lián)合起來使得企業(yè)應(yīng)用直接進(jìn)入分布式應(yīng)用領(lǐng)域,這是我們目前已經(jīng)可以感覺得到的一個(gè)發(fā)展方向。
以下列出COM+的幾個(gè)主要特性:
(1)??? 真正的異步通訊。COM+底層提供了隊(duì)列組件服務(wù),這使客戶和組件有可能在不同的時(shí)間點(diǎn)上協(xié)同工作,COM+應(yīng)用無須增加代碼就可以獲得這樣的特性。
(2)??? 事件服務(wù)。新的事件機(jī)制使事件源和事件接收方實(shí)現(xiàn)事件功能更加靈活,利用系統(tǒng)服務(wù)簡化了事件模型,避免了COM可連接對象機(jī)制的瑣碎細(xì)節(jié)。
(3)??? 可伸縮性。COM+的可伸縮性來源于多個(gè)方面,動態(tài)負(fù)載平衡以及內(nèi)存數(shù)據(jù)庫、對象池等系統(tǒng)服務(wù)都為COM+的可伸縮性提供了技術(shù)基礎(chǔ),COM+的可伸縮性原理上與多層結(jié)構(gòu)的可伸縮特性一致。
(4)??? 繼承并發(fā)展了MTS的特性。從COM到MTS是一個(gè)概念上的飛躍,但實(shí)現(xiàn)上還欠成熟,COM+則完善并實(shí)現(xiàn)了MTS的許多概念和特性。
(5)??? 可管理和可配置性。管理和配置是應(yīng)用系統(tǒng)開發(fā)完成后的行為,在軟件維護(hù)成本不斷增加的今天,COM+應(yīng)用將有助于軟件廠商和用戶減少這方面的投入。
(6)??? 易于開發(fā)。COM+應(yīng)用開發(fā)的復(fù)雜性和難易程度將決定COM+的成功與否,雖然COM+開發(fā)模型比以前的COM組件開發(fā)更為簡化,但真正提高開發(fā)效率仍需要借助于一些優(yōu)秀的開發(fā)工具。
COM+標(biāo)志著Microsoft的組件技術(shù)達(dá)到了一個(gè)新的高度,它不再局限于一臺機(jī)器上的桌面系統(tǒng),它把目標(biāo)指向了更為廣闊的企業(yè)內(nèi)部網(wǎng),甚至Internet國際互連網(wǎng)絡(luò)。COM+與多層結(jié)構(gòu)模型以及Windows操作系統(tǒng)為企業(yè)應(yīng)用或Web應(yīng)用提供了一套完整的解決方案。
本文寫在Windows 2000和COM+發(fā)布之前,最終COM+的面貌和功能可能會有所取舍。由于種種原因,第二部分介紹的系統(tǒng)服務(wù)在最終發(fā)布的Windows 2000中不一定全部實(shí)現(xiàn),但以后的版本一定會逐步實(shí)現(xiàn)所有這些服務(wù);第三部分介紹的開發(fā)方式可能在Microsoft的下一代開發(fā)工具中會有所改變,不過我們可以對這種開發(fā)模型有所認(rèn)識,提前做好思想上的準(zhǔn)備。
轉(zhuǎn)載于:https://www.cnblogs.com/syf/articles/931344.html
總結(jié)
- 上一篇: 在网上常听到说CEO CTO CIO C
- 下一篇: 多路隔离输出的车载辅助电源设计