而物件服務的 Use Case Diagram 如圖 4-2 所示

(1)

第4章系統架構分析

本章以 UML 分析系統模組之架構與功能，第一節對系統組成做一個概略的介紹；第二節深入說明系統運作所需要的各個模組，包括 SOAP Server、Domain Server、Object Manager、Object Observer；第三節說明伺服端的物件階層及其繼承關係；第四節說明客戶端的物件階層。

4-1 系統架構

圖 4-1 物件複製 Use Case

本系統的操作可以分為兩方面來說明，就管理者的角度而言，必須處理的是物件的複製、SOAP Server 的註冊登記、容錯策略的選擇以及物件狀態的掌握。

對客戶端物件而言，僅須實現物件服務的呼叫方式。複製是本系統運作的基礎，

而啟動複製前，通常會對目前容錯域（Fault Tolerant Domain）中的物件分佈進行瞭解；複製之後，還必須進行容錯策略的選擇，因此將這些需求以 Use Case 表現在圖 4-1 中。物件複製由 Object Manager 啟動，搭配 Domain Server 查詢目的站台；容錯策略的選擇則由 Object Manager 發出請求，對 Domain Server 進行內部參數設定；物件狀態取得則由 Object Observer 啟動，再經由 Domain Server 取

(2)

得各物件位址。

複製過程包含物件初始化，因此物件經過複製程序就可以開始提供服務。而物件服務的 Use Case Diagram 如圖 4-2 所示。

圖 4-2 系統服務 Use Case Diagram

由於系統中所有的伺服端物件的執行(Server Object Operation) 都必須依附在 Apache SOAP 之下運作。因而使用者與 SOAP Server 間，存在一個物件的操作程序，這也表示了 SOAP Server 在客戶端及伺服端之間溝通的角色。而 SOAP Server 與 Domain Server 之間存在一個註冊程序，這代表系統啟動之初的位址登記，以及提供服務的過程之中，SOAP Server 的位置會有所改變，因此不斷地進行 Update Server Address 的請求。

User Agent 是使用者端介面，當使用者要求一個服務時，會進入 Invoke Service 的階段，此時為了掌握 SOAP Server 的資訊，必須經由 Query Server Address 的程序來查詢，這兩個需求有著包含的關係，而查詢過程僅牽涉到使用者與 Domain Server 兩端。

就組件的觀點來看，本系統由五個組件構成。分別是、位置伺服器、容錯物件、客戶端物件、物件管理員與物件觀察代理者。其中物件管理員作為接收及傳

(3)

送物件之用；位置伺服器則是一個分散式架構的管理系統，用來管理 SOAP Server 的位置；容錯物件是實作各種容錯策略的伺服端物件，其容錯策略的實現可藉由父類別繼承而來；客戶端物件是位於客戶端的應用程式，開發人員也可以利用繼承的機制獲得呼叫伺服端容錯物件的方法。

本系統以 JAVA 語言實作，組成元素的類別名稱整理如表 4-1 所示：

組件實作類別

位置伺服器 DomainServer 物件管理員 ObjectManager 物件觀察代理者 ObjectObserver 容錯物件 FaultTolerantObject 客戶端物件 FTClient

表 4-1 系統組件

圖 4-3 系統組件的 Class Diagram

圖 4-3 說明了各組件之間的關係。Object Manager 可以透過 Domain Server 得知系統中所有的 SOAP Server 位置，也可以呼叫 Object Stage 以進行複製的動作。但在實作上 Object Stage 是 Object Manager 的一部份，因此存在 aggregation

(4)

的關係。ServerAP 代表伺服端的容錯物件，其與 Fault Tolerant Object 存在繼承關係，表示容錯策略的實作是經由繼承而來。然而，Fault Tolerant Object 的子物件之間又有互相通訊的需求，因此必須內含 FTUtils，且兩者之間有 aggression 的關係。ClientAP 是客戶端的應用程式，因與 FTClient 有繼承關係，才能快速獲得呼叫 ServerAP 的方法。但是，ClientAP 為了發出請求，必須仰賴 FTUtils 的輔助，因此，兩者間仍有 aggression 關係。而 Object Observer 透過 Domain Server 查詢系統中的物件，兩者間存在著呼叫引用的關係。在這個 Class Diagram 中，

