本章節將說明我們如何利用現有的雲端系統來實作前面所設計的系統，主要是以 GridGain 及 Azure 來分別實作，以下將分別說明。在最後會說明兩個系統實作在做棋譜 搜尋時所花時間的比較。
4.1 以 GridGain 實作
一開始將先說明以 GridGain 來實作的例子。由於 GridGain 是 Java 的帄台，所以整 個雲端系統都必需要利用到 Java 語言來撰寫。將 GridGain 的 jar 檔案加入我們雲端系統 的專案並且繼承其中幾個關鍵類別後，就可以開始以 GridGain 來實作我們的雲端系統。
由於 GridGain 中每一個 Grid Node 都視互相為 Grid Instance，並不像我們有提供一 台專門負責工作配送的 Broker 角色，所以在 GridGain 上面的實作將會設計一個特別的 Grid Instance 來當作我們的 Broker，其他沒有特別實作的 Grid Instance 則變成我們的 Worker。
圖表 12 GridGain 實作圖
首先是 Client 與 Broker 溝通的部份，因為 Client 可能是各種教學程式，或是棋譜編 輯器，Client 並不限定使用 Java 來開發，也就不一定會透過 GridGain 將 Client 實作在 GridGain 的 Cluster 之中，我們目前的例子也並不是用 GridGain 來開發 Client 程式，而 是將 Client 獨立在 Cluster 的外面。另外也不限定 Client 的程式語言或是使用環境等等。
因此我們 Client 與 Broker 之間的溝通就是採用標準 TCP Socket 連線，因為大部分的程 式都有支援提供 Socket 的連線方式，另外為了與現有的桌機格網系統配合，溝通的格式 是以交換 XML 檔案的方式來溝通。
後面 GridGain Cluster 的部份，由於 GridGain 已經提供幾個簡單的雲端系統的功能，
這邊我們就不需要再另外實作那些功能。包括：Broker(Grid Instance)與 Worker(Grid Instance)之間的溝通、工作如何依據開發者定義的分配方式將工作發布到 Worker 上執行、
Worker 新加入或離開的簡單管理、Map-Reduce 的運算架構等等。也就是我們只需要依 照前面所講的 GridGain 程式開發的方式就可以簡單設計出一個 Broker 以及後面整個 GridGain Cluster 的部份。
以下將解釋如何利用 GridGain 來實作「單一結果回傳」、「連續結果回傳」、「資料儲
Broker 收到此 XML 檔案後會先解讀各個欄位資訊，取出重要的部份後進入 GridGain 的 Split 方法中。由於此類工作不需要再切割成更小的工作，所以在 Split 方法中只需選 定好一台適合執行此工作的 Worker 來執行工作即可。
而 Worker 執行工作的內容就是以 Java Runtime 來執行 NCTU6.exe，並傳入對應的 參數。因此所有工作要執行的執行檔都必須要預先放在 Worker 端，這也是與目前實驗 室開發的桌機格網系統相配合。等到 Java Runtime 收到 NCTU6.exe 的執行結果後再把 結果傳回給 Broker。
Broker 的 Reduce 方法只需收到該結果之後就立即回傳給 Client，因為不會有其他 Worker 會回傳同一個工作的結果。當 Client 拿到來自 Broker 送回的結果，就完成了利 用「單一結果回傳」的算出最佳著手。
4.1.2 實作連續結果回傳
同樣以本教學系統來說，Client 在需要算出所有擋法時會利用到「連續結果回傳」
的功能。此類工作執行方式上大致上與前者相同，Client 與 Broker 仍然是以 XML 溝通 並且 Worker 端以 Java Runtime 執行 NCTU6。不同的是會先透過參數告知 NCTU6.exe 這次的工作是要做算出所有擋法，而執行算出所有擋法時 NCTU6.exe 會先計算此盤面 是否已經有一方已經必勝，但是大部分的情況都是 NCTU6.exe 沒有算出此盤面有一方 已經必勝，此時 NCTU6.exe 就會輸出所有可能的擋法，此時輸出的結果就會非常多，
並且可能部份結果就有用。所以必須要提供類似 Streaming 的方式將結果傳回給 Broker。
為了要達到單一一個工作回傳多個結果這個要求，本系統使用了 GridGain 所提供的
「Session」元件來讓 Broker 與 Worker 溝通。Session 本來是讓各 Grid Instance 在分別執 行工作時，考慮到可能還是會有相依性所設計的溝通管道。在工作執行前可以為此工作
宣告一個 Session，之後所有負責執行此工作的 Grid Instance 都可以將訊息寫入此 Session，
並且讓每一個執行相同工作的 Grid Instance 可以讀取此 Session 中的訊息。我們的做法 就是當 NCTU6.exe 算出一部份結果時，Worker 就會立刻將此部分結果寫入 Session 中。
而在 Broker 端則是有 Session Listener 隨時監聽 Worker 是否有將資料寫到 Session 中。
若有資料被寫入 Session 則立刻將之取出並傳回給 Client。Client 會自己將這些部份結果 拼湊或是另外使用。
而在工作執行完成後其實 Worker 就不會回傳任何結果，因為結果全部都已經先透 過 Session 傳回去了，執行到 Broker 的 Reduce 方法時也只會通知 Client 工作已經完成，
後面不會再有更多結果。
4.1.3 實作資料儲存
Client 在需要儲存一個現有盤面的時候會利用到「資料儲存」功能。Client 一樣透 過 XML 檔案將要儲存的盤面傳送給 Broker，Broker 會在 Split 方法中以盡量讓資料帄均
Broker，此時 Broker 的 Reduce 方法也就不需要做任何特別的事情。可能也僅是傳送給 Client 一個 OK 的訊息。通知 Client 棋譜儲存的工作已經完成。
4.1.4 實作資料搜尋
Client 在透過一個盤面、圈選部份的棋型或是以 Little Golem 上面的玩家資訊來搜 尋棋譜資料的時候，會用到「資料搜尋」的功能。
Client 透過 XML 檔案將要查詢條件送給 Broker 後，Broker 解讀各欄位之後在 Split 方法會將所有搜尋工作分配到每一個有負責儲存的 Worker 上。要求每一個負責儲存的 Worker 都要執行此搜尋工作，因為所有負責儲存的 Worker 都可能有存放符合條件的盤 面。 Worker role instance 來開發我們的 Worker，使用的語言是 C#，原因是目前開發 Azure 的
程式語言中以 C#的資源較為豐富。所有的 Worker 都是執行在微軟的 Azure 虛擬機器中。
Broker 的部份卻不使用 Azure 的 Worker role instance 來開發，主要原因是我們的系 統架構都是由 Client 及 Worker 主動連線至 Broker，Client 與 Worker 需要預先知道 Broker 的 IP 位址。而所有的 Worker role 程式都是執行於 Azure 的虛擬機器中，當 Worker role instance 執行結束後虛擬機器就會關掉。重開之後 IP 位址就會重新配置，造成每次都需 要更改 Client 與 Worker 設定的麻煩。因此我們將 Broker 設計在 Azure 的外面，給予 Broker 一個固定的 IP，以方便連線。另外為了方便設計，我們讓 Broker 與 Client 的連線方式 與 GridGain 相同，採取 TCP socket 連線以及 XML 檔案格式。
圖表 13 以 Windows Azure 實作圖
另外還有一個地方與 GridGain 的實作不同，那就是 Broker 與 Worker 之間的溝通方 式不像 GridGain 已經由 GridGain 已經處理好了，在 Azure 這邊必須要自己處理。所以 我們參考之前實驗室已開發之桌機格網系統的設計方式，讓 Broker 與 Worker 之間的溝 通也是用 TCP socket 連線及 XML 檔案格式。
以下將解釋如何利用 Windows Azure 來實作「單一結果回傳」、「連續結果回傳」、「資 料儲存」、「資料搜尋」功能之詳細說明。
4.2.1 實作單一結果回傳及連續結果回傳
同樣是在 Client 利用六子棋人工智慧程式 NCTU6.exe 來算出最佳著手或是所有擋 法時使用「單一結果回傳」以及「連續結果回傳」此二功能。另外 Client 與 Broker 之間 的溝通方式也與 GridGain 類似，所以這邊都不再重複。
當 Broker 收到來自 Client 的 XML 檔案並且解析完各欄位後，由於 Azure 沒有像 GridGain 定義 Split 方法後就會自動幫你把工作傳到 Worker 端的功能，所以需要自己決 定要交給哪個 Worker 執行，並且要自己把工作透過 XML 格式傳給 Worker 端。
Worker 收到來自 Broker 的工作之後，同樣是以執行 NCTU6.exe 這個執行檔的方式，
執行的方式是利用 C#的 Process 來執行。所以必須預先把所有會使用到的執行檔發布到 Windows Azure 的虛擬機器中。因為 Broker 與 Worker 連線方式是採 TCP socket 連線方 式，本身就已經有 Streaming 的特性，所以當 Worker 一有部份或完整結果產生，就立即 將該結果透過連線傳回給 Broker。
4.2.2 實作資料儲存
這邊實作資料儲存的方式與 GridGain 的方式有相當大的差異，原因是因為 Worker 都執行於 Azure 的虛擬機器中，而當程式結束後虛擬機器也會關閉並且清掉本地的儲存 空間，無法永久保存資料。當然 Azure 也有提供 Storage 的服務，包含 Blobs 與 Table 以 及 Queue 等等可永久儲存資料的方式。但是因為我們的棋譜資料是存放在資料庫中，所 以直接使用也是由微軟提供的 SQL Azure 雲端資料庫來當作資料儲存的空間是比較適合 的。
Client 要儲存一個盤面的時候，作法上與 GridGain 差異就不大，只是 Worker 就不
是將資料儲存在本地的 MySQL 資料庫，而是將資料統一放在 SQL Azure 雲端資料庫上 面。
4.2.3 實作資料搜尋
由於棋譜不是分散的儲存在各 Worker 的本地 MySQL 資料庫中，而是只存一份在 SQL Azure 的雲端資料庫中，所以就無法提供 Map-Reduce 的棋譜搜尋方式。Broker 僅 會選擇一個 Worker 來執行搜尋 SQL Azure 的方式。
執行的方式一樣是透過 C#中的 Process 來執行負責搜尋 SQL Azure 的 PHP 執行檔。
將結果傳回給 Broker 後再進行排序。排序後的結果再傳回給 Client。以完成棋譜搜尋的 工作。
4.3 實驗數據
以下將比較 GridGain 與 Windows Azure 在棋譜搜尋上面的速度。由於 Windows Azure 那邊的實作中，資料只儲存一份在 SQL Azure，為了比較此兩系統的效能，所以 GridGain 的實作也是將棋譜資料集中在同一個 MySQL 資料庫中。
兩邊資料庫都放入 321 個遊戲盤面。每個盤面帄均有 23.8 手，每一手再解析出來一 共會有 7633 個盤面存在資料庫中。我們舉了六個六子棋的開局盤面來做棋譜搜尋。以 下是比較表格。
盤面編號 結果數量 GridGain 搜尋時間(ms) Azure 搜尋時間(ms)
1 25 2198 3236
2 29 511 2821
3 65 1669 3465
4 32 951 2440
5 8 760 2114
6 1 993 2159
圖表 14 GridGain 與 Winsows Azure 比較