資訊傳遞方法設計

在 3.1 節已提及 web 服務的必要性，就資料傳遞的服務而言，必須能夠在不同 的應用程式之間分享共同的資料處理邏輯，並能在不同的電腦平台上進行協同作 業，一個平台可能是不同硬體、作業系統、軟體框架或程式語言的組合，所以服 務應該要在客戶端的外部流程執行，web 服務便是一種整合異質系統的資料交換途 徑，其經由 HTTP 通訊協定來操作可重複使用的商業功能，並可將其作為一個完 整的應用程式協定，該協定亦可根據語意來定義服務行為(Daigneau, 2012)。

66

由於 BIMFeeD 的資訊必須透過網際網路傳輸，讓其符合服務導向架構(SOA, Service-Oriented Architecture)是可行的辦法，因服務導向架構可帶來抽象化(即對外 部隱藏商業邏輯)、鬆散耦合和資訊封裝的好處。Isikdag (2012)歸納三種在網際網 路 進 行 BIM 資 訊 共 享 的 設 計 模 式 (design pattern) ， 分 別 是 ： BIM AJAX (Asynchronous JavaScript and XML)、BIM SOAP (Simple Object Access Protocol) Façade 以及 RESTful BIM，並比較其異同。

該研究提到 BIM AJAX 較適合模型幾何物件的視覺化，因 AJAX 技術可讓網 路應用程式的互動更即時(如：在不更新頁面的情況下存取資料)，就像 Chen et al.

(2013)的研究也採用 AJAX 技術來開發 web-based 模型瀏覽介面，但 AJAX 的腳本 (script)必須在 client 端的應用程式實作，即 client 端的程式邏輯和資料模型是緊密 耦合(tightly-coupled)，如此便不符合服務導向架構。此外，SOAP 技術雖然發展歷 史悠久，但使用上卻不如 RESTful 方便，因 SOAP 必須基於正式的介面封裝和查 詢規則，所以 RESTful BIM 的資訊交換方式應比較適合 BIMFeeD 的需求。

另一方面，該研究並沒有特別提及資料傳輸格式的效率問題，因為 AJAX 和 SOAP 都必須以標記語言(markup language)來作為資料傳輸的格式，這會使得資料 傳輸量較 BIMFeeD 所採用的 JSON 格式高出許多，而 RESTful 則可採用 XML 或 JSON 格式，故 BIMFeeD 的 web 服務採用 RESTful 搭配 JSON 應是最好的選擇。

REST (Fielding, 2000)是一種軟體架構風格，而非一項標準或協定，而符合 REST 架構的系統可稱為 RESTful。由於 REST 將網路上的所有資料或軟體視為資 源(resource)，每一個資源皆有和其對應的 URI，也就是網址的概念，對於資源的 CRUD 操作正好可對應 HTTP 通訊協定的四種方法，即 GET、POST、PUT 和 DELETE，而資源該以何種型式呈現則視情況而定，例如：HTML (HyperText Markup Language)、XML、JSON 等。因此，RESTful 的 web 服務應包含三個部分：

資源位置、資源傳輸的格式以及對資源的操作方法，例如：欲取得 user id 為 001

67

的使用者資料，其資源位置可能是 http://example.com/user/001，資源格式可以為 JSON 或 XML，當中記錄有關這位使用者的相關資訊，而對資源的操作方法則為 HTTP 的 GET 方法。

表 3 為 BIMFeeD 之 web 服務 API，其包含 URL 位址、所搭配的 HTTP 方法、

所需傳遞的參數及該 HTTP 方法所回應的內容，在 BIMFeeD 之 web 服務當中，所 有回應內容(response)的資料傳輸格式皆為 JSON，故回應內容有可能是 JSON 化的 序列化物件、JSON 化的序列化物件陣列、JSON 化的字串或 JSON 化的字串陣列，

其中包含識別碼的部分以{ }來表示，若僅是單純的字串則以“ ”表示，而序列化物 件則以圖 11 中的類別名稱來表示，其資料模型必須符合圖 11 中的物件關係，如 同 4.2 節所述，TaskLite 和 Advice 這兩個序列化物件是以其多型來表示。

此外，本研究將 HTTP 方法為 POST 的 API 設計為必須傳遞參數(parameter)，

即 HTTP 之 request body 必須包含一參數字串，以將不同類別的序列化物件或字串 傳回至資訊回饋資料庫系統，例如：若要新增一個任務，則必須使用表 3 中的第 一個 API，即 URL 位址為/api/task，HTTP 方法為 POST，所需傳遞之參數組成的 字串為 projectID=xxx&taskLite=xxx&isSendCopy=xxx，其中 projectID 為模型專案 識別碼、taskLite 為 TaskLite 之序列化物件、isSendCopy 為是否將此任務資訊傳送 給模型管理者的字串(當中記錄一布林(boolean)值)，若此任務成功地在資訊回饋資 料庫系統中被建立，則 web 服務會回傳此任務之任務識別碼，即 taskID。

這套 API 為資訊回饋資料庫系統的 web 服務，可供資訊請求端之建模工具外 掛程式和資訊回饋端之網頁操作模組來使用，若爾後要將此套 API 開放給其他系 統開發者(developer)使用，出於安全性考量，則必須引入使用者驗證機制(如：HTTP basic authentication 或 OAuth)，同時根據不同的資料處理邏輯回傳不同的 HTTP 回 應(HTTP response)和狀態代碼(status code)。

68

表 3：BIMFeeD 之 web 服務 API

URL HTTP

方法 參數 回應內容

/api/task POST projectID

taskLite isSendCopy

“{taskID}”

/api/project_id GET N/A “{projectID}”

/api/project_info POST projectID

projectInfo

N/A

/api/model_manager_info POST projectID modelManagerInfo

N/A

/api/model_manager_info/{projectID} GET N/A ModelManagerInfo /api/pending_task_ids/{projectID} GET N/A “{taskID}”陣列 /api/accepted_task_ids/{projectID} GET N/A “{taskID}”陣列 /api/cancelled_task_ids/{projectID} GET N/A “{taskID}”陣列

/api/task_status POST taskID

taskStatus

N/A

/api/task/{taskID} GET TaskLite

/api/accepted_advice_index/{taskID} GET N/A “index”

/api/accepted_advice_index/ POST taskID acceptedAdviceIndex

N/A

/api/advice/{taskID} GET N/A Advice 陣列

69

如同 4.1 節所述，BIMFeeD 建模工具外掛程式的 Autodesk Revit (以下簡稱 Revit) 版本有五種不同類型的任務，如圖 11 中的 TaskType 列舉類別，當資訊請求端使 用者選取至少一個同元件類型(element type)的模型元件時，其可以透過 BIMFeeD 來建立以下五種任務：

 Instance Parameter：即 Revit 中的實作元件參數，BIMFeeD 會將非唯讀(not read-only)的實作元件參數清單提供給使用者，讓其勾選與此任務相關的實 作元件參數，以讓資訊回饋端使用者在網頁操作模組上提供建議，即提供 新的實作元件參數值，例如：窗戶元件有一個「窗台高度」的實作元件參 數，模型管理者可選取某些同元件類型的窗戶元件，並透過 BIMFeeD 建立 Instance Parameter 任務，同時將窗台高度這個實作元件參數勾選，資訊回饋 端使用者即可在網頁操作模組上提供窗台高度的建議值。

 Element Type：即 Revit 中的元件類型，BIMFeeD 會判斷所選取的元件類型，

將可進行替換的元件類型清單提供給使用者，讓其勾選與此任務相關的元