也充份表現出 Domain Server 在整個系統中居於樞紐地帶，其餘四個組件都必須透過 Domain Server 進行服務物件的位址查詢。

4-2 相關組件

本節對系統相關組件包括 Object Manager、Object Observer、SOAP Server 以及 Replication Utilities 之功能及運作方式作詳細的說明。

4-2-1 物件管理員(Object Manager)

物件管理員程式提供一個簡易的方式，讓管理者對物件進行操作。其中包括圖形介面（OM-GUI）與物件中繼站（OM-Stage）兩個部份。

OM-Stage 是每一部參與運作的主機都必須要有的組件，型態上以一個架構在 SOAP Server 上的服務程式存在。OM-Stage 一旦啟動後，即準備接受 OM-GUI 或其他 OM-Stage 的請求，其主要功能如下：

（1）支援物件複製之訊息傳遞，將物件包裝在 SOAP Message 中，並解析參與運作的站台列表，往下一個目的地傳送。

（2）接收到前一個 OM-Stage 所送出的 SOAP Message 後，會將內含之物件還原成檔案型式，並嘗試啟動及初始化相對的物件。

OM-GUI 是以 Swing 開發的使用者介面，其型態為一個獨立的 Java Application，只需安裝在管理者當地的主機上，提供管理者一個選單式的操作方

(5)

法，並與散佈在各地 OM-Stage 溝通。功能主要如下：

（1）啟動複製或關閉已啟動的物件服務。

（2）設定及顯示各物件的狀態值。

（3）藉由現行容錯模式的切換，改變容錯策略。

（4）設定模擬狀態，經由 Domain Server 的內部參數改變，達到模擬通訊網路分割的效果，作為功能評估之用。

物件複製依目的地的不同，共有三種方法可以選擇，每一次啟動複製前，管理者可以經由 OM-GUI 擇一進行：

（1）複製至所有主機上：以目前 Domain Server 內登記的所有主機為目的地。

（2）複製至指定主機上：管理者經由 OM-GUI 選擇特定的目的站台。

（3）複製至一定數目主機上：由管理者指定複本的數量，而系統自動選擇適合的目的站台。若複本數目大於主機總數，則同一主機可接受兩個以上的複本，並以序號加以區分。

實際操作時，管理者可以經由圖形介面選定欲複製的物件檔案，並決定目的節點後，按下複製鍵，以啟動複製機制。至於容錯策略的選擇上，內定使用動態投票的方式來運作。在系統運作期間，管理者可經由 OM-GUI 隨時切換容錯策略，以符合需求。錯誤狀況模擬是為了評估而設計，啟動模擬之後，物件可以形成數個群組，以便觀察其容錯特性。

圖 4-4 是 OM-Stage 的介面定義，主要包括三個呼叫介面及一個相關函式。

由於介面受到 Apache SOAP 的服務註冊機制所管理，因此可接受遠端呼叫，而函式則供物件本身使用，相關的解說如表 4-2 所示。

收到訊息的節點可從中取出物件檔案資訊並加以儲存。而由訊息中亦可得知其他的目的站台資訊，因此可將此訊息傳至下一個 SOAP Server，由該站台之 OM-Stage 接收，達到連鎖反應的效果。

接著，以圖 4-5 的實例，描述兩個 OM-Stage 之間，進行物件複製、啟動及初始化等動作流程：

(6)

圖 4-4 OM-Stage 之介面定義

isAlive( ) 提供遠端物件 OM-GUI 或 OM-Stage 偵測本地端 OM-Stage 是否運作正常。

isObjectFileExist( ) 偵測目的站台之物件是否先前曾經接受複製，若是，則 SOAP 訊息中不攜帶物件程式碼。

介面

receive( ) 接收 SOAP Message，將其中攜帶的物件還原為檔案，並呼叫 replicachain( )進行處理。

函

式 replicaChain( ) 找出複製流程的下一個站台，並繼續複製工作，

如本身為複製的終點，則啟動物件並初始化。

表 4-2 OM-Stage 介面定義功能說明

