原文地址:http://www.189works.com/topic/a/tupianzhuanti/AllJoynkaiyuanxiangmu/download/2012/0308/56.html
AllJoyn介紹
目錄 法律聲明 前言 目的 范圍 修訂歷史 概述 AllJoyn的優勢 開源 操作系統的獨立性 開發語言的獨立性 物理網絡和協議的獨立性 動態配置 廣播和發現服務 安全 對象模型和遠程方法調用 軟件組件 概念概述 遠程方法調用 AllJoyn總線 總線守護進程 總線附件 總線方法、總線屬性和總線信號 總線接口 總線對象和對象路徑 代理總線對象 總線名稱 廣播和發現 會話 郵政地址模擬 AllJoyn會話 綜述 高層系統架構 客戶端、服務和對等點 守護進程 總結 了解更多
法律聲明本文檔中包含的信息均得到了Creative Commons Attribution-ShareAlike 3.0 Unported License的許可。(i)本文檔中的所有源代碼都是基於Apache License version 2.0授權;(ii)本文檔和包含的所有信息都是基於“as-is”申明,並且沒有任何形式的擔保。 AllJoyn是高通創新中心公司的商標,其它產品和品牌可以注冊或使用其各自所有者的注冊商標。 這種技術數據可能受制於美國和國際的出口、轉口或轉讓法律。嚴禁違反美國或國際法律。 Qualcomm Innovation Center, Inc. (高通創新中心公司) 5775 Morehouse Drive San Diego, CA 92121-1714 U.S.A. Copyright © 2011, Qualcomm Innovation Center, Inc., All rights not expressly granted are reserved. HT80-BA013-1 Rev B 可能包含美國和國際出口控制信息 前言目的本文檔提供了AllJoyn™的高層次介紹。它描述了系統的總體目標和優勢,以及AllJoyn如何在移動環境下提高網絡體驗。此外,該文檔涵蓋了系統和描述在高層次的基本抽象,以及多個AllJoyn系統是如何工作並提供基於相鄰的點對點(peer-to-peer)移動計算環境的。 范圍該文檔專門提供給對使用AllJoyn系統來提升網絡或分布式手機應用性能感興趣的人。我們假設使用者對移動通信技術並不特別擅長,所以該文檔對於任何對peer-to-peer網絡感興趣的人都是適合的,包括應用開發商、系統軟件開發者、網絡專家、設備制造商和產品經理。 修訂歷史下表提供了本文檔的修訂歷史。
概述AllJoyn是一個開放源碼的軟件系統,它為分布式應用程序在不同設備中提供了運行環境,特別是移動性、安全性和動態配置。AllJoyn系統處理了異構分布式系統中固有的難題,並解決了將移動性引入方程時所產生的獨特問題。這使得應用開發人員可以將注意力集中到應用程序的核心問題上了。 AllJoyn是一個“中性平台”,它被設計為相對於它運行的具體操作系統、硬件和設備盡可能的獨立。事實上,AllJoyn是在Microsoft Windows、Linux和Android三種環境中開發出來的。 AllJoyn始終秉承相鄰性和移動性的設計理念。在移動環境下,設備將不斷與其它的相鄰設備連接和斷開,並可以改變底層網絡能力。 AllJoyn作為一個開源項目遵守Apache Version 2.0 license授權。AllJoyn的代碼庫可以從http://www.alljoyn.org上獲取。 AllJoyn技術適用的應用程序類型只會受制於開發者的想象力。擴展社交網絡就是其中一個例子。用戶可以在配置文件中記錄自己的喜好和興趣。當進入其它位置后,具有這種AllJoyn功能的手機就會立即尋找附近其它具有類似興趣的設備,並創建一個點對點的對等設備之間的通信網絡,讓它們進行溝通和信息交換。 現在,大多數手機都集成了藍牙功能,所以如果兩個人處在同一個房間並開啟了藍牙,AllJoyn可以允許手機之間直接進行溝通,並允許應用程序進行交互(如果AllJoyn的安全系統允許)。例如,如果兩個用戶進入一個擁有Wi-Fi熱點的家庭或辦公室,他們的設備可以連接到底層接入點並充分利用額外的網絡容量。此外,他們的設備還可以查找到鄰近的其它設備(Wi-Fi的覆蓋區域中),發現這些設備上的服務,如果需要的話還能使用這些服務。 使用AllJoyn實現的另一個例子就是實時多玩家游戲。圖1顯示了如何使用不同設備和不同底層網絡技術來實現多用戶游戲。基礎設備的詳細管理都由AllJoyn處理,所以游戲作者可以把重點放在游戲的設計和開發上,而不是解決對等網絡的復雜性。 圖1. AllJoyn異構網絡
作為AllJoyn生態系統的擴展,你可以想象出豐富多彩的應用。例如: Ÿ 創建一個音樂播放列表,將它們輸入具有AllJoyn功能的汽車音響系統,或儲存到家用立體聲系統中(受數字版權管理) Ÿ 當你剛從國外或旅行后回到家中,同步最新的照片或者其它媒體到啟用了AllJoyn功能的數字相框或電視中 Ÿ 控制家電產品如電視機、錄像機和游戲機 Ÿ 筆記本電腦和台式電腦的互動,並在該區域中分享內容 Ÿ 企業中的同事之間或學校中的學生之間進行項目協作 Ÿ 提供基於鄰近發放的電子優惠券或名片服務 可能性是無窮無盡的。 AllJoyn的優勢如前所述,AllJoyn是一個中性平台系統,旨在簡化鄰近異構分布式移動通信網絡系統。這里的異構性不僅表示不同的設備,而且可以是具有不同操作系統和不同類型的設備(例如個人電腦、手機、平板電腦和消費性電子產品),並且使用不同的通信技術。 開源AllJoyn是在Apache Version 2.0 license授權下作為一個開源項目進行開發的。這代表所有的AllJoyn代碼庫都是可供查閱的,並且鼓勵開發者進行補充和改進。如果AllJoyn缺少某個功能,你可以對此作出改進和貢獻。如果你在嵌入式設備中使用AllJoyn,或者有任何技術性問題,我們開源社區中的眾多參都會願意提供幫助和指導。AllJoyn的代碼庫可以在http://www.alljoyn.org中獲得。 操作系統的獨立性AllJoyn提供了一個抽象層,允許AllJoyn及其應用程序運行在多個操作系統平台上。AllJoyn支持大部分的標准Linux發行版本包括Ubuntu等,並可以運行在Android 2.2和更高版本的智能手機和平板設備上。AllJoyn還在常見版本的Microsoft Windows操作系統上進行了測試和驗證,包括Windows XP和Windows7。 開發語言的獨立性目前,開發人員可以使用C++或Java語言來創建應用程序。其它語言的支持也將很快面世。 物理網絡和協議的獨立性現在,網絡設備支持許多的通信技術。AllJoyn提供了一個抽象層,它為底層網絡協議棧定義了統一的接口,使得軟件工程師可以相對容易地添加和安裝新的網絡。 最近,Wi-Fi聯盟發布了一個Wi-Fi Direct規范,這將允許點對點的Wi-Fi連接。並且Wi-Fi Direct的網絡硬件模塊也正在積極開發中,它將為AllJoyn開發者增加Wi-Fi Direct功能和可用網絡選項的預關聯發現機制。 動態配置通常情況下,移動設備在使用過程中會到達不同的地點,並不斷與各種網絡進行連接和斷開。這意味着它的IP(互聯網協議)地址可能會改變,網絡接口可能無法使用,服務可能是短暫性的。 AllJoyn可以獲知當前服務的斷開和新服務的出現,並創建新的連接(如果需要)。AllJoyn准備作為Wi-Fi Hotspot 2.0技術的應用層,這種技術旨在提升手機和信號發射塔對Wi-Fi熱點的漫游透明度。 有些情況下,網絡拓撲結構對分布式應用程序的性能至關重要。藍牙網絡配置成微微網會比配置成分布式網絡達到更好的性能。AllJoyn在內部對這些配置進行管理,而不需要開發人員對每種網絡技術的具體特性進行任何了解。 廣播和發現服務當設備需要交互時,必須進行某種形式的廣播和發現服務。在靜態網絡的時代,人作為管理員對設備之間通信作出了精確的安排。最近,零配置網絡的概念已經得到了普及,尤其是蘋果的Bonjour和微軟的Plug and Play技術。我們也看到,現有技術的發現機制如藍牙服務發現協議,和新興機制如Wi-Fi Direct P2P發現規范。而AllJoyn提供了一種廣播和發現服務的抽象,可以簡化定位和應用服務的流程。 安全分布式應用程序中安全性的固有模型是應用程序到應用程序的。不幸的是,在許多情況下,網絡安全模型並不匹配這種固有的協定。例如,藍牙協議就要求必須在設備之間進行配對。使用這種方法,一旦設備配對成功,兩個設備上的所有應用程序都會得到授權。但是當考慮更多比藍牙耳機更強大的設備時,這就不可取了。例如,兩台筆記本電腦通過藍牙進行連接,那么更精細的安全控制是非常有必要的。AllJoyn在設計上對這種復雜的安全模型提供了廣泛的支持,特別是應用程序到應用程序的通信。 對象模型和遠程方法調用AllJoyn采用了一種易於理解的對象模型和遠程方法調用(RMI)機制。AllJoyn重新實現了總線協議,基於D-BUS規范和擴展D-BUS協議,以支持分布式設備。 軟件組件根據標准的對象模型和總線協議可以規范各種接口組件。Java接口聲明提供的一個與本地實現實例進行交互的規范,也采用了大致相同的方式。AllJoyn對象模型中提供了一個獨立於語言的規范,來實現遠程交互。 規范中考慮了多種接口的實現,從而可以支持應用程序通信的標准定義。這對於軟件組件是可以實現的技術。軟件組件已經成為了許多現代系統的核心部分,例如Android系統,它定義了四個主要的組件類型作為與Android應用框架進行交互的唯一渠道;或者在微軟系統中,它使用了組件對象模型(COM)系統的子節點。 我們期待出現豐富的接口定義,以實現概述一節中描述的情景。AllJoyn項目希望與用戶進行合作,共同定義和公布標准接口支持,並實現共享。 概念概述AllJoyn中包含了許多抽象概率,以幫助理解並將各個部分聯系在一起。你只需要掌握少數關鍵的抽象以了解基於AllJoyn的系統。 本節提供了了解AllJoyn的更高層次的視角,和后續文件(如詳細的API文檔)的基礎。 遠程方法調用分布式系統就是一組自主計算機通過某種形式的網絡通信來實現一個共同的目標。如果希望運行在某台機器地址空間中的程序去調用位於另一台物理機器地址空間中的進程。這通常需要通過遠程過程調用(RPC),如果使用了面向對象的概念,那么就需要通過RMI或遠程調用(RI)。 在RPC交換的基本模型中,涉及到作為RPC發送者的客戶端(client),和實際執行所需遠程過程的服務器(server),在AllJoyn中稱為service。發送者執行一個客戶端存根,看起來就像是本地系統上的本地進程。客戶端存根將進程的參數包裝(稱為編組或參數序列)成某種形式的消息,然后由RPC系統調用,並使用一些標准傳輸機制進行消息傳遞,如傳輸控制協議(TCP)。在遠程機器上,需要運行相應的RPC系統來解組(反序列化)參數並將消息傳遞到服務器存根中安排執行所需的進程。如果調用的進程需要返回任何信息,將采用類似的過程把返回值傳遞到客戶端存根,最后返回原來的發送者。 請注意它並不要求給定的進程在執行中必須獨占客戶端或服務器。如果兩個或多個進程在相同的客戶端或服務器中執行,它們將被認為是並行的。許多情況下,AllJoyn應用程序將執行類似的功能,而且被認為是並行。AllJoyn既支持原始的客戶端和服務功能,也支持對等網絡。 AllJoyn總線AllJoyn系統最基本的抽象就是AllJoyn總線。它為分布式系統提供了一個快速、輕量級的方式來傳遞消息序列。你可以將AllJoyn總線看作是消息傳遞的“高速公路”。圖2顯示了單一設備上AllJoyn總線實例在理論上的結構。總線用加粗的水平黑線表示。垂直線可以被認為是消息通過總線在源點和目的點之間傳遞的“出口”。 圖2所示的總線連接被描述為了六邊形(這是任意選擇的形狀)。正如高速公路的出口通常都具有編號,圖中每個連接都分配了唯一的連接名稱。為了清晰起見,這里使用連接名稱的簡化形式。 許多情況下,總線上的連接都可以被認為是進程的合作方。因此,在圖2的例子中,獨特的連接名稱:1.1可能被分配給應用程序實例進程的一個連接,而獨特的連接名稱:1.4可能被分配給其它應用程序實例進程的連接。AllJoyn總線的目標就是讓兩個應用程序進行通信,而無需處理底層機制的細節。其中一個連接可以認為是客戶端存根,另一方就可以認為是服務器存根。 圖2. 典型的AllJoyn總線
圖2顯示了AllJoyn總線的一個實例,說明了軟件總線如何給連接到總線上的組件提供進程間通信。AllJoyn總線的典型設備擴展如圖3所示。組件可根據需要,在Smartphone和Linux主機上的組件之間創建邏輯總線段之間的通信鏈路。 圖 3. AllJoyn處理設備到設備的通信
通信鏈路的管理由AllJoyn系統負責,並且由許多底層技術組成,例如Wi-Fi和藍牙技術。可能有不同的設備參與管理AllJoyn總線,但是這對分布式總線上的用戶都是透明的。對於總線上的某個組成部分,分布式AllJoyn系統看起來就像是本地設備中的總線。 圖4顯示了分布式總線對於總線上的用戶是如何呈現的。一個組件(例如,智能手機連接的名稱為1.1)可以創建一個進程來調用Linux主機上的名稱為1.7的組件,而無需擔心該組件的物理位置。 圖4. 分布式AllJoyn總線類似一條本地總線
總線守護進程圖3說明了邏輯分布式總線實際上被分成了若干個段,每個段都運行在不同的設備上。AllJoyn從功能上實現這些邏輯總線段的進程被稱為AllJoyn守護進程。 Unix派生系統中的長駐守護進程,通常用來描述運行在計算機系統中並提供一些必要功能的程序。在Windows系統中,長駐服務更加常見,但是我仍然是指AllJoyn在Windows系統中的守護進程。 圖5. 總線的相關氣泡圖形
為了讓AllJoyn守護進程更形象化,我們創建氣泡圖是很有用的。考慮兩段AllJoyn總線,一段位於Smartphone上而另一段位於Linux主機,如圖5所示。總線連接被標記為了客戶端(C)和服務器(S)基於RMI模型。執行分布式總線核心的守護進程被標記為(D)。圖5中的組件通常被解釋為如圖6所示的插圖。 圖6. AllJoyn氣泡圖形
氣泡可以被看作分布式系統上運行的計算機進程。左側的兩個客戶端(C)和一個服務(S)進程運行在Smartphone上。這三個進程與Smartphone上的AllJoyn守護進程通信,實現了分布式AllJoyn總線上的本地網段。在右側,也有一個守護進程,它在Linux主機上實現了AllJoyn總線的本地網段。這兩個守護進程將協調整個邏輯總線的消息流,如圖4所示,邏輯總線是單一的實體連接。類似Smartphone中的配置,Linux主機上有兩個服務組件和一個客戶端組件。 在此配置中,客戶端組件C1可以采用遠程方法來調用服務組件S1,就像它是一個本地對象。參數在源頭進行封裝,並由Smartphone上的守護進程送至本地總線段的路由。封裝參數通過網絡鏈接(從客戶端來看是透明的)發送至Linux主機上的守護進程。而Linux主機上運行的守護進程確定目的地是S1,並且對封裝參數進行拆封,然后通知服務去調用遠程方法。如果有返回值,那么將反向進行這個通信過程,把返回值傳回給客戶端。 由於守護進程在后台運行,並且客戶端和服務都運行在單獨的進程中,所以在每個單獨進程中必須有一個守護進程的“代理”。 AllJoyn將調用這些代理總線附件。 總線附件每個AllJoyn總線連接都需要一個特定的AllJoyn組件作為介質,它稱為總線附件。每個需要連接AllJoyn總線的進程都有一個總線附件。 當在硬件和軟件之間討論軟件組件時,往往會引出一個比喻。我們可以將分布式AllJoyn總線的本地網段想象為台式電腦的底板硬件總線。硬件總線本身就能傳遞電子信息,並且有一個可以插卡的點稱為連接器。AllJoyn中類似功能的連接器就是總線附件。 AllJoyn總線附件是本地指定語言的對象,它代表了分布式AllJoyn總線中的客戶端、服務或對等點。例如,這里有為用戶提供總線附件功能的C++語言實現,還有為用戶提供相同總線附件功能的Java語言實現。由於AllJoyn增加了語言支持,將會有更多這樣的具體語言實現。 總線方法、總線屬性和總線信號AllJoyn基本上是一個面向對象的系統。在面向對象的系統中,人們將談論對象中的調用方法(因此對於分布式系統,人們將談論長駐遠程方法調用)。面向對象編程中的對象需要有成員。通常,還需要對象方法或屬性,在AllJoyn中就是BusMethods和BusProperties。AllJoyn同樣也有總線信號(BusSignal),它是對象中某些事件或狀態變化的異步通知。 為了使客戶端、服務和對等點之間的通信更加透明,那么總線方法和總線信號中的參數順序必須有一些規范,並且總線屬性中也必須有一些形式的類型信息。對於計算機科學,方法(或信號)輸入和輸出類型的申明或定義被稱為類型簽名。 類型簽名使用字符串來定義,包括所有的基本數字類型(對於大多數編程語言),以及從這些基本類型創建出的復合類型,例如數組和結構體。類型簽名的具體分配和使用超出了本文介紹的范圍,但是總線方法、信號或屬性的類型簽名將傳遞給AllJoyn底層系統,來實現總線上傳遞參數和封裝返回值的轉換。 總線接口在大多數面向對象的編程系統中,方法或屬性集合將合並到具備固有內在聯系的群組中。該集合函數的統一申明被稱為接口。接口為執行接口規范的實體與外界之間的連接提供服務。正因為如此,接口需要適當的標准結構來實現標准化。各種網站上可以找到眾多的接口服務規范,從電話到媒體播放器控制。D-Bus規范在XML中進行描述來指定接口。 接口規范會將總線方法、總線信號、總線屬性以及與它們相關的類型簽名組合到一個命名組中。而實際上,接口會由客戶端、服務或對等點進程來實現。如果實現了給定的命名接口,那么在這個實現和外界之間會有一個隱性契約,接口將會支持它所有的總線方法、總線信號和總線屬性。 接口名稱通常采用域名反轉形式。例如,這里有許多AllJoyn實現的標准接口。其中有一個標准接口是theorg.alljoyn.Businterface,將守護實現並為總線附件提供一些基本功能。 值得注意的是,接口名稱僅僅是相對自由形式的命名空間中的一個字符串,並且其它命名空間可能也有類似的外觀。接口名稱字符串提供的特定函數不應該和其它類似的字符串混淆,特別是總線名稱。例如,org.alljoyn.sample.chat可能是總線名稱常量,就是客戶端搜索的名字。但是也有可能org.alljoyn.sample.chat是接口名稱,它定義了總線對象采用特定的總線名稱連接到總線附件上時提供的方法、信號和屬性。如果存在給定接口名稱的接口就暗示了總線名稱的存在;但是,它們確實是兩個完全不同的東西,有時可能長得一模一樣。 總線對象和對象路徑總線接口提供了一種標准的方式來聲明分布式系統中的接口。總線對象提供橋接到可能實現給定接口規范的地方。總線對象存在於總線附件中,並作為通信的終點。 因為,在特殊的總線附件中特定的接口可能會有多種實現,所以必須增加額外的結構體來區分這些接口實現。這將由對象路徑來提供。 就像接口名稱是命名空間中的一個字符串,對象路徑同樣也存在於命名空間中。命名空間的結構就像一棵樹,路徑的思維模式就是文件系統的目錄樹。事實上,對象路徑的路徑分隔符使用的是斜杠字符,和Unix文件系統類似。由於總線對象是總線接口的實現,所以對象路徑可以遵循相應接口的命名約定。如果定義了一個磁盤控制器接口(exampleorg.freedesktop.DeviceKit.Disks),那么你就可以想象,對於同一系統中的兩個分開的物理磁盤,這個接口的不同實現應該遵循下面的對象路徑: /org/freedesktop/DeviceKit/Disks/sda1 /org/freedesktop/DeviceKit/Disks/sda2 代理總線對象AllJoyn總線上的總線對象需要通過代理訪問。代理就是通過總線訪問遠程對象的本地代表。代理是非常常見的,而且不限於AllJoyn系統,但是你經常會在AllJoyn的內容中看到ProxyBusObject,它表明了代理的具體性質――這是一個遠程總線對象的本地代理。 ProxyBusObject是AllJoyn底層代碼中的一部分,它提供了對象代理的基本功能。 通常,RMI系統的目標就是提供一個代理來實現接口,它看起來就像是需要調用的遠程對象。代理對象實現了和遠程對象相同的接口,但是要驅動封裝參數的過程和向服務發送數據。 在AllJoyn中,客戶端和服務軟件,往往要與具體的編程語言綁定,來提供實際用戶級的代理對象。這個用戶級的代理對象使用AllJoyn代理總線對象的能力,以實現本地/遠程透明的目標。 總線名稱AllJoyn總線上的連接作為一個服務,提供接口名稱描述的接口實現。接口實現被加入到服務總線對象的樹中。客戶端希望通過代理對象獲得服務,並且使用底層AllJoyn代理總線對象來進行總線方法、總線信號和總線屬性相關信息在邏輯AllJoyn總線上的傳遞。 為了擁有完整的總線地址圖,總線上的連接必須具有唯一的名稱。AllJoyn系統將會為每個總線附件分配一個唯一的臨時總線名稱。但是,這種唯一的名稱在服務每次連接到總線是都會自動生成,因此並不適合作為持久的服務標識符。在服務連接到總線時必須有一種連續和持久的方法。這些持久的名稱被稱為“well-known names”。 正如使用域名來指向互聯網上的主機系統,它不會隨着時間而改變(例如quicinc.com),你可以使用它們的well-known總線名稱指向AllJoyn總線的功能單元。正如接口名稱采用域名反轉形式,總線名稱也有相同的形式。注意,這是造成某些混淆的根源,因為為了方便,接口名稱和well-known總線名稱往往選擇相同的字符串。請記住它們為了不同的目的:接口的名稱,是為了標識出總線附件中總線對象執行的客戶端和服務之間的合約;而well-known名稱標識了一個服務,它提供了一種持久的方式實現客戶端和附件之間的連接。 使用well-known名字,應用程序(總線附件的方式)必須向總線守護進程請求使用該名稱。如果這個well-known名稱沒有被其它應用占用,那么理所當然可以使用它。因此,在任何時候任何情況下,well-known名稱都會確保在總線上代表唯一的地址。 通常well-known名稱就意味着總線附件與總線對象以及一些可用的服務概念之間實現了連接。因為總線名稱在分布式總線上提供了唯一的地址,它們必須保證在總線上是唯一的。例如,你可以使用總線名稱org.alljoyn.sample.chat,這表明相同名稱的總線附件正在執行聊天(chat)服務。如果它已經采用了這個名字,你就可以推斷它在總線對象中實現了相應的org.alljoyn.sample.chat接口,對象路徑位於/org/alljoyn/sample/chat。 它的問題是,為了實現“聊天”,你一定希望在AllJoyn總線上發現其它類似的組件,並且也支持聊天服務。由於總線名稱必須唯一地標識總線附件,因此就需要追加一些后綴的形式來確保它的唯一性,你可以采用用戶名或數字的形式。在聊天的例子中,我們可以假象出多個總線附件: org.alljoyn.sample.chat.bob org.alljoyn.sample.chat.carol 在這個例子中,well-known名稱將org.alljoyn.sample.chat.作為了服務名稱的前綴,從中可以推斷出聊天接口和對象實現的存在。后綴bobandcarol可以使well-known名稱實例是唯一的。 這將引出服務是如何在分布式系統上定位的問題。答案就是通過客戶端的服務廣播和發現。 廣播和發現服務廣播和發現的問題有兩個方面。如上所述,即使服務駐留在本地AllJoyn總線段上,你也需要能夠看見和檢查總線上所有總線附件的well-known名稱,以確定其中某個對具體服務感興趣。當考慮如何發現非現有總線段上的服務時,將產生一個更有趣的問題。 讓我們想想如果一台運行AllJoyn的設備進入了另一台的鄰近區域時可能會發生什么。由於兩台設備實現了物理隔離,所涉及的兩個總線守護進程都沒有辦法獲取對方的任何信息。那么守護進程是如何確定對方的存在,以及如何確定是否需要互相連接形成一條邏輯分布式AllJoyn總線呢? 答案就是通過AllJoyn服務的廣播和發現功能。當服務在本地設備上啟動后,它會保留指定的well-known名稱,然后向鄰近設備廣播它的存在。AllJoyn提供了一個抽象層,它使服務可以完成廣播操作,並且能通過底層技術,例如Wi-Fi、藍牙、Wi-Fi Direct,來實現透明通信。無論客戶端或者服務都不需要了解底層技術是如何管理這些廣播的。 例如,在接觸交換(contacts-exchanging)應用中,應用的一個實例可以保留well-known名稱org.alljoyn.sample.contacts.boband,並廣播這個名稱。這可能會產生下面的一個或多個結果:通過連接Wi-Fi接入點的UDP組播,Wi-Fi Direct的預關聯服務廣播,或藍牙的服務發現協議消息。廣播者並不需要關注其中的廣播通信機制。由於接觸交換應用理論上是一個點對點的應用,人們期望另一個電話也進行類似的服務廣播,例如org.alljoyn.sample.contacts.carol。 客戶端應用程序可能會通過初始化發現操作,來在接收廣播時宣布它的興趣。例如,它可能會指定前綴org.alljoyn.sample.contacts來請求發現接觸服務的實例。在這種情況下,兩個設備都會發出這樣的請求。 只要手機進入了其它設備的鄰近范圍,底層AllJoyn系統就會通過可選的傳輸協議來發送和接收廣播消息。它們都將自動接收到一個指示,表面相應的服務可用。 由於服務廣播可以通過多個傳輸協議來接收,在某些情況下,它需要額外的底層工作來確定底層通信機制,這是使用發現服務的另一個概念部分。這是通信會話。 會話此前已經討論了總線名稱、對象路徑和接口名稱的概念。當一個實體連接到AllJoyn總線時,它會被分配一個唯一的名稱。連接(總線附件)請求被授予一個well-known名稱。well-known名稱用來讓客戶端定位或發現總線上的服務。例如,某個服務可能連接到AllJoyn總線上並被總線分配了唯一的名稱:1.1。如果服務希望總線上的其它實體能夠發現它,這個服務就必須向總線請求well-known名稱,例如com.companyA.ProductA(記住,通常要附加上唯一的實例修飾符)。 這個名稱意味着至少有一個實現well-known接口的總線對象是有意義的。通常,總線對象使用連接實例來鑒別,通過與well-known名稱相同的組件路徑(這並不是要求,僅僅是一個約定)。在這個例子中,總線對象的路徑與總線名稱com.companyA.ProductA匹配,可能是/com/companyA/ProductA。 為了了解從客戶端總線附件到類似的服務附件的通信會話是如何形成的,並提供一個端到端的例子,把AllJoyn機制和更常見的機制進行比較和對比是非常有用的。 郵政地址模擬在AllJoyn中,服務要求具有一個“人類可讀”的名字,這樣它就可以使用這個well-known和易於理解的標簽來進行廣播了。well-known名稱必須被底層網絡翻譯成唯一的名稱來提供正確的路由信息,例如: Well-known-name:org.alljoyn.sample.chat 唯一名稱::1.1 這些信息告訴我們,廣播到總線附件中的well-known名字org.alljoyn.sample.chat已經被指定了唯一的名稱:1.1。你可以認為這種方式就像每個企業都有一個名稱和郵政地址一樣。 另一種比喻,當大樓里面的一個企業與其它企業發生業務聯系時,也是相同的狀況。在這種情況下,你可能會先找一組房間號然后再進一步確定公司的地址。由於AllJoyn總線附件能夠提供多個服務,還必須有一種方法在特定的附件中確定一個以上的目標。在郵政地址模擬中還需要在目的地址組號之后添加“連接端口號”。 這正如一個國家的郵件系統或私人快遞公司根據快件不同的緊迫程度(當天件、兩天件、陸路運送等)發送一封信件。當使用AllJoyn進行連接服務時,你必須指定出某些特定需要的網絡連接的特點,並提供一套完整的傳遞規范(例如,可靠地傳遞信息、可靠地傳遞非結構化數據、不可靠地傳遞非結構化數據)。 請注意,在上面的例子中地址信息和傳遞信息是分開的。就像你可以選擇幾種路線將一封信從一個地方傳遞到另一個地方,很明顯,你也可以使用AllJoyn系統從幾個路徑獲得傳遞的數據。 AllJoyn會話正如正確標記的郵政信件具有“寄件(from)”和“收件(to)”地址,AllJoyn會話同樣要求“from”和“to”信息。在AllJoyn系統中,“from”地址將對應客戶端組件的位置,而“to”地址對應服務的位置。 從技術上講,這些計算機網絡環境中“from”或“to”地址被稱為半連接。在AllJoyn中,這些to(服務)地址有下列形式: {session options(會話選項), bus name(總線名稱), session port(會話端口)} 第一個參數會話選項,涉及到如何將數據從連接的一側傳輸到其它地方。在IP網絡中,選項可能是TCP或UDP。在AllJoyn中,這些細節是抽象的,所有選項可以是“基於消息的”、“非結構化數據”或“不可靠的非結構化數據”。服務目標是通過總線附件請求的well-known名稱指定的。 和郵政例子中的組號類似,AllJoyn也具有總線附件內部傳輸點的概念。在AllJoyn中,這被稱為會話端口。正如組號僅僅代表在給定的大樓中,會話端口同樣表示在給定的總線附件范圍內。連接端口的存在和值是從總線名稱中推斷出來的,與底層對象和接口集合的推斷使用了相同的方式。 “from”地址對應的客戶信息同樣也會形成。為了與服務進行通信,客戶端必須具有它自己的半連接。 {session options(會話選項), unique name(唯一名稱), session ID(會話ID)} 它並不要求客戶端請求well-known總線名稱,所以它們提供其唯一的名稱(如:1.1)。由於客戶端並不作為會話的目的地,所以它們不提供會話的端口,但在建立連接時會被分配一個會話ID。此外,在會話建立過程中,將會給服務返回一個會話ID。對於那些熟悉TCP網絡的開發者,這就相當於TCP中使用的連接創建過程,其中服務是通過well-known端口進行的連接。當連接建立后,客戶端會使用臨時端口來描述一個類似的半連接。 在會話建立的過程中,這兩個半連接會有效地組合: {session options, bus name, session port} 服務 {session options, unique name, session ID} 客戶端 請注意,會話選項有兩種實現。當開始建立通信時,它們可能被視為服務提供的支持會話選項和客戶端提供的服務與請求會話選項。會話的建立過程還包括磋商會話中實際將使用的選項。一旦會話已經形成,在客戶端和服務端的半連接就被描述為唯一的AllJoyn通信路徑: {session options(會話選項), bus name(總線名稱), unique name(唯一名稱), session ID(會話ID)} 在會話建立過程中,將在通信守護進程之間形成一個邏輯網絡連接。這可能需要創建一個藍牙微微網或其它復雜的拓撲結構管理操作。如果這樣的連接已經存在,它將被重新啟用。新創建的底層“守護進程-守護進程”的連接將用於執行初始安全檢查,一旦這個操作完成后,這兩個守護進程就已經有效地加入了兩個獨立的AllJoyn軟件總線段以及更大的虛擬總線中。 因為考慮到端到端的底層連接流量控制的問題,在一些技術中會關注拓撲平衡問題,實際兩個通信端的連接(“from”客戶端和“to”服務)可能會或可能不會形成一個單獨的通信通道。在某些情況下,最好是通過ad-hoc拓撲結構來傳遞消息(藍牙微微網),而另一些情況下,直接通過新的連接來傳遞消息可能是更好的選擇(TCP IP)。這里可能需要對通信基礎技術具有深刻的理解,而AllJoyn會很高興為你完成這些。用戶只需要知道消息會根據傳輸機制選擇正確的路由,以滿足應用程序的抽象需求。 綜述AllJoyn旨在提供一個軟件總線用於管理廣播操作和發現服務,提供安全的環境,並且允許位置透明的遠程方法調用。可以采用傳統的客戶端/服務模型,也可以采用結合客戶端和服務兩方面的對等通信。 AllJoyn最基本的抽象就是把所有東西連接在一起的軟件總線。虛擬分布式總線是通過每台設備上運行的后台AllJoyn守護進程來實現的。客戶端和服務通過總線附件連接到總線。總線附件位於本地的客戶端和服務進程中,並且提供與本地AllJoyn守護進程的進程間通信。 在連接時,每個總線連接都會被系統分配唯一的名稱。總線附件可以要求獲得唯一的“人類可讀”的總線名稱,它可以用來向AllJoyn系統的其余部分廣播它自己。這個命名空間中的well-known總線名稱看起來就像反轉的域名,並鼓勵命名空間的自我管理。如果存在指定名稱的總線附件,那么意味着至少有一個總線對象,它實現了至少一個名稱指定的接口。接口名稱被分配給相似的命名空間,但是與總線名稱具有不同的意義。每個總線對象都位於總線附件的樹形結構體中,並且描述了一個看着類似Unix文件系統路徑的對象路徑。 圖7顯示所有部件連接方式的假想布局。中間的黑線代表AllJoyn總線。總線的出口就是指定了唯一名稱(:1.1和:1.4)的總線附件。在圖中,具有唯一名稱(:1.1)的總線附件被以org.alljoyn.samples.chat.1進行請求,並分配相應的well-known總線名稱。添加“1”以確保總線的名稱是唯一的。 總線名稱中還暗示了很多信息。首先,總線對象的樹形結構體駐留在不同的路徑中。在下面的例圖中,有兩個總線對象。一個是在“/org/alljoyn/samples/chat/chat”路徑下,它大概實現了一個聊天界面。其它總線對象在“/org/alljoyn/samples/chat/contact”路徑下,實現了名為org.alljoyn.samples.chat.contacts的接口。由於給定的總線對象實現了接口,它必須提供相應的總線方式、總線信號和總線屬性的實現。 圖7. AllJoyn總線實例圖示
數字42代表了一個連接會話端口,客戶端必須使用它初始服務的通信會話。請注意,這個會話僅相對於特定的總線附件是唯一的,圖中的其它總線附件也可以使用42作為自己的連接端口。 在請求和分配well-known總線名稱之后,服務通常會廣播它的名稱來讓客戶端發現這個服務。圖8顯示了服務向本地守護進程發送廣播請求。守護進程根據服務的輸入,決定應該采用網絡中的某種具體機制來進行廣播,並開始執行操作。 圖8. 服務執行廣播操作
當准客戶端希望定位一個服務時,它會發出查詢名稱的請求。其本地守護設備,再從客戶端輸入的基礎上,確定最佳的方式來查詢和探測廣播。 圖9. 客戶端請求查詢名稱
一旦設備移動到鄰近區域中,它們就會開始監聽對方的廣播消息和發現請求通過啟用的媒體。圖10顯示守護進程是如何驅動服務來監聽發現請求和響應的。 圖10. 守護進程報告發現名稱
最后,圖11顯示了客戶端收到的指示,表面該區域發現一個新出現的承載了所需服務的守護進程。 圖11. 客戶端發現服務
發展方案中的客戶端和服務雙方都使用總線附件對象的方法和回調,以請求協調廣播和發現過程。服務端要求總線對象提供服務,並且客戶端希望使用代理對象提供一個易於使用的接口與服務進行通信。此代理對象將使用AllJoyn ProxyBusObject來協調與服務的通信,並提供方法參數和返回值的封裝和拆封處理。 通信會話必須在遠程方法被調用前被創建,以有效地加入不同的總線段。廣播和發現與會話的建立並不相同。終端可以接收廣播並不采取任何行動。只有當接收到廣播,並且客戶端決定加入通信會話時,總線才會從邏輯上連接為一體。要做到這一點,服務必須建立通信會話端點並廣播它的存在;客戶端必須接收這些廣播,並要求加入會話中。 服務必須在廣播它的服務之前定義一個半連接。對它進行抽看起來像是下面這樣: {reliable IP messages(可靠的IP消息), org.alljoyn.samples.chat.1, 42} 這表明它將通過可靠的消息傳輸與客戶端通信,已經指定了well-known總線名稱,並且預計連接到會話端口42。這是圖7中看到的情況。 假設總線附件具有唯一的名稱:2.1,並希望從遠程物理設備的守護進程進行連接。它將向系統提供半連接,然后會分配一個新的會話ID來讓通信雙方進行溝通: {reliable IP messages, org.alljoyn.samples.chat.1, :2.1, 1025} 新的通信會話將使用可靠的消息傳遞協議來實現,它采用IP協議棧在名為org.alljoyn.samples.chat.1(服務)的總線附件和名為:2.1(客戶端)的總線附件之間進行通信。用來描述會話的會話ID是系統分配的,在這種情況下是1025。 作為建立的端到端的通信會話,AllJoyn系統采取的任何操作都是為了更好地創建虛擬軟件總線,如圖4所示。請注意這是一張模擬的圖片,而實際中可能發生的是,通過TCP連接建立了一個Wi-Fi Direct的點對點連接,使用無線接入點承載UDP連接,或藍牙微微網組成L2CAP連接,決定於所提供的會話選項。無論是客戶端還是服務,我們都為它們完成了這些非常困難的工作。 如果需要,也可以要求進行身份驗證,接着客戶端和服務會使用RMI模型進行通信。 當然,這並不限於一台設備上的一個客戶端和另一台設備上的一個服務。而可能是任何數量的客戶端和任何數量的服務(不能超過設備或網絡容量的限制)相結合,以實現某種形式的協同工作。總線附件可能需要掌握客戶端和服務的屬性來完成點對點服務。AllJoyn守護進程建立了許多不同組件和消息路由的管理邏輯單元。此外,接口描述和語言綁定的性質可以允許不同編程語言編寫的組件之間的互操作性。 高層系統架構從用戶的角度來看AllJoyn系統,了解架構最重要的一塊就是客戶端、服務或對等點。從系統的角度來看,三個基本用例之間確實也沒有差異,僅僅是系統提供的相同功能的不同使用模式。 客戶端、服務和對等點圖12顯示了用戶角度(守護進程)的系統架構。在最高層級是語言綁定。AllJoyn系統是使用C++編寫的,所以對於這種語言的使用者就不需要進行綁定了。但是,對於其它語言如Java或JavaScript的用戶,就會提供相對輕量級的轉換層稱為語言綁定。在某些情況下,綁定可被擴展到提供指定系統的支持。例如,普通的Java語言綁定將允許AllJoyn系統可以在Windows或Linux下運行的一般Java環境中使用;但是,也可以提供Android系統綁定,將AllJoyn系統更加緊密地集成到指定的Android結構中,例如Android應用框架中的服務組件。 系統和語言綁定是建立在一個輔助對象層上,設計它的目的就是為了讓AllJoyn系統中常見的操作更容易。不使用這些輔助對象也可以操作AllJoyn系統,但是我們鼓勵使用它,因為它提供了另一個層次的抽象接口。前面章節中提到的總線附件,就是這樣一種重要的輔助對象,它在所有的系統中都是可用的。除了提供的幾個關鍵功能,總線附件還提供非常方便的功能,使對底層軟件總線的管理和互動更容易。 在輔助層之下是消息和路由層。它們的主要功能是負責對總線發送的消息中的參數和返回值進行封裝和解封。路由層安排將消息傳遞到適當的總線對象和代理,並安排其它總線附件的接收消息被發送到總線守護進程。 消息和路由層與端點層進行通信。在較低層的AllJoyn系統中數據從一個端點傳送到另一個。從網絡代碼的角度來說這是抽象的通信端點。網絡抽象全部在端點層的頂部,所以通過藍牙連接和通過有線以太網連接之間基本上沒有差異。 圖12. 基本的客戶端、服務或對等點架構
端點專指傳輸機制的具體實體,它提供了基本的網絡功能。在客戶端、服務或對等點的情況下,網絡傳輸的唯一渠道就是本地傳輸。這是與本地AllJoyn總線守護進程之間的本地進程間通信。在基於Linux的系統中,這是一個Unix域套接字連接,而在基於Windows的系統中,這是一個和本地守護進程的TCP連接。 AllJoyn還提供了操作系統抽象層,它提供了建立系統其余部分的平台,並且在最底層就是本機系統。 守護進程AllJoyn守護進程就像膠水一樣將各個AllJoyn系統連接到一起。如前所述,守護進程在后台運行,等待相關事件的觸發並響應它們。因為這些事件通常是外部的,那么最好從自下而上的角度來接近守護進程架構。 在圖13中的最底層就是本機系統。我們使用和客戶端架構中相同的操作系統抽象層,來為Linux,Windows和Android上運行的守護進程提供共同的抽象。我們有守護進程的各種底層網絡組件運行在操作系統抽象層上。由於客戶端、服務和對等點只使用本地進程間通信機制與守護進程進行通信,所以守護進程就必須處理給定平台上的各種可用傳輸機制。注意,圖13中的“本地(Local)”傳輸是運行在特定主機上的AllJoyn客戶端、服務和對等點的基礎連接。 圖13. 基本守護進程架構
藍牙傳輸處理了藍牙系統中的微網的創建和管理的復雜性。此外,藍牙傳輸還提供了適當的藍牙服務廣播和發現功能,以及提供了可靠的通信。 有線、Wi-Fi和Wi-Fi Direct傳輸都在IP下被分組,因為所有這些傳輸都使用底層的TCP-IP網絡協議棧。如何完成服務廣播和發現有時具有顯著的差異,因為該功能在TCP-IP標准范圍之外,所以有模塊專門支持這個功能。 各種特定技術的傳輸實現都被聚合到網絡傳輸抽象中。會話模塊將處理通信連接的建立和保持,使守護進程和其相關的客戶端、服務和對等點集合為一個統一的軟件總線。 AllJoyn守護進程使用端點的概念來提供與本地客戶端、服務和對等點的連接,而且將這些對象擴展為“總線-總線”的連接,它可以被守護進程用於主機到主機的消息傳輸。 除了這些連接所隱含的路由功能,AllJoyn守護進程還提供了其總線對象相應端點管理或控制守護進程實現的軟件總線段。例如,當一個服務請求廣播well-known總線名稱時,實際上是服務中的輔助對象將這個請求轉換為遠程方法調用,並指向守護程序實施的總線對象。和服務的情況類似,守護進程有許多總線對象位於相關的對象路徑,來實現特定名稱的接口。控制AllJoyn總線的底層機制,就是向這些守護進程的總線對象發送遠程方法調用。 守護進程操作的某些方面的整體操作都由配置子系統進行控制。這允許系統管理員指定系統中的某些權限,並提供按需創建服務的能力。此外,守護進程配置也可以限制資源消耗,例如,允許系統管理員限制任何特定時間的活躍TCP連接的數量。還有選項可以允許系統管理員降低某些拒絕服務攻擊的影響,通過限制目前登陸的連接數。 總結AllJoyn是一個綜合系統,設計用來為移動異構系統上的分布式應用程序提供一個部署的框架。 AllJoyn提供的解決方案基於成熟的技術和標准的安全系統,使用連貫、系統的方式解決各種網絡技術的相互作用。這使得應用開發人員可以專注於他們的應用程序內容,而不需要具備豐富的底層網絡開發經驗。 AllJoyn系統被設計為一個整體來工作,並不會出現例如使用各個部分創建ad-hoc系統時遇到的固有阻抗不匹配的問題。我們相信,AllJoyn系統可以使分布式應用程序的開發和部署比在其它平台上開發要簡單很多。 了解更多要了解更多有關如何在你的開發工作中整合AllJoyn的信息,請訪問AllJoyn網站中的文檔(https://www.alljoyn.org/docs-and-downloads)。 入門指南:此章節中的文檔描述了AllJoyn的技術和概念。 Ÿ AllJoyn介紹 開發指南:開發指南提供了具體編程問題的解決方案,和搭建開發環境的指南。還包括了代碼片段與注釋。 Ÿ AllJoyn Android環境安裝指南 Ÿ 使用Java SDK進行AllJoyn開發的指南 Ÿ AllJoyn Android的C + +示例程序攻略 Ÿ 配置生成環境(Microsoft Windows平台) Ÿ 配置生成環境(Linux平台) API參考手冊:API參考手冊提供了詳細的AllJoyn源代碼,和使用各種支持的編程語言編寫的應用程序。 Ÿ Java API參考手冊 Ÿ C++ API參考手冊 下載:為用戶提供軟件開發工具包(SDK)和示例代碼,以幫助建立、修改、測試和執行指定任務。 Ÿ AllJoyn SDK示例代碼(包括AllJoyn守護進程)
|