Alljoyn瘦客户端库介绍（1）

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 欢迎加入交流！