儲存在 DRA4WfMS 雲端系統的 DRA4WfMS 文件通常帶有重要的資料。將 重要資料放在雲端儲存通常伴隨著一些安全風險。服務提供者可以洩漏敏感資料、
修改資料或者回傳給使用者不一致的資料。這些問題可能會因為程式臭蟲、當機、
操作錯誤或者是配置錯誤而發生。此外，比起偶然發生的意外，防範惡意的安全 性攻擊更加困難，其比起意外也更具有破壞性。外部的對手可能會非法地訪問雲 端儲存服務提供者營運的伺服器，或者雲端服務提供者的員工可能會從內部攻擊。
即使雲端儲存服務提供者實現了強大的安全性措施，這些安全性的漏洞還是可能 存在的。
沒有任何一個現今的雲端儲存服務在他們的服務層級協議 (Service-Level Agreements, SLAs) 中有提供安全性保證。舉例來說，Amazon S3 [38] 以及 Azure [39] 的服務層級協議只保證可用性：如果可用性低於 99.9%，客戶可以 得到契約上所約定的賠償。元素式加密法以及鏈狀 CER 讓 DRA4WfMS 滿足 身分認證、資料保密性、資料完整性以及不可否認性等安全性要素。即使儲存 工作流程程序實例的伺服器無法被公司所控制，公司也不需要去擔心工作流程 程序的安全性問題。然而，客戶仍然不能確保他們存放在 DRA4WfMS 文件池 中的資料不會遺失。面對這個問題的基本想法是不信任雲端伺服器以及將重要 資料備份 [22, 23, 24, 25]。從市場的角度來看，伺服器提供者們不可能同意用
33
一個簡單且標準的方法去存取他們的服務，因為這會帶給客戶完全的自由，讓 他們可以隨意更換服務提供者，導致更多的開放以及與其他提供者的直接競爭。
我們認為，對一個公司來說，他們不情願將他們的工作流程管理系統放在雲端，
除非該公司可以自行遷移及備份他們的工作流程程序實例，而不需要雲端服務 提供者的支援。
首先，如果一間公司不滿意某個雲端服務提供者所提供的服務，該公司應該 有完全的控制權可以把自己的資料轉換到另一個雲端服務提供者。為了轉換，
公司通常需要遷移正在執行的以及已經完成的工作流程程序實例，因為未完成 的工作流程程序必須要繼續執行，以及已經完成的工作流程程序裡通常包含了 重要的資料。其次，即使服務提供者提供某種的服務層級協議，像是可用性。
顧客可能仍然感覺在任何狀況下，任何工作流程程序實例的遺失，包含未完成 或是已完成的工作流程程序，是不能接受的。由於在圖三.1 中的架構，參與者 可以在流程活動執行期間自己透過 AEA 從一些商業的雲端儲存伺服器中進 行備份以得到完整的 DRA4WfMS 文件。工作流程程序實例的複製很簡單，而 且可以不需要原本的服務提供者協助。因為我們有所有 DRA4WfMS 文件的備 份，我們可以簡單的將其遷移到其他的服務提供者。
34
第六章 實作與實驗結果
在此章，我們將展示我們的實驗結果。我們根據圖三.1 的模式來實現 DRA4WfMS 文件池以及入口伺服器。DRA4WfMS 文件池以 Hadoop 來實做。
入口伺服器是一個 Apache server，讓可以 AEA 透過 HTTP 協定跟入口伺服器 溝通。我們進行了以下實驗：(1) 在 DRA4WfMS 文件池中進行提取、儲存、
搜尋文件等操作的執行時間。(2) 在入口伺服器處理 DRA4WfMS 文件的執行 時間。(3) 系統的同步處理能力。
我們建構了兩個 Hadoop 集群來實做 DRA4WfMS 文件池。一個叫做
“ICLAB cluster”，由五台 PC、五個節點組成。每個節點都有 3.0GHz Intel Core 2 Quad processor 的 CPU、2 GB 的記憶體、500 GB 的硬碟空間、Ubuntu 10.04 LTS 的作業系統以及 Java Development Kit 6。另一個叫做 “CSIE cluster”，由 三十六台虛擬機器、三十六個節點組成，這些虛擬機器分佈在三台實體機器上。
每個節點都有 Intel(R) Xeon(R) CPU E5-2620 @ 2.00GHz 的 CPU、1 GB 的記憶 體、18 GB 的硬碟空間、CentOS release 6.3 的作業系統以及 Java Development Kit 6。DRA4WfMS 文件的大小範圍在 7,304 bytes 與 47,591 bytes 之間。我們 進行實驗去評估若DRA4WfMS 文件池中存放不同數量的文件時，系統的執行 效能為何。
35
首先，我們計算從 DRA4WfMS 文件池中提取一份文件的執行時間。在這 個 狀 況 下 ， 參 與 者 已 經 根 據 他 所 收 到 的 通 知 訊 息 ， 而 獲 得 了 他 要 提 取 的 DRA4WfMS 文件的列名，也就是圖四.1 裡的 “Row”。這就是圖中的步驟 (1) 或 (4)。提供列名，系統直接訪問 DRA4WfMS 文件池而不需要搜尋所有文件 池中的文件。我們設定 DRA4WfMS 文件池中存有的文件數量分別為 10、100、
1000、10000 以及 100000 份文件。根據圖六.1，“ICLAB cluster” 獲得文件需 要花費不到一秒的時間，而 “CSIE cluster” 獲得文件需要花費一秒到三秒的時 間。由此可知，不管 DRA4WfMS 文件池中存有多少數量的文件，系統都可以 在幾乎固定的時間內取得文件。我們可以發現流程活動 C_0 跟 C_1 會花較多 的時間提取文件。這是因為流程活動 C_0 跟 C_1 必須要從 DRA4WfMS 文 件池中提取兩份文件。
圖六.1. 文件池中存有不同數量的文件時，提取文件的時間 (詳細數據請參考附錄表 A-1)
實驗的第二部分，我們去量測執行圖三.1 中的步驟 (2) 或 (5) 需要多少時 間。其包含了三個子步驟：(1) 入口伺服器驗證參與者上傳的 DRA4WfMS 文
件 。(2) 將 時 間 戳 嵌 入 驗 證 過 的 文 件 中 。 (3) 將 擁 有 時 間 戳 的 文 件 存 進 DRA4WfMS 文件池中。根據圖六.2 跟圖六.3，我們分別展示了在 DRA4WfMS
0
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
37
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
圖六.3. 文件池中存有不同數量的文件時，在文件中嵌入時間戳的時間 (詳細數據請參考附錄表 A-3)
在入口伺服器處理完 AEA 上傳到入口伺服器的文件之後，入口伺服器應 該要將文件儲存到 DRA4WfMS 文件池中。根據圖六.4，我們可以觀察到隨著 不同文件數量而成長的儲存時間。在 DRA4WfMS 文件池中提取以及儲存文件
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
39 據資料表中的 “Activity:NextActivities” 行來進行搜尋。我們實做了兩種不同的 搜尋方法。第一個方法，我們稱為 “Direct Scan”，資料表中的每列會依序地被
0
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
A_0 B1_0 B2_0 C_0 D_0 A_1 B1_1 B2_1 C_1 D_1
Time (ms)
掃瞄，以找出符合條件的文件。第二個方法，我們稱為 “MR Search”，我們利 用 Hadoop 中的 MapReduce 計算框架在資料表的每列做平行搜尋。我們測量 兩種方法在不同文件數量時的成長。根據圖六.5，因為 MapReduce 計算本身 有其基本系統開銷（像是要佈署 mapper 跟 reducer 的程式到 Hadoop 集群的
10 100 1000 10000 100000
Time (s)
10 100 1000 10000 100000
Time (s)
41
我們只有一個 DRA4WfMS 文件池，所有的工作流程程序實例都會儲存在 bigtable 中，以提供跨企業以及多租戶的需求。因此，DRA4WfMS 文件池可
能必須去處理參與者的同步操作。我們測量當不同數量的參與者同時存取以及 在文件池中存有不同數量的文件時系統的反應時間。這個實驗在 “ICLAB cluster” 上進行，此集群中只有一個入口伺服器。我們的 AEA、入口伺服器以 及 DRA4WfMS 文件池位於同一個網段內。與之前的實驗類似，我們在文件池 中設置了不同數量的文件：10、100、1000、10000 以及 100000 份文件。根據 表六-1，在所有情況下，當只有一個參與者時，單一操作（隨機讀取或寫入）
的反應時間都小於 350ms。最差的狀況是有 1000 個參與者同時存取存有 10000 份工作流程程序實例的 DRA4WfMS 文件池，最短時間、平均時間以及 最長時間分別為 919 ms、11413 ms 以及 21907 ms。但就算是最差的狀況，系 統依然可以讓一個參與者在平均11 秒內就可以完成他的工作。若我們能夠取得 規格更好的機器，則一定可以呈現出更好的實驗數據。由以上的實驗結果可以 顯示出本系統的可行性，在文件數量龐大的時候，本系統依然可以正常運作，
而在大量用戶同時存取的時候，本系統也能夠快速地處理所有請求。
(A) 10 documents in the DRAWfMS documents pool
: Number of concurrent participants
Minimal (ms) Maximal (ms) Average (ms)
1 310 310 310
10 512 580 546
(B) 100 documents in the DRAWfMS documents pool
Minimal (ms) Maximal (ms) Average (ms)
1 271 271 271
10 487 543 515
100 778 2673 1725.5
(C) 1000 documents in the DRAWfMS documents pool
Minimal (ms) Maximal (ms) Average (ms)
1 300 300 300
10 503 579 541
100 733 2657 7695
1000 863 21369 11116
(D) 10000 documents in the DRAWfMS documents pool
Minimal (ms) Maximal (ms) Average (ms)
1 298 298 298
10 499 532 515.5
100 720 2717 1718.5
1000 919 21907 11413
(E) 100000 documents in the DRAWfMS documents pool
Minimal (ms) Maximal (ms) Average (ms)
1 306 306 306
10 474 551 512.5
100 759 2767 1763
1000 840 21452 11146
43