1 引 言

隨著信息技術的發展，人們對信息的獲取和使用方式由原來的單一網絡連接逐漸向泛在信息服務遷移． 在泛在業務環境中，各類信息設備被應用到生活中的各類場景中． 泛在業務環境是通過對這些無處不在的數字信息進行采集、管理、有效利用，使各類功能各異、無處不在的網絡和設備能夠協同工作，實現泛在業務環境下物與物、物與人、人與現實之間的高效交互模式．如圖 1 所示，傳統的設備能力利用方案多是面向特定行業和場景的垂直型應用，應用開發的壁壘高，通常使用封閉的私有接口和通信協議，難以滿足泛在業務環境下跨網絡、跨行業的水平型應用需求． 所以，本文提出了一種系統架構，采用模塊化的方法將設備映射為抽象的 web 資源，使各類應用能夠通過統一的 ＲESTful\\( ＲEpresentational State Transfer\\) 接口與之實現訪問和交互． 架構考慮到了泛在網中設備海量、異構、移動的特點，因此模塊的劃分和功能設計使架構具有較好的低耦合和可擴展性． 對設備的統一資源抽象使得這些數據源網絡具備應用層的互操作能力，能夠實現一個應用同時聚合使用多種設備的能力，同時，同一個設備的能力也能夠被多個應用所復用，因此可以較好的滿足泛在業務環境下設備能力的匯聚與開放的需求． 經過一個在具體硬件環境中實施的演示系統驗證了該架構的可行性和有效性．

2 相關工作

早期的泛在網研究重點在于將無處不在的數字設備與現實世界進行關聯整合，形成“Internet of Things”． 然而，早期應用的結構一般都是垂直方向的解決方案，每個應用通常只針對特定的場景，需要專用的軟件和通信協議才能工作． 這種結構在設備數量不多，用戶較少的情況下是可行的，然而它不適合泛在業務環境下大量異構設備在應用層的服務聚合與開放．為了實現較好的互操作性，研究人員嘗試將傳統網絡中的協議移植到泛在網環境中． 6LoWPAN［3］即是這種工作的成果，它能使設備具有簡單的 IPv6 通信能力． 文獻［2，6，8］利用該方法在設備中植入精簡的 web 服務． 但是該方案的實施過程仍然非常精細，例如，在各類異構設備上實施 6LoWPAN 本身便需要解決各類兼容性的問題，在受限設備上實施 web 服務也需要針對存儲和計算能力進行專門優化． 這個過程相當于在各類設備上重新實現一套網絡協議棧，成本和專業門檻較高，不適合大規模推廣．在文獻［4］中描述了一種通過對設備能力進行抽象，從而屏蔽異構差異，實現泛在網中可插拔式\\( Plug and Play\\) 開放服務市場的前景． 該工作缺少對下行通信的抽象方法進行討論． 文獻［7］嘗試在社交網絡環境中實現設備信息的共享，該工作重點考慮了實施設備信息共享時的隱私保護和接入控制等相關問題． 該工作主要針對規模和數量較小的數據源網絡信息共享，缺少對泛在網中海量設備、眾多數據源網絡的情況下可擴展性的考慮．利用已被廣泛接受和推廣的技術來實現泛在設備的能力匯聚與開放是非常合適的． Web 技術的大規模普及使之具備這種條件，具有準入門檻低、易于推廣的優勢． 在泛在網中，通常使用 ＲEST 架構［1］的方法將設備的能力抽象成能夠使用統一接口訪問的 web 資源，這主要是由于其相對于其它方法更為簡潔輕量的結果．

3 系統架構和組件功能

相比傳統的傳感器網絡應用，在泛在業務環境下設備的能力匯聚與開放所面對的應用需求種類更多，服務范圍也相對更為分散，加上泛在業務環境下設備數量眾多，架構和功能各異，因此，在架構上，除了要滿足對不同平臺的兼容性和能力匯聚開放的需求外，還需要充分考慮整個系統的低耦合和可擴展性．系統架構如圖 2 所示． 架構的設計以數據為中心，將數據源的能力匯聚與面向用戶的能力開放進行分離． 系統由數據源、預處理模塊、ＲESTful 接口模塊、控制適配模塊、數據倉儲組成． 當數據從傳感網中匯聚到系統中后，首先由預處理模塊進行必要的規整處理，將可能來自不同網絡不同類型節點的原始數據預處理成數據倉儲中所要求的格式． 用戶與系統之間的數據傳輸采用 HTTP 協議，交互過程采用 ＲESTful 風格的接口進行．

3. 1 數據源

數據源通常由普通傳感器節點和 sink 節點組成． 普通節點通常裝備有能夠感知某類參數\\( 如溫度、位置信息等\\) 的專用傳感模塊． 傳感器節點采集數據后，通常通過其自身裝備的無線發射模塊在傳感網中匯聚到 sink 節點． 根據應用需求場景的不同，傳感器節點有時也需要接收和響應處理來自 sink下發的控制類請求報文．Sink 節點連接傳感器網絡和全功能外部設備，同時具備與傳感器網絡中的節點和全功能設備進行通信的能力． 普通節點的數據匯聚到 sink 節點后，由 sink 交給全功能設備上的預處理程序進行處理． 對傳感器網絡的控制指令也首先交由sink 節點然后向下傳達．

