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），提供了相关资源用于帮助用户编译、修改、测试和执行某个项目。

 

看完了，大家有何感想呢？？