一、中文摘要(關鍵詞：元件物件模式、 分散式物件元件模式、物件導向、可靠 度、可用度、可擴充性、容錯機制。) 隨著寬頻網路技術日新月異的發 展，醫學資訊系統的使用不再侷限於醫 院本身，將醫學資訊系統架構於網路上 已是一個不可避免的趨勢。利用分散式 元件物件模式(DCOM)，可讓醫學資訊系 統的程式碼發展具備物件導向及可重複 使用的特性，配合新世代的寬頻網路環 境，使得醫學資訊的傳遞更具即時性。 分散式元件物件模式是由微軟公司 所 提 出 ， 它 延 伸 自 元 件 物 件 模 式 (COM)，用來支援在各種網路環境上不 同電腦間物件的通訊。藉著 DCOM，我 們可以將已經在以 COM 為基礎的應用 程式、元件、工具或知識輕易的轉移到 標準化的分散式計算環境上。 由國外的研究論文中發現，隨著 客戶端請求的數目增多，或是在伺服 器上的物件數目增多，都會使延遲增 長。所以本計畫擬將系統的可擴充性 作深入研究，並提出與實現可改進效 能的方案。其次，我們也將容錯的機 制加以考慮來改進系統的可靠度，並 增加可用性。我們將先建立容錯模 型，找出處理錯誤的機制，提供一個 以分散式元件物件模式為基礎的高可 靠網路服務。 未來的網際網路應用將以分散式物 件為基礎，工業界目前在這方面的進展 非常快速，所以我們學術研究必須在這 個熱門的領域投入人力與心力，而這個 子計畫以可擴充性及容錯機制為課題， 將大幅提高分散式計算環境的效能與可 靠度。
英文摘要 (COM, DCOM, object oriented, reliability, availability, scalability, fault tolerance mechanism.)
It is due to the rapid development on broadband network technology that the medical information system is no longer just conformed to a medical center or a hospital itself. It is an inevitable trend to construct the medical information system on top of the Internet. With Distributed Component Object Model (DCOM), we make the source codes of medical infor-mation system become object oriented and reusable. Together with the next gener-ation broadband network environment, the medical information spreads widely and will serve in a real-time manner.
DCOM is proposed by Microsoft. It extends Component Object Model (COM) to support communication among objects in different computers on the Internet. Because DCOM is a seamless evolution of COM, we can leverage our existing investment in DCOM-based applications, components, tools, and know-ledge to move into the world of standards-based distributed computing.
It has been shown that the latency increases when the number of requests
行政院國家科學委員會專題研究計畫成果報告
網路醫學資訊系統之可擴充性與容錯機制
Scalability and Fault Tolerance Mechanisms for a Network
Medical Information System
計畫編號： NSC88-2219-E-002-006
執行期限： 民國87年08月01日到88年07月31日
from clients or objects on the server increases. Thus we will focus on the scalability of the system, and propose and implement new mechanisms for better system performance. Then we will add fault tolerance mechanisms in the system to improve both the reliability and availability. We'll first setup proper fault model and then find out mechanisms of fault-handling to provide a DCOM-based, highly reliable network service.
It is foreseen that Internet appli-cations will be based on distributed components in the near future. The progress on this topic is very fast in the industry, and we have to keep pace with it in the academia. This project focuses on the topics of scalability and fault tolerance mechanisms. We are sure that it will be of great help in increasing the performance and reliability of a distributed computing environment. 二、計畫緣由與目的 隨著 Java 程式語言和網際網路技術 的發展與進步，我們希望將大又複雜的 軟體應用程式分開成一系列巳經預先建 立、容易發展與了解的模組。這個使用 元件的技術可以讓軟體的發展更快、更 便宜。而微軟公司所發展的 DCOM 技術 是一種可以讓這些軟體元件透過網路彼 此通訊的技術。它有三個獨特點可以使 它成為關鍵性技術。首先 DCOM 是建立 在最被廣泛使用的元件技術上。其次 DCOM 可以與各種網路技術如 TCP/IP、 Java 及 HTTP 相容。最後就是 DCOM 可 以在很多作業系統平台上執行，使得在 原有系統上的投資不會浪費。 提供一個全方位的網路醫學資訊系 統是項非常具挑戰性的工作，因為它必 須是不會停下來的服務，否則將會對醫 生或病人造成重大影響，甚至危害生命 安全。另外效能的表現對於此系統的成 功也是非常重要的，要是不能滿足醫生 或病人的期待，他們便會尋求其它方 法。再者可擴充性也是必須包括的，因 為系統必須能夠隨著醫院及病人之增 加，處理大量同時連線的客戶請求。 原有的網路醫學資訊系統最缺乏的 是在客戶端的發展，若是沒有改善並加 強使用者介面，則與系統間的交談無法 得到改進。而改進會受限於原來巳存在 的系統架構，若不加思索的修改必需完 全改寫原有的程式，這就限制網路醫學 資訊系統的發展。所以，我們將設計的 主要目標設定在如何提供簡單且有效的 存取介面，如何將目前最新的多層式分 散式技術應用於醫學資訊系統，並提供 方法平穩轉移以主機為中心的程式到分 散式計算的程式。進而提供可擴充性及 容錯機制，使得客戶與伺服器都能感到 效能提升及可靠度提高。 我們在新架構中主要是將應用區分 為三個方面：使用者服務、系統服務及 資料服務。將使用者介面服務與系統服 務分開可以使得不同前端技術皆可使用 並同時共享及重複使用相同的系統服務 如圖一，達到使用者的活動可利用不同 的交易組合來存取系統服務。要達到分 散式服務，必須將應用程式分開成許多 的邏輯元件，利用這些元件的重用及組 合來形成新程式或延伸巳存在的應用程 式。
• Run-time software reuse of binary components
Running application Component #1 Component #2 Component #3 Component #4 New Component #4 Binary component update 圖一：物件重用 COM 的 方 法 是 基 於 下 列 三 個 需 求。首先，任何一個 IID (Interface ID)必 須是不變的。第二是使用相同的 CLSID (Class ID)必須支援已存在的介面。最 後，任何客戶必須利用詢間介面的方法 與伺服器交談。如此才能允許客戶端與 伺服器端獨立發展軟體。假設在特定的
機器上，伺服器軟體在客戶端軟體更新 之前更新，因為新的伺服器支援所有舊 有的介面，舊客戶仍然可以保有所有的 指標並正常工作。當客戶軟體更新時， 新客戶將會詢問新的介面 ID 來享受新 機能。相反地假如客戶端軟體先更新， 則新客戶將試著詢問舊伺服器而得到失 敗的結果。當然新的客戶端程式必須被 設計成能夠處理這種找不到新的界面時 的錯誤，然後新客戶端程式需以舊有的 機能來處理這個失誤。這樣才不會使的 程式當掉。圖二表示更新版本處理的架 構。經由這種機制，伺服端只要讓客戶 端知道有哪些界面就可以了，真正的實 作階段就可以分別獨立發展而不會發生 問題。此外，軟體的更新也可以分別獨 立進行，而不會造成問題。 New client Old interface Old component New inter face New component Old client 圖二：更新版本的處理 物件導向程式設計之所以受歡迎的 一個原因，就是程式設計者可以在不同 的專案中共用程式碼。因為重複發展相 似的程式碼及演算法是一件浪費時間、 金錢的事，所以我們可以看出程式碼的 共用有許多好處。可是程式碼的重複使 用需要仔細的計畫和考量，否則可能只 是一廂情願。 對於大多數形態的程式碼重複使用 的狀況來說，還有一個很嚴重的問題， 那就是程式碼的原始設計者與想要重複 使用程式碼的人必須使用相同的一種程 式語言。COM 定義了二進位形式的標 準，可以解決這個問題。在撰寫 COM 程 式的時候，我們只要定義 COM 的界面 並且不可隨意改變此界面，真正實作時 所使用的程式語言則不受到限制。達到 程式碼可以真正重複使用的目的。 三、研究方法與成果 本子計畫於第一年，成果如下： 我 們 簡 單 的 比 較 了 DCOM 與 CORBA 的不同點。這兩個不同分散式物 件模型(Distributed Object Model)基本上 可以看成是如圖三這樣的三層式的架 構。圖中 DCOM Architecture 的部份因為 不同平台而有不同的稱呼，也可以稱為 Wire Protocol Architecture 以避免因為不 同物件模型上面稱呼的不同。關於詳細 的名稱與各層的架構簡圖可以參閱參考 文獻[1]。 最上層的部份稱為基本程式設計界 面架構，這一層是發展客戶端與伺服端 程式的程式設計師所看得到的部份。程 式設計師只要知道客戶端與伺服端之間 的溝通界面即可。每次需要使用到物件 的時候，就經由詢問(Query)界面的方式 來獲得某個特定的界面或功能。所以不 管對方的實作細節是如何，只要它的界 面維持不變，我們都可以由相同的界面 獲得我們所需要的服務。所以界面訂定 之前就必須要詳細的規劃與考慮。一旦 訂定了界面且公佈了，就不可以再隨意 更改界面。若需要新的功能我們可以考 慮增加支援新的界面，而不可以在舊的 界面上面動手腳。在這一層中，用來實 作的程式語言不一定要限制是 C++。不 過由於 C++的參考資料比較多，所以我 們選擇以 C++當作實作的程式語言。 Thr ee-Level Pr esentation
Client componentServer
Proxy Stub
RPC Channel
OXID resolver OXID resolver Object exporter OXID object Basic Pr ogr amming Ar chitectur e Remoting Ar chitectur e DCOM Ar chitectur e 圖三：三層式的 DCOM 架構 在現今的作業系統中，不同行程之 間的資料是處在不同的位址空間中。這
些不同的行程可以是在同一部電腦中或 者是跨越網路連結的不同電腦中。不管 是哪一種方式，我們都需要一種特別的 方式或協定才能夠使用在不同行程之間 的資料。作業系統通常會提供某種程序 間(inter-process)溝通機制，COM 就提供 了這樣的一個可以讓不同程序間的資料 溝通的機制。 這個機制就是由圖中的中間這一層 來達成。它稱為遠端架構層(Remoting Architecture)，它使得不同行程(Processes) 之 間 的 界 面 內 的 指 標 或 物 件 的 參 考 (References)變得有意義。程式設計師可 以直接將指標傳入界面中當作參數，然 後接收端在接收到參數後就可以直接對 此指標做的資料做存取(Dereference)，而 不需要擔心指標指向的地方是不合法的 位址空間。將資料由某一個行程打包 好，然後傳遞給另外一個行程並解包的 這個動作叫做 Marshaling。 DCOM 使用 的是 DCE(Distributed Computing Environment)的 遠 端 程 序 呼 叫(Remote Procedure Call)。為了要達成 Marshaling 的工作，我們必須要實作圖 中的 Proxy/Stub 的程式碼部份。撰寫這 部 份 的 程 式 碼 需 要 利 用 到 一 種 叫 做 IDL(Interface Description Language)的語 言來撰寫界面。這個語言的語法與 C 語 言有點類似。不過由於 IDL 語言沒有太 大的一致性，且相關文件也不多。所以 這個部份的參考資料不是很足夠。還好 對於我們的需求來說，找到的資料已經 夠用了。撰寫好了 IDL 程式碼之後，我 們可以利用編譯器將這些程式碼編譯成 Proxy/Stub。編譯好的 Proxy/Stub 需要在 Registry 裡面註冊。這樣子 COM 才可以 經 由 系 統 的 協 助 尋 找 到 需 要 的 Proxy/Stub 所在的位置。 我們希望以後能對 Marshaling 的部 份做修改，期望達到多點傳輸的功能， 或者增加一些容錯的機制在這個部份。 讓發生錯誤的時候可以有方法可以回 復，或者自動消除錯誤繼續執行。在撰 寫程式的時候，我們大概只需要了解到 這裡即可。除非我們需要針對 Marshaling 做改善或者增進一些特別的功能，否則 圖中最底下的那一層，基本上對於一般 的程式設計師來說是透明看不到的。除 非有非常特別的需求，否則最底層被更 動的機會應該不大。 我們實際實作了兩個可以互相溝通 的應用程式。在我們所實作的程式中， 兩個應用程式可以互相傳遞資料，並且 將結果顯示出來。當我們在第一個程式 中更改資料的時候，我們將被更動的部 份經由特定界面通知第二個程式。第二 個程式在接收到這個通知以後，就知道 對方如何更改了資料，然後可以顯示給 使用者知道。由於我們設計這兩個測試 用的應用程式的時候，是要讓這兩個應 用程式既是客戶端也是伺服端。所以任 何一個應用程式都可以發出連線的要求 給另外一個應用程式，而不需要特定某 一個應用程式才可以發出連線的要求。 為了達成這個要求，我們設計了如圖四 的物件與界面。如圖所示，當任何一個 測試程式被啟動的時候，它可以經由呼 叫 對 方 所 公 開 出 來 的 界 面 裡 面 的 CallMe()函示通知對方要求連線。也就是 說，任何一個應用程式只知道對方所公 開出來的界面與功能，詳細的實作細節 是包含在另外一個程式裡面。這也就是 為什麼圖中的 CallMe()與 Click()函式是 畫進另外一個程式中的原因了。 起初我們遇到程式即使已經結束 了，但仍然佔據系統資源不放的問題。 後來我們針對這個問題改變了我們的程 式結束時的流程。也就是，當我們要結 束程式的時候，我們需要經由任何一個 測試程式通知另外一個測試程式程式， 告訴它我們已經不再需要它的物件與服 務了。這個時候這兩個測試程式就可以 將它們的資源釋放掉。如果沒有經由選 擇選單達成這個目的，我們不允許程式 結束，並且顯示對話框通知使用者結束 程式的步驟。這個結束程式的方法雖然
多了一個步驟，但它可以解決程式佔據 系統資源不放的問題。
圖四：既是客戶端與伺服端的模型 我 們 在 一 台 Windows 95 與 Windows 98 上面分別安裝了 DCOM for Windows 95 與 DCOM for Windows 98， 並且在這兩台機器上面個別安裝了我們 所撰寫的應用程式。這兩個應用程式在 我們的測試下，運作非常的良好。由於 我們實作的部份是使用 COM 的物件模 型，往後需要再加入其他功能的時候， 我們可以輕易地將物件逐漸地加入系統 中。當加入的物件越來越多，系統功能 越來用複雜的時候，物件導向模型的優 點就會越來越明顯。 四、結論與討論 分散式計算巳經成為主流，這是因 為在高速網路的進步及網際網路的蓬勃 發展下，加上物件導向程式也巳成為發 展可重用性軟體的主流，分散式物件結 合這兩大趨勢而漸漸受歡迎。愈來愈多 的系統軟體建立成分散式物件的應用程 式讓彼此間能分享許多共同的目標，這 個計畫主要的目的是研究 COM/DCOM 的特徵並加以應用在醫學網路資訊系統 中，以達成可擴充性及容錯機制。 分散式元件物件模型的特徵包括了 介面及實作，支援物件具有多重介面， 語言中立，即時二元軟體重用，位置透 明化，可延伸架構，轉向，版本管理及 伺 服 器 生 命 周 期 管 理 。 也 就 是 說 以 COM/DCOM 為 發 展 分 散 式 程 式 的 平 台，則研究者及研發者可以專心於對他 們程式比較重要的課題，而不需將大部 分的努力投資在建立支援的基礎建設。 藉由本子計畫的執行，我們於計畫 執行上獲得了許多寶貴的經驗。這些經 驗包括 DCOM 與 CORBA 程式設計界 面、軟體元件的發展模式、分散式物件 應用程式的撰寫、及研究上分析與比較 方法。同時也謝謝國科會給予我們執行 此計畫的機會。 五、參考文獻
[1] P. Emerald Chung, Yennun Huang, and Shalini Yajnik, “DCOM and CORBA Side by Side, Step by Step, and Layer by Layer”, C++ Report, Jan, 1998. [2] D. Rogerson, “Inside COM”, Redmond,
Washington: Microsoft Press, 1996.
[3] Microsoft Corporation and Digital Equipment Corp., “The Component Object Model Specification”,
http://www.microsoft.com/oledev/olec om/title.htm, Oct. 1995. [4] COM/DCOM Resources, http://www.research.att.com/~ymwang /resources/resources.htm [5] Y. M. Wang, “Introduction to COM/DCOM”, tutorial slides,
http://www.research.att.com/~ymwan g/slides/COMHTML/ppframe.htm, 1997
[6] Guy Eddon and Henry Eddon, “Inside Distributed COM”, Microsoft Press, 1998.
[7] A. Avizienis, “The N-version approach to fault-tolerant software”, IEEE Trans. Software Eng., Vol. SE-11, No. 12, pp.
1491-1501, Dec. 1985.
[8] J. Siegel, “COBRA Fundamentals and Programming”, John Wiley & Sons, 1996.
[9] R. Grimes, “Professional DCOM Programming”, Olton, Birmingham, Canada: Wrox Press, 1997.
CallMe() Click() CallMe() Click() 應用程式 1 應用程式 2 行程邊界 Component Component CallMe() Click() CallMe() Click() 應用程式 1 應用程式 2 行程邊界 Component Component