（1）當目的站台資訊存在兩筆以上的資料時，本地端會解析目的站台列表並將其平均分割為兩份，將不包含本身位址的列表作為此次複製所處理的對象，而該列表的第一個項目即為此次複製的目的地。

（2）啟動包裝 SOAP Envelope 的執行緒，將物件服務啟動資訊、物件檔案名稱及目的站台列表（前一步驟分割後的結果）包裝在訊息之中。

（3）呼叫遠端 isObjectFileExist( )介面，判斷物件是否已經存在遠端，以決 package objectmanager;

public class ObjectStage {

public ObjectStage()throws IOException{

}

public boolean isAlive(){

}

public void receive(Envelope env, SOAPContext reqCtx,SOAPContext resCtx)

throws MessagingException,IOException { }

public void replicaChain(Element deployDescriptor, String ofName, Element repSites){

}

public boolean isObjectFileExist(Vector rpcParam){

} }

(7)

定是否必須在 SOAP Message 中包裝物件。

（4）送出 SOAP Message，由本地端 Stage-X 呼叫 Apache SOAP 所提供的函式庫，透過 HTTP 往遠端的 SOAP Server rpcrouter 發送，並指定收件者為 Stage-Y 且接收介面為 receive( )。

（5）遠端的 SOAP Server 接收訊息之後，轉送給 Stage-Y，並由一執行緒負責處理，將 SOAP Message 內含的物件予以檔案化，接著解析目的站台列表。

圖 4-5 物件複製 Sequence Diagram

（6）若 Stage-Y 所得到的目的站台列表僅有單一筆資料，則資料內容必定為

(8)

該站台位址，這代表複製行程已達終點。此時可將 SOAP Message 之 DeployDescriptor 取出，並向當地的 SOAP Server 進行登記，新的服務物件複本隨即產生。若目的站台列表中的資料不只一項時，則由步驟(1)開始，繼續進行複製。

上述步驟(3)，在進行訊息包裝之前，先確定目的地是否已存在物件相對應的檔案，是為了節省網路資源及編碼、解碼的時間。由於在步驟(5)會將接收到的物件予以檔案化，這也意味著曾經複製過的物件會在該主機上留下對應的類別實體。當管理者再次啟動複製時，物件主體可以就地取用該檔案，於 SOAP Message 中僅須包含物件的狀態與目的地列表。如此一來，不必將物件本身重複傳送，達到快取的功能。

4-2-2 物件觀察代理者(Object Observer)

為了操作上的方便，管理者這可以透過物件觀察代理者來瞭解系統內的物件資訊。這是一個圖形介面的程式，具有定時查詢整個容錯域中物件運作狀態的能力。如同前一章所述，物件資訊會被表示成 FTDL 的格式，經過彙整後，再以樹狀結構顯示出來。主要組件如表 4-3：

Poller 繼承 java.util.TimerTask，因此可以定時蒐集物件資訊，整理成 FTDL 檔案，並依照使用者的選擇，結合不同 XSL 檔。

DTCellRender 為 JLabel 之子類，作為 DOM Tree 樹狀結構的顯示之用

表 4-3 物件觀察代理者內含之組件

FTDL 利用物件所在主機的位址或物件名稱作為鍵值，可以有兩種排序方式。實作方法是將 FTDL 結合 sortid.xsl 與 sortname.xsl 兩個不同的 XSL 檔案。

關於這兩個檔案的內容，可參閱附錄二。

4-2-3 Apache SOAP Server

Apache SOAP [2] 套件是 Apache Software Foundation 針對 SOAP v1.1 [4] 及 SOAP Messages with Attachments specifications [1] 兩個規格，在 Java 語言上的參考實作。分散式物件之間以 SOAP 進行通訊時，Apache SOAP 提供了包裝及送

(9)

收 SOAP Message 所需的底層 API，而對 Server 端來說，配合適當的 Servlet Container （例如: Apache Tomcat），則可隨時聽取 SOAP Message。

Apache SOAP 在 Server 端的工作方式有 Message 與 RPC 兩種，所謂的 Message 模式，就是 SOAP Server 啟動之後，隨時接收以下格式的訊息：

