3-2-1 物件複製

(1)

第3章 XML-Based 分散式容錯物件

本章主要探討在 XML 平台上以 SOAP 相關技術進行物件容錯、複製的意義及問題所在，並提出解決問題的對策。第一節說明容錯物件階層結構及容錯策略的運用；在第二節中提出物件平台的相關功能，包括複製機制、複製後的位置管理及狀態描述。本章所提及之系統運作概念如圖 3-1 所示，主機間的通訊協定為 SOAP，客戶端可經由 Apache SOAP 或 JAXM 函式庫產生 SOAP 訊息，以呼叫服務物件。而伺服端的物件間互相溝通、使用者端對服務物件之查詢、SOAP Server 的位置登錄及更新也都以 SOAP 訊息達成。

圖 3-1 XML-Based 容錯物件平台模型

3-1 分散式容錯物件結構與容錯服務

分散式物件之間的溝通平台有許多的選擇，本論文所討論的是 Loosely-coupled 分散式物件，且以 XML/SOAP 為實作技術。於先前的討論中可以得知，諸如 CORBA、DCOM、RMI 等標準幾乎皆有成熟的規格。然而在

Client Object Server Object

SOAP Server

Object Observer Domain

Server

Object Manager SOAP

(2)

XML-based 平台上，利用 SOAP 來達成遠端物件呼叫的相關標準尚在研議中，

尤其在容錯方法上仍需進行探討。

以目前情況來說，SOAP 1.2 是 W3C 的 Working Draft，之前的 1.1 版也僅至 Note 階段，雖然概念已經確立，但是細部的規格仍在修訂中。在這同時，許多軟體研發團隊都推出參考實作工具，如 Microsoft 的 SOAP ToolKit、Apache 的 Apache SOAP 以及 Sun 的 JAXM 等等。由於 Microsoft 的方案必須架構在專有的.Net 平台之上，基於跨平台的考量，本實作選用了 Apache 和 Sun 所提供的開發工具，並搭配 Java 語言來實作，結構上如概念圖 3-2 所示。

圖 3-2 組件結構概念圖

其中的 Object Manager、Fault Tolerant Object（FTO）、Object Observer 及 Domain Server 是自行開發的成果，而 SOAP Server 則採用 Apache 提供的套件。

對於容錯應用物件的開發者來說，只要繼承 FTO，就可使其物件具有容錯能力。

因此可以將大部份的時間投入在物件服務本身的功能設計上，使得程式開發流程更快速，減少除錯時間。

結構上位於核心的 Domain Server 是一個 Quorum-based 位置管理系統。由於本論文需要一個 Naming 機制，又因為 SOAP Server 所在的主機可能是一個行動

Domain Server Object

Manager

Soap Server

Client

FTO FTO FTO

Soap Server FTO

FTO : Fault Tolerant Object Object

Observer

FTO

(3)

裝置，例如 PDA 或者是 Note Book，其位置可能隨時會改變。再加上容錯的考量，為了服務可以隨時讓客戶端使用，因此提出一個物件找尋的機制也是必要的。本實作中，Domain Server 利用 Sun 提供的 JAXM 套件所開發，其功能在於提供物件的名稱與位址對應，與物件本身容錯能力無關。因此對於容錯物件服務平台來說，可以看成是一個獨立的外部輔助系統。換句話說，如果有其他機制可以取代此功能，Domain Server 可依需求更換，而不影響容錯物件的能力。

圖 3-3 容錯物件階層

為了搭配以上兩個套件，選擇 Java 語言是必要的。除此之外，Java 還有幾項特色，對本實作提供相當多的便利性：

（1）在虛擬機器(Virtual-Machine)上運作，使得開發過程可以在不同平台上

(4)

工作以及開發成果得以跨越不同平台(cross-platform)。

（2）完全的物件導向概念，使得程式架構明朗、縮短開發及維護時間。

（3）多執行緒(multi-thread)的支援，使得 SOAP 訊息發送、接收可以由獨立執行緒負責，加快反應時間。

