分散式架構

、布式計算技術形

()OMG(OpenManagementGroup)組織提出的。那時的分散式應用環境都採用Client/Server架構，CORBA的應用很大程度的提高了分散式應用軟體的開發效率。

另布式系統具Microsoft的DCOM(DistributedCommonObjectModel)。Microsoft為了使在Windows平台上開發的各種應用軟體產品的功能能夠在運行時(Runtime)相互調用(比如在MicrosoftWord中直接編輯Excel文件)，實現了OLE(LinkedandEmbeddedObject)技術，後來這個技術衍生為COM(CommonObjectModel)。

隨著Internet的普及和網路服務(WebServices)的廣泛應用,Browser/Server架構的模式逐漸體現出它的優勢。於是，Sun公司在其Java技術的基礎上推出了應用於B/S架構的J2EE的開發和應用平台;Microsoft也在其DCOM技術的基礎上推出了主要面向B/S應用的.NET開發和應用平台。

二、使用的協議

.NET中涵蓋的DCOM技術和CORBA一樣，在網路傳輸層都採用TCP/IP協議；也都有自己的IDL規範。所不同的是，在TCP/IP之上，CORBA採用GIOP/IIOP協議，所有CORBA伺服器以IIOP通信，形成了ORB軟體通道;J2EE的RMI曾經採用獨立的通信協議，目前已經改為RMI/IIOP，體現了J2EE的開放性;DCOM也有自己的通信協議(TCP在135埠的服務)，但微軟沒有公開這個協議的規範；同樣，CORBA的IDL採用類C++的定義，是公開的規範;DCOM的IDL的文件雖然是文本形式的，微軟沒有正式公布它的規範，在使用中，.NET的IDL是由開發工具生成的。

三、應用的環境

關於.NET，比爾蓋茨這樣說:“簡單地說，.NET是以微軟的各種產品為開發工具和應用平台，實現基於XML的網路服務。”由此也可以看出，.NET在Microsoft的世界里功能強大，但對於Unix和Linux這些在伺服器市場佔主要份額的系統，.NET顯得束手無策。

因此，J2EE顯示了它跨平台的優勢，為網路服務商提供了很好的面向前端(front-end)的開發和應用平台,隨著網路服務進一步廣泛應用和服務集成度的提高,在網路服務提供商的後台會形成越來越龐大的分散式計算環境,CORBA模塊結構更適合後台(back-end)的多種服務,例如網路服務的計費程序等.因此可以看出,J2EE和CORBA技術在網路服務(WebServices)這片藍天下,各自有自己的海洋和陸地。如果在前端(front-end)使用了.NET開發平台，那麼在後端(back-end)的分散式結構中，DCOM就是理想的選擇。

J2EE是純Java技術，很多測試顯示RMI(Java)伺服器的響應速度遠遠低於非Java的CORBA伺服器。因此，在一些對數據處理速度和響應時間要求較高的系統開發中，要對RMI和CORBA的性能進行測試對比后再做選擇。

四、應用軟體的開發和維護

從應用軟體的開發過程的角度看,J2EE是完全開放式的平台,體現為既面向設計人員,也面向開發人員的規範;CORBA也是一種規範,但更多體現為中間產品,CORBA產品的提供商才是這種規範的真正執行者,對應用開發的程序員而言,只要了解IDL語言的規範,不必詳細知道ORB/GIOP/IIOP的協議細節。.NET作為Microsoft在網路環境的主打,體現為一系列產品化的開發工具,比如C#,C++,等。這些開發工具是直接針對應用開發人員的。其實Sun公司提供的J2EE也是由許多軟體包(應用API)來面對開發人員的。

從軟體開發成本與周期以及軟體的維護角度看，J2EE比CORBA有以上優勢。

五、應用前景

對於分散式計算技術的架構，不能絕對地說哪一個更好，只能說哪一個更合適。針對不同的軟體項目需求，具體分析才是明智的選擇。

從宏觀市場看，CORBA產品的銷售並沒有想象那樣給CORBA產品提供商帶來可觀的利潤；而J2EE的呼聲也高於.NET;隨著J2EE中RMI/IIOP與CORBA介面的完善，再加上開發費用的考慮和使用的方便性，J2EE一攬子開放的環境會是人們首先考慮的選擇；但CORBA標準的強壯的兼容性，也使這種技術在大型系統開發中會佔有一席之地。

關於作者

周斌北京時力永聯科技公司業務諮詢和軟體外包服務部經理，曾執教於復旦大學計算機科學系,1994年赴美國Oracle總部參加合作項目,后就讀於加拿大哥倫比亞大學

EMCVMAX

VMAX架構包含1個到8個VMAX引擎（存儲節點）。這些引擎相互連接在一起，被稱為虛擬Matrix架構。每個引擎都可以當作存儲陣列，擁有自己的前端主機埠連接、後端磁碟導向器、高速緩存（內部鏡像化）和處理器。VMAX引擎使用Matrix介面主板封裝器（MIBE）連接在一起。MIBE有副本以備冗餘。虛擬Matrix可以進行引擎之間的記憶體訪問。當主機訪問埠和數據不在同一個引擎上的時候需要虛擬Matrix提供連接性。

3ParInServ

3Par由多個存儲節點組成。這些存儲節點彙集到一個高速連接上。3Par稱之為InSpire架構。2到8個節點（按對配置）連接到一個被動背板，每個節點之間的帶寬可高達1.6Gb/秒。3Par如圖所示展示他們的8節點架構，連接的數量很容易就能看清楚。還看到2節點、4節點、6節點和8節點部署下的連接是如何增加的。InServ陣列按對寫入高速緩存數據，因此每個節點都有一個伴點。如果一個節點發生故障，伴點上的高速緩存可以馬上寫入另一個節點，從而保護高速緩存數據。

IBMXIV

IBMXIV陣列採用的是另一種節點設置方式。節點直接連接到底層硬體的數據保護機制。XIV只使用RIAD-1類型的保護，採用的是1MB大小的數據塊，也稱為分區。數據以偽隨機方式均勻分佈在節點上，確保對任何LUN來說，數據都是寫入在所有節點上。本文底部的XIV圖片顯示了這個架構。節點（在XIV中稱為模塊）分成介面模塊和數據模塊。介面模塊有自己的高速緩存、處理器、數據磁碟和主機介面。數據模塊沒有主機介面，但是仍然有高速緩存、處理器和磁碟。每個模塊有12個1TBSATA驅動器。當數據寫入陣列的時候，這些1MB分區寫入到所有驅動器和模塊中，確保任意一個分區的兩個鏡像對不會都處在同一個模塊上。LUN的順序分區分佈在各個模塊上。這樣做的結果就是所有的模塊都參與服務所有的卷，且單個模塊的故障不會導致數據丟失。