在此訊息之中，<s:Body>與</s:Body>間的內容是使用者必須自行包裝的部份。而上例中的 Name Space─”urn:ObjectStage”是一個已經在 SOAP Server 內註冊的服務，代表這個訊息將會被送往名為”urn:ObjectStage”的服務物件，而

<receive>這個標籤則表示，該物件的 receive( )方法會處理這個訊息。之前介紹的物件複製機制就是在這個訊息處理的方法中，進行物件存檔及服務登記。

至於 SOAP Server 的服務註冊功能，可以利用內附的 Web 介面程式處理，

步驟如附錄所示。但在實作上，若需以程式控制，則可利用 Apache SOAP 中 ServiceManagerClient 物件的 deploy( )方法來達成。同理，對於正在運作的服務，

也有 undeploy( ) 方法可以將其停止。

註冊的意義在於維護一個服務物件之邏輯名稱與其實體類別間的對應，因此在呼叫 deploy( )時，會傳入一個部署描述器（DeploymentDescriptor, DD）型態的參數，這是一份 XML 格式的文件，以 4-2-1 複製服務的例子來說，DD 便記載了”urn:ObjectStage”這個邏輯名稱與其所實際對應的 Java class（含 Package）

─”objectmanager.ObjectStage”，以便 SOAP Server 可以正確啟動該物件服務。此外，利用 list( )方法，可以得知所有已註冊的服務資訊，這提供給物件尋找機制一個方便的搜尋管道。

而 RPC 工作模式為 Message 的一種精緻化特例，為了簡化 SOAP 訊息的包

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">

<s:Body>

</receive>

</s:Body>

</s:Envelope>

(10)

裝方式，Apache SOAP 提供更高階的 API，讓客戶端以函式呼叫的方式，將欲傳遞的訊息當作參數，透過一個簡單的介面傳送出去，伺服端則利用函式實作的方式，從參數列中取用該訊息。遠端程序呼叫透過 Apache SOAP 的 RPC 機制實現會相當的透明，就如同近端程序呼叫一樣方便，使用者完全感受不到 SOAP Message 的存在。

4-2-4 輔助組件集(Replica Utilities)

本系統運作時，許多重複的動作會相當頻繁。例如以物件名稱來尋找物件會發生在物件之間的同步化、客戶端呼叫伺服端服務以及物件觀察代理者的查詢工作。除此之外，SOAP Envelope 的產生在整個程式寫作中也處處可見。為了開發上的便利性，故將上述的機制整合於 replicautils package 中。

表 4-4 中列出了 Replica Utilities 的主要類別，而這些類別與整個系統有密切關聯，無論容錯物件，客戶端程式或是物件觀察代理者，均擁有這些類別的物件實體（instance）。

QObjRummager 用來更新 SOAP Server 位址、通知 SOAP Server 進入模擬狀態以及利用 ApacheSoapSurrogate 作物件搜尋。

ApacheSoapSurrogate 發出 SOAP Message 與 Apache SOAP 溝通，進行條件式的服務搜尋。

SetManager Quorum Set 選取方法的實作，可依選取之演算法隨機產生 Update-Set 與 Query-Set。

Spokesman

執行緒化的 SOAP Message 代言人，會啟動新的執行緒，輔助包裝資料及設定目的位址並向 SOAP Server 發出訊息。

表 4-4 Replica Utilities 所包含之組件列表

4-3 伺服端物件階層

本系統在伺服端的物件階層在第三章曾經提及，服務物件可以分為兩類，一類完全不含容錯策略實作，另一類是則由父物件繼承某種的容錯策略。但是在多個複本的情形下，兩者皆具有提供容錯服務的能力。因此，Fault Tolerant Object

(11)

(FTO)在本系統中，是所有容錯物件的父物件，其屬性包括容錯物件該具有的最基本性質，如物件的邏輯名稱、位址資訊及物件在其所屬 SOAP Server 中的序號等。這些資訊的組合可以形成唯一的鍵值，也在容錯域中代表獨一無二的物件。

當一個物件提供服務時，這些資訊可作為辨識或搜尋之用。