依照容錯策略的不同，在實作上會有各種不同的容錯物件產生，因此可以將共同的部份抽出，形成階層式結構。如圖 3-3 所示，本論文以重複物件為核心概念，所有物件都會繼承 Replicate Object，再依照不同的容錯策略所需，衍生出不同種類的物件。

當系統中存在有多個物件複本，且每一個物件都可以提供服務時，其中一個複本的狀態改變若不能夠反映在其他複本上，就會造成物件狀態不一致，因此必須尋求一個適當的解決方法。

圖 3-4 伺服物件狀態改變

圖 3-4 以實例說明這個問題，圖中有三個物件複本(S)，其原始內部狀態皆為 A，且同時可接受 Client 端(C)的呼叫。其中最左方的複本經 binding 之後，成為提供服務的物件，因此其內部狀態由 A 轉變為 X，很明顯地，另外兩個物件內部狀態仍為 A。因此，物件狀態一致性是必須先面對的問題，先要能正確地處理

S S S

C

SOAP

X A A

註︰S 表示伺服端物件﹐C 表示客戶端物件 A､X 表示物件內部的資料成員

(5)

才能進一步實現服務的容錯能力。在實作上，因為容錯策略的不同，這部份會有不同的實作方法，以下分別討論之。

3-1-1 Primary-Backup

這是一種最基本、且最直觀的容錯方法，正常情況下，當使用者發出服務請求時，可以經由 Domain Server 查詢服務得到一個 Primary 物件的位址，再進行物件呼叫。Primary 物件在第一次接受呼叫時，也會利用 Domain Server 查詢所有 Backup 物件位址，並儲存於快取之中，以便將來的呼叫可以隨時取用。接著利用 SOAP 將呼叫送給所有 backup 物件，當所有 backup 物件都接受之後，Primary 物件執行此呼叫，並將結果回覆給使用者，利用上述步驟，可維持所有物件狀態的一致性。

當 Primary 物件發生故障時，經由 Domain Server 所得到的物件皆扮演 backup 角色。此時必須進行新的 Primary 物件選取。由先前的討論得知，於此策略之下，

物件可以排列為一直線。實際應用上，利用物件在 Domain Server 內註冊的順序排列，恰可以得到邏輯上的線形。一旦在 Primary 物件無法提供服務時，即假設其已經發生故障，接著找到下一個可正常工作的物件，取代成為新的 primary 角色，使得服務不致於停擺而達到容錯的目的。循序選取的做法使得 Primary 角色的指定只針對單一個物件進行，而且角色指定是等效(idempotent)的，即使連續執行兩次 Primary 物件的選擇，也不會產生角色混淆。至於如何判斷物件故障或是網路分割造成的暫時性通訊中斷，則不在討論範圍之內。

3-1-2 Dynamic Voting

為了使得每一個投票物件皆允許使用者呼叫，本論文也利用動態投票演算法實作容錯物件。任何一個物件在接受使用者的請求之後，都可成為投票的發起者，接著從投票的結果中，判斷目前物件所在的群組是否為多數，位於多數群組的物件可以提供服務，其他群組的物件則必須暫停服務。所以，該演算法也保證這些被分割的群組中，只有一個群組的物件可以提供服務。以維護執行服務所需的物件一致性。

(6)

而所謂的多數群組可以利用以下兩個基本原則來判定：

（1）依據物件的個數：首要的判別條件是目前群組內，擁有最新狀態的物件數目，如果大於物件總數的一半，則為多數群組。

（2）依據識別物件所在：當上述的物件數目正好是物件總數的一半時，如果擁有識別物件，也可視為多數群組。

識別物件的初始值為第一個複製目的站台所啟動的物件，往後如果發生識別物件故障，或者識別物件不存在多數群組之內，則由發出投票請求的物件繼續擔任識別物件的角色。若兩個物件同時發出投票請求時，則以時間戳記互相比較，

較小者具有較高的優先性，若時間戳記相同，則以物件識別碼來決定。

動態投票演算法可以針對投票當時可參與的物件進行表決，雖然當多數群組再次分割之後，可能造成任一個群組的物件個數都不能形成原有的多數，但是動態投票策略藉由每次投票後都會更新物件總數的做法，只需在每次分割之後都有一次以上的投票完成，便可以解決這個問題。

