Design Pattern

論文系統其中一個主要結構是 MPI Component，功能為使用者與 Open MPI 介 接，以伺服器導向設計，設計一個效率高與消耗資源低的伺服器非常複雜，故引入 符合論文功能需求的 Design Pattern 相互應用設計，包含 Strategy、Observer、Guarded Suspension、Thread-Per-Message、Worker Thread 與 Thread Pool。

2.2.1 Strategy

伺服器在撰寫時會建立 ServerSocket，呼叫 accept()監聽連線與取得客戶端

（Client）的 Socket 等基本動作，在連線之後的服務流程，可將其獨立並封裝成服 務物件，實作服務物件，當有不同的服務邏輯需求時，只需抽換掉服務物件即可，

此即為 Strategy Design Pattern[24-25]的一種實現。在本論文裡使用此 Design Pattern 設計 MPI Server 裡 ServerSocket 接到連線後的服務封裝，便於與其他 Design Pattern 配合應用。圖 2.9 為服務封裝的基本範例，附錄一中圖 1 與圖 2 為服務實作和啟動 範例。

2.2.2 Observer

Observer[24, 26-27]中有兩個角色，主題（Subject）與觀察者（Observer），主 題可被多個觀察者訂閱，當主題發生變化時必頇通知（Notify）訂閱的觀察者，觀 察者檢視主題的變化，並做出對應動作。在 JAVA 中已提供 Observer 實作的 Class，

使用者只頇繼承與擴充即可，論文中也使用 JAVA 提供的 Observer Class 為主，因 重新實作 Observer 並不是論文主要目的。附錄二中的圖 1、圖 2 與圖 3 範例 JAVA 提供的 Class 基本實作，觀察者訂閱主題中的 data 參數，當參數改變時啟動觀察者 的 update Method。論文中使用 Observer Design Pattern 讓 MPI Manager 觀察 MPI

Server 的連線 Client Queue 及 MPI Task Queue 變化做相應的管理。

2.2.3 Guarded Suspension

一個多執行緒的系統，每個執行緒可能會對某個共用的物件做存取動作，

Guarded Suspension Design Pattern[24]強調的是對共用資料的防護，避免共用存取的 競爭問題，以免造成資料的不一致。論文中 MPI Server 的 Client Queue 設計、Task Queue 設計或 Spring framework 的共用物件等皆引入 Guarded Suspension Design Pattern。以一個基本伺服器設計為例，為求迅回應，設計一 RequestQueue 存放需求，

RequestQueue 存放需求時服務元件取出並處理，無需求時服務元件則等待直至被通 知有新的需求放入，如圖 2.9 循序圖所示。在 JAVA 中若要處理資料不一致問題需 要使用 Synchronized Method 鎖定物件，確保一次只有一個執行緒在使用，此例中 RequestQueue 即可如附錄三中圖 1 設計。

圖 2.9 Guarded Suspension 的 UML 循序圖

2.2.4 Thread-Per-Message

Thread-Per-Message Design Pattern[24]應用於需要高回應性的系統，當需求被接 受時建立一執行緒負責，執行緒建立後可立即返回回應，處理需求的執行緒繼續將 需求處理完畢。論文中將其設計在 MPI Server 裡 ServerSocket 的回應機制，並與其 他 Design Pattern 混合設計。Thread-Per-Message 的基本範例如圖 2.10 循序圖，Client 傳送要求給 Server，Server 接到後建立新執行緒處理並立即返回回應，JAVA 實作範 例如附錄四中圖 1。

圖 2.10 Thread-Per-Message 範例循序圖

2.2.5 Worker Thread

在 Guarded Suspension Design Pattern 的基本伺服器設計範例中，為求迅回應，

設計一 RequestQueue 存放需求，但處理 RequestQueue 內需求的只有一個執行緒，

當 Server 不斷在短時間加入需求至 RequestQueue 時，勢必造成太多需求在等待無 法快速處理。Worker Thread Design Pattern[24]改善其需求形成太快來不及處理的問 題，在 RequestQueue 建立時也建立多個處理執行緒，這些執行緒稱為 Worker，Worker 的數量由開發者自訂。基本範例結構如圖 2.11 循序圖所示，附錄五圖 1 為 Worker

與 RequestQueue 實作。論文中使用其設計 Task Queue 處理及 ServerSocket 建立的 連線服務需求。

圖 2.11 Worker Thread 範例循序圖

2.2.5 Thread Pool

Thread Pool Design Pattern[24]與 Worker Thread 的概念皆是預先建立好處理執 行緒，並當需求處理完成後不釋放執行緒，將其返回 Queue 等待下一次取用，不同 在於 Thread Pool 當偵測到處理執行緒皆正在執行中時，會建立新的處理執行緒加 入 Queue 並同其他執行緒處理完成後不釋放，故 Thread Pool 的處理執行緒 Queue 是會增長的，附錄六中圖 1 為基本實作範例 Worker，圖 2 為 Thread Pool。在 Spring Framework 建立 Thread Pool 有固定的規範與方法，但較不符合本論文需要對一些 Thread Pool 例外狀況的監控需求，如自訂當 Thread Pool 超出使用者設置的最大增 長限度時的邏輯，故論文中實作 Thread Pool 同其他 Design Pattern 混合設計[28-29]，

並加入 Spring Framework 的 IoC 特性對其做最小數量與最大增長數量的限制外部設 定。