百科解釋
目錄·DCOM·使用·為什么要做分布式應用·靈活的配置·在應用間共享連接管理·安全性設置·Internet上的安全性·動態(tài)負載平衡 DCOM(分布式組件對象模型)是一系列微軟的概念和程序接口,利用這個接口,客戶端程序?qū)ο竽軌蛘埱髞碜跃W(wǎng)絡中另一臺計算機上的服務器程序?qū)ο。DCOM基于組件對象模型(COM),COM提供了一套允許同一臺計算機上的客戶端和服務器之間進行通信的接口(運行在Windows95或者其后的版本上)。 DCOM(分布式組件對象模型,分布式組件對象模式)是一系列微軟的概念和程序接口,利用這個接口,客戶端程序?qū)ο竽軌蛘埱髞碜跃W(wǎng)絡中另一臺計算機上的服務器程序?qū)ο蟆COM基于組件對象模型(COM),COM提供了一套允許同一臺計算機上的客戶端和服務器之間進行通信的接口(運行在Windows95或者其后的版本上)! 使用 Microsoft Distributed Component Object Model(DCOM)是Component Object Model(COM)的擴展,它支持不同的兩臺機器上的組件間的通信,而且不論它們是運行在局域網(wǎng)、廣域網(wǎng)、還是Internet上。借助DCOM你的應用程序?qū)⒛軌蛉我膺M行空間分布。 由于DCOM是COM這個組件技術的無縫升級,所以你能夠從你現(xiàn)有的有關COM得知識中獲益,你的以前在COM中開發(fā)的應用程序、組件、工具都可以移入分布式的環(huán)境中。DCOM將為你屏蔽底層網(wǎng)絡協(xié)議的細節(jié),你只需要集中精力于你的應用。 例如,你可以為一個網(wǎng)站創(chuàng)建應該頁面,其中包括了一段能夠在網(wǎng)絡中另一臺更加專業(yè)的服務器電腦上處理(在將它們發(fā)送到發(fā)出請求的用戶之前)的腳本或者程序。使用DCOM接口,網(wǎng)絡服務器站點程序(現(xiàn)在以客戶端對象方式發(fā)出動作)就能夠?qū)⒁粋遠程程序調(diào)用(RPC)發(fā)送到一個專門的服務器對象,它可以通過必要的處理,并給站點返回一個結果。結果將發(fā)送到網(wǎng)頁瀏覽器上! DCOM還可以工作在位于企業(yè)內(nèi)部或者除了公共因特網(wǎng)之外的其他網(wǎng)絡中。它使用TC/IP和超文本傳輸協(xié)議。DCOM是作為Windows操作系統(tǒng)中的一部分集成的。DCOM將很快在所有的主流UNIX平臺和IBM的大型服務器產(chǎn)品中出現(xiàn)。DCOM替代了OLE遠程自動控制! 在提供一系列分布式范圍方面,DCOM通常與通用對象請求代理體系結構(CORBA)相提并論。DCOM是微軟給程序和數(shù)據(jù)對象傳輸?shù)木W(wǎng)絡范圍的環(huán)境。CORBA則是在對象管理組織(OMG)的幫助下,由信息技術行業(yè)的其他商家提供贊助的。 DCOM概述 Microsoft的分布式COM(DCOM)擴展了組件對象模型技術(COM),使其能夠支持在局域網(wǎng)、廣域網(wǎng)甚至Internet上不同計算機的對象之間的通訊。使用DCOM,你的應用程序就可以在位置上達到分布性,從而滿足你的客戶和應用的需求。 因為DCOM是世界上領先的組件技術COM的無縫擴展,所以你可以將你現(xiàn)在對基于COM的應用、組件、工具以及知識轉(zhuǎn)移到標準化的分布式計算領域中來。當你在做分布式計算時,DCOM處理網(wǎng)絡協(xié)議的低層次的細節(jié)問題,從而使你能夠集中精力解決用戶所要求的問題。 為什么要做分布式應用 將應用分布化并不是問題的結束。分布式應用引入了一個全新的設計和擴展概念,它增加了軟件產(chǎn)品的復雜性,但是帶來了可觀的回報。某些應用本身就帶有分布性,例如多人對戰(zhàn)游戲、聊天程序以及遠程會議系統(tǒng)等等。因此,一種健壯的分布式計算框架所帶來的好處是不言自明的。很多其它的應用也是分布式的,即它至少有兩個組件運行在不同的計算機上,但是因為它不是為分布性應用而設計的,所以它們的規(guī)模和可擴展性就有很大的局限性。任何的工作流或群件應用程序,大多數(shù)的客戶機/服務器應用程序一些桌面辦公系統(tǒng)本質(zhì)上都控制著它們的用戶的通訊和協(xié)作。將這些系統(tǒng)作為分布式系統(tǒng)并能夠在正確的地方運行正確的組件會給用戶帶來好處,并且使人們對網(wǎng)絡和計算機資源的運用更加充滿信心。設計應用程序時考慮到分布性,能通過在客戶端運行組件使應用適用于具有不同性能的不同的客戶。 設計應用時考慮分布性能夠使系統(tǒng)在擴展上具有很高的靈活性。 分布式應用與它們的非分布式版本比起來具有更大的可擴展性。如果整個復雜應用的邏輯結構可以用一個簡單的模型來表示,那么僅僅只有一種方法來增加系統(tǒng)的工作效率:用更快的機器,而無需的應用本身進行調(diào)整。雖然現(xiàn)在的服務器和操作系統(tǒng)升級很快,但是買一個同樣性能的機器還是比將服務器的速度升級為原來的兩倍所花的錢少。有了一個設計適當?shù)姆植际綉孟到y(tǒng),一臺功能不怎么強大的服務器就能夠運行所有的組件。當負載增加時,可以將一些組件擴展到價格便宜的附加的機器上。 DCOM的結構 DCOM是組件對象模型(COM)的進一步擴展。COM定義了組件和它們的客戶之間互相作用的方式。它使得組件和客戶端無需任何中介組件就能相互聯(lián)系?蛻暨M程直接調(diào)用組件中的方法。圖1說明了組件對象模型的表示法: 圖1 同一進程中的COM組件http://hiphotos.baidu.com/sgsmyx/pic/item/a71579d3f31d8b093bf3cf6d.jpg 在現(xiàn)在的操作系統(tǒng)中,各進程之間是相互屏蔽的。當一個客戶進程需要和另一個進程中的組件通訊時,它不能直接調(diào)用該進程,而需要遵循操作系統(tǒng)對進程間通訊所做的規(guī)定。COM使得這種通訊能夠以一種完全透明的方式進行:它截取從客戶進程來的調(diào)用并將其傳送到另一進程中的組件。圖2表明了COM/DCOM運行庫是怎樣提供客戶進程和組件之間的聯(lián)系的。 圖2 不同進程中的COM組件http://hiphotos.baidu.com/sgsmyx/pic/item/87f1895c3d066e4afaf2c047.jpg 當客戶進程和組件位于不同的機器時,DCOM僅僅只是用網(wǎng)絡協(xié)議來代替本地進程之間的通訊。無論是客戶還是組件都不會知道連接它們的線路比以前長了許多。 圖3顯示了DCOM的整體結構:COM運行庫向客戶和組件提供了面向?qū)ο蟮姆⻊,并且使用RPC和安全機制產(chǎn)生符合DCOM線路協(xié)議標準的標準網(wǎng)絡包。 圖3 DCOM: 不同機器上的COM組件http://hiphotos.baidu.com/sgsmyx/pic/item/be0cde23a0e39c4dac34de47.jpg 組件和復用 大多數(shù)分布式應用都不是憑空產(chǎn)生的,F(xiàn)存的硬件結構、軟件、組件以及工具需要集成起來,以便減少開發(fā)和擴展時間以及費用。DCOM能夠直接且透明地改進現(xiàn)存的對COM組件和工具的投資。對各種各樣組件需求的巨大市場使得將標準化的解決方案集成到一個普通的應用系統(tǒng)中成為可能。許多熟悉COM的開發(fā)者能夠很輕易地將他們在COM方面的經(jīng)驗運用到基于DCOM的分布式應用中去。 任何為分布式應用開發(fā)的組件都有可能在將來被復用。圍繞組件模式來組織開發(fā)過程使得你能夠在原有工作的基礎上不斷的提高新系統(tǒng)的功能并減少開發(fā)時間。基于COM和DCOM的設計能使你的組件在現(xiàn)在和將來都能被很好到使用。 位置獨立性 當你開始在一個真正的網(wǎng)絡上設計一個分布式應用時,以下幾個相互沖突的設計問題會很清楚地反映出來: 相互作用頻繁的組件彼此間應該靠得更近些。 某些組件只能在特定的機器或位置上運行。 小組件增加了配置的靈活性,但它同時也增加了網(wǎng)絡的擁塞。 大組件減少了網(wǎng)絡的擁塞,但它同時也減少了配置的靈活性。 當你使用DCOM時,這些設計上的限制將很容易解決,因為配置的細節(jié)并不是在源碼中說明的。DCOM使得組件的位置對你來說完全透明,無論它是位于客戶的同一進程中或是在地球的另一端。在任何情況下,客戶連接組件和調(diào)用組件的方法的方式都是一樣的。DCOM不僅無需改變源碼,而且無需重新編譯程序。一個簡單的再配置動作就改變了組件組件之間相互連接的方式。 DCOM的位置獨立性極大地簡化了將應用組件分布化的任務,使其能夠達到最合適的執(zhí)行效果。例如,設想某個組件必需位于某臺特定的機器上或某個特定的位置,并且此應用有許多小組件,你可以通過將這些組件配置在同一個LAN上,或者同一臺機器上,甚至同一個進程中來減少網(wǎng)絡的負載。當應用是由比較少的大組件構成時,網(wǎng)絡負載并不是問題,此時你可以將組件放在速度快的機器上,而不用去管這些機器到底在哪兒。 圖4顯示了相同的“有效性檢查組件”在兩種不同情況下是如何分別配置的。一種情況是當“客戶”機和“中間層”機器之間的帶寬足夠大時,它是怎樣配置在客戶機上的;另一種情況是當客戶進程通過比較慢的網(wǎng)絡連接來訪問組件時,它又是怎樣配置在服務器上的。 圖4 位置獨立性http://hiphotos.baidu.com/sgsmyx/pic/item/1e7461dde7f241d08c102947.jpg 有了DCOM的位置獨立性,應用系統(tǒng)可以將互相關聯(lián)的組件放到靠地比較近的機器上,甚至可以將它們放到同一臺機器上或同一個進程中。即使是由大量的小組件來完成一個具有復雜邏輯結構的功能,它們之間仍然能夠有效到相互作用。當組件在客戶機上運行時,將用戶界面和有效性檢查放在客戶端或離客戶端比較近的機器上會更有意義;集中的數(shù)據(jù)庫事務應該將服務器靠近數(shù)據(jù)庫。 語言無關性 在設計和實現(xiàn)分布式應用系統(tǒng)時,一個普遍的問題就是為開發(fā)一個特定的組件而選擇語言以及工具的問題。語言選擇是一個典型的在開發(fā)費用、可得到的技術支持以及執(zhí)行性能之間的折衷。作為COM的擴展,DCOM DCO具有語言獨立性。任何語言都可以用來創(chuàng)建COM組件,并且這些組件可以使用更多的語言和工具。Java,Microsoft Visual C++,Microsoft Visual Basic,Delphi,PowerBuilder和Micro Focus COBOL都能夠和DCOM很好地相互作用。 因為DCOM具有語言獨立性,應用系統(tǒng)開發(fā)人員可以選擇他們最熟悉的語言和工具來進行開發(fā)。語言獨立性還使得一些原型組件開始時可以用諸如Visual Basic這樣的高級語言來開發(fā),而在以后用一種不同的語言,例如Visual C++和Java來重新實現(xiàn),而這種語言能夠更好地支持諸如DCOM的自由線程/多線程以及線程共用這些先進特性。 連接管理 網(wǎng)絡連接本身就比同一臺機器中的連接更脆弱。當一個客戶不再有效,特別是當出現(xiàn)網(wǎng)絡或硬件錯誤時,分布式應用中的組件需要被加以注意。 DCOM通過給每個組件保持一個索引計數(shù)來管理對組件的連接問題,這些組件有可能是僅僅只連到一個客戶上,也有可能被多個客戶所共享。當一個客戶和一個組件建立連接時,DCOM就增加此組件的索引計數(shù)。同理,當客戶釋放連接時,DCOM就減少此組件的索引計數(shù)。如果索引計數(shù)為零,組件就可以被釋放了。 DCOM使用有效的地址合法性檢查(pinging)協(xié)議來檢查客戶進程是否仍然是活躍的?蛻魴C周期性地發(fā)送消息,當經(jīng)過大于等于三次ping周期而組件沒有收到ping消息時,DCOM就認為這個連接中斷了。一旦連接中斷,DCOM就減少索引計數(shù),當索引計數(shù)為零時就釋放組件。從組件的這一點看來,無論是客戶進程自己中斷連接這種良性情況,還是網(wǎng)絡或者客戶機崩潰這種致命情況,都被同一種索引計數(shù)機制處理。 在很多種情況下,組件和它的客戶進程之間的信息流是沒有方向性的:組件需要在客戶端進行某些初始化操作,例如一個長進程的結束,用戶所觀看數(shù)據(jù)的更新,或者諸如電視以及多用戶游戲這些協(xié)作環(huán)境中的下一條信息等。許多協(xié)議使得完成這種對稱性的通訊十分困難。使用DCOM,任何組件都既可以使功能的提供者,有能是功能的使用者。通訊的兩個方向都用同一種機制來管理使得完成對等通訊和客戶機/服務器之間的相互作用一樣容易。 DCOM提供了一個對應用完全透明的分布式垃圾收集機制。DCOM是一個天生的對稱性網(wǎng)絡協(xié)議和編程模型。它不僅提供傳統(tǒng)的單向的客戶機-服務器之間的相互作用方式,還提供了客戶機和服務器以及對等進程之間的豐富的交談式的通訊方式。 可擴展性 分布式應用的一個重要因素是它的處理能力能夠隨著用戶的數(shù)量、數(shù)據(jù)量所需性能的提高而增加。當需求比較小時,應用系統(tǒng)就比較小而速度快,并且它要能夠在不犧牲性能和可靠性的前提下處理附加的需求。DCOM提供了許多特性來增強你的應用的可擴展性。 對稱的多進程處理(SMP) DCOM提高了Windows NT對于多進程處理的支持。對于使用自由線程模式的應用,DCOM使用一個線程隊列來處理新來的請求。在多處理器機上,線程隊列是由可利用的處理器的數(shù)量來決定的:太多的線程會導致經(jīng)常性的上下文切換,而太少的線程又會使處理器處于空閑狀態(tài)。DCOM只提供一個手工編碼的線程管理器,從而使開發(fā)者從線程的細節(jié)中解脫出來并獲得最好的性能。 DCOM通過使用Windows NT對于對稱性多進程處理的高級支持功能就能輕易地將應用從一個單處理機擴展到龐大的多處理機系統(tǒng)上去。 靈活的配置 當負載增加時,即使你的預算支持你買一臺最快的多處理機,它也有可能不能適應需求。DCOM的位置獨立性提供了一個簡單而便宜的方法來提高擴展性,那就是將分布性的組件放到其它的機器上。 對于無狀態(tài)或無需和其它組件共享狀態(tài)的組件來說,再配置是再容易不過的事了。對于這樣一些組件來說,可以在不同的機器上運行它們的多個復本。用戶負載可以被平等地分配到各個機器中去,甚至可以考慮到機器的處理能力以及當時負載這些因素來進行分配。使用DCOM,可以很容易地改變客戶進程同組件以及組件之間的連接方式。同一組件無需作別的改動甚至無需重新編譯就可以被動態(tài)地重新配置。所有必須做的工作只是更新登記、文件系統(tǒng)以及所涉及的組件所在的數(shù)據(jù)庫而已。 例子:一個組織在多個地方有辦工室,例如紐約、倫敦、舊金山和華盛頓等,它可以將組件安裝到服務器上。兩百個用戶同時在能達到預期的性能的前提下訪問五十個組件。當新的事務應用發(fā)送給用戶時,應用系統(tǒng)中同時在使用一些現(xiàn)存的以及新的組件,服務器的負載增長到六百個用戶,同時事務組件的數(shù)目增加到七十。有了這些附加的用戶和組件后,峰值時間的響應時間變得不能接受。管理員將其中的三十個組件單獨配置在另一臺服務器上,而將二十個組件單獨放在原來的服務器上,同時剩下的二十個組件同時在兩臺服務器上運行。 圖5 并行配置http://hiphotos.baidu.com/sgsmyx/pic/item/8bda6e3ff23046e555e72347.jpg 絕大多數(shù)現(xiàn)實的應用系統(tǒng)都有一個或多個涉及到大多數(shù)操作的關鍵性組件。這種組件有數(shù)據(jù)庫組件或者事務規(guī)則組件,它們必須被串行地執(zhí)行以保證“先來的先服務”這一策略被執(zhí)行。這些組件不能被復用,因為它們的唯一任務就是為應用系統(tǒng)的所有用戶提供一個單一的時間同步點。為了增強分步式應用系統(tǒng)的整體功能,必須將這些瓶頸組件放到一個專門的、功能強大的服務器上去。DCOM可以使你早在設計階段就將這些關鍵性組件分開,最初將多個組件放在一臺功能簡單的機器上,以后再把關鍵性的組件放到專門的機器上去。這一過程無需組件的再設計,甚至無需重新編譯。 圖6 關鍵性組件的分離http://hiphotos.baidu.com/sgsmyx/pic/item/209e99884f76ba9da5c2724a.jpg DCOM對于這些決定性的瓶頸組件的處理使得整個任務能夠迅速執(zhí)行。這些瓶頸組件往往是過程執(zhí)行序列的一部分,例如電子交易系統(tǒng)中的買賣命令,它們必須按照接收的順序執(zhí)行(先來的先被服務)。對于此問題的一個解決方法是將任務分成許多小的組件,并將這些組件配置到不同的機器上。這種效果類似于當今微處理器中的管道pipelining技術:第一個請求來了,第一個組件執(zhí)行(例如一致性檢查),然后將請求傳遞給下一個組件(例如,可能是更新數(shù)據(jù)庫)。一旦第一個組件將一條請求傳遞給下一個組件,它就準備執(zhí)行下一條請求。實際上有兩臺機器在并行的執(zhí)行多個請求,并且能夠保證按照請求來到的順序執(zhí)行。也可以在同一臺機器上使用DCOM來達到同樣的效果:多個組件在不同的線程或者不同的進程中執(zhí)行。這種方法在以后可以簡化擴展,我們可以將線程分布到一個帶多處理器的機器上,或者可以將進程配置到不同的機器上。 圖7 Pipelining http://hiphotos.baidu.com/sgsmyx/pic/item/298b00c2875cb83ce4dd3b47.jpg DCOM的位置獨立性編程模型使得隨著應用增加而改變配置設計變得容易了。最初,一個功能簡單的服務器就可以容納所有的組件。隨著需求的增加,其它的機器被添加進來,而組件能夠不做任何代碼上的改動就被分步到這些機器中去。 功能的發(fā)展:版本化 除了隨著用戶的數(shù)量以及事務的數(shù)量而擴展規(guī)模外,當新的特性加入時應用系統(tǒng)也需要擴展規(guī)模。隨著時間的推移,新的任務被添加進來,原有的任務被更新。傳統(tǒng)的做法是或者客戶進程和組件都需要同時被更新,或者舊的組件必須被保留直到所有的客戶進程被更新,當大量的地理上分布的站點和用戶在使用系統(tǒng)時,這就成為一個非常費力的管理問題。 DCOM為組件和客戶進程提供了靈活的擴展機制。使用COM和DCOM,客戶進程能夠動態(tài)地查詢組件的機能。一個COM組件不是將其機能表現(xiàn)為一個簡單、統(tǒng)一的方法和屬性組,而是對于不同的客戶進程表現(xiàn)為不同的形式。使用特定特性的客戶進程只需要訪問它所需要使用的方法和屬性。客戶進程也能夠同時使用一個組件的多個特性。當新的特性加入組件時,它不會影響不涉及這些特性的老的客戶進程。 用這種方法來組織組件,使得我們能夠有一種新的方法來發(fā)展組件功能:最初的組件表現(xiàn)為諸如COM界面的一套核心特性,這些特性是每個客戶進程都需要使用的。當組件需要新的特性時,大多數(shù)(甚至是全部)的界面仍然是必須的,我們根本無須更改原來的界面就可以將新的功能和屬性放到附加的界面中去。老的用戶進程就好像什么事也沒發(fā)生似的繼續(xù)訪問核心界面。新的客戶進程既可以測試新的界面是否存在以便能使用它,也可以仍然只使用原來的界面。 圖8 健壯的版本發(fā)展http://hiphotos.baidu.com/sgsmyx/pic/item/785b2a383997ac2a96ddd841.jpg 因為在DCOM編程模型中機能被分組放入界面中,你可以設計使用老的服務器程序的新的客戶程序,也可以設計使用老的客戶程序的新的服務器程序,或者將這些混合起來以便能夠適合你的需求和編程資源。使用傳統(tǒng)的對象模型時,那怕是對一個方法的細微改動都可能在根本上改變客戶和組件之間的協(xié)議。在一些模型中,可以將方法加到方法隊列的隊尾,但是卻不能在老的組件上測試新的方法。從網(wǎng)絡發(fā)展的前景看來,這些事情將會變得越來越復雜:編碼以及其它的一些功能典型地依賴于方法和參數(shù)的順序。增加或改動方法和參數(shù)也會顯著地改變網(wǎng)絡協(xié)議。DCOM為對象模式和網(wǎng)絡協(xié)議設計了一個簡單、優(yōu)雅和統(tǒng)一的方法來解決這些問題。 執(zhí)行性能 如果最初的執(zhí)行性能不能讓人滿意的話,可擴展性就不會帶來太多好處了。經(jīng)?紤]到更多更好的硬件會使得應用向下發(fā)展是非常有益的,但是這些需求是怎樣的呢?這些尖端擴展特性是否有用呢?是否對從COBOL到匯編這每一種語言的支持會危害到系統(tǒng)的執(zhí)行性能呢?使組件能夠在地球的另一面運行的能力是否妨礙了當它和客戶在同一個進程中時的執(zhí)行性能呢? 在COM和DCOM中,客戶并不能自己看到服務器,但是除非是在必要的情況下,否則客戶進程決不會被系統(tǒng)組件將自己同服務器分開。這種透明性是通過一個簡單的思想來實現(xiàn)的:客戶進程同組件交互的唯一方式就是通過方法調(diào)用?蛻暨M程從一個簡單的方法地址表(一個“vtable”)中得到這些方法的地址。當客戶進程想要調(diào)用一個組件中的某個方法時,它先得到方法的地址,然后調(diào)用它。在COM和DCOM模型中調(diào)用一個傳統(tǒng)的C或匯編函數(shù)的唯一開支就是對方法地址的簡單查詢。如果組件是和客戶運行在同一個線程中的過程中組件,那么無需調(diào)用任何COM或系統(tǒng)代碼就可以直接找到方法的地址,COM僅僅只定義了找到方法地址表的標準。 當用戶和組件不是那么靠近──在另一個線程中,在另一個程序中或者在地球另一面的一臺機器中時情況又是怎樣的呢?COM將它的遠程過程調(diào)用(RPC)框架代碼放到vtable中,然后將每個方法調(diào)用打包放到一個標準的緩沖器結構中,這個緩沖器結構將被發(fā)送給組件,組件打開包并且重新運行最初的方法調(diào)用。從這方面來說,COM提供了一個面向?qū)ο蟮腞PC機制。 這種RPC機制的速度有多快呢?下面是需要考慮的不同的性能尺度: 一個“空”方法調(diào)用有多快? “真正的”需要發(fā)送和接收數(shù)據(jù)的方法調(diào)用有多快? 在網(wǎng)絡上轉(zhuǎn)一圈有多快? 下表顯示了COM和DCOM的一些真實的執(zhí)行性能參數(shù),使我們能夠?qū)COM和其它的協(xié)議的相關的執(zhí)行性能有一定的了解。 http://hiphotos.baidu.com/sgsmyx/pic/item/a71579d3f37a8b093bf3cf4c.jpg 開始兩列表示一個“空”方法調(diào)用(發(fā)送和接收一個4字節(jié)長的整數(shù))。最后兩列可以認為是一個“真正的”COM方法調(diào)用(50字節(jié)長的參數(shù))。 此表顯示了進程中組件是怎樣得到零開支的執(zhí)行性能的(第一排和第二排)。 進程之間的方法調(diào)用(第三排和第四排)需要將參數(shù)存入緩沖器并將其發(fā)送給其它的進程。在一個標準的桌面辦公系統(tǒng)硬件中,每秒鐘大約可以執(zhí)行2000個方法調(diào)用,這可以滿足大多數(shù)的執(zhí)行性能需求。所有的本地調(diào)用是完全由處理器速度(一定程度上由存儲器容量)決定的,并且能夠很好地適用于多處理器型機器。 遠程調(diào)用(第五排和第六排)主要受限于網(wǎng)絡速度,同時可以看出DCOM的開支大約比TCP/IP多了35%(TCP/IP的循環(huán)時間是兩秒)。 微軟很快會提供許多平臺上的正式的DCOM性能參數(shù),它將顯示出DCOM與客戶數(shù)量以及服務器中處理器數(shù)量相關的擴展能力。 帶寬及潛在問題 分布式應用利用了網(wǎng)絡的優(yōu)點將組件結合到一起。理論上來說,DCOM將組件在不同的機器上運行這一事實隱藏起來。實際上,應用必須考慮到網(wǎng)絡連接帶來的兩個主要限制: 帶寬:傳遞給方法調(diào)用的參數(shù)的大小直接影響著完成方法調(diào)用的時間。 潛在問題:物理距離以及相關的網(wǎng)絡器件(例如路由器合傳輸線)甚至能使最小的數(shù)據(jù)包都被顯著地延遲。 DCOM怎樣幫助應用解決這些局限呢?DCOM自己將網(wǎng)絡循環(huán)時間最小化,使得避免網(wǎng)絡中潛在的擁塞成為可能。DCOM選擇了TCP/IP協(xié)議套件中的無連接UDP協(xié)議作為自己的傳輸協(xié)議。協(xié)議的無連接特性使得DCOM能夠?qū)⒃S多低級別的確認包和實際的數(shù)據(jù)以及地址合法性檢查(pinging)信息混合起來從而改善了性能。即使是運行在面向連接的協(xié)議上,DCOM也優(yōu)于傳統(tǒng)的面向特殊應用的協(xié)議。 在應用間共享連接管理 大多數(shù)的應用級別的協(xié)議需要某種從頭到尾地管理。當客戶機出現(xiàn)了嚴重的硬件故障或者客戶和組件之間的網(wǎng)絡連接中斷已經(jīng)操過一定時間時,應該及時通知組件。 解決這一問題的一個普遍方法是個一段時間(Pinging)發(fā)送保持活躍keep-alive消息。如果服務器在一定的時間間隔內(nèi)沒有收到一條ping消息,它就斷定客戶進程“死掉了”。 DCOM對每臺機器使用一個keep-alive消息。即使一臺客戶機使用了某一臺服務器上的100個組件,僅僅只要一條ping消息就能使所有這些客戶連接保持活躍狀態(tài)。為了將所有的ping消息組合起來,DCOM使用delta pinging機制來將這些ping消息的大小最小化。對于這100個連接,它并不是發(fā)送100個客戶標識符,而是創(chuàng)造了一個可變標識符來重復代表這100個引用。當引用集改變時,僅僅只是兩套引用的相交的部分被互相交換。最終,DCOM將所有ping消息轉(zhuǎn)化為正常消息。只有當對于服務器來說,某臺客戶機完全是空閑的時,它才定時發(fā)送ping消息(每隔兩分鐘一次)。 圖9 組合的生命期管理http://hiphotos.baidu.com/sgsmyx/pic/item/eb59fdb7ece231fd30add141.jpg COM允許多個應用(甚至來自不同的賣主)共享一個簡單而且優(yōu)化的生命期管理和網(wǎng)絡錯誤檢測協(xié)議,這樣可以顯著地減少帶寬。如果在一臺服務器上運行使用100個不同的傳統(tǒng)協(xié)議的100個不同的應用,對于每一個客戶連接上的每一個應用來說,服務器都要接收一條ping消息。只有這些協(xié)議當在它們的pinging策略上相互合作時,整個網(wǎng)絡的開銷才有可能減少。而DCOM在任意的基于DCOM的協(xié)議中自動地提供了這種協(xié)作。 優(yōu)化網(wǎng)絡的來回旋程 設計分布式應用的一個普遍問題是減少不同機器上組件之間在網(wǎng)絡上的過度的來回繞圈數(shù)。 在Internet上,每一次網(wǎng)絡繞圈就會引入1秒甚至更多的延遲。即使在速度快的局域網(wǎng)上,旋程時間也是以微秒來計算的──它超過了本地操作所需時間的量級。 減少網(wǎng)絡繞圈數(shù)的一個普遍的方法是將多個方法調(diào)用捆綁起來。DCOM將這種技術擴展使用,用來解決諸如連接一個對象或者創(chuàng)造一個對象查詢對象的機能的任務中。這種技術對于一般組件的不足之處是它在本地和遠程情況下的編程模型差別太大。 例子:一個數(shù)據(jù)庫組件提供了一個能夠分行或多行顯示結果的方法。在本地的情況下,開發(fā)者只需使用這個方法將結果一列一列地加入列表框即可。而在遠程的情況下,每列出一行就會引起一定的網(wǎng)絡旋程。使用批量方式的方法需要開發(fā)者分配一個能容納查詢出的所有列的緩沖器,然后在一次調(diào)用將其取回并將其一列一列地加入到列表框中。因為編程模型變化很大,開發(fā)者需要對設計作大的改動以便應用能夠在分布式環(huán)境中有效地工作。 DCOM使得組件開發(fā)者能夠輕易地執(zhí)行批量技術而無需客戶端也使用批量形式的API。DCOM的marshling機制使得組件可以將代碼加到客戶端,這叫作“代理對象”,它可以攔截多個方法調(diào)用并將其捆綁到一個遠程調(diào)用中去。 例子:因為應用系統(tǒng)的邏輯結構的需要(列表框API的要求),上面例子的開發(fā)者仍然需要一個一個地列舉方法。然而,為了列舉查詢結果的第一次調(diào)用應用中特殊的代理對象,它取得了所有列(或者一批列)并將其緩存到代理對象中。后來的調(diào)用就自接從這個緩存中發(fā)出,就避免了網(wǎng)絡旋程。開發(fā)者仍然使用一個簡單的編程模型,而整個應用卻得到了優(yōu)化。 圖10 組件模型:客戶端的緩存http://hiphotos.baidu.com/sgsmyx/pic/item/f9ede3af6d9d9ec57dd92a41.jpg DCOM同樣允許從一個組件到另一個組件的有效的指引。如果一個組件保存了到另一臺機器上的一個組件的索引,它可以將其傳遞給在第三方機器上運行的一個客戶進程(假設此客戶進程正在使用另一臺機器上運行的另一個組件)?蛻暨M程使用此索引就可以直接和第二個組件通訊。DCOM縮短了這種索引,并且使得第一個組件和機器可以完全從這個過程中脫離出來。這使得能夠提供索引的傳統(tǒng)的目錄服務適用于遠程組件的范圍。 例1:一個棋類應用系統(tǒng)能夠使正在等待對手的用戶將自己登錄到一個棋類目錄服務中。其它的用戶可以瀏覽并查詢正在等待對手的用戶的列表。當一個用戶選擇了自己的對手后,棋類目錄服務系統(tǒng)將對手的客戶組件索引返回給該用戶。DCOM自動連接兩個用戶,目錄服務系統(tǒng)無需涉及任何其它的事務處理過程。 例2:一個“經(jīng)紀人”組件監(jiān)控著運行著同一個組件的二十臺服務器,它監(jiān)測服務器的負載量和服務器的加入和刪除情況。當一個客戶需要使用該組件時,它連接到“經(jīng)紀人”組件,此組件返回負載最輕的服務器上的一個組件的索引。DCOM自動連接客戶和服務器,此時“經(jīng)紀人”組件和以后的過程就無關了。 圖11 索引指示http://hiphotos.baidu.com/sgsmyx/pic/item/b3327601687f85077aec2c41.jpg 如果需要的話,DCOM甚至允許將組件插入任意一個傳統(tǒng)的協(xié)議中,這個協(xié)議可以使用不在DCOM機能范圍內(nèi)的方法。組件可以使用傳統(tǒng)的配置方法將任意的代理對象放到客戶進程中,此進程能夠使用任何協(xié)議將信息傳回組件。 例1:一個服務器端組件可以使用一個ODBC連接來和一個SQL Server數(shù)據(jù)庫通訊。當客戶取得對象后,客戶機直接和SQL Server數(shù)據(jù)庫(使用ODBC)比使用DCOM和服務器通訊,同時服務器和SQL Server數(shù)據(jù)庫通訊更有效。在DCOM的傳統(tǒng)配置情況下,數(shù)據(jù)庫組件能夠?qū)⒆约簭椭频娇蛻魴C上,并將自己同SQL Server相連接,而此時客戶并沒有意識到自己已經(jīng)不再和服務器上的數(shù)據(jù)庫組件相連了,而是和該組件的一個本地復本連接這著。 例2:一個商業(yè)系統(tǒng)需要兩種通訊機制,一種是從客戶端到中央系統(tǒng)的一條安全而經(jīng)過鑒定的通道,它用來發(fā)出和撤消命令;另一種是一條分布式的通道,它用來將命令信息同時發(fā)送給連接在系統(tǒng)上的客戶。使用DCOM的安全而同步的連接方式可以簡單而有效地操作客戶機/服務器之間的通道,同時廣播通道需要一種更為尖端的機制,它使用多點廣播技術以便容納大量的偵聽者。DCOM允許將傳統(tǒng)的協(xié)議(“可靠的廣播協(xié)議”)無縫地插入到應用系統(tǒng)的體系結構中:一個數(shù)據(jù)接收端組件能夠?qū)⒋藚f(xié)議封裝起來,并使其對客戶和服務器完全透明。當用戶數(shù)量少安裝量小時,標準的DCOM點到點協(xié)議就足夠了;而對于有很多用戶的站點來說,就需要使用高級的廣播協(xié)議。DCOM將來會提供一個標準的多通道廣播傳輸協(xié)議,它能夠無縫地移植到應用系統(tǒng)中。 圖12 用custom協(xié)議代替DCOM http://hiphotos.baidu.com/sgsmyx/pic/item/2bfef3313b2009a15fdf0e41.jpg 安全性 使用網(wǎng)絡來將應用系統(tǒng)分布化是一個挑戰(zhàn),這不僅是因為帶寬的物理限制以及一些潛在的問題,而且也由于它產(chǎn)生一些諸如關系到客戶間、組件間以及客戶和組件之間的安全問題。因為現(xiàn)在的許多操作可以被網(wǎng)絡中的任何一個人訪問,所以對這些操作的訪問應該被限制在一個高級別上。 如果分布式開發(fā)平臺沒有提供安全支持,那么每一個分布式應用就必需完成自己的安全機制。一種典型的方法是用某種登錄的方法要求用戶通過用戶名及密碼的檢測,這些一般來說都是被加密了的。應用系統(tǒng)將通過用戶數(shù)據(jù)庫或者有關目錄來確認以上用戶身份,并返回動態(tài)的標識符以便用戶以后用來進行方法調(diào)用。以后每次涉及到調(diào)用有安全檢查的方法時,用戶都需要通過這種安全認證。每個應用系統(tǒng)都要存儲和管理許多用戶名和密碼,防止用戶進行未授權的訪問,管理密碼的改動以及處理在網(wǎng)絡上傳遞密碼而帶來的危險。 因此分布式平臺必需提供一個安全性框架來確切地區(qū)分不同的用戶或者不同組的用戶以便系統(tǒng)或應用有辦法知道誰將對某組件進行操作。DCOM使用了Windows NT提供的擴展的安全框架。Windows NT提供了一套穩(wěn)固的內(nèi)建式安全模塊,它用來提供從傳統(tǒng)的信用領域的安全模式到非集中管理模式的復雜的身份確認和鑒定機制,極大地擴展了公鑰式安全機制。安全性框架的中心部分是一個用戶目錄,它存儲著用來確認用戶憑據(jù)(用戶名、密碼、公鑰)的必要信息。大多數(shù)并非基于Windows NT平臺的系統(tǒng)提供了相似或相同的擴展機制,我們可以使用這種機制而不用管此平臺上用的是哪種安全模塊。大多數(shù)DCOM的UNIX版本提供了同Windows NT平臺相容的安全模塊。 安全性設置 DCOM無需在客戶端和組件上進行任何專門為安全性而做的編碼和設計工作就可以為分布式應用系統(tǒng)提供安全性保障。就象DCOM編程模型屏蔽了組件的位置一樣,它也屏蔽了組件的安全性需求。在無需考慮安全性的單機環(huán)境下工作的二進制代碼能夠在分布式環(huán)境下以一種安全的方式工作。 DCOM通過讓開發(fā)者和管理員為每個組件設置安全性環(huán)境而使安全性透明。就象Windows NT允許管理員為文件和目錄設置訪問控制列表(ACLs)一樣,DCOM將組件的訪問控制列表存儲起來。這些列表清楚地指出了哪些用戶或用戶組有權訪問某一類的組件。使用DCOM的設置工具(DCOMCNFG)或者在編程中使用Windows NT的registry以及Win32的安全函數(shù)可以很簡單地設置這些列表。 只要一個客戶進程調(diào)用一個方法或者創(chuàng)建某個組件的實例,DCOM就可以獲得使用當前進程(實際上是當前正在執(zhí)行的線程)的用戶的當前用戶名。Windows NT確保這個用戶的憑據(jù)是可靠的,然后DCOM將用戶名正在運行組件的機器或進程。然后組件上的DCOM用自己設置的鑒定機制再一次檢查用戶名,并在訪問控制列表中查找組件(實際上是查找包含此組件的進程中運行的第一個組件)。如果此列表中不包括此用戶(既不是直接在此表中又不是某用戶組的一員),DCOM就在組件被激活前拒絕此次調(diào)用。這種安全性機制對用戶和組件都完全是透明的,而且是高度優(yōu)化的。它基于Windows NT的安全框架,而此框架是Windows NT操作系統(tǒng)中最經(jīng)常被使用(也是最完美的。┑牟糠,對每一個對文件或者諸如一個事件或信號的同步線程的訪問都需要經(jīng)過相同的訪問檢查。Windows NT能夠和同類的操作系統(tǒng)以及網(wǎng)絡操作系統(tǒng)競爭并超過它們的事實可以顯示出這種安全性機制是多么有效。 圖13 安全性設置http://hiphotos.baidu.com/sgsmyx/pic/item/eb59fdb7ece031fd30add143.jpg DCOM提供了一個非常有效的缺省的安全性機制,它使開發(fā)員能夠在無需但心任何安全性問題的情況下開發(fā)出安全的分布式應用 對安全性的編程控制 對某些應用系統(tǒng)來說,僅僅是組件級的訪問控制列表是不夠的,因為一個組件中的某些方法是只能被特定的用戶訪問的。 例子:一個商務結算組件可以有一個方法用來登錄新事務,以及另一個方法用來獲得已經(jīng)存在的事務。僅僅只有財務組(“Accounting”用戶組)的成員才能夠添加新事務,同時僅僅只有高級管理人員(“Upper Management”用戶組)才能查看事務。 正如上一部分所說,應用系統(tǒng)能夠通過管理自己的用戶數(shù)據(jù)庫以及安全憑據(jù)來達到本身的安全。然而,在一個標準的安全框架下工作將會給最終用戶帶來更多的好處。沒有一個統(tǒng)一的安全性框架時,用戶需要為他們所使用的每一個應用記住和管理相應的登錄憑據(jù)。開發(fā)者為每一個組件靠慮到安全性問題。 DCOM通過加入Windows NT提供的非常靈活的安全性標準將安全性用戶化的要求簡化為對某些特定組件和應用的需求。 使用DCOM安全性標準的應用達到上面例子所要求的有所選擇安全性呢?當一個方法調(diào)用來到時,組件要求DCOM提供客戶的身份。然后根據(jù)其身份,被調(diào)用線程就僅僅執(zhí)行允許該客戶執(zhí)行的安全對象中的某些操作。接著組件就試著訪問諸如登錄字之類的安全對象,這些對象中有一個訪問控制列表ACL,如果訪問失敗,說明客戶不在ACL中,組件就拒絕方法調(diào)用。通過根據(jù)所調(diào)用的方法的不同而選擇的不同的登錄字,組件就能夠用一種非常簡單,但卻靈活而有效的方式提供有選擇的安全性。 圖14 使用登錄字的安全接口http://hiphotos.baidu.com/sgsmyx/pic/item/ce02c21046ab0408203f2e43.jpg 組件也能夠很輕易地得到客戶的用戶名并且利用它在自己的數(shù)據(jù)庫中查找有關的許可和策略。這一策略使用了Windows NT的安全性框架(密碼/公鑰,傳輸線上加過密的密碼等等)所提供的鑒定機制。應用系統(tǒng)無需為儲存密碼和其它有關的敏感信息擔心。新版本的Windows NT將提供一個擴展的目錄服務,它允許應用系統(tǒng)將用戶信息存儲到Windows NT的用戶數(shù)據(jù)庫中。 DCOM的做法更為靈活。組件能夠要求不同級別的加密以及不同級別的鑒定,同時可以在自己進行身份認證時阻止組件使用自己的憑據(jù)。 Internet上的安全性 設計在Internet上公作的應用系統(tǒng)時需要面對兩個主要問題。 即使是在最大的公司,在Internet上用戶的數(shù)量都會比原來提高好幾個數(shù)量級。 最終用戶希望對他們所使用的所有應用使用相同的公鑰或密碼,即使這些應用是由不同的公司所提供的。提供服務的公司不能在應用系統(tǒng)或安全性框架中儲存用戶的私人密碼。 DCOM的靈活的安全性結構怎樣幫助應用來解決這些問題呢?對于這一問題,DCOM使用了Windows NT的安全框架(參看安全性部分)。Windows NT的安全性體系結構提供了多個安全性模塊,其中包括: Windows NT NTLM鑒別協(xié)議,它在Windows NT 4.0以及以前版本的Windows NT中使用。 Kerveros Version 5鑒別協(xié)議,它在處理Windows NT中以及Windows NT間的訪問時代替NTLM成為最主要的安全性協(xié)議。 分布式密碼鑒定(DPA),諸如MSN和CompuServe這些最大的Internet成員組織中的某些公司所使用的共享的密碼鑒別協(xié)議。 安全性通道服務,它被用來完成Windows NT 4.0中的SSL/PCT協(xié)議。下一版本的Windows NT將加強對支持SSL 3.0客戶鑒定系統(tǒng)的公鑰協(xié)議的支持。 一個DCE提出的安全性模塊,它可以作為第三方工具加在Windows NT中。 所有這些模塊都是在標準Internet協(xié)議上工作的,都各有其優(yōu)缺點。NTLM安全性模塊以及在Windows NT 5.0中替帶它的基于Kerberos的模塊都是私人密鑰基礎協(xié)議。它們在集中式管理環(huán)境以及使用相互或者單方面信任關系的基于Windows NT服務器的局域網(wǎng)中是非常有效而安全的。對大多數(shù)UNIX系統(tǒng)來說,都可以使用NTLM來進行商業(yè)實現(xiàn)。(例如AT&T的“Unix系統(tǒng)的高級服務器(Advanced Server for Unix Systems)”)。 使用Windows NT 4.0的目錄服務,可以很好地擴展到大約100000個用戶。使用Windows NT 5.0的擴展目錄服務,一個Windows NT域控制器可以擴展到大約一億個用戶。通過將多個域控制器結合到Windows NT 5.0的目錄樹中,在一個域中所能支持的用戶實際上是無限的。 Windows NT 5.0的基于Kerberos的安全性模塊引入了例如在客戶進行身份認證時對組件行為的控制等更先進的安全性概念。它在執(zhí)行鑒別時比NTLM安全性提供模塊所占用的資源更少。 Windows NT 5.0還提供了基于安全性模塊的一個公共密鑰。這一模塊可以在基于Windows NT的應用以及基于DCOM的應用中將對于安全性憑據(jù)的管理分布化。使用公共密鑰進行身份鑒別不如使用私人密鑰有效,但是它允許在無需儲存客戶的私人憑據(jù)的情況下進行身份鑒別。 因為有如此多的互不相同的基本的安全性提供模塊(私人密鑰,公共密鑰)可以被使用,所以基于DCOM的分布式應用系統(tǒng)可以無需對其進行任何改動就能完成甚至更為先進,對安全性敏感的應用。Windows NT的安全性框架使得無需犧牲靈活性和執(zhí)行性能就能很容易地擴展應用并保證應用的安全性。 負載平衡 一個分布式應用系統(tǒng)越成功,由于用戶數(shù)量的增長而給應用系統(tǒng)中的所有組件帶來的負載就越高。一個經(jīng)常出現(xiàn)的情況是即使是最快的硬件的計算能力也無法滿足用戶的需求。 這一問題的一個無法必免的解決方案是將負載分布到多個服務器中去。在“可擴展性”部分簡要地提到了DCOM怎樣促進負載平衡的幾種不同的技術:并行配置,分離關鍵組件和連續(xù)進程的pipelining技術。 “負載平衡”是一個經(jīng)常被使用的名詞,它描敘了一整套相關技術。DCOM并沒有透明地提供各種意義上的負載平衡,但是它使得完成各種方式的負載平衡變得容易起來。 靜態(tài)負載平衡 解決負載平衡的一個方法是不斷地將某些用戶分配到運行同一應用的某些服務器上。因為這種分配不隨網(wǎng)絡狀況以及其它因素的變化而變化,所以這種方法稱為靜態(tài)負載平衡。 基于DCOM的應用可以很容易地通過改變登記入口將其配置到某些特定的服務器上運行。顧客登記工具可以使用Win32的遠程登記函數(shù)來改變每一個客戶的設置。在Windows NT 5.0中,DCOM可以使用擴展的目錄服務來完成對分布的類的儲存,這使得將這些配置改變集中化成為可能。 在Windows NT 4.0中,應用系統(tǒng)可以使用一些簡單的技術達到同樣的效果。一個基本的方法是將服務器的名字存到諸如數(shù)據(jù)庫和一個小文件這樣的眾所周知的集中環(huán)境中。當組件想要和服務器相連接時,它就能很輕易地獲得服務器的名字。對數(shù)據(jù)庫或文件內(nèi)容的改動也就同時改變了所有的用戶以及有關的用戶組。 一個靈活得多的方法使用了一個精致復雜的指示組件。這個組件駐留在一臺為大家所共知的服務器中。客戶組件首先和此組件連接,請求一個指向它所需服務的索引。指示組件能夠使用DCOM的安全性機制來對發(fā)出請求的用戶進行確認,并根據(jù)發(fā)出請求者的身份選擇服務器。指示組件并不直接返回服務器名,它實際上建立了一個到服務器的連接并將此連接直接傳遞給客戶。然后DCOM透明地將服務器和客戶連接起來,這時指示組件的工作就完成了。我們還可以通過在指示組件上建立一個顧客類代理店之類的東西而將以上機制對客戶完全屏蔽起來。 當用戶需求增加時,管理員可以通過改變組件而為不同的用戶透明地選擇不同的服務器。此時客戶組件沒有做任何改動,而應用可以從一個非集中式管理的模式變?yōu)橐粋集中式管理的模式。DCOM的位置獨立性以及它對有效的指示的支持使得這種設計的靈活性成為可能。 動態(tài)負載平衡 靜態(tài)負載平衡方法是解決不斷增長的用戶需求的一個好方法,但它需要管理員的介入,并且只有在負載可預測時才能很好地工作。 指示組件的思想能夠提供更加巧妙的負載平衡方法。指示組件不僅可以基于用戶ID來選擇服務器,它還可以利用有關服務器負載、客戶和可用服務器之間的網(wǎng)絡拓樸結構以及某個給定用戶過去需求量的統(tǒng)計數(shù)字來選擇服務器。每當一個客戶連接一個組件時,指示組件將其分配給當時最合適的可用的服務器。當然,從客戶的觀點看來,這一切都是透明發(fā)生的。這種方法叫做動態(tài)負載平衡法。 對某些應用來說,連接時的動態(tài)負載平衡法可能仍然是不充分的。客戶不能被長時間中斷,或者用戶之間的負載分布不均衡。DCOM本身并沒有提供對這種動態(tài)重連接以及動態(tài)的方法分布化的支持,因為這樣做需要對客戶進程和組件之間相互作用的情況非常熟悉才行,此時組件在方法激活過程中保留了一些客戶的特殊的狀態(tài)信息。如果此時DCOM突然將客戶和在另一臺機器上的另一個不同的組件再連接,那么這些信息就丟失了。 然而,DCOM使得應用系統(tǒng)的設計者能夠很容易地將這種邏輯結構清楚地引入到客戶和組件之間的協(xié)議中來?蛻艉徒M件能夠使用特殊的界面來決定什么時候一個連接可以被安全地經(jīng)過再尋徑接到另一臺服務器上而不丟失任何重要的狀態(tài)信息。從這一點看來,無論是客戶還是組件都可以在下一個方法激活前初始化一個到另一臺機器上的另一個組件的再連接。DCOM提供了用來完成這些附加的面向特殊應用的協(xié)議的所有的豐富的協(xié)議擴展機制。 DCOM結構也允許將面向特殊組件的代碼放到客戶進程中。無論什么時候客戶進程要激活一個方法時,由真實組件組件所提供的代理組件在客戶進程中截取這一調(diào)用,并能夠?qū)⑵湓賹降搅硪慌_服務器上。而客戶根本無需了解這一過程,DCOM提供了靈活的機制來透明的建立這些“分布式組件”。 有了以上獨特的特性,DCOM使得開發(fā)用來處理負載平衡和動態(tài)方法尋徑的一般底層結構成為可能。這種底層結構能夠定義一套標準界面,它可以用來在客戶進程和組件之間傳遞狀態(tài)信息的出現(xiàn)和消失情況。一旦組件位于客戶端的部分發(fā)現(xiàn)狀態(tài)信息消失,它就能動態(tài)地將客戶重連接到另一臺服務器上。 例子:微軟的事務服務器(以前叫做“Viper”)使用這一機制來擴展了DCOM編程模型。通過一套簡單的標準狀態(tài)信息管理界面,事務服務器能夠獲得必要的信息來提供高級別的負載平衡。在這種新的編程模型中,客戶和組件之間的相互作用被捆綁到事務中,它能夠指出什么時候一系列的方法調(diào)用所涉及的組件的狀態(tài)信息都是清楚的。 DCOM提供了一個用來完成動態(tài)負載平衡的強大的底層結構。簡單的指示組件在連接時可以用來透明地完成動態(tài)服務器分配工作。用來將單一的方法調(diào)用再尋徑到不同的服務器的更尖端的機制也能夠輕易地完成,但是它需要對客戶進程和組件之間的相互作用過程有更為深入的了解。微軟的完全基于DCOM建立的事務服務器(“Viper”)提供了一個標準的編程模型用來向事務服務器的底層結構傳遞面向這一附加的特殊應用的有關細節(jié)問題,它可以用來執(zhí)行非常高級的靜態(tài)和動態(tài)的重配置與負載平衡。 容錯性 容錯性對于需要高可靠性的面向關鍵任務的應用系統(tǒng)來說是非常重要的。對于錯誤的恢復能立通常是是通過一定量的硬件、操作系統(tǒng)以及應用系統(tǒng)的軟件機制來實現(xiàn)的。 DCOM在協(xié)議級提供了對容錯性的一般支持。前面的“應用系統(tǒng)間的共享式連接管理”部分所描敘的一種高級pinging機制能夠發(fā)現(xiàn)網(wǎng)絡以及客戶端的硬件錯誤。如果網(wǎng)絡能夠在要求的時間間隔內(nèi)恢復,DCOM就能自動地重新建立連接。 DCOM使實現(xiàn)容錯性變得容易起來。一種技術就是上一部分所說的指示組件的技術。當客戶進程發(fā)現(xiàn)一個組件出錯時,它重新連接到建立第一個連接的那個指示組件。指示組件內(nèi)有哪些服務器不再有效的消息,并能提供在另一臺機器上運行的這一組件的一個新的實例。當然,在這種情況下應用系統(tǒng)仍然需要在高級別上(一致性以及消息丟失問題等)處理錯誤的恢復問題。 因為DCOM可以將一個組件分別放到服務器方和客戶方,所以可以對用戶完全透明地實現(xiàn)組件的連接和重連接以及一致性問題。 例子:微軟的事務服務器(“Viper”)提供了一個在應用級處理一致性問題的一般性機制。將多個方法調(diào)用組合到一個原子事務中就能夠保證一致性,并使應用能夠很容易地避免信息的丟失。 圖15 用于容錯的分布式組件http://hiphotos.baidu.com/sgsmyx/pic/item/840a602ef67aa6594ec22643.jpg 另一技術經(jīng)常被稱為“熱備份”。同一服務器組件的兩個復本并行地在不同的機器上運行,它們處理相同的信息?蛻暨M程能夠明確地同時連接這兩臺機器。DCOM的“分布式組件”通過將處理容錯性的服務代碼放到客戶端使得以上過程對用戶應用完全透明。另一種方法是使用另一臺機器上運行的一個協(xié)作組件,由它代表客戶將客戶請求發(fā)送給那兩個服務器組件。 當錯誤發(fā)生時試圖將一個服務器組件轉(zhuǎn)移到另一臺機器上經(jīng)事實證明是失敗的。Windows NT組的最初版本使用了這一方法,當然它可以在應用級完成。DCOM的“分布式組件”使得完成這一機能更容易了,并且它對用戶隱蔽了實現(xiàn)細節(jié)。 DCOM使得完成高級的容錯技術變得更為容易。使用DCOM提供的部分在客戶進程中運行的分布式組件技術能夠使解決問題的細節(jié)對用戶透明。開發(fā)者無需改動客戶組件,甚至客戶機進行重新配置就能夠增強分布式應用系統(tǒng)的容錯性。 輕松配置 如果不容易安裝和管理的話,即使是最好的應用系統(tǒng)也是沒有用的。對于分布式應用來說,能夠集中管理和盡可能簡單的客戶安裝過程是非常關鍵的。同時,提供一些辦法使系統(tǒng)管理員能夠在潛在的錯誤造成任何損害之前盡可能早的發(fā)現(xiàn)它對于分布式應用也是非常必要的。 DCOM提供了什么技術能夠讓一個應用更加易于管理呢? 安裝 簡化客戶端安裝的一種普遍方法可以概括為一個詞“稀薄的客戶”,意思是駐留在客戶端的機能越少,安裝以及可能發(fā)生的維護問題也就越少。 然而,客戶組件越“稀薄”,整個應用的用戶友好度就越低,對網(wǎng)絡和服務器的需求也就越高。稀薄的客戶還不能充分利用當今桌面辦工系統(tǒng)所能得到的強大的計算能力,而由于諸如字處理軟件以及電子表格軟件這些桌面生產(chǎn)應用系統(tǒng)本身就具有統(tǒng)一而龐大的特性,所以大多數(shù)用戶對于這種系統(tǒng)的強大的計算能力的需求也不會減弱。因此在正確的級別實現(xiàn)“濃厚”對于分布式應用的設計來說是一個非常重要的決定。DCOM通過讓開發(fā)者甚至管理員來選擇每個組件的位置來促進配置的簡單性和靈活性之間的平衡。可以通過對配置的簡單改動使同一個事務組件(例如數(shù)據(jù)登錄檢查組件)分別在服務器和客戶端執(zhí)行。應用能夠動態(tài)地選擇所使用的用戶界面組件(服務器上的HTML產(chǎn)生器或者客戶端的ActiveX控件)。 保持“肥胖的”客戶的一個最大的問題是將這些客戶更新到最新版本的問題,F(xiàn)在通過對代碼下載的支持,微軟的Internet Explorer 3.0提供了解決這一問題的一個非常優(yōu)雅的辦法。只要用戶在瀏覽一頁頁面,微軟的Internet Explorer就會檢查頁面中所使用的ActiveX控件,并在必要時自動對其進行更新。應用也可以在不明確使用瀏覽器的時候使用這一被微軟直接支持的特性(ActiveX的CoCreateClassFromURL函數(shù))。 在Windows NT 5.0中,代碼下載的概念將被擴展到本地COM類庫中。這一類庫將使用擴展目錄來儲存組件的配置信息和到實際代碼的索引,它改變了當前使用的本地登記概念。這個類庫將向Intranet(擴展目錄)和Internet(代碼下載,Internet路徑搜索)提供代碼倉庫,并使它們對已存在的應用完全透明。 安裝和更新服務器組件通常不是一個嚴重的問題。然而,在一個高度分布化的應用中,同時更新所有的客戶一般來說是不太可能的。如第一部分中“功能的發(fā)展:版本化”部分所述的DCOM的健壯的版本化支持允許服務器在保持向后兼容的基礎上加入新的功能。服務器組件既可以處理舊客戶進程,又可以處理新客戶進程。一旦所有的客戶都被更新,組件就可以停止對新客戶所不需要的功能的支持。 使用代碼下載技術以及以后它的擴展技術,類庫、管理員能夠有效而安全地集中安裝和更新客戶,并能在不用削減太多功能的情況下將“肥胖的”客戶變?yōu)殪`巧的客戶。DCOM對于健壯性版本化的支持使得無需先更新所有客戶就可以更新服務器程序。 另: Combining unit for DTRU BTS -- 合路單元
移動通信網(wǎng) | 通信人才網(wǎng) | 更新日志 | 團隊博客 | 免責聲明 | 關于詞典 | 幫助