每個容錯服務物件除了必須實作投票演算法之外，在投票機制運作上，物件內部設計有以下的輔助參數：

（1）物件狀態(Object State, OS)：為一個整數值，用來表達物件內資料被更新的次數，也就是說每提供一次服務其值就會增加。投票機制啟動時，

擁有最新狀態的物件才有投票權。

（2）物件基數(Object Cardinality, OC)：為一整數值，表示目前群組中，擁有最新狀態的物件個數。同樣地，每次提供服務後會重新計算，作為下次投票的參考值。

（3）識別物件(Distinguished Object, DO)：為一個物件的識別碼，在本實作中，該識別碼以主機位址、物件邏輯名稱及序號所組成。因此，每個物件都有唯一的識別碼。

3-1-3 Quorum

無論是 Primary-Backup 或是 Dynamic Voting 策略在物件狀態的更新上，都

(7)

必須針對所有物件作處理。投票物件甚至在提供查詢服務時，也必須經由所有成員的投票才能保證該物件處於最新狀態。如果物件總數增加，或者通訊網路的頻寬不足時，物件之間通訊的次數會是一個值得關切的問題。以 Quorum 的方法選出特定物件，當物件提供服務時，只有被選定的物件必須參與運作，如此可以減少通訊次數。

本論文在實作上，利用 Quorum Set Coordinator 執行服務物件的選取，客戶端可以向此代理者提出服務請求，不須自行實作選取之演算法，以下列出這部份的服務請求處理過程：

T : 服務物件的邏輯時間戳記 S : Quorum Set

P : 物件內部參數 V : 服務請求參數

serviceObject : Quorum-based 服務物件 clientUI : 客戶端介面

[State]:

status∈{ idle﹐update﹐query}﹐initially idle qSet,uSet ∈ S , initially null

sValue ∈ V

oData, oDNew ∈ P serviceObj ∈ Q ts, tsNew, tsReply ∈ T

[Message]:

receive(“doUpdate”﹐sValue)﹐sValue∈V status := update

receive(“doQuery”) status := query

[Transission]:

if status = update then

perform update set selection algorithm and generate uSet

(8)

send (“updateRequest”) to each serviceObj in uSet then wait for reply

if all serviceObjs return tsReply & oData then take the biggest tsReply as tsNew

make oDNew of oData and sValue

send (“updateACK”, oDNew, tsNew) to each serviceObj wait for reply

if every serverObject reply ACK then status := idle

else

status := update else

send (“updateAbort”) message to each serviceObj that was available status := update

if status = query then

perform query set selection algorithm and generate qSet send (“query”) to each serviceObj in uSet then wait for reply if every serviceObj return tsReply and objParam then

decide result from all objParams by tsReply and return to clientUI status := idle

else

status := query

當 Quorum-based 物件接受請求之後，即判斷請求項目、進行適當的處理程序，且將結果回應給 Coordinator，過程如下列所示：

T : 服務物件的邏輯時間戳記 P : 物件內部參數

V : 服務請求參數

Coordinator:接受客戶端請求，並呼叫 quorum 服務物件的代理程式

shlockCounter: shared lock 計數器

[State]:

status∈{ idle﹐update﹐query﹐abort,

setup}﹐initially idle

exlock∈{ true﹐false }﹐initially false shlock∈{ true﹐false }﹐initially false shlockCounter initially 0

timeStamp∈T, initially 0

objParam, oDNew ∈ P, initially null

[Message]:

if status = update then

(9)

update timeStamp with ts, update objParam with oDNew exlock := false

send ACK to coordinator status := idle

If status = query then shlock := false

send objParam and timeStamp to coordinator

decrease shlockCounter if shlockCounter = 0 then

shlock := false status := idle

if status = abort then exlock := false status := idle

if status = setup then

setup objParam with oDNew

[Transission]:

receive(“updateRequest”)

if exlock != true and shlock!= true exlock :=true

return timestamp else

return null status := idle

receive(“queryRequest”) if exlock != true then

increase shlockCounter shlock :=true

return timestamp status := idle

receive(“updateACK”﹐oDNew, ts)﹐