從 FTO 衍生的子類別依照不同的容錯策略可以將其分類，本論文實作了三種：採 Primary-Backup 者，歸為 PBO 類別；採 Dynamic Voting 策略者，歸為 DVO 類別；採 Quorum 策略者，歸為 QRM 類別；對於程式開發者來說，每個類別都提供 invoke( )介面，供遠端呼叫之用，無論物件之間傳遞訊息，或者是物件管理員對物件進行初始化，都可以透過 invoke( )介面進行，只須利用不同的參數加以區隔即可。因此，invoke( )必須接受兩個參數，第一個是功能字串，用來判別呼叫時所需執行的動作，第二個參數是 Vector 型態，內含該動作所需處理的資料及相關控制命令。當 invoke( )完成呼叫後，會傳回一個 Vector 型態的變數，內含此次呼叫的處理結果。而上述各容錯物件類別因為運作方法不同，各具其必要的屬性與方法，也就是該類別的容錯策略實作，以便繼承給子類別。FTO 因為是集各類之大成，具有各類別共通的方法定義，如表 4-5 所列。

setup( ) 初始化時設定內部參數，如：物件位址、邏輯名稱 getFTDL( ) 傳回 FTDL 表示其內部參數值

writeFTDL( ) 將內部參數之 FTDL 文件儲存為檔案格式 setupFromFTDL( ) 將物件以 FTDL 之記載作初始化

表 4-5 FTO 提供之方法

4-3-1 Primary-Backup 物件

這類物件根據 PBO 衍生而來，其內含 status 的參數，記錄目前物件所扮演的角色。表 4-6 列出 PBO 所提供的方法：

backupProcessing( ) 處理 backup 物件與 primary 物件的同步工作 getStatus( ) 回傳目前的工作角色（primary 或 backup）

表 4-6 Primary-Backup 物件提供之方法

這類物件若為 primary 角色，會負責處理 client 端的請求，並維持各物件的

(12)

狀態一致性，其運作流程以圖 4-6 表示：

圖 4-6 Primary-Backup 物件接受請求之循序圖

圖 4-6 表示 primary 物件與 backup 物件之協同運作情形，以下分別說明之：

（1）客戶端發出請求：經由 Domain Server 得到 primary 物件的位址，並將請求送往 primary 物件。

（2）呼叫備份函式：primary 物件呼叫 backupProcessing( )，將請求發送給所有 backup 物件。

（3）進行請求處理：primary 物件進行請求處理，並利用 writeFTDL( )將物件最新狀態存檔。

（4）回應客戶端：Primary-Object 將請求處理結果回覆給客戶端。

4-3-2 Dynamic Voting 物件

這類物件根據 DVO 衍生而來，而 DVO 已將動態投票演算法實作完成，並提供呼叫介面，因此 DVO 物件內含三個必要的參數：物件狀態的版本號─

(13)

objState（OS），初始值為 0；所有的物件複本數目─objCardinal（OC），初值亦為 0；識別物件─distinguishedObj（DO），複製過程產生的第一個物件。表 4-7 列出 DVO 所提供的方法：

concurrencyControl( ) 針對所有物件發出同步請求，以確保同一個時間內只進行一次投票。

dynamicVotingBegin( ) 接受 Client 端請求的物件可以呼叫此方法，以進入投票程序。投票結果傳回值若為 0，代表非多數部份；1 代表該物件處於多數部份;2 代表處於多數部份，但其值並非最新。

dynamicVotingEnd( ) 若物件處於多數部份，則允許提供服務，並利用此方法呼叫所有物件的 invoke( )介面，完成 commit。

getCatchUpValue( ) 當物件狀態並非最新時，利用此方法向其他狀態最新的物件要求同步。

getStatus( ) 傳回目前物件的 OS、OC、DO 值。

表 4-7 Dynamic Voting 物件所提供之方法

提供服務的投票過程如同圖 4-7 所示：

（1）客戶端發出請求：經由 Domain Server 找到任一個可提供服務的物件，

本例中為 Server-A。

（2）進入投票程序：Server-A 呼叫 dynamicVotingBegin( )，進行投票。利用 objectManager 的 findServicesWithNameInSpecifiedMode( )方法，得到所有執行中的物件。再以本身的 concurrencyControl( )方法，對所有物件，

