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客戶端的遠程方法，從而對外界事件進行響應。
未完待續。。。 等不急的童鞋可以看原文 https://allseenalliance.org/docs-and-downloads/documentation/introduction-alljoyn-thin-library
另創建了alljoyn物聯網群 49073007 歡迎加入交流！