sValue ∈V﹐ts∈T status := update receive(“query”) status := query

receive(“updateAbort”) status := uabort

receive(“objectSetup”, oDNew) oDNew ∈ P

status := setup

接著以實例說明 Quorum-based 物件的運作原理。圖 3-5 中有二十個節點，

代表經複製產生的物件。圖 3-5A 表示客戶端發出 Update 請求時，隨機產生的亂數為 1，此時所產生的 Update-Set(1)為{ 1 , 2 , 6 , 8 , 11 , 14 , 16 , 20 }，如圖中的灰色節點所示。依照請求執行更新動作後，集合中的每個節點都會擁有最新狀態。接著若使用者提出查詢請求，且隨機產生的亂數為 4，則生成的 Query-Set(4) 為{ 4 , 9 , 14 , 19 }。其中節點 14 為兩個集合的交集處，由此節點可以得到最新的狀態值。若由節點 13 為起始產生查詢集合，所得到的 Query-Set(13)為{ 13 , 18 , 3 , 8}，其中節點 8 與 Update-Set(1)也有交集，仍然可以得知物件最新狀態。

(10)

圖 3-5 Quorum 範例

圖 3-5B 表示利用 18 產生 Update-Set(18)為{ 18 , 19 , 3 , 5 , 8 , 11 , 13 , 17 }，

如圖中灰色節點所示，這個集合的物件擁有最新狀態。和圖 3-6A 相較之下，如果由 Query-Set(4)查詢，則在節點 19 處有交集，若以 Query-Set(13)查詢，則恰好所有節點均與 Update-Set 有交集，因此可以順利取得物件最新狀態。這也說明

2 1

3 4 5

6 7

8

9 10 11

12 13

14 15 16 17 18

20 19 Update

Query Query

(A)以 U-Set(1)執行更新、Q-Set(4)、Q-Set(13)查詢

(B) 以 U-Set(18)執行更新、Q-Set(4)、Q-Set(13)查詢

2 1

3 4 5

6 7

8

9 10 11

12 13

14 15 16 17 18 20 19

Update

Query Query

(11)

了，任何一個 Update-Set 興 Query-Set 都能產交集，以保持正確的結果。

Quorum Scheme 在容錯上，有其獨特的表現方式，也就是利用隨機產生的亂數，取得不同的 Quorum Set。舉例來說，當圖 3-6B 以 Query-Set(4)執行查詢時，

若發現該集合中任何一節點沒有回應，可以隨機再產生新的 Query-Set 來代替。

在此例中，假設新產生的亂數為 13，則 Query-Set(13)就是一個最好的替代集合。

同理，Update-Set 的容錯處理上，也可依相同的模式進行。

以 Update-Set 來說，任兩個集合彼此都有交集。在本例中所列舉的{ 1 , 2 , 6 , 8 , 11 , 14 , 16 , 20 }與{ 18 , 19 , 3 , 5 , 8 , 11 , 13 , 17 }在節點 8 與節點 11 處交集，

因此無法同時更新資料，這可用來維持各物件的一致性。至於這些節點的求法，

可以參閱第二章的說明，於此不再贅述。

3-1-4 容錯策略的切換

當同一個服務提供多種容錯策略，且管理者決定轉換容錯模式時，有以下幾個步驟。由於轉換的過程中，系統處於不穩定狀態，Primary 物件可能尚未產生、

投票機制無法運作、Quorum 的選取更無法進行，因此首先必須利用物件管理員界面將物件服務暫停，這在實作上可以利用 Domain Server 的內部參數設定達成。接著，取得現行模式的一致性值，在 Primary-Backup 模式即為 Primary 物件狀態值，在 Dynamic Voting 模式必須經過投票程序，決定物件狀態最之新版本，

而在 Quorum 模式則由 Query-set 中，求取時間戳記最大的物件狀態值。接著再進行物件狀態設定，Primary-Backup 策略下將狀態設定給 Primary 物件即可；

Dynamic Voting 策略則須將狀態設定給所有物件，才能夠使投票演算法順利運作；至於 Quorum 策略則可將狀態設定給任一個 U-Set。最後在物件管理界面上，

