(來源：http://nj.863cims.net/)
李剛 王茜
(東南大學計算機科學與工程系, 210096,prince@seu.edu.cn)
摘要：分布計算是企業級應用開發的關鍵技術，本文闡述了分布計算中兩種流行標準DCOM和CORBA的原理和
結構，并探討了一種DCOM與CORBA集成的應用服務器實用模型的建立。
關鍵字：DCOM CORBA
Research of a kind of practical DCOM and CORBA integrated application server model
Gang Li Qian Wang
Department of computer science and engineering
Southeast University
Nanjing, Jiangsu, 210096, P.R.C.
Abstract: Distributed computing is the vital technology in the application development of the
enterprise level, this paper illustrates the rationale and architecture of two distributed
computing standards in vogue DCOM and CORBA, and a practical DCOM and CORBA integrated
application server model is discrtibed .
Key Words: DCOM CORBA
1 分布式計算環境與多層結構的發展背景
早在70年代末第一個關系型數據庫管理系統出現時，計算機的數據庫時代就已悄然開始。那時的觀念是由應
用程序與關系型數據庫共享統一文件系統，這種數據處理的模式一般稱為單層結構（1 －Tier）。 由于這種
結構的數據庫程序占用計算機資源較多也不利于多用戶環境數據庫的訪問，于是在80年代中期，數據庫應用
開始轉向C/S（Client/Server） 結構， 也就是所謂的兩層結構(2－Tier)。 這種結構在近十年內不但得到
了廣泛的運用， 而且相當成功。 然而，在兩層C/S 結構成功的背后卻逐漸暴露出其構架上的缺陷。其中最
明顯的問題表現在應用程序的伸縮性和維護方面。 例如，一個跨國企業如何把數據庫管理系統及其應用程序
分散到十分緩慢的網絡上， 如何控制數據的統一性和完整性； 一旦應用程序有任何改動，維護人員就必須
修改每一個客戶端上的應用。特別是每一個客戶端往往必須配置數據庫的客戶端服務或ODBC/BDE軟件,使得客
戶端占用資源很多,配置也很繁瑣。
90年代中期后,由于分布式計算技術和Web的迅速發展，數據庫應用系統在傳統的 C/S 結構的基礎上，出現了
兩個重要轉變：一是在客戶層與數據庫服務器層之間增加了應用程序服務器層，應用程序服務器包括了統一
的界面、 業務規則的封裝和數據處理邏輯的規定等等。這種新的結構就是所謂的3層或多層結構。多層應用
服務技術允許分割應用程序，本地計算機上無須安裝一整套數據庫客戶工具， 就可以在另一臺機器上存取
數據。 同時它允許對業務規則和進程進行集中管理，并在整個網絡上分發、 實現進程負載的動態調節。
二是隨著Internet/Intranet的流行，越來越多的客戶需要數據庫的前端能夠在瀏覽器中運行，于是出現了
B/S（Browser/Server）結構。應用服務器的出現使得原來占用資源很多的應用程序客戶端（稱作肥客戶）
轉變成占用資源較少的瘦客戶，也使得瘦客戶可以在瀏覽器中運行。這兩個轉變實際上同時發展并且相互
推進,可以認為，CGI Web數據庫訪問方案是三層結構與B/S結構共同的鼻祖。
在多層分布式計算環境中，目前有兩種協議處于主導地位，以下分別闡述。
1.1 DCOM(Distributed Component Object Model)
DCOM是微軟，DEC等公司的分布式計算策略。1996年Microsoft提出的DCOM（分布是組件對象模型）是基于以
下一個簡單的思想:在DCOM協議的支持下,不同應用程序可以透過網絡進行互操作。這樣我們可以在一個應用
程序中（或DLL連接庫）創建對象，而從駐留在另外一臺機器上的程序中通過接口調用此對象的方法。DCOM
基于COM（組件對象模型），而COM正是微軟的核心技術OLE與ActiveX的基礎,并且已經成為Windows不可缺少
的組成部分。圖1顯示了DCOM的整體結構：COM運行庫向客戶和組件提供了面向對象的服務，并且使用RPC和
安全機制產生符合DCOM線路協議標準的標準網絡包。
圖1 DCOM 架構
COM規范可被視作一種對象的層次結構，正如MFC或是VCL，但COM與MFC或是VCL不同在于COM規范具有開發語
言無關性，故有很多工具可以用來創建COM和DCOM組件-- Visual C++、RAD（Rapid Application
Development）工具(如Visual Basic、Delphi/CBuilder及PowerBuilder)，同時已經有大量的已被建立、
商品化了的ActiveX組件可供使用。盡管DCOM首先適用于Windows環境，它也正在擴展到多種UNIX（如
Solaris）平臺。
1.2 CORBA(Common Object Request Broker Architecture)
CORBA 技術規范是OMG（Object Manegement Group）的產品，OMG是一個包含800多個組織的聯合協會，
CORBA 技術得到許多著名的計算機公司的支持，Oracle的NCA（Network Conputing Architecture）的核心
技術也在CORBA。CORBA 是一個完全的分布式對象平臺。CORBA協議的核心部件稱作對象請求代理ORB（Object
Request Broker）。CORBA的對象請求代理（ORB）將客戶端程序與它將調用的對象連接起來。客戶端通過
事先定義好的接口請求對象服務，接口是通過OMG的接口描述語言（IDL）書寫。客戶端通過IDL存根（STUB）
或通過DII（Dynamic Invocation Interface）與ORB核心通信，由于IDL存根表示了客戶端實現語言與ORB核
心實現語言的對應，故客戶端可以用ORB核心支持的任一種語言進行開發。
2 我們的做法--DCOM 與CORBA集成的應用服務器模型的建立
隨著分布式計算對于企業應用擁有越來越重要的作用，各種標準之爭越來越火熱，最為明顯的就是DCOM
與CORBA。但由于在目前的形勢下，無論是CORBA還是DCOM均還不是事實上的標準，故目前企業開發的應用最
好能兼顧這兩種標準，實現DCOM與CORBA的集成。目前比較流行是COM-CORBA橋或利用COM和CORBA兼容的API
技術方案，目前有一些公司已提供成熟的商業產品，但這種方案會造成緩慢的程序運行效率，也不利于系
統的擴展，并且隨著COM+標準的來臨，很多COM兼容性問題都將過時。
所以本系統模型采用了一種全新的解決方法，我們在應用服務器中直接對兩種標準提供支持（當然也可只支
持其中一種）。只有這種方案才能保證分布是程序的運行效率，特別是在于需要大量數據進行處理的系統相
連上尤為明顯。這種方法思想為：在一個應用服務器中同時提供DCOM與CORBA接口，同時支持DCOM客戶與
CORBA客戶。實現上可以考慮Microsoft 的VC或Borland的Delphi/Cbuilder,我們對此的實現方案應用了
Inprise的Midas技術。
我們在開發CIMS-MRPII的成本管理系統中,構造了一個能同時支持DCOM/CORBA標準的應用服務器模型，由于本
系統涉及大量復雜的對樹狀BOM表的查詢與更改,有很多算法需要占用大量的CPU資源，我們采用放置在較高性
能多CPU處理器上的應用服務器集中處理與數據庫的連接與查詢，客戶端將SQL查詢和修改語句動態傳給應用
服務器，再由應用服務器集中與數據庫交易。當計算的每一階段完成后，應用服務器將中間結果傳給客戶端，
客戶端可根據此中間結果再構造算法所需的另外的SQL查詢和修改語句，由于客戶端不與數據庫直接連接，
顧客戶端無需附加配置諸如ODBC/BDE等動態連接庫，故客戶端是真正的瘦客戶。為使應用服務器實現DCOM與
CORBA 的雙重支持，就必須使應用服務器同時具有DCOM和CORBA接口,我們的做法如下：
首先，在Delphi4/Cbuilder4利用Remote Data Module先構造一個DCOM應用服務器，通過Tprovider提供SQL接
口。特別是DCOM應用服務器同時作為OLE自動化服務器，可以被客戶端透明激活。
然后再使此應用服務器的類型庫同時提供CORBA支持。
最后，可以使用Type Library工具，提供 CORBA IDL 接口描述語言和微軟MIDL接口描述語言，以便今后可以
使用合適的工具重新編譯應用服務器。
由于本應用服務器同時提供DCOM與CORBA 接口，以下具體就這兩種不同協議下客戶端的建立和他們怎么與應
用服務器通信尤其是從Internet上作一討論。
2.1 基于CORBA 的客戶端與應用服務器的互操作
由于CORBA 對象之間可以達到完全的互操作，CORBA對象的通信基于IIOP（Internet Inter-ORB Protocol）
協議。我們通過帶Javabean的瀏覽器客戶端程序，與支持CORBA的應用服務器通信，從而實現Java與CORBA的
互操作。客戶端的程序通過本機的ORB請求得到其他CORBA對象的服務，通過IIOP協議，客戶端的ORB 可以穿
過網絡尋找其他系統的ORB及可以提供服務的服務器對象。一旦ORB找到可以提供服務的服務器對象，客戶端
對象就可以與服務器對象進行通行，仍然基于IIOP協議。
由于當今各種流行的Unix平臺（如Linux，Solaris）普遍擁有Netscape瀏覽器，從而我們可以很容易的
從Unix客戶端訪問CORBA服務器。正是由于這種CORBA與Java的互操作，使得我們的企業應用跳出Windows平
臺限制，實現了企業信息集成中需要的平臺無關性。
2.2 基于DCOM客戶端與應用服務器的通信
對于無需相互作用的，文本的或者簡單的圖形信息，HTML頁面可以為用戶訪問所需信息提供一個著名而有效
的方式。對于更加復雜、結構化和相互作用的信息來說，如分布式多層應用系統，我們可以用ActiveX組件
來擴展HTML頁面，使其以一種用戶友好、安全和有效的方式真正的分布式任務。可以在客戶端應用一些簡單
的事務規則來為用戶提供迅速的反饋。更加復雜的事務規則能夠透明地激活DCOM上應用服務器的組件，特別
可以采用Active Form技術直接將Vcl控件轉為ActiveX控件嵌入HTML頁面。不過需要強調的是，因為DCOM的
語言獨立性，這些ActiveX組件可以用任何一種編程語言來完成，其中包括C++、Delphi,Powerbuilder,
Java、Visual Basic或者Cobol。現存的組件（ActiveX控件）能夠被結合到客戶端或者用Visual Basic
Script或Java Script寫的服務器端顧客組件上。以下為原理圖
圖2 ActiveX Dcom 訪問示意圖
值得注意的是，由于DCOM主要實用與Window NT/95/98環境，平臺的專有性無疑是其最大的缺陷。另外，
采用本模型可以擁有分布計算的公文包的支持， 隨著企業的發展,企業內有很多職員的工作地點不是固定的,
越來越多的人擁有了筆記本電腦,為適應這種潮流,我們的應用服務器支持一種稱作公文包的移動計算工作方
式。公文包模式是數據庫緩存更新的發展,我們所熟悉的Office軟件中也有這樣一個公文包,可以預期隨著移
動用戶的增加,公文包模式的支持將是企業應用服務器不可少的功能之一。為采用此種方式，只需如下操作即
可:
(1) 筆記本電腦在公司的局域網內與應用服務器相連并且從應用服務器上獲得數據,然后將緩存在本地的數據
即進行文件存盤,存盤后即可斷線。
(2) 在斷線后, 擁有筆記本電腦的職員就可以在任何地點,如飛機上,從存盤過的文件中讀出數據,并可對數據
進行各種離線處理和分析。
(3) 當擁有筆記本電腦的職員回到公司并和公司內應用服務器重新連接后,可以一次新的將離線所作的處理更
新到數據庫服務器中.
3 總結
通過本模型應用服務器的建立，可以非常快速地開發出企業環境下所需的分布式應用，而其可行的要點
在于DCOM，CORBA這兩種競爭的分布式計算標準在原理和功能上出奇的接近，而采用本模型又恰能使這兩種模
型的優勢互為補充，并為下一代即將流行的操作系統平臺Windows2000（內置com+）作好擴充的準備。
參考文獻
1 Best practices in distributed object application development Tom Albertson 1998
2 Borland Delphi Developer Guide Inprise Corporation 1998
作者簡介
李剛: 東南大學計算機科學與工程系碩士研究生。目前研究方向分布計算,數據庫技術。
王茜: 東南大學計算機科學與工程系教授。