3. 2 預處理模塊

在泛在業務環境中，平臺需要能夠支持不同種類，功能和架構各異的數據源設備的接入． 這意味著接入平臺的泛在設備的能力、上傳的數據類型、數據的封裝方式等等也是非常多樣化的． 因此，當數據匯聚到 sink 節點后，需要由預處理模塊對數據進行必要的規整和格式化操作，屏蔽差異，使之符合平臺對數據格式的要求，然后將其存入數據倉儲模塊．舉例來說，預處理通常需要完成的功能如下:

1\\) 針對各類 sink 節點上傳的報文，進行相應的解析，提取出相關的數據字段;

2\\) 若節點為能力受限節點，不能隨報文提供數據采集的時間戳信息，則預處理模塊有必要在數據進入倉儲模塊前為其添加當前的時間信息;

3\\) 當數據源網絡缺少標識，相互之間無法區分時，預處理模塊可以在收到數據后為其添加相應的網絡信息標識;

4\\) 如有必要，需要對采集的數據進行單位換算，或者進行異常值檢測，便于統計處理;

5\\) 為了增加傳輸的效率、延長數據源網絡的生命周期，數據源節點可能會積累多個感知數據后用封裝到同一個報文中發出． 在這種情況下，預處理模塊可能需要將其分拆開，作為單個數據條目存入數據倉儲模塊．

3. 3 ＲESTful 接口模塊

ＲESTful 接口模塊用于對泛在業務環境下的設備進行功能抽象和能力開放． 將設備的能力封裝為 ＲESTful 風格的接口供外部應用系統調用． ＲESTful 接口通常使用 HTTP 協議作為數據傳輸的方法，接口交互時的數據封裝格式一般采用較輕量的 JSON，或者 XML 格式．ＲESTful 接口的設計主要需要表達對數據源的常用操作，如數據的查詢和基本控制功能，還可以通過接口的封裝提供原設備不具備的能力接口，如統計相關和事務控制類的接口等．通過 ＲESTful 接口抽象層，各類設備自身的私有通信方式和協議細節被隱藏起來，應用程序接入設備的門檻可以大大降低． 同時，通過抽象層開放設備的能力，使得能夠同時接入和使用數據源服務的用戶數大大增加，符合泛在業務環境下對服務聚合和開放的需求．

3. 4 控制適配模塊

當需要通過 ＲESTful 接口向下實施對數據源的配置功能時，由于向下傳達控制指令時的網絡延時和傳輸的可靠性難以保證，加上 HTTP 協議本身無狀態的特點，對數據源的配置類指令采用事務控制和非阻塞的方式進行． 這種做法的好處是，在保證服務可用性的同時，客戶端在進行數據源配置時無需考慮每類設備的細節，從而簡化與數據源進行主動交互時的復雜度．控制適配模塊的功能流程描述如下:

1\\) 首先，由平臺的用戶向 ＲESTful 接口模塊調用配置相關的接口;

2\\) ＲESTful 接口模驗證請求來源的合法性以及請求本身的完整性后，為該次配置動作創建相應的事務記錄，存入事務倉儲中; 將事務標識號返回給客戶端． 否則，該次調用配置接口失敗，執行結束;

3\\) 控制適配模塊監控事務倉儲中的事務列表，依據每條事務信息的描述內容執行不同的動作． 事務的描述字段可包括: 事務的當前狀態、單次執行失敗后重復次數、執行間隔、上次執行時間、事務執行動作的描述信息等． 事務的終止狀態至少包括兩類: 執行成功、執行失敗終止;

4\\) 平臺的用戶使用之前獲得的事務標識號向 ＲESTful后端模塊查詢事務當前的執行狀態;

5\\) ＲESTful 接口模塊驗證請求完整性后，向事務倉儲查詢相關的事務信息，并將之返回給用戶應用程序．

3. 5 數據倉儲模塊

在泛在業務環境中，一方面，平臺需要適應來自多個數據源網絡的能力匯聚和開放需求; 另一方面，平臺也需要應對來自應用程序對開放接口的大量調用． 在這種情況下，在平臺中將數據倉儲模塊獨立出來單獨考慮就顯得非常必要，因為在大數據量和并發量的情況下，需要特別保證數據的安全和高可用性，隨機接入平臺的數據源網絡和應用程序越來越多，隨之而來的可擴展性需求也會出現． 將業務邏輯和數據倉儲分離開來正是為了適應這種可擴展性的需求．數據倉儲模塊在本系統中主要用作兩類功能:

1\\) 作為永久數據倉庫存儲預處理模塊規范化后的傳感數據;

2\\) 為控制適配功能提供相應的事務信息基礎設施．