將先前暫停的服務予以接續即可。

3-2 分散式容錯物件服務

「重複」在分散式系統的容錯設計上，是常見而有效的方法。為了讓運作中

(12)

的系統可以穩定運作，不因為某個主機的異常而導致系統停擺，通常同樣的功能都會由兩部以上的主機來提供，只要其中一部主機可以參與工作，系統就可以正確運作。在物件服務的設計上亦是相同的概念，若將一個物件的複本分別複製到不同的主機上，再加以有效管理，就可以在某個物件無法工作時，讓系統一如往常地提供服務，客戶端甚至察覺不到伺服器端的異狀，只是感受到運作時間拉長，但結果仍然正確。

傳統物件的呼叫被侷限在單一的程序之中，不同的處理程序之間缺乏一個簡易的溝通管道，因此物件共享變得相當困難。自從 middleware 的觀念興起之後，

這樣的藩籬逐漸被打破。以 CORBA 來說，使用者端可以經由 ORB 的協助來存取本地或遠端伺服器的物件。而且對於使用者來說，一切都是通透的，被呼叫的物件可以用一個邏輯名稱來代表，而主機的位址、通訊埠號等資訊都可以隱藏起來。呼叫者與被呼叫者還可以使用不同的程式語言來實作，使得主從兩端的搭配更加靈活。

就上述之分散式精神來看，物件服務的方式不限制在集權式的架構上。本實作即以物件複製概念為核心，將原本中央集權式物件服務改進為分散式架構。如此一來，物件服務不再因單一物件的失效而停擺，容錯物件服務系統即可實現。

然而，以 SOAP 相關技術進行分散式物件服務的容錯系統設計，在實作上仍有一些問題須加以解決：

（1）物件如何包裝在 SOAP Envelope 之中，加以傳送並啟動

（2）服務物件的位置登錄與查詢

（3）系統容錯能力的描述

3-2-1 物件複製

欲將容錯物件分散至各個主機上，可以利用網路檔案傳輸的方式分別傳送，

再連線至各主機將物件一一啟動，但這就顯得相當麻煩而且缺乏效率。若利用

(13)

SOAP 來實作，由於其僅為 XML-Based 通訊協定，還必須讓物件包裝在 Envelope 之中，再利用適當的輔助機制，才能夠自動複製至所有目的主機。

圖 3-6 SOAP 訊息格式

為了讓物件的複製工作可以更簡便，在這個系統中，有一個圖形界面的物件管理員程式(Object Manager, OM)，利用這個工具，系統管理者可以選定被複製的物件以及複製的目的地位址，並啟動複製功能。當 OM 進行複製工作時，所使用的方法就是 SOAP 附加檔，亦即 SOAP Messages with Attachments 的規格。

如圖 3-6 所示，在此規格中一個 SOAP 的訊息包括 Primary MIME Part 也就是一般所謂的 Envelope 部份，以及 Attachment 的部份。複製的過程中所需要的資訊有三項，分別是：

（1） Apache SOAP Server 的物件啟動資訊。當物件在 SOAP Server 中被 deploy 成為一個服務時，所需的描述資訊，其內容包括物件的邏輯名稱、CLASSPATH 以及可供呼叫的介面名稱等資訊。

（2）所有參與複製工作的 SOAP Server 列表，OM 整理出這份列表之後，會傳遞給第一個 SOAP Server，並依複製規則傳遞下去。

（3）物件檔案及物件狀態，也就是將物件檔案編碼後的結果以及 FTDL。

在這三個項目中，前二項會被置於 Envelope 內。如附錄二所示，<receive>

(14)

這個節點的 NameSpace 為”urn:ObjectStage”，也就說明了其內含的(1)、(2)項資訊將會送給”urn:ObjectStage”服務。至於(3)的部份，會附加在 Envelope 之後。

實際複製流程是模擬細胞分列的動作，每經過一次複製程序，物件數目會成為原來的兩倍。站台接受複製物件的 SOAP 訊息時，會將其內含的物件還原成實體檔案，接著分析訊息內所夾帶的目的站台資訊，並嘗試將站台列表盡量分割為平均的兩份，以加快複製速度。

