Hi3861的SAMGR--系统服务框架子系统-4-面向服务架构的实现 原创 精华

liangkz_梁开祝
发布于 2021-6-11 13:42
浏览
4收藏

Hi3861的SAMGR--系统服务框架子系统-4

面向服务架构的实现

liangkz 2021.06.11 v2.5

接前文:

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

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

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

 

5. 面向服务架构的实现

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

面向服务的架构,包括下面三种角色:

  • Provider:服务的提供者,为系统提供能力(即对外接口),它接受和执行来自消费者的请求。

    它将自己的服务和接口发布到服务管理中心,以便服务的消费者可以发现和访问该服务。

  • Consumer:服务的消费者,调用服务提供的功能(即对外接口)来实现某种结果。

    它可以是一个应用程序、一个软件模块或者另一个服务,它发起对服务管理中心的服务查询、绑定服务, 然后执行服务提供的能力。

  • Samgr:服务管理中心是一个中介者,它管理着Provider提供的能力,同时帮助Consumer发现Provider的能力。

 

它们的关系如下图所示:

Hi3861的SAMGR--系统服务框架子系统-4-面向服务架构的实现-鸿蒙开发者社区

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

代码结构为 Hi3861/distributedschedule/samgr_lite/communication/

Hi3861的SAMGR--系统服务框架子系统-4-面向服务架构的实现-鸿蒙开发者社区

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

Hi3861的SAMGR--系统服务框架子系统-4-面向服务架构的实现-鸿蒙开发者社区

Hi3861的SAMGR--系统服务框架子系统-4-面向服务架构的实现-鸿蒙开发者社区

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

  • g_pubSubImplement 的展开Hi3861的SAMGR--系统服务框架子系统-4-面向服务架构的实现-鸿蒙开发者社区

如前文《系统服务框架子系统-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的展开

Hi3861的SAMGR--系统服务框架子系统-4-面向服务架构的实现-鸿蒙开发者社区

这里的重点是relations这个双重的双向链表及其node上所挂载的东西,注意,上图的head node和tail node的指针会互相指向对方,形成闭环,这里没有画出来。

 

g_pubSubImplement 主要是提供一组统一的标准的对外的接口,外部程序可以通过这组接口来:

  • 为Consumer订阅(Subscribe) Topic
  • 为Provider 发布(Publish) Topic

 

当某个Consumer[i]要订阅某个Topic[x]的时候,首先需要通过AddTopic(Topic[x])将Topic[x]添加到relations链表中去,添加的时候会做检查和判断,确保Topic[x]不会在relations链表上重复添加。然后再通过Subscribe(Topic[x], Consumer[i])来订阅Topic[x],实际上就是把Consumer[i]添加到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的订阅情况如下表:

Hi3861的SAMGR--系统服务框架子系统-4-面向服务架构的实现-鸿蒙开发者社区

当某个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就知道是怎样的了。

 

©著作权归作者所有,如需转载,请注明出处,否则将追究法律责任
分类
Hi3861的SOA示例程序及log.rar 8.57K 83次下载
已于2021-6-11 13:42:19修改
6
收藏 4
回复
举报
2条回复
按时间正序
/
按时间倒序
红叶亦知秋
红叶亦知秋

感谢楼主分享。

回复
2021-6-11 13:51:24
liangkz_梁开祝
liangkz_梁开祝 回复了 红叶亦知秋
感谢楼主分享。

不客气!

回复
2021-6-11 13:52:47
回复
    相关推荐