即 Server-B 及 Server-C 進行同步請求。完成之後，針對所有物件發出投票請求。

（3）判斷投票狀態：Server-A 蒐集由其他物件傳回的投票結果，判斷 Server-A 是否處於多數群組。符合條件則可提供服務，接著判斷其內容是否為最新，若否，則呼叫 getStatus( )以獲得最新狀態。

（4）完成請求：Server-A 呼叫 dynamicVotingEnd( )進入投票結束階段，若符合提供服務的條件，則以 Server-B 及 Server-C 的 invoke( )介面做 commit，否則做 abort。

(14)

（5）回應客戶端：Server-A 回覆處理結果。

圖 4-7 Dynamic Voting 物件接受請求之循序圖

4-3-3 Quorum-based 物件

這類物件根據 QRM 衍生而來，在此策略下，物件之間並無訊息溝通，僅存在客戶端與服務物件間的訊息傳遞。QRM 所提供的方法如表 4-8 所示，而物件狀態的更新與查詢則表現於圖 4-8 中。

shareLock() 進入查詢模式，禁止更新狀態，但仍提供其它查詢服務 unlockShare() 解除查詢模式的鎖定

exclusiveLock() 進入更新模式，停止任何服務 unlockExclusive() 解除更新模式的鎖定

表 4-8 Quorum-based 物件提供之方法

(15)

若以圖 4-8 為例，可列出資料更新操作步驟為：

（1）客戶端發出請求：由 Quorum 演算法得到對應的 Update Set，假設在此例中求得 Server-A、Server-B、Server-C。

（2）進行更新請求：針對 Update Set 內之物件發出更新請求。

（3）蒐集時間戳記：比對各服務物件之時間戳記，確定最新資料版本。

（4）進行資料更新：針對 Update Set 內之物件作資料更新。

圖 4-8 Quorum-based 物件接受請求之循序圖

資料查詢的步驟與資料更新之前三項相似，而查詢之結果亦透過時間戳記的

(16)

比對，與步驟 4 相同。

4-3-4 一般伺服端物件

在某些應用上，物件僅提供查詢的功能，因此不需考慮物件狀態一致性的問題。此種物件之所以能夠容錯，在於同時存在多個複本，只要有一個複本可以正常工作，查詢服務就可以不中斷。對這類一般化的物件，系統給予的支援是複製以及位址查詢。實作上，必須繼承 FTO 以獲得容錯物件最基本的屬性。

4-3-5 容錯應用物件(Business Object)

之前所提及的四個容錯物件類別，分別具有不同的容錯策略。身為一個程式開發者可以依自已的需求，繼承其中一個類別，以實作出該類別的容錯物件。在實作過程中還必須注意 FTO 的方法覆寫（override），表 4-5 所列的三個方法，在不同的物件中，會有不同的版本。在不同的應用物件中，也必須要依照不同的需求，進行改寫。

4-4 客戶端物件階層

客戶端的程式會透過 SOAP Message 來呼叫伺服端的服務，所以也必須要有收發 SOAP Message 的能力，於是在本實作中，提供了客戶端的基礎物件，以便客戶端的應用程式可以快速開發。

在第二章中，曾經提到 Client 端會透過一個 Front End 與 Server 端連結。實作上，本系統以 Handler 類別實現其功能。圖 4-9 是 Handler 的 Class Diagram。

由於不同的伺服端物件會有不同的操作方式，因此依照 4-3 節所提到的四個物件類別，會有四個不同的 Handler 產生。而由 QObjRummagerClient 判別目前使用的容錯策略、啟用正確的 Handler。

PBHandler 可以與 PBO 溝通，其功能如下：

（1）查詢並製作所有 Primary-Backup 物件列表，如果查詢成功，則於列表中找出 Primary 物件。

(17)

圖 4-9 客戶端物件階層圖

（2）若 Primary 存在，則利用 Replica Utilities 中的 Spokesman 向 Primary 物件請求服務，否則選取新的 Primary 物件，再進行服務請求。

DVHandler 負責與 DVO 物件溝通，其功能如下：

（1）查詢所有 Dynamic Voting 物件，依照物件所在的位置作為選取條件，

選出最適合提供服務者。