兩份列表的處理方式有些不同，但概念上是一致的。取出第二份列表的第一個項目，可以做為該列表的下一個目的站台，所以可以將 SOAP 訊息及該列表繼續往下一個節點傳送。而第一份站台列表的第一個項目，必定是本地站台位址，

所以本地站台就是第一份站台列表的下一個目的站台，於是第一份列表會在本地端再度進行分割，重複上述的動作。當某個 SOAP Server 所接受到的列表中，只有一項站台資訊時，該項資訊必為本地站的位址，這也表示行程已經到達終點，

可以停止分割站台列表的動作，並將物件啟動。以下列出複製流程之描述：

D:Apache SOAP 的啟動描述文件，為 XML 格式，儲存物件的啟動相關資訊 I:Apache SOAP Server 的位址

H:參與運作之所有 I 的列表，為 XML 格式，由 ObjectManager 產生 O:物件經 MIME 編碼後的結果

[State]:

status∈{idle,replicate}, initially idle DeployDescriptor∈D, initially null HostList∈H, initially null

HostList1∈H,initially null HostList2∈H, initially null NextHostIP1∈I, initially null NextHostIp2∈I, initially null obj∈O, initially null

[Message]:

if status = replicate then

(15)

if(number of host in HostList = 1 ){

deploy the object in local host with DeployDescriptor }

else{

split HostList up into two lots equally

HostList1:= first lot which contains address of the self HostList2:= second lot

NextHostIP1:= get first item from HostList1 NextHostIP2:= get first item from HostList2

send Replicate to NextHostIP2 with(DeployDescriptor,HostList2,obj) HostList := HostList1

Status:=replicate }

status:=idle

[Transition]:

receive("Replicate",DeployDescriptor,HostList,obj), DeployDescriptor∈D , HostList∈H, obj∈O

status:= replicate

圖 3-7 是一個物件複製的例子，假設一物件被指定複製至 A、B、C、D 四個站台，首先由 Object Manager 產生目的站台列表{A,B,C,D}，由於列表中的第一個站台為 A，因此將物件及站台列表包裝成 SOAP 訊息傳送至 A 站台，當 A 站台接收到 SOAP 訊息時，即在本地端形成物件對應的檔案，並處理站台列表。

於圖中可知，站台列表經分割之後形成 {A,B} 與 {C,D} 兩個部份，第一部份留在本地端繼續分割，而第二部份則傳送給表中的第一個站台，即將物件及列表傳送給 C 站台。接著 A 站台與 C 站台會重複上述分割、傳送的步驟，直到四個站台都接收到訊息並形成物件檔案為止。由於此時每個站台的所處理的站台列表只剩一個項目，依照上述規則，必須啟動 Deploy 的程序，在四個站台形成可供呼叫的物件。

3-2-2 物件位置伺服器(Domain Server)

SOAP Server 是系統底層用來接收 SOAP 訊息的重要工具，因此利用這個特

(16)

圖 3-7 物件複製範例

{A,B C,D}

A

B

C

D {A,B,C,D} 初始化

A

B

C

D

{A B} {C D}

A

B

C

D {A}

{B}

{C}

{D}

A

B

C

D

註：表示主機表示物件

{A,B,C,D} 表示四個目的主機位址，A 為該次複製的目的地

(17)

性，只要掌握 SOAPServer 的位置即等於掌握所有服務物件的位址。圖 3-8 表示本論文的實作架構，藉由虛線內的 SOAP Server 將自身位址註冊至 Domain Server 供呼叫端查詢，以達成服務物件的查詢。尤其當 SOAP Server 位於一個行動裝置上時，其位置隨時會更新，更要有適當的管理機制，才能讓客戶端隨時掌握 SOAP Server 的位置，且正確呼叫服務。除此之外，本論文實作之中，所有的物件服務呼叫，都要仰賴 SOAP Server 負責代收訊息，再依訊息目的地名稱轉發給底下的服務物件。因此，SOAP Server 的位址與系統運作息息相關，如何管理這些重要資訊，是一個必須討論的問題。

圖 3-8 Domain Server 模型

