评论

收藏

[HarmonyOS] Hi3861的SAMGR--系统服务框架子系统-4 面向服务架构的实现

移动开发 移动开发 发布于:2021-07-02 18:25 | 阅读数:644 | 评论:0

接前文:

《Hi3861的SAMGR--系统服务框架子系统-1》

《Hi3861的SAMGR--系统服务框架子系统-2》

《Hi3861的SAMGR--系统服务框架子系统-3》

 

5. 面向服务架构的实现

  SOA(service-oriented architectur,面向服务的架构是一种软件架构或者软件模型,这种架构下,系统提供的各种功能都会以服务的形式,提供给用户或者系统内外的其它服务来使用,服务与服务之间是松耦合的关系,互相之间使用中立的接口和标准的方式进行通信和交互,与硬件平台、操作系统、编程语言没有相关性。这种架构特别适合在分布式的环境中使用,鸿蒙系统就是一个分布式的操作系统,自然采用了这种架构。
  面向服务的架构,包括下面三种角色:

  • Provider:服务的提供者,为系统提供能力(即对外接口),它接受和执行来自消费者的请求。
  它将自己的服务和接口发布到服务管理中心,以便服务的消费者可以发现和访问该服务。

  • Consumer:服务的消费者,调用服务提供的功能(即对外接口)来实现某种结果。
  它可以是一个应用程序、一个软件模块或者另一个服务,它发起对服务管理中心的服务查询、绑定服务, 然后执行服务提供的能力。

  • Samgr:服务管理中心是一个中介者,它管理着Provider提供的能力,同时帮助Consumer发现Provider的能力。
  它们的关系如下图所示:
DSC0000.jpg

  前文《系统服务框架子系统-2》4.6 小节对PubSubFeature 和PubSubImplement结构体的分析,提到了它们是SOA(面向服务的架构)的实现,本节我们就来具体分析一下。
  代码结构为 Hi3861/distributedschedule/samgr_lite/communication/
DSC0001.jpg

  我们还是先对PubSubFeature 和PubSubImplement结构体做比较完整的展开,如下图:
DSC0002.jpg

DSC0003.jpg

  两个全局变量g_pubSubImplement和g_broadcastFeature也分别展开:

  • g_pubSubImplement 的展开 DSC0004.jpg
  如前文《系统服务框架子系统-2》“4.7  IUnknown 接口类及其相关定义” 所分析的,任何应用或者其他模块通过:
IUnknown *iUnknown = SAMGR_GetInstance()->GetFeatureApi(BROADCAST_SERVICE, PUB_SUB_FEATURE);
  就可以拿到上面的iUnknown的指针了,拿到这个指针后,就可以再通过:
PubSubInterface *fapi = NULL;
iUnknown->QueryInterface(iUnknown, DEFAULT_VERSION, (void **)&fapi);
  来恢复出PubSubInterface 对象的指针fapi,也就可以访问 subscriber和provider的API了。

  • g_broadcastFeature的展开
DSC0005.jpg

  这里的重点是relations这个双重的双向链表及其node上所挂载的东西,注意,上图的head node和tail node的指针会互相指向对方,形成闭环,这里没有画出来。
  g_pubSubImplement 主要是提供一组统一的标准的对外的接口,外部程序可以通过这组接口来:

  • 为Consumer订阅(Subscribe) Topic
  • 为Provider 发布(Publish) Topic
  当某个Consumer要订阅某个Topic[x]的时候,首先需要通过AddTopic(Topic[x])将Topic[x]添加到relations链表中去,添加的时候会做检查和判断,确保Topic[x]不会在relations链表上重复添加。然后再通过Subscribe(Topic[x], Consumer)来订阅Topic[x],实际上就是把Consumer添加到Topic[x]的双线链表中去,以获得对Topic[x]的订阅权限。
  当某个Provider Publish一个Topic[x]的时候,Broadcast 的这个PubSubFeature会从relations链表中找到对应的Topic[x],对其所有订阅者发起广播(也就是遍历Topic[x]的ConsumerNode链表,对链表上所有的consumer节点发送消息,让它们对消息进行处理)。
  简单来说,g_pubSubImplement和g_broadcastFeature这两个全局变量,g_broadcastFeatur提供了feature的生命周期和数据结构,g_pubSubImplemen则提供了对外接口和对数据结构的操作。具体他们是如何配合工作的,请自行阅读broadcast目录下的代码。
  附件包含两个测试程序,分别是broadcast_exampleuser_button_test,以及它们跑起来的log,感兴趣的朋友请自行编译和做验证。

  • broadcast_example 
  以官方的samgr例程为样本,框架是一样的,跑的内容做了一些修改,按照我的习惯对log做了整理,基 本上相当于重写了这个测试用例。
  以CASE_AddAndUnsubscribeTopic()为例,我添加了4个Topic,三个Consumer对Topic的订阅情况如下表:
DSC0006.jpg

  当某个Topic[x] 发布的时候,只有订阅了它的Consumer会做出反应,Consumer会调用callback函数对Topic[x]的request做出针对性的处理。

  • user_button_test
  我自己写的Provider测试程序,Hi3861开发板响应user按键消息,每次按键事件触发一次 Publish 一个随机的 topic,以此检验上表中的Consumer对各自订阅的Topic的处理情况。
按键线程 UserButtonTask 每1s循环一次,计数器++,检测到按键按下时,当前计数器%5,  得到 0~4 的一个随机数字,这个数字就是 topic,上表中只添加了topic[0~3],当UserButtonTask  publish topic[4]时,就会出现异常,请查阅附件的log就知道是怎样的了。
 
文章相关附件可以点击下面的原文链接前往下载
原文链接: https://harmonyos.51cto.com/posts/5667#bkwz
想了解更多关于鸿蒙的内容,请访问:
51CTO和华为官方战略合作共建的鸿蒙技术社区
https://harmonyos.51cto.com/#bkwz

  
关注下面的标签,发现更多相似文章