行政院國家科學委員會專題研究計畫 成果報告
子計畫三：高可擴充性與可用性行動電子商務中介軟體技術
之研發與實作(3/3)
計畫類別： 整合型計畫 計畫編號： NSC92-2213-E-002-011- 執行期間： 92 年 08 月 01 日至 93 年 07 月 31 日 執行單位： 國立臺灣大學電機工程學系暨研究所 計畫主持人： 郭斯彥 計畫參與人員： 王思齊 林宏遙 張鴻祺 周宗謚 報告類型： 完整報告 處理方式： 本計畫可公開查詢中 華 民 國 93 年 10 月 5 日
中文摘要
關鍵詞：多層次式架構，分散式元件技術，高可用度，高可擴充性。 隨著網際網路與行動通訊的普及化，二者技術的整合產生了許多新穎的應用，所謂的行 動電子商務就是其中之一。本子計畫主要目的在於對於系統容錯機制的探討和改進系統的 可靠度，並以模組化的方式與其他各子計劃整合運作，以實現新世代的行動電子商務系統。 要如何提供不間斷的服務和一個具備高可用度的系統，本身就是項重大的挑戰。從另一 方面來說，各項新技術的快速發展，使得軟體系統的生命週期變得相當短促。因此在考量 網際網路應用程式伺服系統架構時，必須將系統的維護與日後功能擴充的可能性列入考量 的項目。本計畫使用分散式元件技術，設計以多中介層次的架構提供不同的功能層級，以 達成行動電子商務系統之高度可擴充性。另外，由於分散式元件具有良好的替代性，用於 架構系統將有利於系統的維護與更新。本計畫同時著重於研究如何使系統具備高可用度。 我們使用元件層級的容錯群組技術，達成系統高可用度的需求。 在傳統的商業模式中多使用固定接點的網路通訊程式進行遠端處理，然而隨著網際網路 的普遍化，網路通訊的定義已從以往定點對定點的通訊方式逐漸擴展其領域；網際網路應 用程式與行動通訊是目前相當明顯的一個發展方向。行動通訊可以視為網際網路的一個延 伸，且行動通訊網路的使用方式則更加接近人類在商業行為中的習慣。本子計畫將完成交 易系統中介軟體之決策邏輯與流程控制邏輯，並以 CORBA 和 Java, XML 等技術提供系統 元件之容錯，來實現系統之高可用度及高可擴充性。Abstract
Keywords: Mobile E-commerce, Middleware, Multi-tier, Availability, and Scalability.
As the use of the Internet and mobile communications becomes popular, the combination of these two technologies has brought many novel applications into the real world. The so-called mobile e-commerce is one of them. The main goal of this project is to investigate how to provide fault-tolerance for the whole platform and to improve system scalability. With the integration of other projects, a new wireless Internet business system could be realized.
However, it is not easy to convert a legacy client-server style system into Internet-compliance. The Internet clients can be worldwide. The system must have high availability to provide continuous services. Furthermore, the rapid development of new technology makes the life cycle of one system even shorter. As a result, it's important to put scalability and maintainability into consideration when constructing the system architecture. In this project, we make use of the distributed object technology to design and implement the multi-tier system architecture. By building different function levels in the multi-tier fashion, high system scalability can be achieved. Furthermore, because of the ease of component replacement, building the system by distributed objects is also beneficial in the maintenance and upgrades of the system. At the same time, we aim at providing the system with high availability. It is achieved by using the component-level fault-tolerant group technique.
In traditional commercial activations, trading can function through wired network communication applications. Nevertheless, the definition of "communications" changed forever with the introduction of Internet. The future communication style have no other choices but rely on internet and mobile network, which can be treated as a extension of Internet, with more people in business activities. We have implemented the decision-making logic and flow-control logic of the middleware for the proposed wireless Internet business system. The high system availability and scalability is achieved by using fault-tolerant CORBA components and other techniques, such as XML and the Java programming language.
目錄
報告內容………..1 1. 前言………1 2. 研究目的………2 3. 文獻探討………4 4. 研究方法………6 5. 結果與討論………..13 參考文獻………17 計畫成果自評………18 可供推廣之研發成果資料表………....………19報告內容
一、前言 網際網路 (Internet) 的出現，帶動人類歷史成長最快速的科技發明浪潮，以達成全北美地 區普及率 25% 的目標來說，電話花了約 35 年，汽車花了約 55 年，電視花了約 26 年， 而網際網路在短短的七年內就達到這個目標。另外隨著行動通訊的普及化，二者技術的整 合產生了許多新穎的應用，所謂的行動電子商務就是其中之一。簡單的說，電子商務就是 把真實世界的“交易”過程－瀏覽、採買、付款等複雜的流程，藉由 Internet 的相關技術， 以更方便、更省錢、更有效率的方法來執行。電子商務中的經濟個體，由“交易”所產生的 資訊流、物流、金流都可以在更便宜、快速、無遠弗屆的 Internet 上進行。目前較為代表 性的電子商務多是以此模式為基礎，結合企業資源管理 (Enterprise Resource Project，ERP) 與行銷等手法所形成的純虛擬商店 (又稱為達康公司 dot.com company)，例如 Amazon， eBay，由微軟公司主要股東 Paul Allen 成立的 Mercada 等，以及依附於傳統經濟模式的公 司 (例如 Dell)，作為增加銷售擴充的企業型網路市集。 電子商務的興起，對於系統架構設計帶來了新的挑戰。要如何提供不間斷的服務，提供一 個具備高可用度 (availability) 的系統，將是一個挑戰。另一方面，各項新技術的快速發展， 使得軟體系統的生命週期變得相當短促。因此在考量網際網路應用程式伺服系統架構時， 必須將系統的維護與日後功能擴充的可能性列入考量。分散式物件技術是現今主要趨勢。 如果再配合容錯的相關機制，將可使系統達到更高的穩定性。在本子計畫中，我們引進分 散式元件 (distributed object) 的相關技術，設計以多中介層次 (multi-tier) 的架構提供不同 的功能層級，以達成行動電子商務系統之高度可擴充性 (high scalability)。另外，由於分散 式元件具有良好的替代性，用於架構系統將有利於系統的維護與更新。本子計畫同時著重 於研究如何使系統具備高可用度。我們使用元件層級的容錯群組技術、查核點設定並配合 後退回復服務，以達成系統高可用度的需求。 我們依循具有決策、程式、服務、協定等不同層次的系統架構雛形，並將制定不同的界面 定義作為系統元件間溝通的標準，以確保系統可以針對不同的客戶需求做出反應，同時保 留足夠的彈性可以隨時加入新的需求種類。我們的主要目標在於藉由本子計畫的執行，能 發展出一個具彈性、效率和可靠性的通用型電子商務系統架構，並以此作為與其他子計畫 所發展不同層級系統服務間的共用資訊界面，包括子計畫四與子計畫五作為傳輸協定層與 服務層部份元件的實作，子計畫一與子計畫二作為決策層企業邏輯與客戶關係管理技術引 擎的實作。我們預期這個架構將能適用於傳統的網路架構、以網路瀏覽器為主的 HTTP 網 際網路環境、現行的 WAP 行動通訊網路、以及未來可能的多種無線網路環境。此項研究 將具有相當大的實用性與商業潛力。二、研究目的 電子商務的興起，對於系統架構設計帶來了新的挑戰。如何提供不間斷的服務和一個具備 高可用度的系統，是個相當重要的議題。另一方面，各項新技術的快速發展，使得軟體系 統的生命週期變得相當短，因此在考量網際網路應用程式伺服系統架構時，必須將系統的 維護與日後功能的可擴充性列入考量。本子計畫將以研究交易系統中介軟體的決策邏輯與 流程控制邏輯，並以分散式物件的相關技術 (例如 CORBA) 來增加系統之可用度及可擴充 性，並提供系統元件之容錯。 以今日的角度檢視電子商務的發展史，我們不難看出這種商務系統運作模式的演進與淘汰 速率比人類所發展出的任何一種商業模式還要劇烈。從 1998 年底的 B2C 模式、1999 年 中 的 社 群 (community) 、 2000 年 初 的 B2B 模 式 ， 直 至 現 在 的 虛 擬 市 集 (virtual marketplace)，系統工程師們往往發現他們在日以際夜地工作了幾個月，完成一套系統之 後，馬上就要面臨“擴充”或是“改版”的壓力。以目前的發展趨勢，一個完整的電子商 務系統其生命週期大約只有半年。因此系統在運作一段短暫的時間之後，局部的功能擴充、 組件修正等已然形成系統的基本需求。而 2000 底的網路泡沫經濟衝擊，則顯示了電子商 務本身不能脫離實體經濟，進入完全虛擬的世界。系統要如何順利融入以“人”為主的企 業實體運作，如何在新舊系統間進行完美的協調運作，也成為新電子商務時代系統設計重 要的課題。 在設計電子商務系統時所必要面對的一個問題即是：應如何在不對系統運作造成整體性的 改變的前提下，增列新的支援，並同時兼顧其擴充性 (scalability)。物件導向 (object oriented, OO) 的程式設計方式是極為適合的解決方案。物件導向程式的程式重新使用 (code reuse) 精神不僅利於程式的開發、維護，同時適合用於商業用途。然而物件導向程式本身重視的 是 抽 象 化 資 料 型 (abstractive data type) 的 定 義 與 抽 象 化 物 件 呼 叫 (abstractive object invocation method)，並未著重於系統“擴充性”的提升。系統的擴充性須仰賴系統本身的 良好規劃，才能順利達成。 在現實生活中，一項硬體裝置在製造的時候一定不可能使其具備所有已知未知的功能。而 這項硬體裝置是否在日後能夠以“擴增”或“升級”等手段進行功能的提升或增加，取決 於硬體裝置本身是否有良好的組件規劃，以及一個固定常態的接續界面。軟體系統基本上 也是如此；系統本身的可擴充性取決於系統是否有明確劃分不同功能區塊 (function block) 的層級 (layer)，以及各功能區塊之間是否有規劃良好的界面 (interface)。
在圖一我們以抽象形式描述典型的元件式 (component-based) 程式架構，其中 Client Object 和 Server Object 均遵循良好定義之程式方式；經由不同的介面層次呼叫，Client Object 可 以動態的呼叫一個已存在程式實體的 Server Object 提供服務，或是動態的配置一個 Server Object 程式實體來提供必要的服務。物件的底層 Remote Layer 和 Protocol 可以用來提供 足夠的基礎功能 (Infrastructures)，做到跨記憶體區段 (Memory Block)、跨行程 (Process)， 甚至跨機器呼叫物件界面。
Programming Layer Remoting Layer Protocol Layer Client Object Client Stub Protocol Connection Server Object Server Stub Protocol 圖一、典型的元件式程式架構 利用此種元件式程式架構所組成的系統，不僅是系統的組織架構與傳統網路通訊程式有相 當大的不同，連同通訊的方式也會變得更具彈性。傳統網路應用程式中，通訊伺服器與客 戶端程式的通訊方式可能使用 NetBEUI、AppleTalk、IPX 或 TCP/IP Socket 和伺服器程式 互相通訊，並使用 ODBC 直接存取資料庫伺服器上的關連式資料庫 (SQL RDBM)。而在 元件式程式架構所組成的系統中，元件可藉由 Protocol Layer 達到跨機器呼叫的功能，因 此可以利用這種特性做到單一的通訊界面。這種形式的程式架構，是使用軟體元件在系統 核心資料和客戶端之間做一個新的、負責處理溝通中介的層次 (middle-ware)。而使用中介 層負責處理伺服器端和客戶程式端的通訊需求的系統，稱為多層次式架構 (multi-tier structure)。多層次是架構使得系統具有相當大的彈性，同時使不同層次的系統間能夠獨立 開發、維護、修改。而系統功能的擴充也可以藉由詳細制定出需求功能的層級關連性，針 對單一層次進行元件的重組。
多層次式架構現在被廣泛運用在網際網路之上。一般所謂的 CGI 程式 (common gateway interface) 例如 Servlet、JSP : Java Server Page、ASP : Active Server Page、PHP : Professional Hypertext Processor，即是由“SQL 資料庫－CGI 程式－網頁瀏覽器”三者所構成的三層式 架構 (3-tier architecture)。這種三層式架構為一般網站型網路應用程式 (website-based application) 大量運用，但是要作為一個具有抽象資料型別與抽象程式運作原則的泛用型網 際網路應用程式平台 (Internet-based application platform)，三層式架構並不能完全能作為在 第三部份所提到的問題的解決方案。現在的 CGI 程式所專注解決的問題多在於單純的資 料格式轉換，大部分工作都是由個別的單一程式負責處理。「擴充」的做法即是撰寫新的程 式來追加新的功能。在一般的狀況下這種做法不會有太大問題，但是如果系統本身複雜度 高到一個程度，功能的追加往往牽涉到系統底層架構的變遷，這樣就需要進行系統的轉換 (Transform) 而不是單純的擴充了。另一方面，CGI 程式多用直接輸出的方式回應瀏覽器或 行動通訊客戶端的呼叫，每當有新的資料格式產生 (例如 HTML 至 WML) 就需要重新撰 寫所有的程式，相當耗費時間。因此單一 CGI 程式層次這種簡單的系統架構不足以應付 抽象形態的存在，亦無法作為一個高可擴充性的系統的基礎。
三、文獻探討 隨著網際網路的普遍化，網路通訊的定義已從傳統的定點對定點方式逐漸進步，網際網路 應用程式 (internet application) 與行動通訊是目前相當明顯的一個發展方向。行動通訊可以 視為網際網路的一個延伸；無線傳輸的通訊協定發展已使行動通訊的資料封包傳輸速率達 到可接受的範圍，例如預計在未來數年內逐步推廣的 GPRS 系統，傳輸速率可達下載 43.2 Kbps，上傳 14.4 Kbps，雙向傳輸速率可達 56Kbps。在 21 世紀的第一個世代之內行動通 訊的傳輸速率肯可望達到 100Mbps。我們不難看出，行動通訊在電子商務中將會扮演十分 重要的角色，讓電子商務的範圍更深更廣、完全擺脫地區和時間的束縛。對於電子商務化 所帶來的系統架構衝擊，傳統的系統開發者習慣用疊床架屋的方式來處理不同的需求，而 這種處理方式多半牽涉到系統的重新開發。然而一個具備多重客戶端程式服務能力的系 統，往往會過於龐大而難以維護；同時當又有新的需求要增加時，所需要花費的程式開發 人 力 成本 也會 越來 越高 。 在這 種情 況下 系統 的 程式 重複 使 (code reuse) 和可擴充性 (scalability) 即是開發系統時所必須考量的要素。 在實作上，目前正在蓬勃發展的分散式物件技術可用來架構兼具可擴充性與可靠性的電子 商務系統架構。目前在分散式物件技術相關領域中，主要的競爭者是 Microsoft 提出的 DCOM (Distributed Component Object Model) 技術，OMG 提出的 CORBA (Common Object Request Broker Architecture) 技術，以及由 Sun Microsystems 主推的 JAVA BEANS 技術。雖 然基本的概念與技術很接近，但是實際上每種物件技術的架構與特性卻有很大的差異。因 此如何善加利用各種技術的長處，以期達到最大效益，將是一個重要的研究課題。在我們 的研究及實驗中，是以 CORBA 為主，因為 CORBA 是 OMG (Object Management Group) 所 定的標準，並已被廣泛使用。另外 CORBA 還有如下的優點，它允許系統中有不同架構的 機器，不同的作業系統，各物件以不同的程式語言來撰寫。CORBA 的 ORB (Object Request Broker) 可以處理這些使用不同平台所帶來的問題，例如在不同的通訊協定之間做轉換，在 不同的程式語言之間做型別轉換等等。此外，CORBA 的標準中還包含了一套標準的服務， 例如名稱服務 (naming service)、交易服務 (transaction service) 等等，可以大大地便利工業 上的使用。事實上，OMG 已經制定出 Fault Tolerant CORBA V1.0 的標準。圖二即為其主要 架構。在這樣的系統中，物件若發生錯誤，並不會造成服務的終止，而會有其他備份的物 件來取代它。 Invoked by Application Fault Tolerance Managers Client Objects Host 1 Server Replica Host 2 Server Replica Host 3 Fault Notifier Fault Detector Fault Detector Fault Detector 圖二、FT-CORBA 的錯誤偵測架構
在此架構中，達成這樣功能的主要物件有三種： 1. 複本管理者 (Replication Manager)：原則上，在一個容錯區域中，只會有一個複本管理 者。複本管理者必須提供 PropertyManager 的介面 (interface) 以供使用者選擇容錯機制的 一些特性，例如採用何種備份方式等等。而 GenericFactory 介面，則提供如 create_object() 等方法讓使用者可以產生一個新的物件群組來提供服務。另外，複本管理者還提供 ObjectGroupManager 介 面 ， 讓 使 用 者 可 以 透 過 此 介 面 中 的 create_member() 、 add_member()、remove_member()等方法來控制、管理一個物件群組。 2. 錯誤偵測 (fault detector)：每台主機上都會有一個錯誤偵測者，稱為局部錯誤偵測者 (local fault detector)。它會檢查這台主機上是否有物件發生錯誤，如果有的話，則會通知 錯誤通知者。因為局部錯誤偵測者本身也有可能發生錯誤，因此我們還需要另有其他的 錯誤偵測者來偵測它是否有發生錯誤。於是另外還設有全域錯誤偵測者 (global fault detector)，其功能就是檢查此容錯區域中的所有錯誤偵測者是否有錯誤，同樣地，如果檢 查出有錯誤的話，也是將此訊息通知錯誤通知者。然而，全域錯誤偵測者也有可能會發 生錯誤，為了避免『單點失敗』的可能性，在一個容錯區域中，不只有一個全域錯誤偵 測者，而是有多個，每個全域錯誤偵測者除了檢查局部錯誤偵測者有沒有發生錯誤之外， 還必須檢查其他的全域錯誤偵測者有沒有發生錯誤。 3. 錯誤通知者（fault notifier）：當有錯誤發生時，錯誤偵測者會告知錯誤通知者。而錯誤 通知者會把這些訊息再傳送出去給複本管理者及其他與此訊息有相關的物件。至於該傳 送給那些物件，就看有那些物件有向錯誤通知者註冊對那些訊息有興趣了。
另外，微軟公司提出由 Microsoft Transaction Server (MTS) 來處理 business process，在 MTS 中由許多 ActiveX components 組成，這些 components 可以使用任何支援 COM 工 具開發，例如 Visual Basic、Java、C++ 等等。MTS 內建了許多功能，幫助開發人員在開 發元件時能減少許多基礎的程式設計問題 (deadlock、race condition、starvation、other performance issue)，讓開發人員能夠專注於 business rule 的設計，這些功能包含：(1)自動 安排 Thread 與 Process 的管理。(2)DCOM 的支援。(3)與 DBMS 的聯結。(4)其他。關 於網路聯結的方面，則是由 Microsoft Message Queue Server (MSMQ) 負責。Message
queuing 是非同步的通訊方式（asynchronous communication）。使用非同步通訊的主要原因
在於：(1)sender 在等待 response 時，可能要處理其他工作。(2)response 本身可能不需要， 或是 sender 本身不需要等待 receiver 處理 request。MSMQ 的架構概念如圖三所示。
四、研究方法
如前所述，設計下一代電子商務的系統架構主要的核心問題在於同時兼顧其擴充性、穩定 性，並且能和行動通訊的應用結合。很明顯的，當程式越複雜，前端的負荷量越來越大， 加上遍佈全球的前端，程式越來越難管理。Client/Server 架構面臨許多困難，如果有一百 個 client，在軟體更新時就必須處理一百台電腦，這對 MIS 人員實在是一大負擔。這時演 變出新一代的三層式架構：在 client 與 server 間增加一層 middleware，用以處理企業的 邏輯，解決兩程式架構所帶來的限制。下面我們正式討論這種三層式架構：其基本觀念是 把應用程式分成三個層次，分別是 Presentation、Business Process、Database Server，以下 分別簡單描述之。 1. Presentation：這一層負責顯示使用者介面，與簡單的資料檢查。 2. Business Process：這一層負責提供商業規則，並且結合多個資料來源。 3. Database Server：這一層主要是 DBMS，用以管理資料。 另外，分散式資料集是減少網路流量的一種方法。從伺服器下載資料後，在用戶端這邊就 可以處理，不需動用網路交通，除非要更新伺服器的資料。這表示無需經由網路就可進行 編輯、插入、刪除多筆紀錄。而要更新伺服器時，可在某個事先選定的時間一次傳送多個 封包。資料庫系統規定參數的存取：從伺服器下載資料的同時，也可下載一組可以自動執 行的系統規定參數。系統規定參數有助於程式設計者確認使用者輸入的都是有效資料。在 重新連上網路時，資料便能正確無誤的更新。萬一更新資料庫時發生錯誤，內建的處理機 制也能在報告及處理錯誤方面協助程式設計者。例如：如果另一名使用者已經更新了已修 改的記錄，這件事會顯現出來，使用者便可選擇下一步如何繼續。將資料的工作量分散給 多個伺服器，並提供錯誤復原功能。再來，我們引進公事包模型的概念，這是能讓用戶端 切離網路卻依然能存取資料，其作法如下：把遠端資料集存入磁片，將電腦關機，切斷網 路。之後不用連線就可以編輯資料。當重新連線時，可以重新與資料庫連結並更新資料。 資料庫的錯誤通知及可能發生衝突的解決都由某個機制來控制。例如：如果有兩個人在編 輯同一筆資料，將會有幾種解決辦法可供選擇。用戶端機器不必有大型資料庫工具就可以 辦到這些。因為不需保持和伺服器連結才能處理資料，對於筆記型電腦的使用者或想把資 料庫流量降至最低的人來說，這功能相當理想。 同時，我們引進物件代理者的觀念，也就是將工作量隨機分配給多部伺服器。代理者於每 次連線時可從中選擇。比如說，如果有一百個用戶端及三部主機，代理者會把工作量隨機 分給三部主機。代理者在主機意外被迫關機時也提供協助。提供錯誤復原服務，並把該主 機上的用戶端轉給其他運作中的主機。更進一步說：代理者絕不會嘗試把新用戶連到離線 的主機，而是自動跟仍在運作的主機連線。有別於傳統的網路金融 (net finance) 重視的是 純數據資料，電子商務 (e-commerce) 本身著重的重點是“交易”與互動 (interaction)。檢 視電子商務的交易模式，我們大致可以發現四種範式：
1. BtoC (Business to Consumer)：企業直接將商品或服務推上網路，並提供充足的資訊與便 利的界面吸引消費者選購。
2. BtoB (Business to Business)：企業間的電子商務運作可以讓整個“供應鍊”與“配銷鍊” 管理自動化，節省成本，增加效率。
3. CtoC (Consumer to Consumer)：主持者協助市場資訊的匯集，並建立信用評等制度。買賣 雙方透過服務自行協商價格與交貨等事宜。
4. CtoB (Consumer to Business) ： 以 社 群 (community) 為 出 發 點 ， 匯 集 需 求 (demand aggregator) 作為吸引賣方提出交易。 以上這四種範式中，系統都直接或間接的和交易的雙方產生若干程度的互動，例如顧客需 要瀏覽以及採購，而商店則需要處理訂單、倉儲與退款。我們若將交易雙方與系統的互動 關係進行分析，大致可以規劃出一些系統的功能部件需求： 1. 系統需要一個統一的資料輸出入 彙整界面以供使用者存取服務。此一界面須能整合不 同的傳輸協定。（子計畫四與子計畫五） 2. 系統本身需要依據一個交易規則（trading rule）監督交易雙方的行為。這個規則可能只 是單純的採購行為，或是拍賣喊價等。以一個完整的交易過程為例，雙方須經歷的過程 包括了 通知→認可交易→異動→異動確認→議價→付款→付款確認→出貨→出貨確認 →交易完成 等不同狀態。同時系統必須能應付一些狀況外的事件，例如退款、退貨、 取消交易等。 3. 系統必須能夠進行自我維護，處理諸如無效交易、無效 Session 等廢棄資料清除。 4. 系統需要進行完整的帳務記錄（logging）工作，並能利用統計與資料探勘等技術進行分 析，以作為客戶關係管理與行銷活動管理的基礎（子計畫一與子計畫二）。 依據以上的需求，我們可以畫出一個電子商務平台的骨幹。再加上網際網路程式的特殊需 求以及行動網路的考量，我們可以規劃本計畫的主要目標：中介元件的多層次式架構： 1. 決策層：在這個層級中系統應著重於“資料”與“資源”本身的保存與管理。包括主關 連式資料庫、程式運作流程（enterprise logic）、資源管理等項目。此處資料和資源泛指 一般數位化的抽象資料，或者是人力資源。 2. 應用程式層：在這個層級中需要專注在資料的“處理”，以提供決策層使用。除了須依 照任務而調整的應用程式之外，尚須應用程式的流程控制（workflow，包括 message queue）與確保應用程式執行的容錯控制，例如交易管理（transaction control）。應用程 式層與決策層關注的是資料本身而非資料的格式，因此在這個層級以上都使用具有抽象 性質的資料形態來做為不同元件間的資料交換格式。 3. 服務層：服務層的主要功能是作為應用程式層的資料輸出╱輸入單一窗口，將網路協定 層所提出的服務請求轉換成一具有共通格式 (format)、共通形態 (meta) 的資料格式， 並 傳 遞 給 該 負 責 的 應 用 程 式 層 元 件 。 服 務 層 須 有 能 力 處 理 資 料 格 式 的 辨 識 (identification)、資料讀取 (parsing)、資料格式轉換 (converting)，同時處理部份低階的 連線特殊需求 (如 Session 管理)。
4. 網路協定層：網路協定層需要處理來自不同的客戶端程式的不同請求，轉換成一制式格 式，傳送給服務層做後續處理。同時將服務層所轉來的抽象資料加以包裝以因應不同的 客戶端需求。
在圖四中顯示了一個五層式邏輯架構層級圖。在實際系統架構時，可以採用相當有彈性的 配置方式，可以由數台機器共同組成一個層級，也可以一台機器擔任多個服務層級。 Application Layer Service Layer Protocol Layer ORDBM Database Enterprise Resource Enterprise
Logic Resource Layer
Application Server Transaction Server Schedule Server Data Parser Format Parser Session Service Specified API HTTP Service WAP Service
...
Trad. Client Web Browser Mobile Client 圖四、網際網路應用程式五層式邏輯架構層級 因此，我們將依循圖四的系統架構，重新檢視先前所提出的系統需求。包括系統擴充性、 系統穩定度、行動通訊領域的支援等等，分別說明如下： 1. 系統可擴充性（Scalability）的需求 元件式的系統架構本身即具有相當大的擴充彈性。在硬體系統架構方面，分散式物件架構 （distributed object）可用來取代傳統的單一大型主機（mainframe），同時系統本身的運算 能力可以獲得無限制的提升：配合系統設計與程式行程控制，可以將系統運算平均由數台 機器分攤，達成叢集式（clustering）系統架構。另一方面，由於元件式系統架構本身依循 統一規劃的界面，因此系統功能性的增加可以藉由開發新的軟體元件，獲得相當簡單的解 決方案。從實體系統架構來看，系統功能的提升可以是軟硬體互相配合的結果。新開發的 程式元件可以由一台獨立運作的伺服器主機來執行服務，如此可做到對現行系統干擾最少 的情況下達到系統功能擴充的目的。在先前提出的五層式系統架構中，一個獨立功能元件 的加入對系統的衝擊可以限制在和該層級相接口的一個層級之內；在決策層可能需要依照 新的功能增加新的資料庫藍圖 (database table schema)，以及針對新功能制定擴增的程式流 程規則 (Workflow Rule)。以一般的功能擴增來說，所需要的修改都不會太過複雜。另外由 於服務層是客戶端程式取的系統服務的一個統一窗口，因此服務層必須針對新功能元件的 資料型別和處理規則 (Data type & Parsing Rule) 進行增改。如此一來當有客戶端程式使用 新功能時，服務層才能正確的辨識該程式元件，並將資料做正確的前置處理。為了達到這項功能，服務層與應用程式層的元件之間必須有一個統一、共通的界面呼叫準 則，如此在系統擴充時才能以最精簡的方式達到修改的目的。元件式系統架構中一個界面 的定義包括了物件的呼叫方法 (method) 以及資料格式。考慮到擴充的需要以及資料複雜度 的增加，使用具有抽象資料本質 (abstractive data format) 的格式作為資料傳遞的協定是比 較理想的做法。使用這種處理方法的額外好處是在系統服務層和應用程式層級分處網際網 路的兩端時，可以利用錯誤回復碼、電子簽章等方式進一步的確認呼叫的正確性與安全性。 2. 系統穩定度的需求
要使系統達到高穩定度的要求，可以使用避免錯誤 (fault avoidance)，錯誤排除 (fault removal)，錯誤預防 (fault forecasting) 等方式，分別簡單敘述如下：
(1) 避免錯誤：建構一個零缺點系統，使得錯誤不會發生。 (2) 錯誤排除：藉由改進系統規格、設計、製程等，降低系統發生錯誤的可能性。 (3) 錯誤預防：藉由預測可能出現的錯誤及其影響範圍，來提供處理系統錯誤的方式。 這些方式通常用在系統發展或是系統維護時，可使用種種工程技巧來進一部提升系統的穩 定度。然而系統在運作的過程中有可能因為種種因素而導致系統發生錯誤。建立一個零缺 點系統是很難達成的要求，同時在系統故障時再來檢討系統有何缺失對於本子計畫的高可 用度的需求不僅緩不濟急，也不切實際。因此必須讓系統具備在發生錯誤時依然能夠繼續 運作的能力，即是容錯（fault tolerant）。容錯的基本原理就是備份。“備份”指的就是在系 統運作所需的基本組件之外，額外配置的一些組件。備份的目的是在系統組件發生故障之 時，可以利用備份組件校正錯誤，或是用作故障組件的替換。如此一來就可以達成備份的 目的：當其中一個元件失效時，可以使用其他的元件取代。備份的方法分為三種，熱備份 (hot backup)、溫備份 (warm backup)、冷備份 (cold backup)，如圖五所示。
Server Hot Replica Server Hot Replica Server Hot Replica Client sy nc hr on iz a tio n Warm Backup Replica Warm Backup Replica Primary State updated State updated Client Cold Backup Replica Instantiation Primary State update Client Cold Replication
Hot Replication Warm Replication
Data Server Hot Replica Server Hot Replica Server Hot Replica Client sy nc hr on iz a tio n Warm Backup Replica Warm Backup Replica Primary State updated State updated Client Cold Backup Replica Instantiation Primary State update Client Cold Replication
Hot Replication Warm Replication
要達到這個目的，備份與主要元件之間必須能夠共有一致的程式參數狀態，如此在備份元 件啟用時才能接續服務現在正在使用中的客戶端程式。同時，為了要讓客戶端感覺不到錯 誤的存在，必須提供具有複本通透性 (replication transparency) 的複本管理機制，亦即一組 管理元件與其複本組成的群組所需要的相關服務，例如群組成員的加入與維護、主要負責 元件的挑選，或是對群組公告的傳播。因此對於元件群組而言，確保其各個成員達到全體 一致 (consensus) 狀態的演算法便成為研究的重心。在實際應用層面的考量上，由於分散 式計算環境潛在的不同步性 (asynchrony)，使得我們無法精確的預估不同機器間通訊延遲 (message delay)、時脈偏移 (clock drift) 與執行時間的上限。在上述的情況中所有需要群組 成員一致性的問題，將變得極為複雜與困難。為了讓複本管理機制的設計具有實用價值， 我們將致力於研究一些基礎問題的解決之道，其中最主要的是在分散式環境下錯誤偵測服 務以及群組成員協定。 錯誤偵測是所有一致性問題的核心，換句話說，一個分散式環境所能提供的錯誤偵測品質， 將影響建構在其上的應用系統效能。所謂錯誤偵測的品質主要是指偵測時間 (detection time) 與準確度 (accuracy)。提昇錯誤偵測的品質往往需要消耗多餘的系統資源，找出在花費代 價最少的情況下提供合理偵測品質的方法，對於系統設計者來說是非常關鍵與重要的。當 錯誤被偵測出來之後，群組成員協定則提供了群組內各成員調和 (coordinate) 狀態的管 道，利用這個管道各成員將可更新內部的狀態資訊，並選出新的主要負責服務的元件。在 以往的研究中多只針對電腦叢集(cluster)或具有高度同質性(homogeneous)的分散式環境討 論，但隨著相關技術的發展與普及，由各種具不同軟硬體架構的電腦所組成的異質性分散 式環境也越顯重要。因此我們必須構思如何對過去群組成員協定的方法做相關的調整與修 正，以達成更廣泛的應用。 最後，對於一個與狀態相關的伺服器應用程式來說，在正常運作時即需對其關鍵性的資料 做查核點 (checkpoint)，以便讓備份能夠回復。一般關於查核點設置的研究多著重於建立查 核點的時機，以及建置查核點的資料。以平行分散式系統來說，查核點的設置必須能達到 一致性 (consistence) 的資料點，如此才能用後退回復的方式繼續執行運算工作。頻繁的查 核點設定很顯然的比較容易在多個不同的執行緒中取得一致性的資料點，然而查核點的設 置本身即會佔用部份系統資源，而對於系統效率有實際而明顯的影響。現今研究的趨勢是 以系統事件（event）的方式進行持續性的查核紀錄 (incremental)，並將研究的焦點放在執 行緒與網路和儲存媒體的互動上。但在實際執行卻缺乏一套統一的範式 (infrastructure)。元 件程式的出現使得這個問題變得更為複雜。由於元件本身資料封裝的特性，比較難制定查 核點所必須涵蓋的元件範圍與負責執行查核點的元件。 仔細審視本計畫的需求，電子商務的運作過程，可以規劃出一個比較明確的查核點與回復 的問題領域： (1) 交易是以人為主的互動，因此處理的效率不是最優先考量的因素 (2) 客戶端可以忍受短暫的交易終止或服務中斷 (3) 資料（帳目）必須絕對正確
(4) 失敗的交易必須回應給客戶端 依據這些特性，本計畫可以用一個比較實用的解決方式：採用交易管理服務 (transaction service) 機制來進行資料查核點的建置。在商務與金融程式中為確保帳目的正確，需要大量 使用交易管理服務；在交易中的每一個步驟都需經雙方確認 (commit) 才能正式生效。在 這種情況下向後回復的機制是可以做到的。我們可以在交易確認時記錄負責進行交易過程 的元件查核點，藉由元件生命週期查詢服務，在系統進行後退回復時則可以訂出回復的範 圍，以確保資料與交易管制的正確進行。這種做法的缺點是需要較大的系統資源與較長的 後退回復範圍，但是以計畫系統本身的性質來說，資料的正確性為第一優先考量，同時客 戶端程式也是透過 HTTP 這種無狀態化 (stateless) 的網路協定，相信這會是一個適當的解 決方式。 3. 行動通訊領域的支援 隨著網際網路的普遍化，網路通訊的定義已經從傳統的定點對定點的通訊方式逐漸擴展， 而網際網路應用程式 (Internet application) 與行動通訊(mobile communications) 是目前相 當明顯的一個發展方向。行動通訊可以視為網際網路的一個延伸；無線傳輸的通訊協定發 展已使行動通訊的資料封包傳輸速率達到一個可接受的範圍。以純技術的角度來看，電子 商務可說是一種在網際網路 行動通訊網路上執行的應用程式伺服器。然而發展網際網路 應用程式與行動 通訊 應用程式，直接 會面 臨到的一項挑戰 即是 傳統伺服器 客 戶端 （Server-Client） 的通訊概念不再適用。系統架構本身需要進行相對應的調整，才能達成 新的需求。另一方面，電子商務本身對於系統的需求亦和一般的網站（Web-site）型應用伺 服系統不相同。在現有的商用環境中，從基地台到應用程式伺服器端的網路連線方式還是 採用傳統的 TCP/IP 方式進行。這種做法的好處是應用程式伺服器不需要太多的網路橋接 設備即可用來擔任行動通訊應用程式伺服器，同時可用 TCP/IP 本身的特性和一些資料容 錯技巧來減低資料傳送錯誤的機率。然而由於行動通訊基本上沒有一個服務的定點，因此 在維持連線和程式運作的狀態 (state) 方面存在相當大的挑戰。 網際網路的一個特點即是“非持續性”的網路連線。傳統以通訊閘 (socket) 為基礎的網路 通訊程式，伺服端 客戶端程式間雙方資料傳輸通道是持續性、具有狀態性的。當資料通 道因管線錯誤（pipeline failure）等軟體錯誤或實體線路故障等因素而導致連結失效時，雙 方皆能偵測出這個狀況並且採取因應措施。在這種情況下交易管理 (transaction management) 變得可以實作。然而 HTTP 或者 WAP 基本上是一種不具狀態性 (stateless)、非持續性的 連線。伺服器無法從傳輸協定中得知傳入的一連串請求是否來自同一個客戶端程式；一個 完整的 HTTP 傳輸僅包含一次的請求－回應組合，伺服器和客戶端程式之間的通訊管道會 隨即被關閉。對於需要數次資訊交換才能完成的應用或者具有狀態性的程式，例如商務交 易、證券查詢等，這種缺乏持續狀態的通訊方式會造成極大的困擾。 對於這個問題，一般的解決方案是使用“Session Tracking”。也就是讓伺服器端記錄狀態 值，並讓客戶端程式在請求中附帶身分驗證。每個客戶端程式都必須提供伺服器一個獨一 無二的身分識別代碼，或是其他足以讓伺服器處理後續請求的資訊。
Session Tracking 的技巧在傳統的 CGI (Common Gateway Interface) 程式中被廣泛使用，一 般常用的方式包括表單 (Form) 中的隱藏欄位 (hidden field)，URL 重寫 (URL rewrite)，以 及 HTTP Cookie 資訊等方式。在伺服器程式方面，藉由這種身分識別技術，已經能充分應 用於複雜的、需要狀態控制的程式。一些比較成熟的伺服器程式語言，例如 Java Servlet， 具有完整的 Session Tracking 的系統功能呼叫。在這些環境下，設計者可以將相當多的資 訊、甚至是一個完整的程式物件，存放入 Session 資料中。由此可以歸納出 Session 的一 個性質：Session 基本上是依存於應用程式 (application specified)，Session 存在的範圍也只 應侷限於應用程式所能提供服務的範圍。
回頭來看行動通訊網際網路應用程式的狀況；在現行的商業環境中，每個基地台可能是由 不同的系統廠商所提供，因此 Session 的資料不可能存放在基地台端。另一方面，應用程 式提供者也不可能安裝並維護數量龐大的基地台。同時無線通訊裝置本身和硬體及作業平 台相關，且運算資源較少，不適合發展客戶端 Session 物件。綜合以上數點，可以發現適 合用來提供 Session 的伺服器即是系統本身的服務窗口（service gateway）。當客戶端需要 在基地台間進行交替時，則可能會從一個服務窗口換至另一個服務窗口。服務窗口之間則 可以利用 Session Service 元件以分散物件功能呼叫等方式，在服務層之間交換 Session 資 料。Session 資料可以使用定時鏡射方式進行同步，或者在有必要的時候才做交換。 另一方面，由於行動通訊基地台本身是分散在各處，系統服務窗口也可有不同的配置方針： (1) 專注式服務窗口配置：每一服務窗口對應一特定應用程式元件界面。這種配置方式可以 減低每個服務窗口的複雜度，且若應用程式的使用頻率有地區專一性（例如物流服務 等），使用這種配置方式可以讓基地台至服務窗口間的路由途徑縮短，增加服務反應時 間。缺點是 Session 交換的頻率會增加，同時在系統擴充功能時需要配置新的服務窗口 伺服器。 (2) 單一式服務窗口配置：所有服務皆使用同一個服務窗口。這種配置方式可以完全不需要 進行 Session 交換，同時基地台的設定也是最為簡化的。這種配置方式的缺點是服務窗 口的複雜度比較高。另一個缺點則是基地台至服務窗口的路由途徑可能會變得很長。 (3) 混合式服務窗口配置：這種配置方式混合了兩種方式的優點，每一個單一服務窗口伺服 器皆可以接收所有服務，同時可以依照使用者的分布，在不同的地點配置服務窗口。這 種配置方式的缺點是服務窗口的複雜度較高，同時還是有機會需要處理 Session 內容交 換，另外在系統擴充功能時需要更新每個服務窗口的資料剖析器和資料格式分析器，維 護時比單一式服務窗口配置要複雜。但是這種配置方式的優點即是客戶端可以得到較快 的反應時間，同時當其中一個系統服務窗口故障時，可以立即使用另外的服務窗口取 代，不至於造成斷線。 由上可以看出第三種配置方式可以使系統獲得更大的彈性，不過在 Hand-Over 或是在服務 窗口故障更換路由途徑時，該使用何種策略來確保 Session 內容的同步更新，尚有許多地 方需要考量。
五、結果與討論 電子商務最重要的特質是其無遠弗屆的廣泛性，網際網路所能涵蓋的服務範圍將不僅局限 於某一區域網路、某一特定廣域網路；客戶端程式可能遍佈全世界，換句話說，客戶所在 位置可能分布在不同時區。這表示伺服器必須能夠提供每天 24 小時不間斷的服務。系統 本身需要具備相當的穩定度才能負擔這項工作。現今商務與金融體系的運作，最重視的即 是資料的正確性和一致性，而短暫的交易終止、服務中斷或是可以被接受的。因此本計畫 必須滿足系統穩定度的需求。首先，在實際執行部份，我們使用以下幾點考量作為選用相 關技術的評估標準： 1. 支援物件導向程式：選用的技術須支援物件導向技術，包括虛擬資料型別 (abstractive data type) 及多重繼承 (multi-Inheritance)。
2. 可以使用元件程式框架 (framework)：選用的技術必須可使用元件程式框架，以配合整 體系統架構的元件化目的。
3. 有完整開發、 除錯環 境：選用的技 術須有 完整的開發環 境 (integrated development environment) 以及除錯 (debugging) 工具。
4. 支援多種平台 (cross-platform)：業界商用的網路伺服器主機多為微軟視窗系統以及 UNIX 系統，其中視窗系統又分為一般 Win32 以及 NT 系統，UNIX 系統又分為以 Linux 為主的 System V 系列和以 Solaris 為主的 BSD 系列。為簡化在不同平台間移 植（Porting）的過程，選用的技術須能支援多種平台，尤以程式能跨平台為最佳。 5. 支援抽象資料形態：在應用程式層次與決策層次中期望能以一具有共通性、一致性的抽
象資料形態來做為資料本身的描述語言 (meta data type) 以及元件間的溝通管道。選用
的技術須能支援此種類型的資料形態直接存取或者匯入 匯出。
依據以上的要求我們可以規劃出系統發展的方向：使用 Java 程式語言進行系統開發，使 用 CORBA 作為元件的框架，並使用 XML 作為抽象資料形態的標準格式。Java 程式語 言本身即是完全物件導向，同時 Java 程式使用虛擬機器 (Virtual Machine) 的做法使得一 個 編 輯 完 成 的 Java 程 式 即 可 在 不 同 機 器 上 被 執 行 。 CORBA 是 共 通 物 件 呼 叫 架 構 (Common Object Request Broker Array) 的簡寫，由 OMG 聯盟所提出的一個元件式框架。 CORBA 本身具有完整的界面定義與物件函式庫 (CORBAFacilities & CORBAServices)，目 前業界有不少 CORBA 實作的框架套件可以選用。部份 CORBA 框架包含有容錯群組的 機能，可配合查核點與後退回復服務一併運作，以達到更高的穩定度。 再來，如前所述，錯誤偵測是整個容錯機制的第一步。我們必須先偵測出錯誤，才能對此 情形做進一步的處理。而在錯誤偵測方面，FT-CORBA 中並無太多著墨，於是我們提出一 個更完整的錯誤偵測機制。一般來說，錯誤偵測的方法有兩種，一是推動法 (push)，一是 拉動法 (pull)。推動法的方式即是由物件本身定時發送訊息通知錯誤偵測器，以告知錯誤 偵測器該物件目前正常工作中；而拉動法的方法則相反，是由錯誤偵測器定時地發送訊息 給物件，要求該物件回應以確定其是否正常工作。拉動法的方法在實作上比較容易，因此 在 FT-CORBA 中也是採用拉動法。在我們設計的錯誤偵測機制中，也是採用拉動法。此機
制的設計概念則是由每一個物件及錯誤偵測器自行去尋找對自己來說最適合的錯誤偵測
器，並向其註冊。在目前的設計，「最適合」指的是回應時間最短的，之所以以這個條件來
判定是否為最適合，主要是因為回應時間較短的話，當物件發生錯誤時，能比較快速地偵 測到錯誤。此外我們特別考慮到，因為錯誤偵測器也是一般 CORBA 物件，所以也有可能 會發生錯誤。我們可以考慮如圖六中所示的架構。
Application Object Application Object Process Object
Fault Detector
Application Object Application Object Process Object
Fault Detector
Application Object Application Object Process Object Fault Detector Process Fault Detector Process Fault Detector Host Fault Detector Host Host
Application Object Application Object Process Object
Fault Detector
Application Object Application Object Process Object
Fault Detector
Application Object Application Object Process Object Fault Detector Process Fault Detector Process Fault Detector Host Fault Detector Host Host 圖六、階層狀錯誤偵測架構 這類的階層式錯誤偵測設計，是 FT-CORBA 的文件中推薦適合用在大型系統的架構。由圖 中我們可以發現，若某一個錯誤偵測器發生錯誤，雖然此錯誤偵測器的錯誤可以被偵測出 來，然而其下的其他物件就變成沒有受到監視了，也就是說這些物件即使以後發生錯誤， 也無法被偵測出來了，因為負責監視他們的錯誤偵測器已經沒有繼續正常工作了。於是我 們便把備份的功能也加入錯誤偵測器中。在介紹這個機制之前，我們先介紹一個觀念 ─ 母 偵測器/子偵測器：若偵測器 A 監視偵測器 B，則我們稱 A 為 B 的母偵測器，而 B 為 A 的 子偵測器。為了避免因某一個錯誤偵測器發生錯誤而導致一些物件不受監視，我們把每一 個錯誤偵測器監視那些物件的資訊備份起來，以便在此錯誤偵測器發生錯誤後，能由其他 錯誤偵測器接管。而最適合備份的地方，就是母偵測器。因為母偵測器會是首先知道其子 偵測器是否發生錯誤，所以若每一個錯誤偵測器將其內部資料備分在母偵測器，那麼回復 的效率會最佳。因為在這樣的系統中每一個錯誤偵測器都必須被其他錯誤偵測器監視，所 以無論那一個錯誤偵測器發生錯誤，都不會造成有些物件不再受監視的情形。我們在每一 個偵測器中加入兩個資料結構，一為客戶表 (client table)，一為備份表(backup table)。客戶 表中紀錄所有被此錯誤偵測器監視的物件資料，而備份表則是紀錄了所有子偵測器的客戶 表。當某一子偵測器發生錯誤時，其母偵測器在偵測出此錯誤之後，便會從備份表中將此 子偵測器的客戶表移到母偵測器的客戶表中，接著這些物件就由母偵測器來接管了。 除了資料結構的 設計 之外，我們還需 要為 此機制中的錯誤 偵測 器設計一些運算 方法 (operation)。因為分散式物件應用程式是以物件彼此之間的交互作用(interaction)來達成的， 而此交互作用就是透過呼叫其他物件的運算方法。圖七中簡介三種主要的運算方法。
• accept—接收某物件的註冊，定時監測此物件的狀態 • add_backups—將傳送來的資料加入備份表
• update_backups—根據傳送來的資料更新備份表
圖七、錯誤偵測器的三種主要運算方法
以通訊的角度來看，可以把 CORBA 劃分為三層。最上層是 CORBA 用來執行程序呼叫 (method invocation)的基礎：ORB(Object Request Broker)，中間一層則是用來連結各台機器 上的 ORB 所需的通訊協定 GIOP (General Inter-ORB Protocol)，最底層則將 CORBA 本身的 通訊協定 GIOP 對映到實際網路上的通訊協定，如 TCP/IP。在這三層之上則有各家廠商所 自行開發的各項服務 (CORBA services)，它們提供了具有通用性與重覆使用性的標準介 面，可以讓系統開發人員方便運用。目前實作在 CORBA 上對於群組通訊的解決方法主要 可分為三類。第一類是將群組通訊與 ORB 整合在一起，例如 Electra system 和 Orbix + Isis。 第二類則是增加 GIOP 與群組通訊的對映，如 Aqua project 和 Eternal project。最後一類則 是將群組通訊建構在最上層，也就是自定的 CORBA 服務。這三類方法的差異可參考圖八。 IIOP GIOP ORB + Group Communication Services GIOP Services ORB
IIOP CommunicationGroup
GIOP Services
ORB
IIOP CommunicationGroup IIOP GIOP ORB + Group Communication Services GIOP Services ORB
IIOP CommunicationGroup
GIOP Services
ORB
IIOP CommunicationGroup
圖八、在 CORBA 上提供群組通訊的方法 這三類方法各有其利弊，例如第一類方法可以提供較佳的效能，但在通用性上就不如第三 類方法，必須要求各台機器上的 ORB 都是屬於同一家廠商的產品。因此要根據系統特性的 不同，來選擇適當的方法。對於異質性的分散式環境而言，要考慮各台機器軟硬體架構的 差異性。另外，我們也要注意實體網路的限制，例如多點傳輸(multicast)術雖然能讓第二類 方式的設計簡化，但應用的範圍卻大多只能侷限在區域網路上 (LAN)。如何達到在效率與 擴充性上的取捨 (trade-off)，將是群組通訊在實作上最重要的議題。 我們以之前的經驗為基礎，將錯誤偵測的機制擴展到應用系統的層級。也就是說，我們必 須找出在由眾多元件組成的應用系統中，如何設計錯誤偵測的架構，在消耗系統資源最小 的情況下，仍然可以有高品質的錯誤偵測服務。當整體的錯誤偵測機制建立以後，才有可 能發展群組成員協定。群組成員協定在提高分散式應用系統的可靠度上是很關鍵的技術， 因為有完整的群組成員協定，才能滿足應用元件群組之間的各項管理需求。因此我們不但 需要提出分散式的演算法，也需要實作元件間的群組通訊服務。為了達到以上的目標，我 們考量在分散式環境下所可能遇到的各種不同步性，並盡力消除所帶來的影響。 行動通訊網際網路應用程式和一般網際網路應用程式最大的差距即是在於行動通訊網際網
路應用程式的客戶端程式的位置非固定。如圖九所示，行動通訊應用程式的客戶端可能透 過一般網路連線（wired）或是無線網路（wireless）的方式跟基地台（mobile station）進行 資料交換，再由基地台向伺服器發出服務請求。綜觀以上數點需求，我們規劃出一個適用 於網際網路應用程式的系統藍圖：系統必須具備高度的擴充性、以及向前 向後相容 (backward/forward compatibility) 的技術。系統必須具備容錯機制以因應網際網路上大量的 使用需求，也必須能夠處理在無線通訊區域替換時與客戶端維持持續性的程式運作能力。 透過本子計畫，我們提出一個具體的系統規劃，達成這些需求，以因應電腦通訊技術的迅 速變革。經由本計畫的執行，我們期望能夠作為其他子計畫間的溝通管道（interface），結 合資料探勘技術與智慧代理人技術做到具有高度靈活度的客戶關係管理（custom relation manager, CRM）行銷管理，並結合高速通訊協定以達乘一通用型資料輸出入管道，最後在 配合資料保密技術以提供客戶與系統，以及系統與系統間的一個安全溝通管道。 Application Server Mobile Station Mobile Station Client Client Client 圖九、行動通訊網際網路應用程式架構 在與其他子計畫配合方面，依據本計畫所提出的多層次式中介服務架構，可以作為其他子 計畫不同層級間的共通資訊界面；子計畫一和子計畫二所提出的資料探勘繼續與智慧型代 理人技術實作了決策層的企業邏輯部份，同時資料探勘的結果則可以作為應用程式層級中 交易規則與促銷行為等客戶關係管理的依據。子計畫五實作了通訊協定層，替其他層次提 供了一個高速的資訊界面，而子計畫四則是在實體的通訊協定、以及分散式物件間的通訊 管道上加強安全防護。另一方面，藉由良好規劃的界面，個別子計畫可以進行獨立的發展， 而不用去處理細節的溝通、資料格式轉換、版本控制等問題。而容錯機制則可以確保獨立 的部件間不會產生鎖死的狀況，同時可以發展個別的錯誤處理程序以正確而迅速的處理不 同的錯誤狀況。也就是說，經由本子計畫我們發展出一個兼具彈性與效率的通用型電子商 務系統架構框架，並與其他的子計畫進行整合之後，將能建構出適用於傳統的網路架構、 網路瀏覽器為主的 HTTP 網際網路環境、現行的 WAP 行動通訊網路、以及未來可能的多 種無線網路環境。日前網際網路標準組織 W3C 通過以 XHTML 作為未來手提式行動通訊 終端設備的內容標準，同時下一代的行動通訊協定在數年內也會漸漸成熟；因此在可見的 未來，此項研究將具有相當大的實用性與商業潛力。
參考文獻
[1] Andrew S. Tanenbaum, “Computer Networks”, Prentice Hall Inc., 1996
[2] Thomas Wierlemann & Thorsten Kassing, “Performance of TCP/IP and its Application Protocols over Narrowband Bearers with high Latency”,
http://www.w3.org/1998/11/05/WC-workshop/Papers/wierlemann.html [3] Hunter & Crawford, “Java Servlet Programming”, O’Reilly, 1999
[4] Daniel J. Berg, “Advanced Techniques for Java Developers”, John Wiley & Sons, Inc., 1998 [5] Michael S. Jenkins, “Abstract Data Types in Java”, McGraw-Hill, 1998
[6] Matthew Siple, “Java Database Programming”, McGraw-Hill, 1998 [7] Elliotte Rusty Harold, “Java Network Programming”, O’Reilly, 1997 [8] David S. Frankel, “CORBA components”, JavaReport, Oct. 1999
[9] W. Richard Stevens, “Advanced Programming in the UNIX Environment”, Addison-Wesley, 1998
[10] Thomas J. Mowbray & William A. Ruh, “Inside CORBA”, Addison-Wesley, 1998 [11] Markus Voelter, “Aspect-Oriented Programming in Java”, JavaReport, Jan. 2000 [12] Richard Deadman, “XML as Distributed Application Protocol”, JavaReport, Oct. 1999 [13] William J. Pardi, “XML in Action Web Technology”, Microsoft Press, 1998
[14] Danny Goodman, “Dynamic HTML”, O’Reilly, 1998
[15] “Mobile Network Computing Reference Specification Consortium”, http://www.mncrs.org/ [16] “Considerations for Web Transaction Security”, RFC2084,
http://www.cis.ohio-state.edu/rfc/rfc2084.txt
[17] “HTTP State Management Mechanism”, RFC2109, http://www.cis.ohio-state.edu/rfc/rfc2109.txt
[18] “HTTP Spec”, http://www.w3.org/Protocols/ [19] “XML Spec”, http://www.w3.org/XML/
[20] “WAP – W3C White Paper”, http://www.w3.org/TR/NOTE-WAP
[21] IPng Mobility Considerations, RFC1688, http://www.cis.ohio-state.edu/rfc/rfc1688.txt [22] M. Sullivan and R. Chillarege, “Software defects and their impact on system availability – A
study of field failures in operating systems”, in Proc. IEEE Fault-Tolerant Computing Symp., pp. 2-9, 1991.
[23] J. Gray and D P. Siewiorek, “High-availability computer systems” IEEE Comput. Mag., pp. 39-48, Sept. 1991.
[24] B. Randell, “System structure for software fault tolerance”, IEEE Trans. Software Eng., Vol. SE-1, No. 2, pp. 220-232, June 1975.
[25] E. Adams, “Optimizing preventive service of software products”, IBM J. R&D, No.1, pp. 2-14, Jan. 1984.
[26] Y. Huang and C. Kintala, “A software fault tolerance platform”, in Practical Reusable Software, Ed. B. Krishnamurthy, pp. 223-245, John Wiley & Sons, 1995.
[27] Y. M. Wang and W. K. Fuchs, “Lazy checkpoint coordination for bounding rollback propagation”, in Proc. IEEE Symp. Reliable Distributed Syst., pp. 78-85, Oct. 1993.
計畫成果自評
本子計畫的目標在於對於行動電子商務的系統架構設計上遇到的挑戰尋求解決之道。首 先、我們將重點放在如何提供不間斷的服務，並建構一個具備高可用度 (availability) 的系 統。再來，各種網路相關的新技術發展非常地快速，使得軟體系統的生命週期變得相當短 促。因此在考量結合網際網路的應用伺服系統時，必須將系統的維護與日後功能擴充的可 能性列入考量。分散式物件技術是現今開發大型系統的重要趨勢。我們計畫的特點在於結 合了容錯的相關機制，使系統能達到更高的穩定性。 為了因應上述的目標，在本子計畫中，我們花費了相當多的時間在查找、比較和評估各種 可能的應用技術或重要觀念。我們決定引進分散式元件 (distributed object) 的相關技術，並 設計以多中介層次 (multi-tier) 的架構來提供不同的系統功能層級，以達成行動電子商務系 統之高度可擴充性 (high scalability)。另外，由於分散式元件本身具有良好的替代性，用於 架構系統將有利於系統的維護與更新。在提高系統的可用度方面。我們使用 OMG 的 CORBA 所提供的元件層級容錯群組技術，並引進查核點設定和後退回復服務的理論基礎。我們依 循不同層次的系統架構雛形，來制定不同的界面定義作為系統元件間溝通的標準，同時保 留足夠的彈性可以隨時加入新的需求種類。最後，本計畫加入 Java 程式語言以輔助系統開 發，並使用 XML 作為抽象資料形態的標準格式。Java 程式語言本身即是完全物件導向， 同時 Java 程式使用虛擬機器 (virtual machine) 的做法使得一個編輯完成的 Java 程式即可在 不同機器上被執行。因為 CORBA 本身具有完整的界面定義與物件函式庫 (CORBA Facilities & CORBA Services)，加上目前業界有不少 CORBA 實作的框架套件可以選用，新 一代的 CORBA 框架更包含了容錯群組的基本機能和發展方針。經由各種面向的探討和驗 證，我們相信本計畫的研究成果對於原來的目標有相當高的符合度。 藉由本子計畫的執行，我們能夠發展出一個兼具彈性、效率和可靠性的電子商務系統架構， 並以此作為與其他子計畫所發展不同層級系統服務間的共用資訊界面。我們預期這個架構 將能適用於傳統的固接式網路應用系統、以資料庫系統和網路瀏覽器為主的網際網路運算 環境，或是結合未來的第三代行動通訊系統 (3G) 等具有多樣性網路協定的環境。因此， 本研究計畫主要的價值在實際應用方面，可用來申請上述相關技術的專利，以增進我國在 工商業應用系統的發展和智慧財產權方面的競爭力。在學術價值方面，因為我們須瞭解如 何對關鍵性的資料做查核點 (checkpoint)，以便讓備份能夠回復，所以我們也研讀了相關的 學術期刊。一般關於查核點設置的研究著重於建立查核點的時機，以及建置查核點的資料。 以行動分散式系統來說，查核點必須能設置於達到一致性 (consistence) 的資料點上，如此 才能用後退回復的方式繼續執行運算工作。元件概念的引進使得這個問題變得更為複雜。 由於元件本身資料封裝的特性，比較難制定查核點所必須涵蓋的元件範圍與負責執行查核 點的元件。對於這些主題我們在計畫進行的同時亦投入心力在理論的驗證和改善上。總而 言之，基於本子計畫所累積的知識和經驗，我們對於中介軟體技術研發和相關的應用有了 更深入的心得，並相信這些成果將進一步引領在此方向上與世界級技術接軌的可能性。可供推廣之研發成果資料表
□ 可申請專利 □ 可技術移轉 日期： 年 月 日國科會補助計畫
計畫名稱： 高可擴充性與可用性行動電子商務中介軟體技術之研 發與實作 計畫主持人：郭斯彥 計畫編號： NSC 92-2213-E-002-011 學門領域：資訊技術/創作名稱
具高可擴充性與可用性的行動電子商務中介軟體技術發明人/創作人
郭斯彥 中文： 我們主要發展的技術在於： (1)使用元件程式框架，以配合整體系 統架構的元件化目的及提供元件分散計算與跨越平台的能力。(1) 使用 OMG CORBA 框架下的容錯服務來設計元件備份的機制。(2) 對於物件與交易服務進行查核點建立，以進行資料與服務的回復。 (3)提供系統元件之容錯，來實現系統之高可用度及高可擴充性。(4) 設計以使用 Java 程式語言進行系統開發，使用 CORBA 作為元件 框架，並使用 XML 作為抽象資料形態標準格式的系統開發觀念。技術說明
英文：The main techniques developed by this project are as follows. (1) How to decompose a huge system into components that are able to work across various platforms in a distributed manner. (2) How to recover data and services by setting checkpoints. (3) Provide a fault tolerance mechanism between the components. (4) Propose a new idea to design the architecture of business applications by adopting several state-of- the-art solutions such as CORBA, Java, and XML.