一般來說，管理的方式可以分為兩類，也就是集中式與分散式。兩者各有優缺點，分述如下：

z 集中式：

Domain Server SOAP Server

140.122.76.186

Object gate FTO/BO FTO/BO

<Site id="Mercury" ts="15"

loc="140.122.76.186"/>

<Site id="Venus" ts="12"

loc="140.122.76.187"/>

<Site id="Mars" ts="8"

loc="140.122.76.188"/>

</SiteInfo>

Object gate

FTO/BO FTO/BO

SOAP Server 140.122.76.187

FTO/BO FTO/BO

SOAP Server 140.122.76.188

Object gate

loc="140.122.76.186"/>

loc="140.122.76.187"/>

loc="140.122.76.188"/>

</SiteInfo>

loc="140.122.76.186"/>

loc="140.122.76.187"/>

loc="140.122.76.188"/>

</SiteInfo>

Mercury

Venus Mars

(18)

實作簡單，當管理量少資訊時，效能有很好的表現，但無容錯特性。

此外，一旦資訊量膨脹之後，效能隨之降低，且擴充不易。

z 分散式：

站台之間溝通訊息傳遞頻繁是其最大缺點，但是管理的資訊可以分流，以達到負載平衡。且系統擴充性佳、各站台可以互相備援，達到容錯的目的。

基於容錯考量，本論文採用 Quorum-based 分散式管理方式，將資訊分別儲存在不同的主機上。如圖 3-8 所示，位於中心的 Domain Servers 中的每一個節點都有一份 XML 格式的文件，利用該文件描述 SOAP Server 所在的位址。

主機位址管理系統對本實作平台來說，是一個獨立機制。在這個系統啟動之初，管理者應公佈一份文件來描述管理系統內的站台資訊，而且所有 Domain Server 的用戶，都必須擁有該文件。如此一來，無論 SOAP Server 要登入系統，

或是客戶端呼叫服務時，只要利用上述文件配合 Quorum-based 演算法，即可正確地操作此機制。

圖 3-9 選定 LS0 及 LS1 作 SOAP Server 位置更新

在負載平衡方面，此管理方式是利用隨機的方式選取 Quorum Set 來達成，

當 SOAP Server 登錄位址時，每次選取的 U-Set 都不同，因此不會造成單一站台的負載過重。同理，當客戶端查詢 SOAP Server 的位址時，所使用的 Q-Set 也是

id="Mercury"

ts="13"

loc="140.122.219.57 Location Server 3 id="Mercury"

ts="15"

loc="140.122.76.186 Location Server 1

id="Mercury"

ts="14"

ts="15"

(19)

隨機選取的。利用演算法的設計，使得這兩個隨機產生的集合一定能夠產生交集。在容錯方面，當集合中的任何一個成員發生故障時，可以隨機再產生新的集合，直到服務完成為止。

參與運作的 SOAP Server 位址如果有異動，必須向 Domain Server 登記最新的狀態。其中登記的資訊包括 SOAP Server 的識別碼(id)，時間戳記(ts)，以及最新的位址(loc)。

圖 3-10 選定 LS 3 及 LS4 作 SOAP Server 位置更新

圖 3-9 至圖 3-11 描述一個 ID 為 Mercury 的 SOAP Server 位置資訊更新及查詢過程。其中圖 3-9、圖 3-10 代表二次的位置更新，圖 3-11 代表一次位置查詢。

首先由圖 3-9 中的虛線橢圓形所圈選的兩個位置管理主機(Location Server,LS)來看，這兩個主機的是該次作業的更新集合，稱為 U-Set。假定此時 Mercury 的 TimeStamp 已達 15，且位址在於 140.122.76.186，則更新後的 LS0 及 LS1 就如同圖中所示。而 LS2 及 LS3 很明顯可以看出是前兩次更新的結果，對於現在這個時間點來說，LS2 及 LS3 所代表的是一個過時的資訊。

Domain Server 的 U-Set 選擇是按照演算法隨機選取的，在圖 3-10 的更新作業中，被選定的位置管理主機是 LS2 及 LS3。由圖中可以明白看出，Murcury 的位址已經更新為 140.122.77.180。然而此時的 LS0 及 LS1 所代表的反而是過時的

