由於其他事情耽誤，這個翻譯現在才完成。接上篇——
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），提供了相關資源用於幫助用戶編譯、修改、測試和執行某個項目。
看完了，大家有何感想呢？？