【Alljoyn】 Alljoyn学习笔记七 Alljoyn瘦客户端库介绍
Alljoyn瘦客戶端庫介紹（上）
?
1、簡介
本文檔對AllJoynTM瘦客戶端的核心庫文件（AJTCL）進行了詳盡的介紹。本文檔介紹了系統整體架構，AllJoyn框架結構，并著重于介紹如何將嵌入式設備加入AllJoyn系統整體架構中。
1.1目的
本文檔介紹了如何使一個受限于功耗、計算能力和內存的設備（嵌入式設備）加入AllJoyn分布式系統。具體而言，本文檔包括了對AllJoyn面向嵌入式系統的方面的介紹，并著重描述了基于AllJoyn的系統的各個組件是如何與嵌入式設備協作以構建一個基于接近式結構的，點對點的計算系統。
1.2適用人群
本文檔適用于任何想將嵌入式設備加入點對點網絡的電子愛好者，包括應用開發人員、系統軟件開發人員、網絡專家、設備操作人員和系統經理。我們假設讀者已經對嵌入式系統有了基本的認識，并且已經理解了了《Introduction to the AllJoyn Framework》（AllJoyn架構介紹）一文說描述的AllJoyn系統概況。
2、綜述
AllJoyn是一個開源的軟件系統，用于將運行在不同類別設備上的分布式應用構建成一個分布式環境，并著重于便攜性、安全性和可動態配置性。AllJoyn不依賴于平臺，即它的設計盡可能地獨立于其所運行的操作系統和軟硬件。
AllJoyn標準核心庫（AJSCL）被設計成可用于 Microsoft Windows、Linux、Android、iOS、OS X、OpenWRT和瀏覽器插件的系統環境中。這些軟件系統的共同特點是它們運行于通用型計算機系統。通用型計算機通常擁有相當數量的內存、足夠大的功耗和計算能力，甚至很多操作系統都支持多處理器、多線程和多語言環境。
與之相對的是，嵌入式系統往往只針對單一功能，并運行于某個設備中的嵌入式處理器中。由于其需要完成的功能有限，工程師們往往通過減小內存容量、降低處理器速度和功耗、減少外設接口和用戶接口等方式來優化系統，以降低產品成本和體積。AllJoyn 瘦客戶端核心庫（AJTCL）便是針對嵌入式系統的分布式編程所設計。
由于AJTCL的運行環境資源有限，AllJoyn組件定會受到此系統的很多限制。具體來說，這意味著我們無法像編寫AllJoyn路由程序一樣（需要多線程支持）使用多個網絡連接和大量的RAM和ROM資源，也無法使用那些支持多語言的面向對象的編程環境。鑒于這種情況，AJTCL僅僅包含了一些總線連接程序（參看《Introduction to the AllJoyn Framework》一文），并完全由C語言寫成。其對應于接口、方法、信號、屬性和總線對象的數據結構都經過了大幅優化以減少空間占用，同時API（應用程序接口）也大不相同。
盡管AJTCL與AJSCL的API大不相同，但他們所有的核心概念都是相通的，AJTCL只是以一個更緊湊的形式出現，或者實際上是遠程運行在一個（計算能力）更強的機器上。
3、概念性模型
如之前章節中所言，絕大多數在AJTCL中所使用的高度抽象的概念都與其在AJSCL系統中的概念相同。《Introduction to the AllJoyn Framework》一文中“Conceptual Overview”一章已經向讀者介紹了這些概念。在本章中，我們假設讀者已經對上文的相關概念有所熟悉，因此本章只介紹兩者的不同點，用于幫助讀者理解AJTCL的架構。
3、1 AllJoyn瘦客戶端核心庫仍然是AllJoyn
理解“AJTCL是AllJoyn架構的一部分”對于理解整個AllJoyn系統很重要。瘦客戶端的核心庫程序可完全地與AJSCL互動。鑒于AllJoyn網絡傳輸協議在兩種類型的庫中都有實現，AJSCL程序完全不用考慮他到底是在跟AJTCL程序對話還是在跟AJSCL程序對話。
回顧《Introduction to the AllJoyn Framework》一文，AllJoyn分布式總線的基本結構由幾個處于不同的、物理上分離的計算機系統所構成，如圖1所示。
如圖所示，下標為Host A和Host B的兩個虛線框表示在給定的兩個主機（host computer）上的兩個總線段（bus segment）。每個總線段都包含一個AllJoyn路由節點（以標注了D字母的圓圈表示）。一個主機上可能連接了多個總線掛件（bus attachments），每個總線掛件都與一個本地的守護進程（以六邊形表示）相連接。這些總線掛件分為服務器（services）和客戶端（clients）兩類。
由于運行AJTCL的設備通常沒有足夠的資源運行路由程序，AllJoyn架構對瘦客戶端進行了一些改變，使運行瘦客戶端的設備借助于分布總線上其他主機上的AllJoyn路由程序連接到AllJoyn網絡。具體方法如圖2所示。請注意嵌入式系統A（Embedded System A）和嵌入式系統B（Embedded System B）與運行路由程序并管理該分布式總線段的主機B（Host B）并不是同一個設備。這些運行AJTCL的嵌入式系統與該總線段上的主機路由程序之間的連接通過TCP協議（傳輸控制協議，Transmission Control Protocol）實現。
其中，嵌入式系統和路由節點之間的通信流稱為AllJoyn消息，如《Introduction to the AllJoyn Framework》一文所述，包括總線方法、總線信號和對應于各個對話的屬性流。
在某些場合，我們允許AJTCL設備連接并借助附近尋找到的老式路由節點。我們稱這種連接關系為“不受信的關系”（以路由節點的視角）。同樣在某些場合，我們只允許特定的AJTCL設備連接到特定的路由節點。我們稱這種關系為“受信關系”（同樣從路由節點的視角）。
這些關系的建立依賴于一個在概念上與客戶端與服務器之間的發現和連接過程相似的發現和連接過程。一個AllJoyn路由節點通過廣播一個眾所周知的名稱來表達其對接管一類AJTCL設備的意愿。這個廣播可能以路由配置包或以一個具體的AllJoyn組件建立的廣播包的形式出現。緊隨其后的一個來自設備的連接請求將會使預備建立受信連接的路由節點開始詢問發送該請求的AJTCL（或冒名頂替的AJTCL）以建立一個憑證。在建立非受信連接的情況下，路由節點將會允許任何連接請求。對于非受信連接，路由節點不會允許AJTCL執行任何需要建立遠程對話的操作（和任何需要付費的操作）。
正如以上所引述的，一個AJTL設備建立連接的過程可以分為三個步驟：
發現過程
連接過程
認證過程
其中，發現過程除了兩種例外情況以外，都如《Introduction to the AllJoyn Framework》一文中所描述的那樣，就像是某種服務廣播。第一種例外是AJTL發現廣播的方式通常是“靜默的”廣播。這表明路由節點不是無緣無故地發送此廣播。
第二種例外是對靜默廣播的響應通常是靜默的——我們稱之為“靜默響應”。這表明響應將被單播回發送者，而不是像活躍廣播一樣被多播出去。這么做的主要原因是為了使某些無法實現多播的嵌入式設備加入Alljoyn分布式系統。
3.2什么是AllJoyn瘦客戶端核心庫設備？
人們通常人為AJTCL設備和傳感器網絡（Wireless Sensor Network，WSN）中的傳感器節點（Sensor Node，SN）在概念上很相似。傳感器節點通常是某些小體積、低功耗、低配置的傳感器或者執行器件。它們通常可以檢測周圍環境、與外界通信，甚至有可能在基于網絡處理或外界事件的激勵下執行某種動作。這是一個非常寬泛的定義，下面舉的一部分設備的例子適用于這個定義：
點燈開關
自動調溫器
空調
排風閥
煙霧傳感器
運動檢測傳感器
人體傳感器
麥克風
揚聲器
耳機
門
門鈴
烤箱
電冰箱
烤面包機
關于無線傳感器網絡的文章一搜一大把。AllJoyn系統與之不同的是，無線傳感器網絡通常使用自組織、多跳、點對點的無線網絡（Self-organizing multi-hop ad hoc wireless networks），而不會主要關注安全問題；而AllJoyn架構就像是運行于基礎模式的Wi-Fi網絡，即給定的設備必須經過認證和組織。為了完成某個Wi-Fi網絡的身份認證，AJTCL使用了一個名為“onboarding”的過程。這個登陸服務的架構允許一個假定沒有友好的用戶接口的運行瘦客戶端的設備從他的目標網絡獲取足夠的信息，用以完成加入目標網絡所需的身份認證過程。這個登錄服務架構將在一個專門的文檔中定義并介紹。
如同一個傳感器節點所扮演的角色一樣，一個AJTCL設備通常包含一項AllJoyn發現服務。該服務會以AllJoyn信號的形式通過連接的硬件和通信事件探索自己的周圍環境。如《Introduction to the AllJoyn Framework》一文所描述，它可以通過監聽其他設備發來的信號，或者響應其他AllJoyn客戶端的遠程方法，從而對外界事件進行響應。
?
?
4 瘦客戶端核心庫架構
由于AllJoyn瘦客戶端核心庫（AJTCL）必須運行在那些功耗受限、計算能力有限、資源緊缺的設備上，因此它無法像運行在通用型計算機系統上那樣使用和AllJoyn標準核心庫（AJSCL）一樣的架構。
一個AJSL或服務進程的分層結構如圖3所示。《Introduction to the AllJoyn Framework》一文描述了這些層次結構的更詳盡細節。需要特別注意的是， 每個Alljoyn客戶端或服務器程序都會以這種層次結構來構建AllJoyn應用。
每個運行AJSCL的主機上至少都要運行一個路由程序。這個路由程序可以以單獨的路由進程形式運行，或者寄生于某個應用程序中運行。AJSCL路由程序的分層結構如圖4所示。
注意到，路由程序可以為路由節點之間路由消息的傳遞提供額外的支持，并能支持如Wi-Fi Direct的多重網絡傳輸機制。這個功能可以有效地降低計算能力、功耗和內存的開銷。
我們很明顯無法在嵌入式系統中運行如此數量的程序，所以AJTCL最大程度地縮減了在給定設備上運行所需的代碼量。AJTCL只使用最基礎的C運行環境，并通過借助其他設備的計算能力實現路由規則。如圖5所示，對比AJSCL，AJTCL舍去了大部分AJSL系統開銷。AJTL僅僅為總線掛件提供少量必須的API（應用程序接口），并將AllJoyn消息接口直接提供給程序員，而不是提供間接的接口函數。
消息層沒有提供抽象的傳輸機制，而是直接使用了用戶數據塊傳輸協議（UDP）和TCP協議。分層結構中的端口層非常簡單，又幾個簡單必須的本地系統函數構成。為了是代碼體積最小化，其完全以C語言寫成。由于使用了這些優化機制，一個AJTCL系統只需25K字節的內存就可運行，而一個綁定了路由功能和C++版本客戶端和服務器程序的應用可能需要十倍數額的內存開銷，而一個Java語言版本的AllJoyn程序則需要40倍左右的開銷。
5 整合運行
?
為了使本章的討論更加具體，在此舉了兩個分布式系統的例子。第一個例子是一個最小化的AllJoyn系統，由一個運行在智能手機上的AllJoyn應用程序和一個簡單的AJTCL設備構成。此例闡述了上文描述的受信路由關系。第二個例子稍微復雜一些，包括一個運行在無線路由器上的路由程序。
注釋 通常的情形是由一個運行OpenWRT系統的路由器來運行預裝好的AllJoyn路由程序。此路由程序接受那些連接到Wi-Fi網絡的瘦客戶端庫發來的非受信連接請求。
少量AJTCL設備連接到路由器，并在基于AllJoyn的無線傳感器網絡中扮演傳感器節點的角色，而一個通用型計算機則完成數據融合的工作。
注釋 在無線傳感器網絡中，數據融合是將一些不同的節點收集到的結果整合到一起的過程，或者將其結果與其他傳感節點獲得的結果融合到一起，以便做出決策。
5.1 一個最小化的瘦客戶端系統
?
一個最小化的使用AJTCL的系統包括一個運行AJSCL的主機和一個瘦客戶端設備。AJSCL給將要連接到它的瘦客戶端提供AllJoyn路由功能，同時也為使用瘦客戶端的應用提供平臺。就如之所說，瘦客戶端設備通常扮演傳感器節點的角色，它向運行在主機上的應用程序發送信息。應用程序以某種方式處理這些信息，并向傳感器節點發送一些命令，使其應對當前環境。
考慮一種簡單但可能欠考慮的情況，一個壁掛式恒溫器控制著一個電爐，并在一個安卓設備上運行著一個控制應用。安卓設備上運行AJSCL，而壁掛式恒溫器上運行著AJTCL。該系統可以用圖6來表示。
在本例中，一個需求是壁掛式恒溫器，其只能被安卓設備中對應的恒溫器控制程序所控制。
盡管在本例的需求中說明了恒溫器僅可被安卓設備控制，但需求也可以是恒溫器連接到某個路由節點，再由該路由節點連接到應用程序。這意味著安卓應用程序應該與AllJoyn路由程序綁定在一起，而這個綁定在一起的路由程序和應用程序應該以一個路由節點的身份提供給瘦客戶端使用。這種配置允許在AJTCL和路由節點/應用程序對中建立一種受信關系。
應用程序接著請求與他綁定的路由程序以一個眾所周知的命名方式向AJTCL發送一個“安靜的”廣播（例如，com.company.BusNode<guid>）。路由程序接著準備響應那些以之前廣播的命名方式命名的安靜的（單播）的回復。當瘦客戶端出現時，它應當在關聯的網絡前綴（com.company.BusNode）上啟用發現過程，如圖7所示。
當路由節點收到一個對其之前“安靜地”廣播過的名字的明確的請求時，它將回應一個表明該名字是由此路由節點所廣播的消息。接下來AJTCL會嘗試連接到這個響應的路由節點。過程如圖8所示。
這樣一來，一個邏輯上的AllJoyn總線就已經建立起來了，應用程序和瘦客戶端服務通過運行在安卓設備上的路由程序連接起來。以在《Introduction to the AllJoyn Framework》一文中使用過的泡泡圖來表示該系統，這種配置看上去就像是AllJoyn路由節點連接了服務器程序和客戶端程序，如圖9所示。
此時，AJTCL已經連接到與應用程序綁定在一起的路由程序，但是應用程序和瘦客戶端互相都不知道對方的存在。一般在此時，AJTCL便會請求一個眾所周知的總線名，并會在AllJoyn的感知下實例化一個服務。如《Introduction to the AllJoyn Framework》一文所描述，瘦客戶端會使用瘦客戶端核心庫的API接口創建一個對話端口并廣播一個眾所周知的名稱。這個名稱一般不會和路由節點廣播的名稱相同；它與瘦客戶端和應用間的客戶端/服務器的關系有關，而與路由節點—瘦客戶端間的關系無關。運行在安卓設備上的應用程序將會針對這個名稱運行發現服務，如圖10所示。
當運行在AJTCL上的服務被運行在安卓設備上的客戶端發現時，該客戶端會加入此服務創建的對話。
從這個角度來說，運行在安卓設備上的應用程序可以訪問到AJTCL的服務，而且可以是任何AllJoyn服務。它可能通報服務發送的信號——在此例中，可能是包含當前溫度的周期信號。此應用可能構建一個用戶界面，允許用戶鍵入期望達到的溫度，并將此溫度使用如《Introduction to the AllJoyn Framework》一文所描述的AllJoyn遠程方法發送給AJTCL。一旦收到一個呼叫方法，運行在AJTCL上的服務程序便會將請求轉發到電爐以設置理想溫度。
在瘦客戶端上使用的API和在AJSCL或服務程序上使用的API有很大的不同；盡管在兩種情況下，傳輸協議是完全一樣的，但對于其中一方而言，另一方組件的性狀是不可見的。從這方面而言，AllJoyn是獨一無二的，而之前框圖中的各個泡泡，包括瘦客戶端，從其目的或行為來看都是沒有區別的。
5.2 一個基于瘦客戶端庫的無線傳感器網絡
本例描述了一個非常基礎的家庭管理系統。該系統的無線接入點是一個運行OpenWRT的路由器，在其上預裝了一個允許來自瘦客戶端的非受信連接的AllJoyn路由程序。這樣AJTCL客戶端便可以通過連接到該路由節點接入系統。網絡中的瘦客戶端設備可以是溫度傳感器、運動檢測傳感器、電燈開關、熱水器、電爐或空調。
如之前所言，本例中的數據融合功能由一個運行在通用型計算機上的應用程序實現并整合顯示。這并不是說在該網絡中一定要有一個通用型計算機——數據融合可以以其他方式實現；但是，在本例中的通用型計算機可以幫助我們理解AJSCL和瘦客戶端設備是如何互動的。整合顯示可以使用壁掛式的顯示設備，或者簡單地在家中的某個PC上顯示。舉例而言，該顯示程序可以提供不同房間的溫控器和溫度計的用戶接口；或者是虛擬的電燈開關，或運動檢測儀。數據融合算法程序將會決定什么時候開燈，如何控制電爐或空調的開關，或者如何最有效地控制熱水器的溫度。
要考慮的第一個組件是如圖12所示的OpenWRT路由器。該路由器管控一個獨立的AllJoyn路由域（在圖中以黑色粗水平線表示，代表一個AllJoyn分布式軟件總線的一個總線段）。
在該路由器所在的總線段中有一個AllJoyn服務程序，該程序使用AllJoyn架構提供了一種方式來配置路由器和預裝在路由器上的路由程序。此外，圖中的一些空槽表示與AJTCL之間的非受信連接。由于這是一個通用AllJoyn路由器，對應的軟件總線可以被擴展到其他的總線段以形成如圖1所示的分布式總線。
如之前的章節所述，AJTCL設備將會運行發現過程以搜尋他們能連接到的路由節點。盡管在此描述的是一個非受信關系，運行在OpenWRT路由器上的AllJoyn路由程序可以配置成“安靜地”廣播一個通用的名稱，如org.alljoyn.BusNode，暗示該路由節點是一個AllJoyn分布式總線上的一個節點，并意圖接管瘦客戶端。
代表傳感器節點的AJTL設備通過登錄過程接入無線網絡。在此過程中，他們以所謂的友好的名稱（即有意義的名稱）來命名。舉例說，一個電燈控制器（開-關-調光控制器）可能被命名為“廚房”，而另一個可能被命名為“臥室”。對應的瘦客戶端節點開始探索他們連接的路由節點（可能是org.alljoyn.BusNode），并嘗試連接。盡管上圖中的很多“槽”假定是非受信的，瘦客戶端設備還是可以如圖13所示那樣加入網絡。
一旦瘦客戶端程序連接到了OpenWRT路由器所在的總線段，它們就會開始廣播其對應的服務。如之前所假設的，這是一個家庭控制系統，連接到路由器提供的無線網絡。該設備會嘗試發現服務，并在系統中尋找瘦客戶端庫提供的服務，如圖14所示。
一旦家庭控制系統發現了某個瘦客戶端廣播的服務，它將嘗試與該瘦客戶端開始對話。其結果是路由器所在的總線段和家庭控制系統融合成一個虛擬分布式總線。
當這個融合的總線完全形成時，連接到總線的設備就成了一個標準的AllJoyn客戶端或服務器。布式設備上的其他部件不會知道這些ALlJoyn瘦客戶端傳感器/執行器實際上是嵌入式設備，并通過TCP協議連接到AllJoyn路由節點，也不會知道家庭控制程序以Java編寫并運行在一個運行安卓系統的通用型計算機上。這些客戶端和服務器僅僅只是執行遠程呼叫方法和收發信號。
讀者現在可以了解運行在數據融合節點上的算法。舉例說明。在分布式總線上傳輸的一個重要的AllJoyn信號可能是與CARBON-MONOXIDE-DETECTED（檢測到一氧化碳）對應的某種東西。這個信號將被家庭控制系統（數據融合中心）接收。家庭控制系統收到這個信號以后，可能會發送一個遠程方法給某個執行節點，使其TURN-FAN_ON（打開風扇），它也可能發送一個遠程方法給另一個執行節點，使其SOUND-ALARM（播放報警音），還可能發送短信給屋主，告訴他家中出現過量的一氧化碳。
更為常見的情形下，家庭控制系統還可能向電爐發送一個遠程方法，使其在房間中沒人的情況下（通過運動檢測裝置的檢測結果和日程表判斷）降低房間溫度。房屋控制單元可能向熱水器發送一個消息，使其在工作時間和午夜降低水溫，而在午夜洗碗器需要工作時向其發送一個呼叫方法使其提高水溫，這樣一來便可以在電費最低的時候工作。
所有這些家庭控制系統響應的信號和發送的呼叫方法都與信號發送/接受設備的類型完全無關。
6 總結
AllJoyn是一個綜合的系統，其設計目的是為了在成分各異的系統上開發分布式應用程序。AJTCL使嵌入式設備可以加入AllJoyn分布式軟件總線，并能以忽略細節的方式在系統中存在，而這一點正是開發人員所頭疼的。這個成果可以讓應用開發者專注于應用程序的內容，而不必考慮太多底層的、嵌入式系統網絡方面的事情。
AllJoyn系統可以以一個整體共同工作，而不像點對點網絡，不同節點間固有的不匹配會造成很多問題。我們相信，與在其他平臺上開發的應用相比，AllJoyn系統可以以更簡單的方式構建包含嵌入式設備的更為強大的分布式應用。
了解更多
想要了解更多關于如何在開發中使用AllJoyn的信息，請在AllSeen聯盟的網站上瀏覽并下載相關文檔：（www.allseenalliance.org）
介紹型說明書——描述了ALlJoyn技術和相關概念。
開發型說明說——介紹了如何構建環境，并提供了對于特殊問題的解決方案，包括代碼片段的注釋。
API參考——提供了在所有支持的編程語言中使用AllJoyn源代碼編寫應用程序的相關細節。
下載——軟件開發包（SDK，Software Development Kits），提供了相關資源用于幫助用戶編譯、修改、測試和執行某個項目。
?
原文來自；http://www.cnblogs.com/alljoyn/p/3925910.html
?
總結
以上是生活随笔為你收集整理的【Alljoyn】 Alljoyn学习笔记七 Alljoyn瘦客户端库介绍的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【Alljoyn】 Alljoyn学习笔
- 下一篇： 【Http协议】深入理解HTTP协议