id="Mercury"

ts="16"

ts="15"

id="Mercury"

ts="16"

ts="15"

(20)

資訊。

圖 3-11 表示 Domain Server 接受查詢時，選定了 LS0 及 LS2 作為 Q-Set，因此可以由 LS0 得到 Murcury 的位址為 140.122.76.186 ，且由 LS2 得到 140.122.76.180。此時，就必須比較兩者的 TimeStamp。很明顯地，LS2 的 TimeStamp 較大，Murcury 的最新位址應該是 140.122.76.180。

圖 3-11 SOAP Server 位置查詢

3-2-3 容錯描述語言(FTDL)與物件觀察代理者

概念中的物件在實作上包含物件程式碼與物件狀態值兩個部份，一般來說，

程式碼在開發完成之後，就不會輕易改變，而狀態則隨著物件的生命週期而變動。對應於本論文的實作上，程式碼是 Java Class，而物件的狀態，則必須定義一個方法加以描述。

於 Java 規格中，有所謂物件序列化的標準定義，使得物件可以擁有 persistence 的特性，也提供程式開發者一個將物件存檔、還原的機制。一個物件只要實作 Serializable 的介面，便可以很容易地將內部狀態擷取並保存下來，以傳送給至他處。但在這個規格中，並未定義如何以 XML 格式來表現物件序列化的內容，以致於實作出的物件序列化結果僅限於提供物件重建之用。於是有些學者將 Java

id="Mercury"

ts="16"

ts="15"

id="Mercury"

ts="16"

ts="15"

(21)

這方面的規格予以延伸，Java Serialization for XML [15] 就是一個實例。

本論文所提及的容錯物件，其內部狀態並不一定要完整的序列化，僅須針對容錯能力相關的部份加以整理，即可滿足需求。因此實作上並未採用上述序列化規格，而改以自行定義的 XML-Based 表示方法─容錯描述語言 (Fault Tolerant Description Language, FTDL)，做為物件狀態的描述之用。

圖 3-12 FTDL 範例

當系統中存在著各種容錯物件時，為了方便管理，將物件予以階層式的劃分，抽出物件相同的部份，予以一般化，詳細結構在第四章會有進一步的說明。

而 FTDL 也必須與物件階層整合，圖 3-12 為 FTDL 實例，描述一個以動態投票為容錯方法的郵局帳號應用物件。

其中的文件階層即對應系統物件階層，但與物件階層的順序相反，例如 ReplicateObject(RO) 是 DynamicVoting(DVO)的最後一個 Child，就代表在物件階層中，DVO 是 RO 的父物件。而 RO 的其他 Child 則是 RO 自身的屬性值。依此類推，FaultTolerantObject(FTO) 的最後一個 Child 並非物件，因而可得知 FTO

<DO>http://140.122.219.57:8080/rpcrouter/urn:PostOffice:1</DO>

<LogicalName>urn:PostOffice</LogicalName>

</FaultTolerantObject>

</ReplicatedObject>

</DynamicVotingObject>

</BusinessObject>

(22)

是所有物件的始祖，且其具有<LocalIP>、<LogicalName>以及<SerialNo>等容錯物件所共有的屬性。

以 XML 格式儲存物件狀態除了可以提供物件複製用之外，還可以衍生出更多的附加價值。以本論文為例，物件觀察代理者可以搜集所有物件狀態資訊，加上每個物件的狀態均以 XML 格式表示，可以很方便地整合，並依照管理者的選擇，加以結構重組。若啟動定時查詢功能，可以在介面上隨時顯示最新的物件狀態列表，掌握各個容錯物件的狀態。對於系統管理員來說，每一個提供服務的物件是否運作正常，都是必須瞭解的資訊，FTDL 也提供管理者一個觀察物件狀態的管道。

回顧圖 3-2，可以清楚地看出物件觀察代理者的運作方式是利用 Domain Server 提供的查詢，得知所有物件的位置。再加上每個物件都具有產生 FTDL 的能力，因此實作上會呼叫所有物件所提供的服務，再將回傳的結果加以整理，物件狀態列表就可以很容易地得到。