當用作傳感數據的存儲時，其中應至少包含節點標識信息、數據和數據類型描述． 當需要區分多個數據源網絡時，需要包含不同網絡的標識信息． 對于節點的信息，可依需求對節點型號、節點運行程序的版本號、節點配置相關的參數進行記錄．當用作事務信息存儲時，其中至少應包含事務標識號、事務描述信息、事務當前執行狀態信息． 對于事務描述信息，其規范由控制適配模塊來定義以保證相應的功能需求和兼容性．

4 系統參考實現和部署

系統架構的可行性和有效性通過一個在具體硬件平臺上實施的參考系統來進行一步驗證． 系統中傳感器網絡的硬件設備共有 4 種，主要為功能受限設備，它們組成數據源網絡．1\\) 普通節點 2 種，分別是 Crossbow MPＲ 2400\\( MICAz\\) 和Crossbow MPＲ XM2110\\( IＲIS\\) ;2\\) Sink 節點 Crossbow MPＲ XM2110\\( IＲIS\\) ;3\\) Sink 節點與 PC 的接口設備 Crossbow MIB 520 USB In-terface Board;4\\) 傳感器設備 Crossbow MTS300．傳感器網絡中的節點運行 TinyOS 2. 1. 0 系統，其所使用的通信協議和接入方式是專門設計的私有方法． 應用程序通過 ＲESTful 接口模塊提供的接口來訪問傳感器網絡，在演示系統中呈現給最終用戶的是 Web 交互界面．具體來說，普通節點周期性地\\( 默認以 10 秒為周期\\) 在傳感器網絡中向 sink 節點上傳數據，數據類型有兩種，分別為溫度值和光照強度值．預處理模塊與 sink 節點通過串口進行通信，取得數據的原始報文，從中獲取關鍵的節點標識、傳感數據、數據類型信息． 由于這些節點所上傳的報文中無法包含有效的時間戳信息，因此在預處理時需要對此進行添補． 另外，TinyOS 系統中節點的標識是局部唯一的，當有多個網絡接入系統時，則可能會出現不同網絡中設備標識符相互沖突的情況，因此預處理模塊需要對不同網絡進行區分，根據與之通信的 sink 節點的不同為數據添加數據來源信息． 也可以依據業務邏輯的需要，對節點標識符進行補充，使之具備全局唯一性．ＲESTful 接口模塊收到客戶端的查詢類請求后，從數據倉儲中取得信息，然后再按照接口參數的要求封裝成標準的格式返回給客戶端． 在演示系統中有控制類接口 1 個，用于設置節點的數據上報周期． ＲESTful 接口在收到這類請求后，通過控制適配模塊注冊相應的事務信息，然后將事務號返回給用戶應用程序． 控制適配模塊負責事務的執行，從而實現控制指令的非阻塞操作．

演示系統的 ＲESTful 接口設計示例如表 1 所示． ＲESTful接口模塊抽象和封裝出必要的數據查詢接口和網絡參數控制功能，還可以在此基礎上提供原始數據源不具備的接口，例如基本的數據統計接口、數據可視化相關的接口等． 接口調用參數使用 HTTP 協議標準的方式編碼，數據傳輸時的封裝也使用標準的 JSON 格式編碼，從而保證不同平臺間的兼容性和互用性，具有易于實施和推廣的優點．如圖 3 所示，系統在整體上為各個接口設計了統一的應答格式． 合并具有相同語義的部分，減少了細節差異，從應用開發人員的角度看使得接口整體具有相互關聯的一致性．

圖 4 為某次調用/QueryData 的結果示例，該次調用為數據查詢類的調用，查詢結果使用 JSON 進行封裝表示． status字段的值為 0，reason 字段的值為”ok”，它們表示此次調用成功． 查詢結果中數據負載的封裝和表示需要依據各個接口的功能需求而分別定義，此處使用 JSON 的 object 類型進行表示． 其中，dataset 字段為 array 類型，用于封裝滿足查詢條件的數據集． 每個數組元素又使用 object 對象封裝，包含有 data、sn、ts、id 等 4 個字段，分別表示光照值、數據的序號、數據的時間戳、數據源的節點標識符． 數據負載中還含有數據集的簡單統計信息，由平臺計算后返回給應用程序，封裝在字段 min、max、median、mean、std _dev 中，分別表示最小值、最大值、中值、平均值、標準差。

5 結束語

本文針對泛在業務環境下設備的接入和交互問題，設計了一種基于 ＲEST 的能力匯聚與開放系統架構． 考慮到泛在網中設備數量大、異構、移動等特點，系統的設計采用了模塊化劃分的方法，模塊的劃分方式保證了平臺的低耦合和可擴展性． 與傳統方法中客戶端與數據源一對一交互的模式相比，采用 ＲEST 架構方法對數據源能力進行抽象，使得同一個數據源的能力能夠同時應用到多個應用中去，同一個應用可以使用統一的接口來訪問多個不同的數據源能力． 標準的通信和交互接口相比私有協議具有準入門檻低、易于推廣的特點，符合泛在業務環境下能力匯聚與開放的需求．