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