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