科技部補助專題研究計畫成果報告
期末報告
具 Web of Things 概念適用於小型智慧空間的隨插即用服
務管理機制之設計與實現
計 畫 類 別 ： 個別型計畫 計 畫 編 號 ： MOST 103-2221-E-004-018- 執 行 期 間 ： 103 年 08 月 01 日至 104 年 07 月 31 日 執 行 單 位 ： 國立政治大學資訊科學系 計 畫 主 持 人 ： 廖峻鋒 計畫參與人員： 碩士班研究生-兼任助理人員：張惟誠 碩士班研究生-兼任助理人員：王依晴 處 理 方 式 ： 1.公開資訊：本計畫涉及專利或其他智慧財產權，2 年後可公開查詢 2.「本研究」是否已有嚴重損及公共利益之發現：否 3.「本報告」是否建議提供政府單位施政參考：否中 華 民 國 104 年 09 月 19 日
中 文 摘 要 ： 普及計算(Pervasive Computing)將具備計算能力的裝置嵌入 至日常生活物品、傢俱與家電中，藉由服務管理機制的整合 協調，彼此互相合作，根據使用者意圖提供居住者適當的服 務，而形成智慧空間(Smart Environments)。雖然智慧空間 研究近年來有豐富成果產出，然市場接受度仍小，主要原因 在於大部份裝置需依賴特定平台或技術，造成應用服務開發 不易。近年來，由於物聯網技術的發展，Web of Things (WoT)的概念被提出，開發人員只需要使用標準 Web 技術，即 可存取感測服務、使用邏輯規則或控制環境週邊，而不需花 費大量時間學習及整合家庭網路中的各式特殊架構或通訊協 定。本計畫主要目的在於以發展成熟的 UPnP 為藍本，以 WoT 概念設計一個適用於小型智慧空間的資源導向服務管理機 制，並實作上述機制原型，透過實驗與實作應用情境方式， 驗證其功能完整性、效能及易用性及可行性，期望此計畫所 開發的技術，能使得智慧空間服務朝向一般使用者亦可自行 設計調控智慧空間的願景更進一步。 中文關鍵詞： 物聯網, 表徵狀態轉移, 網路服務, 通用隨插即用協定 英 文 摘 要 ： A Pervasive-computing-enriched smart environment,
which contains hundreds of embedded and tiny intelligent devices and sensors coordinated by service management mechanisms, is capable of
anticipating intensions of occupants and providing appropriate services accordingly. Although there is a wealth of research achievements in recent years, the degree of market acceptance is still low. The main reason is that most of the devices and services in such environments depend on specific platform or technology, making it hard to develop an application by composing the devices or services. Meanwhile, the concept of Web of Things (WoT) is becoming popular recently. Based on WoT, the developers are able to build applications based on well-known web tools or technologies. Consequently, the objective of this project is to design and to implement a WoT-driven service management mechanism for a small scale smart environment. Formal validations and experiments will also be conducted to verify the effectiveness of the proposed approach. We expect that the results of this project can be a solid foundation of realizing the vision of “end user programmable smart
environments＂.
科技部專題研究計畫成果報告
計畫名稱：具 Web of Things 概念適用於小型智慧空間的
隨插即用服務管理機制之設計與實現
計畫編號：MOST 103-2221-E-004-018
執行期限：103 年 8 月 1 日至 104 年 7 月 31 日
主持人：廖峻鋒
1
前言
近年智慧生活環境相關研究雖有豐富成果產出，然在實務上其市場接受度仍小。許多學者 指出，主要原因在於大部份裝置需依賴特定平台或技術，造成應用服務開發不易 (Gurp et al., 2009; Guinard et al., 2011)。基於 Web 技術的成功與普及，開始有許多研究人員希望 借鏡 Web 2.0 (Musser & O’reilly, 2007) 發展出來的 Mashup 概念來突破此一困境。所謂 Mashup 的概念，指的是開發人員基於普及的 Web 技術，如 HTML、JavaScript、XML 等，藉由 reuse 各式 Web Services，快速拼出特定服務，縮短開發週期。例如，若要開 發「飲食評介導覽服務」，可基於 Google Map API、Facebook Graph API，並使用美食的 Open Data 網站做為資料來源，就馬上具備了關鍵的軟體元件與主要資料來源，不必從無 到有重新開發 (Yu et al., 2008)。就 Web 技術觀點來看，所謂「Web Services」指的是基於 HTTP 協定的 Request-Response 模式，透過標準化且獨立於特定平台的各式應用層協定，基於 HTTP 的 Web Services 最大的好處就是可以 reuse 已發展非常成熟的 HTTP Client 和 Server 技術。傳 統的 Web Services 將 HTTP 做為傳輸媒介 (HTTP as a transportation mechanism)(Trifa et al., 2009)，主要是將一個 Remote Method 的簽章 (例如: 名稱、參數、回傳值或型別)， 在 HTTP 上再定義一層訊息協定加以包裝。這類技術近年來快速發展了一系列相關規格， 均以 WS-開頭，因此也被稱為 WS-* 型 Web Services 或「Big」Web Services (Pautasso et al., 2008)。WS-* 型 Web Services 在過去 10 年廣被採用，包含 UPnP 的裝置呼叫也是透 過此機制來運作。
然而，基於 HTTP 運作的 Web 之所以可以具備高度彈性與擴充能力，乃因 HTTP 設計時有其特定的架構風格 (Architectural Style) 考量，而 WS-* 型式的 Web Services， 只是透過 HTTP 承載特定格式訊息，表示 Method 簽章及其呼叫，技術上等同於使用 HTTP、XML 技術將傳統 CORBA 的重型分散式物件技術再重新定義一次，在架構上 並沒有突破性的創新，反而讓整個架構更加複雜，造成「Web is simple」但「Big Web Services are not simple」的窘境 (Richardson & Ruby, 2007)。因此，HTTP 的主要設計
人 Fielding 博士建議，若要真正享受 Web 架構設計好處時，應該將 HTTP 做為架構 風格 (HTTP as an architectural style)，而非傳輸媒介。Fielding 將這種設計思維命名為 REST(REpresentation State Transfer) 架構 (Fielding, 2000)，依循 REST 架構所設計 Web Services 又稱為 RESTful Web services (Richardson & Ruby, 2007)。
在 REST 架構中，所有的服務均視為 Resource，所有 Resources 均具備唯一的 URI， 而 Web Client 只能使用 HTTP 規範的 Methods (如 GET、POST、PUT、DELETE、 HEAD、OPTIONS 等等) 來存取 Resources。以物件導向設計的觀點來看，其效果等同為 Resource 制定了一致的介面 (Interface)，故根據多形 (Polymorphism) 原理，Web Clients 只要遵循各式 HTTP Methods 就能存取所有 Resources。只使用特定的 HTTP Methods 乍看之下是對 Resource 做的限制，但也確保 RESTful Web Services 可完全與既有 Web Clients 相容。因此，Webber 等人 (2010) 指出，REST 架構具有可享現存主流 Web 技術支 持、較 WS-* 高的擴充性及效能、低耦合、介面一致 (Uniformity) 及簡單易用 (Simplicity) 等特性。Gartner 機構調查也顯示，2008 年起 RESTful Web Services 數量有顯著提升 (Sholler, 2008)。研究人員分析了重要 Web Services 集散網站 ProgrammableWeb.com 後， 更發現其上採用 REST 架構的 Web Services 比例在 2010 年已高達 75%，而 WS-* 僅佔 16%(Wilde & Pautasso, 2011)。因此，Guinard 等人 (2011) 認為，RESTful Web Services 已漸成為現今企業發展 Web Services 的主流架構。REST 與傳統 WS-* 的各式架構屬性評 估及適用場合，在 Pautassso(2008) 有完整深入的討論，在此不予贅述。
由於近年來物聯網技術 (Internet of Things) 的發展，加上 REST 架構日益受重視，在 智慧生活環境研究領域出現了 Web of Things (WoT) 的概念 (Guinard et al., 2011)。事實 上，早在 HP 的 Cool Town 專案中就已提出類似構想 (Kindberg et al., 2002)，此專案構 思一個完全以 HTTP 為基礎的 Web 化世界，所有物品都具有 URI，並且可透過此 URI 取得物件資訊或狀態。由於受限於當時軟硬體技術，無法將此構想落實。近年來由於軟硬 體技術快速發展，HTTP 伺服器已經可以在無作業系統的情況下，以 8KB 以內的記憶體 獨立運作 (Duquennoy et al., 2009)。換句話說，以低成本方式在各式家電甚至感測器模組 中嵌入具處理 HTTP 能力的元件已成為可能，故 WoT 目前遂成為相當具可行性的概念。 根據現有文獻，將 WoT 概念應用在智慧生活環境具有下列好處: 1. 開發人員只需要使用標準 Web 技術，即可存取感測服務、使用邏輯規則或控制環 境週邊，而不需花費大量時間學習及整合家庭網路中的各式特殊架構或通訊協定。 正如 Guinard 等人 (2010) 指出，在當代各式智慧生活環境系統上，要將各式智慧 裝置組合成服務相當困難。而 WoT 最大的好處在於透過標準的 Web 介面即可以 Mashup 方式開發出智慧生活環境服務。
2. REST 架構中的 Resource 皆為無狀態 (Stateless)，Web Client 必須自行實作狀態保 留功能。這種設計在本質上是將 Server 端的負擔轉嫁到 Client 端。這種特性恰巧與 智慧生活環境不謀而合: 智慧生活環境中用來實現應用服務的 Client 端 (例如 Home Gateway 或使用者的手機) 計算及儲存能力通常會比 Server 端 (受存取的感測器嵌 入板或智慧家電) 強。此外，狀態保留在 Client 端時，在相同功能 A 智慧裝置消失 後又 B 裝置加入時，對 Client 來說並不影響其狀態的存續，可以進行不間斷的服務
(Caporuscio et al., 2011)。
3. 將 WoT 應用在智慧生活環境中亦帶來 REST 架構的低耦合、高效能及高互通性等 優勢。
有鑒於此，近年來許多研究團隊嘗試提出具 WoT 概念的智慧生活環境平台，將各式 感測器、軟體服務及家電轉化為 REST 架構中的 Resources(Gurp et al., 2009; Guinard et al., 2011; Caporuscio et al., 2011; Chander et al., 2012)。然而，正如 Mathew 等人 (2011) 所指出，將 WoT 應用在智慧空間目前仍然存在許多未解決的問題，為避免在設計時顧此 失彼，在基於 REST 架構設計智慧生活環境 WoT 架構時，應參考適當既有規格做為藍 本，且應選定特定型式智慧生活環境，如此在做架構決策時才不會無所適從。例如，目 前少數將 WoT 應用於智慧生活環境中服務管理機制的研究，皆採用集中式服務目錄架構 設計 (Zhu et al., 2005)，雖然集中式目錄容易實作且不需處理一致性，但在如智慧家庭這 種小型智慧生活環境，要額外架設一目錄伺服器具有成本高及單一節點失效 (Single point of failure) 的問題。基於與系統強健性與成本考量，集中式服務目錄架構在此類空間中並 不適合 (Zhu et al., 2005)。因此，本計畫主要目的在於以分散式服務目錄架構為基礎的 UPnP 規格 (UPnP Forum, 2008) 為藍本，基 WoT 概念設計一個適用於小型智慧空間 (如 智慧家庭) 的資源 (Resource) 導向服務管理機制，並加以實現。
2
研究目的
本計畫主要目的在於以發展成熟的 UPnP 為藍本，基於 Web of Things (WoT) 概念設計 一個適用於小型智慧生活環境的資源導向服務管理機制，並加以實現，使得開發人員只需 要使用標準 Web 技術，即可存取感測服務、使用邏輯規則或控制環境週邊，而不需花費 大量時間學習及整合家庭網路中的各式特殊架構或通訊協定。最後實作上述機制初步原 型，透過實驗與實作應用情境方式，驗證其功能完備性、效能及實務上之可行性，我們期 望此期末報告所揭露之研究成果能使得一般使用者在使用相關智慧環境時，可自行調控、 設定甚至是創作新服務的願景更進一步。
3
文獻探討
智慧生活環境系統主要任務為整合並管理智慧生活環境中的各式裝置與服務，在普及計算 研究領域稱為 Pervasive System。針對智慧生活環境的特定需求，近年來有許多 Pervasive System 系統被提出。Pervasive System 需搭配服務管理協定才能順利進行管理任務。現有 的智慧生活環境服務管理協定依架構可分二類: 集中式與分散式。集中式服務管理協定將 所有受管節點 (軟體服務與硬體裝置) 的狀態集中記錄到「目錄」伺服器，例如 Jini(Arnold et al.,1999)、Context Toolkits(Dey, 2000) 與 JADE(Bellifemine et al., 2007)。反之，分散 式服務管理協定並不依賴「目錄」伺服器，而是基於 IP 群播機制，將所有受管節點狀態 進行群播，再由各節點自行接並維護網內所有節點狀態，例如 UPnP(UPnP Forum, 2008) 與 Bluetooth(Bluetooth SIG, 2003)。Zhu 等人 (2005) 指出，分散式服務管理協定較適合小型智慧生活環境，因為在此類空間中，額外架設一目錄伺服器具有成本高及單一節點失效 的問題。就本計畫所著眼的小型智慧生活環境來說，UPnP 採用分散式管理架構是相當合 宜的設計。然而如同上一節所提及，UPnP 本身也存在許多問題與限制，因此歷來有不少 研究著眼於改善或擴充 UPnP 的功能。例如 Nakamura 等人 (2008) 及 Liao(2013) 等人的 研究致力於改善 UPnP 服務發現機制的效能問題;Hu 等人 (2007) 及 Mazuryk 等人 (2008) 的研究則主要改進 UPnP 事件通知機制 (GENA, General Event Notification Architecture) 效能; 蔡明倫等人 (2013) 則是針對 UPnP 服務表述及搜尋能力進行強化。
如前所述，本計畫主要以 UPnP 為藍本，基於 WoT 概念設計一個適用於小型智慧生 活環境的服務管理協定。WoT 概念最早出現在 HP 的 Cool Town 專案 (Kindberg et al., 2002)。隨著 RESTful Web Services 的普及，許多學者也提議透過 REST 架構將 WoT 概 念落實在智慧生活環境中。Drytkiewicz 等人 (2004)、Gurp 等人 (2008) 及 Glombitza 等 人 (2010) 的研究均將智慧生活環境中的裝置視為 Resources，可在 RESTful 架構下被任何 HTTP 客端存取。另一類是將感測器網路基於 WoT 概念包裝，使用 middleware 讓 Web Clients 得以透過 HTTP 協定存取資訊 (Dawson-Haggerty et al.,2010; Gao et al.,2011)。 上述研究著重於裝置控制及資訊取得，並未提及服務管理協定議題。Guinard 等人針對 WoT 在智慧生活環境中的平台、事件通知、服務管理協定及硬體可行性等議題做了一系 列較完整的討論 (Stribu, 2008; Trifa, 2009; Guinard et al, 2010;Guinard et al., 2011)，然 其設計也是針對大型戶外空間之感測網路 (作者稱之為 Sensor Area Network, SAN)，且採 用集中式架構，對於小型智慧生活環境而言較不合適。最後，也有學者主張在大型 WoT 網路中，應採更精簡的方式來實現 REST 架構，應採用二進位編碼方式來取代 HTTP。 例如 IETF 的 CoAP(Constrained Application Protocol)(Bormann et al, 2012; Chander et al. 2012)。然而，如此一來即失去了和大部份 Web 技術的相容性，必須透過類似 Adapter 或 Proxy 方式進行協定轉換。在 Bormann(2012) 中也指出，CoAP 較適合節點數較多的 戶外 SAN(而非小型智慧生活環境)。與本計畫目的最為接近的是 Newmarch 等人 (2005) 的研究，他們基於 WoT 概念，以 REST 架構改良 UPnP 的 SOAP 呼叫機制，然其對於 UPnP 的服務管理協定、事件通知等其它面向並沒有更進一步的討論。
上述陳述呈現出另一個重要議題: 既然 REST 架構是實現 WoT 的關鍵技術，那麼 REST 架構本身是否有具體定義? 如何才算是符合 REST 架構的設計? 如何才能驗證 REST 架構設計的品質? Navon 等人 (2011) 指出，即使 REST 如此普及，對於什麼才 是符合 REST 的設計，目前還眾說紛云，尚待未來更多的研究加以釐清。目前相關領域 研究通常只提供設計方案，並未針對設計品質進行檢核或評估，最多只進行初步量化評 估，藉以呈現 REST 架構設計比 WS-* 類型的服務有較高的效能。然而 REST 架構的優 勢包含: 高擴充性及效能低耦合、介面一致性及簡單易用性，REST 架構及 WoT 概念本 身 breakthrough 應該是在架構上的改善，效能只是其中一部份。就目前已知文獻資料中， 較常被用來評估符合 REST 程度的指標是 RMM(Richardson Maturity Model)(Richardson, 2008; Fowler, 2010)。近年來也有許多文獻提出如何設計良好的 REST 服務的指引，例如 Masse(2012) 提出的 REST API Design Rule、Li 與 Chou(2010) 提出的 RESTful 設計樣式 及 Richardson 與 Amundsen(2013) 提出的 Web API 設計指引。
改，提出了 P-REST 設計架構風格 (Pervasive REST Architectural Style)，作者將 URI 分 成二類:C-URI(Concrete URI) 與 A-URI(Abstract URI)，其中 C-URI 既為傳統 URI，而 A-URI 代表此 URI 指向一個虛擬的概念。之所以會有這個概念，主要是針對採用分散式 服務管理的智慧生活環境，通常必需透過類似群播 (Multicast) 的 Group Communication 機制來進行存在性管理及服務搜尋，所以必須存在一虛擬 URI，讓所有屬於同一群體的 節點得以根據此虛擬位址訂閱或發送群體訊息，其原因和 IP Multicast 需要虛擬群播位址 的原理是一樣的。P-REST 風格提供了額外的 HTTP Method 讓智慧生活環境機制較容易 實現，包含: Access、Observe/Notify、Lookup，這種擴充和 UPnP 定義額外的 Notify 與 M-Search 方法帶來一樣的問題: 既有的 Web Clients 並不認得這些擴充的 HTTP 方法，反 而帶來相容性問題。在本計畫中，我們希望能採用和 P-REST 及 UPnP 不同的途徑來解 決這個問題，希望在不更動 HTTP 協定的前提下，考量 RMM 評估指標與設計指引，設 計出品質較佳且相容性高的資源導向服務管理機制。
4
研究方法
本章節將介紹研究過程中，我們所設計出的主要概念、服務模型及其機制。首先，我們先 對於 REST 架構概念進行探討，其次，我們說明智慧環境中的 REST 架構設計原則，最 後，則說明我們在此計畫提出的具 WoT 概念的服務管理機制的細節。4.1
REST 架構概念與定義
在 Fielding(2000) 提出的 REST 架構中，任何在 Web 上可存取到的事物皆稱為 Resource; 每個 Resource 都可具備一到多個 URI(Uniform Resource Identifier)，但一個 URI 只能指 向唯一的 Resource。具備定址能力的 URI 則又可稱為 URL(Uniform Resource Locator)， 透過 URL，Web Clients 可存取特定 Resources。同理，Resource 所具有的 URIs 中至少 要有一個是 URL，否則該 Resource 將無法被定址並存取。每個 Resource 都會有一到多 個 Representation，代表此一 Resource 在某一時間點的狀態。以文件版本控制系統為例， 將 Resource 想像成受控文件，則每份文件 d 在不用時間可能有不同版本 dt，因而形成一
集合 {dt1, dt2, ..., dtn}。
依據此概念，可將 Resource 定義成一個歸屬函式 (membership function) MR(t)，其中
R 代表 Resource 名稱。透過此定義，MR(t) 在不同時間取得不同的 Representation。例
如，MR(t1) = dt1 (Fielding, 2000)。有時候 Representation 必須透過 URL(以 l 表示) 間接 取得，因此 MR(t) 的值也可能是指向其它 Resource 的超連結，例如 MR(t2) = lt2。有時 候也有可能 MR(t) 會回傳多個超連結，此時 Client 必須從這些超連結中選擇一個，而一
旦做出選擇，也等同於改變了該 Resource 的狀態。連結間可能有連鎖的串接，例如存取 一個 URL 後，在三個連結間選一個 URL (MR(t3) = L1，其中 L1 ={l1, l2, l3})，之後又回
傳二個連結 (L2 = {l4, l5})，選擇一個後才回傳真正的 Representation dt3。此種透過超連 結進行應用程式狀態轉換的機制在 REST 中稱為 HATEOAS(Hypermedia As The engine Of Application State)。(Fielding, 2000; Fielding, 2008)
由上可知，REST 最核心的概念即在於將 Resource 與 Representation 分離，由於 Resource 本身是定義為歸屬函式，因此 Representation 只能代表在「t 時刻」的 Resource。 另一個將 Resource 與 Representation 分離的副作用是同一個 Resource 的 Representation 也可以具備多種格式，具體來說，可以想像在 Web 上一個 Resource，其 URL 為http: //www.nccu.edu.tw/cfliao，透過此 URL 可取得一份 Representation，透過 HTTP 的格 式協商機制 (Content Negotiation)，可以取得不同格式的 Representation (如 JSON、PDF 或 XML)。Webber(2011) 指出，正是這種 Resource 與 Representation 分離的設計，造就 了 Web 鬆散耦合 (loose coupling) 的特性，他更進一步指出，Representation 格式在設計 時應對使用者透通 (opaque to user)，因此 URL 上出現副檔名 (如 index.html，test.php) 是不符合 REST 的設計，Representation 格式應透過格式協商機制由系統自動指定完成。 基於上述討論，Fielding 提出了四個基本設計原則，符合這些原則的設計架構稱為 REST 架構 (Fielding, 2000):
1. 每個資源都必須可識別 (Identification of resources): 意指每一個 Web 元素都具有 URI。
2. 透過 Representation 來操作資源 (Manipulation of resources through representations)。
3. 可自我描述的訊息 (Self-descriptive message): 善用 HTTP 訊息表頭 (headers)，以 key-value 的型式存放 meta-data 來自我表述。
4. 透過超連結進行應用程式狀態轉換 (Hypermedia as the engine of application state): 即為上述的 HATEOAS 概念。
REST 架構的操作語意 (Protocol Semantics)(Richardson & Amundsen, 2013) 主要討 論的是如何將應用程式所需要的操作，對應到合適的 HTTP Methods。目前並沒有統 一規格對此做明確規範，然隨著 REST 架構的普及，近年對大部份操作語意的對應 已漸形成共識 (Richardson & Ruby, 2007; Allamaraju, 2010; Masse, 2012, Richardson & Amundsen, 2013)。常見的操作包含 GET 用來表示對 Resource 狀態的讀取動作、POST 用來在相同的 URI 中建立新的 Resource(例如在一個表示 Collections 的 URI 中加入新元 素)、DELETE 是用來刪除 Resource、PUT 用來在新的 URI 中加入新的 Resource，或是 更新既有 URI 的 Resource 等。REST 操作可分為 idempotent 與 non-idempotent 二種。 Idempotent 指的是無論 Client 對 Resource 進行此操作幾次，對 Resource 的狀態影響均相 同。上述操作中，除了 POST 之外，均應設計為 idempotent。值得注意的是，DELETE 也是 idempotent，因為第一次刪除了某 Resource 以後，此 Resource 就不見了，之後無論 刪幾次，此 Resource 還是不在。
4.2
智慧環境中的 REST 架構設計
REST 架構中，所有 Resource 均具有一致的介面，也就是 HTTP/1.1 中的所定義的 Meth-ods: GET、POST、PUT、DELETE、OPTIONS、HEAD、TRACE、CONNECT 及 PATCH (Fielding et al., 1999)。所有的 Web Clients，根據操作的語意 (Protocol Semantics)，透過
圖 1: UPnP 裝置架構
適當 Methods 存取 Resource。就物件導向設計的觀點來看，只要介面相同，不管實作為 何，Clients 均不受影響，這也正是我們希望將 REST 架構落實到智慧空間的一大理由: 只 要符合 REST，則無論底下裝置、服務為何，智慧空間 Clients 的寫作方式和一般的 Web Clients 將完全相同。
如同我們在相關研究章節陳述過的，UPnP(UPnP Forum, 2008) 和 P-REST(Caporuscio, 2011) 為了加入智慧環境專屬機制，均修改了 HTTP/1.1 所定義的 Methods，這就像在做 物件導向設計時修改了介面，這當然是簡單直覺的方法，但會破壞與既有 Clients 的合約; 較好的設計方式應該是在不變更介面的前提下實現新增機制。
本計畫以 UPnP 為設計藍本，因此說明我們的設計前，我們先針對 UPnP 原有的服 務模型簡要說明。UPnP 所有裝置的設計與實作均基於 UPnP 裝置架構 (UPnP Device Architecture) 規格 (UPnP Forum, 2008)，UPnP 網路服務由 Device、Service、Action 及 Control Point 所組成。如圖 1所示，一個 Device 可能包含多組 Services，而一個 Service 會包含多組 Actions，而 Device 本身也可以包含多個子 Devices。一個 UPnP 硬體實例通 常會具有一個 Root Device，例如一個支援 UPnP 的印表機會有一個 Printer Root Device， 而其下的 Service 就是它能提供的服務，也就是 Printing Service。Service 中具有一些狀 態變數記錄自身狀態，例如 Printing Service 會有狀態變數記錄列印狀態、紙張數量等。 而 Service 下的 Action 的功能類似程式語言中的函式，可以透過 SOAP 協定 (Box et al., 2000) 被 Control Point 遠端呼叫，例如 Printing Service 下會有一個稱為 print 的 Action。 Control Point 是一種具有叫用 (Invoke) 及搜尋 (Search) 能力的特殊 Device，因此就物件 導向的角度來說，可視為是一般 Device 的子類別。由此可知在控制與存取部份，UPnP 是採用 WS-* 而非 REST 機制。
Richardson Maturity Model(RMM) 最早是由 Richardson(2008) 在 QCon 會議的 keynote speech 中提出，之後由 Fowler(2010) 及 Webber 等人 (2011) 進一步闡釋與評論。RMM 之所以被提出，主要因為 REST 架構至今並沒有像 WS-* 型式 Web Services 一樣有明 確規格定義，造成許多號稱 REST 架構設計的系統品質良莠不齊。Richardson 因此根據 Fielding(2000) 論文中對 REST 的陳述，整理出一個可用來評估符合 REST 設計原則程 度的質性模型。這種「符合 REST 設計原則的程度」Webber 等人 (2011) 稱之為「Web Friendliness」。Web Friendliness 愈高，當然就代表愈具有 REST 架構所承諾的高擴充性、 高效能低耦合、介面一致性及簡單易用性等好處。有關 RMM 的效度，Fielding 本人認 為，只有達成 RMM Level 3 才能稱之為 REST 架構 (Fielding, 2008)，而 Fowler(2010) 則
認為雖然單就 RMM 模型可能不足以用來評估軟體架構的品質，然而 RMM 卻是一個很 適合用來做為持續改善 REST 設計的工具。因此，我們採用 RMM 導引研究團隊持續改 善服務管理機制的設計。
4.3 ROSA: 具 WoT 概念的服務管理機制
Stribu(2008) 認為，利用 WoT 概念在智慧環境中實現 Plug and Play 必須考量 Discovering Things、Controlling Things、Notifications from Things 及 Representing Things 等面向。 這幾個面向恰對應到 UPnP 規格書中提到的 Discovery、Control、Eventing 及 Description 等議題，在這一年的研究期程中，我們基於這四個面向加以設計，並提出了一個具備 WoT 概念的服務管理機制，稱為 ROSA(Resource-Oriented Service Administration)。
ROSA 主要以 UPnP 為基礎，遵守 REST 架構，僅以 HTTP 標準方法來進行實作 所有 UPnP 具有的機制。HTTP 方法 (Method) 具備兩種屬性：安全性 (Safe) 與冪等性 (Idempotent)。安全性意指對 Client 來說，除了該方法提供的功能外，這些請求不應該有 其他意義。舉例來說：GET 應該只用來取得資訊，而不能有修改使用者資訊的行為。在 HTTP 中，符合安全性的方法有二個:GET 與 HEAD。冪等性則影響了相同方法是否可重 覆下達，符合冪等性的方法有三個:GET、HEAD、PUT 與 DELETE，該特定的意思是相 同的操作執行一次與執行多次所產生的結果都是一樣的，而 POST 為何不不具冪等性而 PUT 有，是因為 POST 通常是用來新增資料，PUT 用來更新資料。例如在資料庫中，同 一筆資料新增多比與同一筆資料更新多筆的結果會不會一樣，這也就是冪等性的作用。針 對安全性與冪等性作了一個表格來描述方便比對。
如同前面所提到的，在設計 ROSA 時，必須考量 REST 架構的操作語意 (Protocol Se-mantics)(Richardson & Amundsen, 2013)。GET 通常是用來檢索，舉例來說，若要取得設 備的狀態，就適合使用 GET，範例：GET http://thehost:8080/light/lightService/ lightStatus，可以取得電燈目前的狀態。PUT 通常是用來更新設備狀態，例如若想針對 更新電燈狀態，則使用 PUT 並附上新的狀態值。POST 則通常是用來新增 (或更新) 資 料，例如每一個裝置都要維護一個訂閱其狀態通知的列表，因此實作「新的 Client 要加 入訂閱列表」的動作時，就要使用這個方法來實作。DELETE 則是用來刪除資料，在前 述例子中，取消訂閱會使用這個方法。以資料操作的角度來看，POST、GET、PUT 與 DELETE 可以約略等同於 Insert or update、Retrieve、Update、Delete 等四項操作。
以下就各子概念分別就 Discovering Things、Controlling Things、Notifications from Things 及 Representing Things 等面向來說明我們的設計陳述。
4.3.1 Discovering Things
UPnP 之所以可做到「隨插即用」是因為它具有一個稱為 SSDP(Simple Service Discovery Protocol) 的服務管理協定，主要功能包含搜尋所需服務，或即時得知某服務是否存在。 其中，即時得知某服務是否存在稱為裝置存在性管理 (Presence Management)，而搜尋所 需服務則稱為服務搜尋機制 (Service Discovery)。SSDP 主要運作原理基於 IP 群播，IP 群播是一種由路由器將一個 IP 封包透過 UDP 發送到一群主機的網路機制。SSDP 定義，
(a) (b)
(c) (d)
圖 2: (a)UPnP 存在性管理; (b)UPnP 服務搜尋; (c)WoT 存在性管理; (d)WoT 服務搜尋
只要發送到 239.255.255.250:1900 的封包，就會透過群播被區域網路內的每個 UPnP 裝置 接收。在 UPnP 的群播機制中，UDP 封包的內容格式是以 HTTP 協定為主，因此又稱為 HTTPMU(HTTP Multicast over UDP)。
SSDP 在標準的 HTTP Method 之外，另行定義了 Notify 宣告裝置與服務的存在性， 此一訊息依循 HTTP 標準，以 Key-Value 型式呈現。在訊息中描述了裝置種類 (NT)、唯 一識別名稱 (USN)、訊息子類 (NTS) 及取得服務描述檔位址等重要訊息。其運作機制如 圖 2a 所示，當一個裝置加入 UPnP 網路時，會將 Notify 訊息發送到群播位址，此訊息 的 NTS 會被設為”ssdp:alive”，代表此訊息是服務在宣告自已的存在性。這些訊息會循群 播機制傳送到區域網路內所有 Device(包含 Control Point)。此時 Control Point 會比對裝 置種類 (NT)，若發現有其需要的服務，就會根據訊息中服務描述檔的位址 (LOCATION) 去取得服務描述檔，再進一步根據該檔對特定的 Action 進行 Invoke。
另一種運作模式是由 Control Point 主動搜尋某種類型服務，SSDP 定義了 M-Search 操作來支援服務搜尋，整個運作流程如圖 2b 所示。Control Point 可以發出服務搜尋 訊息。假設 Device B 符合此一種類，則會告知此 Control Point 其服務描述檔的位址， 之後 Control Point 一樣會根據訊息中服務描述檔的位址 (LOCATION) 去取得服務描 述檔，再進一步根據該檔對特定的 Action 進行 Invoke 動作。然而如同前面已提及的， UPnP 額外加入了 Notify 與 M-Search 機制，均修改了 HTTP/1.1 所定義的原始操作，
會破壞與既有 Web Clients 的合約; 較好的設計方式應該是在不變更介面的前提下實 現新增機制。我們藉由引入 Caporuscio 等人 (2012) 提出的虛擬網址 A-URI 概念，避 免額外定義 Notify 及 M-Search 而仍 達 成相同的語意。在此可將 UPnP 的群播位址 (httpmu://239.255.255.250:1900) 視為一個 A-URI，如此一來，節點收到此一要求時， 仍然會透過 HTTPMU 進行群播處理，而從應用開發人員角度來看，可將此虛擬網址視為 虛擬存在網路中的服務目錄伺服器，根據 REST 的操作語意對其進行節點存在性資訊的 增刪或修改 (CRUD)。
例 如 Discovery， 可 視 為 對 於 虛 擬 服 務 目 錄 伺 服 器 進 行 查 詢， 就 RESTful HTTP Method 的操作語意來看，應對目錄進行 GET 動作。在此我們定義一個 well-known URI:http://239.255.255.250:1900/.well-known/discover，其中/.well-known 是延用 IETF RFC 5785 的慣例 (Nottingham & Hammer-Lahav, 2010)。如此一來，新的運作機制 如圖 2d 所示，其中 Active Resource 代表具備 Web Client 能力的 Resource(相當於 UPnP 中的 Control Point)，而 M 代表虛擬服務目錄伺服器。如此一來，所發出的 discovery 訊 息會像下面這樣: GET /.well-known/discover HTTP/1.1 Host: 239.255.255.250:1900 MX: 3 RT: http://rosa.selab.iecs.fcu.edu.tw/device/WebCam/1 Port: 3344 當 resource 收到由控制點發送的訊息後，resource 會根據 RT 標頭來查詢本身是否符合 發現訊息，若是自身符合條件，設備會回應控制點自身訊息，這自身訊息會告知自己的位 址。此時回應碼由「HTTP/1.1 200 OK」改為「HTTP/1.1 204 No Content」。由於原本此 一行為就沒有訊息本體，大部份 REST 設計指引均認為在這種情況下應使用 204 回應較 為合理 (Allamaraju, 2010; Masse, 2012)。依據相同概念，可以用來處理 UPnP 的存在性 管理相關機制: 將 UPnP 的「Notify * HTTP/1.1」改為「PUT /.well-known/presence」 (如圖 2c)，下面是一個範例訊息:
HTTP/1.1 204 No Content
Content-Type: text/html; charset="utf-8" Server: Windows XP/5.1 CyberHTTP/1.1 Content-Length: 0
URI: http://thehost/.well-known/schema Cache-Control: max-age=1800
RT: http://thehost/device/WebCam/1
如同之前提過，PUT 在 REST 架構中常用來表示對特定資源進行新 URI 的新增，或 對既有 URI 的更新動作，符合裝置第一次出現或後續宣告其存在的語意。而者，由於服
務發現是基於 UDP 的 IP 群播機制，而 UDP 可能會遺失封包而重送，因此需要確保無論 重送幾次對 Resouce 狀態的影響相同，由於 PUT 具有 idempotent 性質，代表無論重送 幾次對 Resouce 狀態的影響相同，因此在此應採用 PUT 來表示存在性宣告。範例訊息如 下所示：
PUT /.well-known/presence HTTP/1.1 Cache-Control: max-age=1800
URI: http://thehost/device/WebCam/
Server: Microsoft-Windows-NT/5.1 UPnP/1.0 UPnP-Device- Host/1.0 RT: http://thehost/device/WebCam/1
同理，不存在的宣告 (Leave Announcement) 則應該使用 DELETE 這個 idempotenet 操作。
PUT /.well-known/presence HTTP/1.1 Cache-Control: max-age=1800
URI: http://thehost:8080/device/WebCam/
Server: Microsoft-Windows-NT/5.1 UPnP/1.0 UPnP-Device- Host/1.0 RT: http://thehost/device/WebCam/1
4.3.2 Representing Things
控制點在發現設備後，並不了解設備的詳細功能，為了得知設備詳細規格及能力，控制 點會經由設備描述檔得知的訊息有設備名稱、製造商名稱、提供服務資訊等等，經由服 務描述檔可以得知目前服務狀態與控制方法。在 UPnP 中，設備描述檔與服務描述檔都 是由 XML 所提供，在 ROSA 中，我們依循 RESTful Web Services 的慣例，使用 Web Application Description Language (WADL) 來描述服務。WADL 描述 web service 提供的 資源與如何使用的方法，這份檔案可以由發現訊息中 URI 標頭所提供的位址來取得，跟 UPnP 不同的是在 WADL 檔只有一種格式，而 UPnP 則分為設備描述檔與服務描述檔兩 種。 4.3.3 Controlling Things 當控制點取得設備描述檔與服務描述檔後，控制點可以使用服務或設備，或查詢服務或設 備目前的狀態，這是藉由控制點通過發送控制訊息給服務來完成。當服務收到訊息會做出 對應的動作 (action)，並把結果回傳給控制點。若動作的結果會使服務狀態改變，這可能 會引起設備的事件通知協議，這會將狀態改變的訊息通知給感興趣的控制點。控制訊息在 UPnP 中是由 SOAP(Simple Object Access Protocol) 來進行傳送，藉由 SOAP 來控制動 作。
圖 3: 資源命名規則
在 ROSA 中，所有的資源都會有一個唯一 URI 來標識自己，我們根據 UPnP 設備架 構，來擬定一套 URI 的命名系統，根據 UPnP 設備是由 Device、Service 和 Action 所組 成，因此我們依循 RFC 2396 來規劃一套命名規則，其 BNF 如圖 3。
舉 例 來 說， 放 設 備 的 server URL 為http://thehost:8080/，root device 為 light， 沒有 embedded device，service 名稱為 lightService，參數名稱為 lightLevel，那想直接 對 lightLevel 進行控制就可以輸入 lightLevel 的 URI 為：http://thehost:8080/light/ lightService/lightLevel。
進行 Control 時，可能會改變 Resource 狀態 (如開啟電源)，也可能不會改變 Resource 狀態 (如查詢狀態)。針對會改變 Resource 狀態的指令，我們使用 PUT 來實作，而不會改 變 Resource 狀態的指令我們則使用 GET 來實作。以電燈控制為例，詳細控制訊息如下: GET http://thehost:8080/device/light/LightStatus HTTP/1.1
Content-Type: application/json; charset="utf-8" Host: thehost:8080
若該資源存在則會回應成功接受要求的封包，此時 Payload 中的資訊依 RESTful Web Services 慣例以 JSON 表示 (JavaScript Object Notation):
Response-Code: 200 Content-Type: application/json Headers: Content-Type=[application/json], Date=[Wed, 9 Mar 2014 01:15:34 GMT] Payload: "LightStatus":"0" 想控制該資源狀態，則使用 PUT，下面為控制燈光的開燈範例: PUT http://140.134.26.63:8080/device/light/LightLevel HTTP/1.1 Content-Type: application/json; charset="utf-8"
Host: 140.134.26.63:8080 Content-Length: 2
User-Agent: curl/7.31.0 Payload: 81
圖 4: Controlling Things Response-Code: 200 Content-Type: application/json Headers: Content-Type=[application/json], Date=[Wed, 9 Mar 2014 01:28:00 GMT] Payload: " LightLevel ":"81" 整個控制流程如圖 4所示。
4.3.4 Notifications from Things
UPnP 原來提供 Subscribe/Notify 等 Method 結合類似 Observer 樣式來實現事件通知功 能。然而，根據 Li & Chou(2010) 提出的 REST 設計樣式，事件通知機制可以單純採用 GET/POST/PUT/DELETE 來實現:
1. 首先，subscriber 向 publisher 發出 PUT(內含自身 URI) 註冊，表達訂閱意願。
2. Publisher 本身狀態變化時，透過註冊的 URI 向 subscriber 發出 PUT，通知狀態改 變事件。
3. 在過程中若 subscriber 想要調整訂閱，也可使用 PUT 來實現。
詳細訂閱訊息封包如下所示： POST http://host:port/.well-known/subscribe/stateVariableName HTTP/1.1 Callback: http://thehost:8080/.well-known/callback Timeout: max-age=1800 若訂閱成功，resource 則會回傳訊息來確定訂閱，一個可能的訂閱回應如下所示： HTTP/1.1 204 No Content SID: uuid:a0d599de-275b-4171-8ae9-c8a0da7aad13 在期限內若還想要訂閱則應該傳送續訂訊息給 resource，因續訂訊息屬於更新資訊， 所以需要使用 PUT 方法實作續訂功能，訊息如下所示： PUT http://140.134.26.63:8080/.well-known/callback HTTP/1.1 SID: uuid:a0d599de-275b-4171-8ae9-c8a0da7aad13 Timeout: max-age=1800 若不想再收到 resource 的資訊，則應當傳送取消訂閱訊息，該訊息必須附帶想要刪除 資源的資訊。因為取消訂閱屬於刪除不需要的資訊，所以使用 DELETE 來實作取消訂閱 功能，如下所示： DELETE http://host:port/.well-known/subscribe HTTP/1.1 SID: uuid:a0d599de-275b-4171-8ae9-c8a0da7aad13
當 resource 狀態改變，會對所有訂閱該 resource 的 resource 進行通知，因為是狀態改 變的資訊，所以使用 PUT 來實作通知功能，一個可能的訊息如下：
PUT delivery path HTTP/1.1 Content-Type: application/json
Content-Length: length of body in bytes
SID: uuid:a0d599de-275b-4171-8ae9-c8a0da7aad13 SEQ: event key
“valueName”:”value”
4.4
小結
總結上述說明，我們所設計以 RESTful 的方式來實現服務管理機制的 ROSA 協定，其 Protocol 架構如圖 5所示。ROSA 由此圖可知，ROSA 藉由 RESTful 方式完整地實現 了 UPnP/SSDP 中 Discovery、Description、Control 與 Notification 等功能，並完全與 HTTP 相容，且不需像原來 UPnP 一般，必須使用 HTTP 的特殊化版本 (即 HTTPMU)。
圖 5: ROSA 架構
5
結果與討論
5.1
系統實作
為了驗證我們所提出的理論與設計，我們設計並實作了 ROSA 原型系統。在 Discoverying things 部份，我們借用了原有 UPnP 的 HTTPMUSocket 實作，並加以修改，discover 訊 息發出後，若 resource 有符合，則會根據訊息中的 port 透過以建立的 Socket 回傳至發送 訊息的地方，負責發送與負責接收的程式碼片斷如下所示。
public void p e r f o r m D i s c o v e r y ( S t r i n g r t ) throws S o c k e t E x c e p t i o n {
HTTPRequest r e q u e s t = new HTTPRequest ( ) ; r e q u e s t . setMethod (HTTP.GET) ;
r e q u e s t . setURI (ROSA. DISCOVERY_URI ) ;
r e q u e s t . addHeader ( ”MX” , ROSA.DEFAULT_MSEARCH_MX) ; r e q u e s t . addHeader ( ”RT” , r t ) ; r e q u e s t . addHeader ( ” Port ” , l o c a l P o r t ) ; d i s c o v e r y S o c k e t . p o s t ( r e q u e s t ) ; } public c l a s s D i s c o v e r y R e c e i v e r {
HTTPResponse r e s p o n s e = new HTTPResponse ( ) ; r e s p o n s e . s e t V e r s i o n (HTTP. VERSION ) ;
r e s p o n s e . s e t S t a t u s C o d e ( HTTPStatus .NO_CONTENT) ; r e s p o n s e . s e t H e a d e r ( ”URL” , URL ) ; //URI???
r e s p o n s e . s e t S e r v e r ( HTTPResponse . getName ( ) ) ;
r e s p o n s e . s e t H e a d e r (HTTP.CACHE_CONTROL, ”max−age =1800” ) ; r e s p o n s e . s e t H e a d e r ( ”RT” , RT ) ;
r e s p o n s e S o c k e t . p o s t ( p a c k e t . getRemoteAddress ( ) ,
I n t e g e r . p a r s e I n t ( p a c k e t . g e t P o r t ( ) ) , r e s p o n s e . t o S t r i n g ( ) ) ; }
在 Description 的部份，我們採用的是 WADL，利用 WADL 來描述設備的能力與功 能，在實作時用來產生 WADL 的 API 是採用開放源碼的專案 JDOM2 XML API 來完成。 在 Control 部份我們使用 REST 風格來完成控制動作，利用 GET 與 PUT 來對設備進行
圖 6: ROSA Eventing observer
操作，當設備接收到訊息則會產生對應的動作，這部份主要基於 Apache CXF 開源專案 來完成，例如下列程式碼是用來接收訊息、調控燈光亮度的程式碼片斷。
@GET
@Path ( ” /{ s e r v i c e t y p e } ” )
public Response s e r v i c e ( @PathParam ( ” s e r v i c e t y p e ” ) S t r i n g s t y p e ) {
. . . try { i f ( ” L i g h t L e v e l ” . e q u a l s ( s t y p e ) ) { r e a d i n g D a t a . put ( ” L i g h t L e v e l ” , l i g h t . g e t N o w L i g h t L e v e l ( ) ) ; } e l s e { b u i l d e r = Response . s e r v e r E r r o r ( ) . h e a d e r ( ” f a u l t s t r i n g ” , s t y p e ) ; return b u i l d e r . b u i l d ( ) ; } . . . } 在 Notification 部份，客端可對設備進行訂閱，若設備狀態有改變則通知訂閱者，我們 採用 Observer Pattern 進行實作，圖 6為實作的類別圖。ActiveResource 可以訂閱 Device， 若 Device 中有狀態改變則會透過 notifyObservers 來提醒訂閱者狀態改變。
5.2
實驗
基於 Discovery things、Describing things 與 Controlling things 等不同面向，透過一系列 實驗分別探討本計畫所設計之機制是否對整體系統效能有所提升。
圖 7: Discovery things 效能實驗，resource type 數量為 3
圖 8: Discovery things 效能實驗，resource type 數量為 18
5.2.1 Discovery things 實驗
第一項是針對發現步驟來了解 resource 與 resource type 對發現的影響。在這項實驗中， 首先隨機產生 n 種 resource type，最少三種，接著產生 m 個 resource，然後產生一段 URI 例如：http://local:port/rt1/resource01，因此每種 resource type 有 m/n 個 resource。 接下來將 m 個 resource 啟動，每個 resource 每 5 秒發布一次存在通知訊息。確認收到 m 個 resource 通知訊息後，Active Resource 開始發出 discovery 訊息搜尋，從 n 種 rt 中任 選三種來搜尋，發出 discovery 訊息後等待回應，先接收到回應則優先選擇，當三個搜尋 完成後停下實驗並記錄全程時間。重複實驗，固定 n=3，m 由 3 漸漸提升至 18。重複實 驗，固定 m=18，m/n 由 1 漸漸提升至 6，藉由兩個實驗比對 resource 與 resource type 對發現的影響。
實驗結果如圖 7與圖 8表示，由這兩張圖會發現若固定 resource type 數目但 resource 越來越多，或是固定 resource 數目但減少 resource type，會因為同樣 resource type 的設 備變多的原因導致搜尋完成時間變短，但全部搜尋時間還是差不多，會造成這樣的原因是 在搜尋的時候為避免封包同時碰撞，在搜尋時會有一個參數來負責處理延長秒數，讓收到 搜尋訊息的 resource 可以在這有限時間秒數內發送封包，這秒數是隨機的，有可能馬上送
圖 9: Controlling things 效能實驗，resource type 數量為 3
圖 10: Controlling things 效能實驗，resource type 數量為 18
出，也有可能時間快到才送出，所以全部訊息收到的時間才會靠近 3 秒，而搜尋完成時間 只會因為重複 resource type 的設備愈多讓搜尋秒數下降。
5.2.2 Controlling things 實驗
第二項實驗是針對控制步驟來比較 ROSA 與傳統 UPnP 在控制時所使用的封包流量，首 先隨機產生 n 種 resource type，最少三種，接著產生 m 個 resource，每個 resource 皆有 四個一樣的變數，因此每種 resource type 有 m/n 個 resource。接下來將 m 個 resource 啟 動，全部完成後 Control Point/Active Resource 隨機選取其中三個 resource，並且 GET/ PUT 各個變數一次，以此來計算流量。重複實驗，固定 n=3，m 由 3 漸漸提升至 18。重 複實驗，固定 m=18，m/n 由 1 漸漸提升至 6，藉由兩個實驗比對 resource 與 resource type 對控制的影響，並以此來比較 ROSA 與 UPnP 差異。
實驗結果如圖 9與圖 10所示，很明顯 ROSA 在流量上比傳統 UPnP 來的更輕量，這是 因為 ROSA 是使用 REST 的關係，由實驗結果來看，ROSA 的流量約略為傳統 UPnP 的 三分之一，這也顯示傳統 UPnP 對網路的負擔確實是比較重，在智慧家庭環境中，往往 是有限的網路環境，減少流量也能夠減少伺服器的負擔。
圖 11: Describing things 實驗
5.2.3 Describing things 實驗
最後一項是針對描述步驟，在此實驗本論文比較兩系統在獲取描述檔時所使用的封包流 量，了解兩系統在獲取描述檔的流量差異，首先隨機產生 m 個 resource，每個 resource 皆 有自我描述檔。接下來將 m 個 resource 全部啟動，完成後 Control Point/Active Resource 對每個 resource 獲取其描述檔，以此來計算流量。由 resource 數量 3 漸漸提升至 30，以 此來了解 resource 數量在 UPnP 與 ROSA 兩系統之間獲取描述檔流量的差異，監控封包 流量的軟體為 Wireshark。
實驗結果如圖 11表示，ROSA 獲取描述檔的流量遠比傳統 UPnP 少，這是因為傳統 UPnP 使用的描述檔有廠商或開發商等資訊，並且設備與服務是分開為兩個 XML 檔案來 分別描述，而 ROSA 採用的 WADL 則很簡單的描述資源與使用方法，在描述階段 ROSA 很明顯的比傳統 UPnP 來的較輕量。
5.3
小結
本節說明了我們在研究過程中，針對服務發現、控制與描述進行的實驗結果，以此來讓 ROSA 與傳統 UPnP 做比較，結果發現 ROSA 比未經改良後的傳統 UPnP 使用了較少的 頻寬，在控制階段與描述階段皆大幅減少網路流量，使得 ROSA 更適合在受限制的網路 環境中使用。
6
結論與建議
本計畫以發展成熟的 UPnP 為藍本，基於 Web of Things (WoT) 概念設計一個適用於 小型智慧生活環境的資源導向服務管理機制，並加以實現，使得開發人員只需要使用標 準 Web 技術，即可存取感測服務、使用邏輯規則或控制環境週邊，而不需花費大量時 間學習及整合家庭網路中的各式特殊架構或通訊協定。我們在設計時，考量了 UPnP 所 著重的資訊存取、裝置控制、事件通知及服務管理等面向，參考 RMM、Masse(2012)、
Richardson 與 Amundsen(2013) 等重要 REST 文獻設計指引來設計符合 REST 架構概念 的各項子機制。在本研究案期限結束之前，我們亦已完成此機制的原型實作，透過實驗與 實作應用情境方式，驗證其功能完備性、效能、易用性及實務上之可行性，我們相信此計 畫之研發成果，能使得智慧生活環境朝向「End-User Programmable Smart Environments」 的願景更進一步。
參考資料
Allamaraju, S. (2010). RESTful Web Services Cookbook. O’reilly Media Inc.
Arnold, K., O’Sullivan, B., Scheifler, R., Waldo, J., Wollrath, A (1999). The Jini
Specifica-tion. Addison-Wesley.
Bellifemine, F., Caire,G., and Greenwood,D. (2007). Developing Multi-Agent Systems with JADE, John Wiley & Sons, Ltd.
Bluetooth SIG (2003). Bluetooth System Specification.
Bormann, C., Castellani, A. P., Shelby, Z. (2012). CoAP: An Application Protocol for Billions of Tiny Internet Nodes. IEEE Internet Computing, Vol.16, No.2.
Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H. F., Winer, D. (2000). Simple object access protocol (SOAP) 1.1.
Caporuscio, M., Funaro, M., Ghezzi, C. (2011). RESTful Service Architectures for Pervasive Networking Environments. REST: From Research to Practice, Springer.
Chander, R. P. V., Elias, S., Shivashankar, S. Manoj, P. (2012). A REST based design for Web of Things in smart environments. In: Proc. 2012 IEEE International Conference
on Parallel Distributed and Grid Computing (PDGC).
Chen, H., Finin, T., Joshi, A. (2004). Semantic Web in in the Context Broker Architecture. In: Proc. of the IEEE International Conference on Pervasive Computer and
Communi-cations.
Chappel, D. (1998). Trouble with CORBA. In: Object News, May, 1998.
Crockford, D. (2006). The application/json Media Type for JavaScript Object Notation (JSON).
Dawson-Haggerty, S., Jiang, X., Tolle, G., Ortiz, J., Culler, D. (2010). sMAP: a simple measurement and actuation profile for physical information. In: Proc. the 8th ACM
Conference on Embedded Networked Sensor Systems.
Dey, A. K. (2000). Providing Architectural Support for Building Context-Aware Applications. Ph.D. Thesis. Georgia Institute of Technology.
DiCioccio, L., Teixeira, R., May, M., Kreibich, C. (2012). Probe and Pray: Using UPnP for Home Network Measurements. Passive and Active Measurement, Lecture Notes in
Computer Science Volume 7192, pp 96-105.
Drytkiewicz, W., Radusch, I., Arbanowski, S. (2004). pREST: A REST-based Protocol for Pervasive Systems. Proc. International Conference on Mobile Ad-hoc and Sensor
Systems.
Duquennoy, S., Grimaud, G., Vandewalle, J. (2009). The Web of Things: interconnecting de-vices with high usability and performance. In: Proc. 6th IEEE International Conference
on Embedded Software and Systems (ICESS’09). HangZhou, Zhejiang, China.
Fielding, R. T., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., & Berners-Lee, T. (1999). Hypertext transfer protocol¡VHTTP/1.1.
Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software
Ar-chitectures. Ph. D. Thesis, University of California, Irvine.
Fielding, R. T. (2008). REST APIs must be hypertext-driven. Available at: http://roy. gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Fowler, M. (2010). Richardson Maturity Model: steps toward the glory of REST. Available at: http://martinfowler.com/articles/richardsonMaturityModel.html
Gao, L., Zhang, C., Sun, L. (2011). RESTful Web of Things API in Sharing Sensor Data. In: Proc. 2011 International Conference on Internet Technology and Applications (iTAP). Garlan, D., Siewiorek, D., Smailagic, A., Steenkiste, P. (2002). Project Aura: Towards
Distraction-Free Pervasive Computing. IEEE Pervasive Computing, Vol.21, No.2. Glombitza, N., Mietz, R., Romer, K., Fischer, S., Pfisterer, D. (2010). Self-Description and
Protocol Conversion for a Web of Things. In: Proc. 2010 IEEE International Conferences
on Sensor Networks, Ubiquitous, and Trustworthy Computing.
Grune, D. (1999). Parsing Techniques: A Practical Guide. Springer.
Gu, T., Pung, H. K., Zhang, D. Q. (2004). Toward an OSGi-based Infrastructure for Context-Aware Applications. IEEE Pervasive Computing.
Gu, T., Pung, H. K., Zhang, D. Q. (2005). A Service-Oriented Middleware for Building Context-Aware Services. Journal of Network and Computer Applications, Vol.28.
Guinard, D., Trifa, V., Wilde, K. (2010). A Resource Oriented Architecture for the Web of Things. In: Proc. 2010 International Conferences on Internet of Things, Tokyo.
Guinard, D., Trifa, V., Mattern, F., Wilde, E. (2011). From the Internet of Things to the Web of Things: Resource-oriented Architecture and Best Practices. In: Uckelmann et al. (eds.) Architecting the Internet of Things, pp.97-129. Springer-Verlag Berlin Heidelberg. Gurp, v. J., Prehofer, C., Flora, d. C. (2008). Experiences with Realizing Smart Space Web Service Applications. In: Proc. IEEE Consumer Communications and Networking Conference, pp. 1171-1175.
Hadley, M. J. (2009). Web Application Description Language. Available at: http://java. net/projects/wadl/sources/svn/content/trunk/www/wadl20090202.pdf
Henning, M. (2006). The Rise and Fall of CORBA. ACM Queue. June, 2006.
Hu, C.L., Huang, Y.J., Liao, W.S. (2007). Multicast Complement for Efficient UPnP Event-ing in Home ComputEvent-ing Network. In Proc. of 2007 IEEE International Conference on
Portable Information Devices.
Internet Computing, Jan-Feb.
Kindberg, T., Barton, J., Morgan, J., Becker, G., Caswell, D., Debaty, P., Gopal, G., Frid, M., Krishan, V., Morris, H., Schettino, J., Serra, B., Spasojevic, M. (2002). People, Places, Things: Web Presence for the Real World. Mobile Networks and Applications, 7(5).
Li, L., Chou, W. (2010). Design Patterns for RESTful Communication Web Services. In:
Proc. 2010 IEEE International Conference on Web Services.
Liao, C. F., Chang, H. C., & Fu, L. C. (2013). Message-Efficient Service Management Schemes for MOM-based UPnP Networks. IEEE Transactions on Services Computing. Masse, M. (2012). REST API Design Rulebook. O’reilly Media Inc.
Mathew, S. S., Atif, Y., Sheng, Q. Z., Maamar, Z. (2011). Web of Things: Description, Discovery and Integration. In: Proc. 2011 IEEE International Conferences on Internet of Things, and Cyber, Physical and Social Computing, pp.9-15.
Mazuryk, Y., Lukkien, J. J. (2004). Analysis and improvements of the eventing protocol for universal plug and play. In: Proc. of the IASTED Conference on Communications,
Internet and Information Technology.
Musser, J., & O’Reilly, T. (2007). Web 2.0: Principles and best practices. Sebastopol, CA: O’Reilly Media.
Nakamura, K., Ogawa, M., Koita, T.,Sato, K. (2008). Implementation and Evaluation of Caching Method to Increase the Speed of UPnP Gateway. In: Proc. IEEE/IFIP
International Conference on Embedded and Ubiquitous Computing.
Navon, J. & Fernadez, F. (2011). The Essence of REST Architectural Style. In: Uckelmann et al. (eds.) Architecting the Internet of Things, pp.97-129. Springer-Verlag Berlin Heidelberg.
Nottingham, M., Hammer-Lahav, E. (2010). Defining Well-Known Uniform Resource
Iden-tifiers (URIs). IETF RFC 5785.
Newmarch, J. (2005). A RESTful Approach: Clean UPnP without SOAP. In: Proc. IEEE
Consumer Communications and Networking Conference.
Object Management Group (2000). CORBA Trading Object Service Specification, Version 1.0, available at http://www.corba.org/.
Pautasso, C., Zimmermann, O., Leymann, F. (2008). RESTful Web Services vs. ”Big” Web Services: Making the Right Architectural Decision. In: Proc. 2008 International
Conference on World Wide Web (WWW 2008).
Pasternak, M. (2013). RESTful Service Description Language (RSDL). Available at: http: //en.wikipedia.org/wiki/RSDL
Richarson, L., Ruby, S. (2007). RESTful Web Services: Web Services for the Real World. O’Reilly Media Inc.
Richarson, L. (2008). Justice Will Take Us Millions Of Intricate Moves. Available at: http://www.crummy.com/writing/speaking/2008-QCon/act3.html
Richardson, L., Amundsen, M. (2013).RESTful Web APIs. O’Reilly Media Inc.
Roman, M., Hess, C., Cerqueira, R., Ranganathan, A., Campbell, R. H., Nahrstedt, K. (2002). A Middleware Infrastructure for Active Spaces. IEEE Pervasive Computing, Vol.1, No.4.
Sholler, D. (2008). SOA User Survey: Adoption Trends and Characteristics.
Stribu, V. (2008). Towards a RESTful Plug and Play Experience in the Web of Things. In:
Proc. 2008 IEEE International Conference on Semantic Computing.
Trifa, V.,Wieland, S., Guinard, D., Bohneret, T. (2009). Design and Implementation of a Gateway for Web-based Interaction and Management of Embedded Devices. In: Proc. International Workshop on Sensor Network Engineering (IWSNE 09).
UPnP Forum (2008). UPnP Device Architecture 1.0, ISO/IEC DIS 29341.
Webber, J., Parastatidis, S., Robinson, I. (2010). REST in Practice: Hypermedia and System
Architecture. O’reilly Media Inc.
Wilde, E., Pautasso, C. (Edt.) (2011). REST: From Research to Practice. Springer.
Yu, J., Benatallah, B., Casati, F., Daniel, F. (2008). Understanding Mashup Development.
IEEE Internet Computing, Vol.12, No.5.
Zhu, F., Mutka, M. W., Ni, L. M. (2005). Service Discovery in Pervasive Computing Envi-ronments. IEEE Pervasive Computing, Vol.4, No.4.
科技部補助計畫衍生研發成果推廣資料表
日期:2015/09/19科技部補助計畫
計畫名稱: 具Web of Things概念適用於小型智慧空間的隨插即用服務管理機制之設計與 實現 計畫主持人: 廖峻鋒 計畫編號: 103-2221-E-004-018- 學門領域: 程式語言與軟體工程無研發成果推廣資料
103 年度專題研究計畫研究成果彙整表
計畫主持人：廖峻鋒 計畫編號： 103-2221-E-004-018-計畫名稱：具 Web of Things 概念適用於小型智慧空間的隨插即用服務管理機制之設計與實現 量化 成果項目 實際已達 成數（被接 受或已發 表） 預期總達成 數(含實際 已達成數) 本計畫 實際貢 獻百分 比 單位 備註（質 化 說 明 ： 如 數 個 計 畫 共 同 成 果、成 果 列 為 該 期 刊 之 封 面 故 事 ...等） 期刊論文 0 0 100% 研 究 報 告 / 技 術 報 告 0 0 100% 研討會論文 1 3 100% 篇 翁子原, 廖峻鋒, 楊東麟, “基於複雜事件分析技術 偵測智慧生活空間中的高 階情境, ＂ 2015 台灣軟 體工程研討會 (TCSE), 雲 林, 台灣, 2015. (2 計畫共同成果) 陳韋升, 廖峻鋒, 楊東麟, “半導 體測試產出之巨量晶圓資 料處理程式效能優化的真 實案例研究, ＂ 2015 台 灣 軟 體 工 程 研 討 會 (TCSE), 雲林, 台灣, 2015. 胥沛恩, 廖峻鋒, “智慧 家庭中 MQTT 透通式傳 輸層轉接架構的設計與實 作,＂ 第 20 屆行動計算研 討 會 (MC 2015), 南 投 , 台灣, 2015. 論文著作 專書 0 0 100% 申請中件數 0 0 100% 專利 已獲得件數 0 0 100% 件 件數 0 0 100% 件 技術移轉 權利金 0 0 100% 千元 碩士生 2 2 100% 博士生 0 0 100% 博士後研究員 0 0 100% 國內 參與計畫人力 （本國籍） 專任助理 0 0 100% 人次 國外 論文著作 期刊論文 1 1 50% 篇 (2 計 畫 共 同 成果)Chun-Feng Liao, Kung Chen, Deik Hoong Tan, and Jiu-Jye Chen, “Automatic
Applications, ＂ in
Automated Software Engineering, (SCI, EI),
2015. (DOI) 10.1007/s10515-015-0178-2 (to appear) 研 究 報 告 / 技 術 報 告 0 0 100% 研討會論文 1 2 100%
Chun-Feng Liao, Chao-Ting Cheng, Tzu-Yuan Weng, Wei-Chen Lu, and Kung Chen “A Platform for Detecting High-Level Contexts from Complex Event Streams in Pervasive Environment,” in Proc. International Conference on Platform Technology and Service, 2015.
Hsin Huang, Hsin-Chien Huang, Chun-Feng Liao, Ying-Chun Li, Tzu-Chieh Tsai, Li-jia Teng, and Shih Wei Wang, “Future Circus:
A Performer-Guided Mixed-reality Performance Art, ” in International Symposium on Wearable Computers (ISWC), Design Exhibition track, Osaka, Japan, 2015.
專書 0 1 50% 章/本
(2 計 畫 共 同 成 果 ) Chun-Feng Liao, Kung Chen, and Jiu-Jye Chen, “ Context and Data
Management for Multitenant Enterprise Applications in SaaS Environments: A Middleware Approach, ＂ in Software Technologies, Communications in Computer and Information
Science, Springer, 2014.
申請中件數 0 0 100%
專利
已獲得件數 0 0 100% 件
權利金 0 0 100% 千元 碩士生 0 0 100% 博士生 0 0 100% 博士後研究員 0 0 100% 參與計畫人力 （外國籍） 專任助理 0 0 100% 人次 其他成果
![圖 4: Controlling Things Response-Code: 200 Content-Type: application/json Headers: Content-Type=[application/json], Date=[Wed, 9 Mar 2014 01:28:00 GMT] Payload: " LightLevel ":"81" 整個控制流程如圖 4所示。](https://thumb-ap.123doks.com/thumbv2/9libinfo/7346781.86240/16.918.257.665.83.475/圖ControllingThingsContentType=applicationjsonMarGMTPayload34LightLevel34348134整個控制流程如圖4所示.webp)
