5. 面向服务架构的实现
SOA(service-oriented architectur，面向服务的架构是一种软件架构或者软件模型，这种架构下，系统提供的各种功能都会以服务的形式，提供给用户或者系统内外的其它服务来使用，服务与服务之间是松耦合的关系，互相之间使用中立的接口和标准的方式进行通信和交互，与硬件平台、操作系统、编程语言没有相关性。这种架构特别适合在分布式的环境中使用，鸿蒙系统就是一个分布式的操作系统，自然采用了这种架构。【更多的SOA相关信息，请自行网上搜索学习。】
面向服务的架构，包括下面三种角色：
- Provider：服务的提供者，为系统提供能力(即对外接口)，它接受和执行来自消费者的请求。
它将自己的服务和接口发布到服务管理中心，以便服务的消费者可以发现和访问该服务。
- Consumer：服务的消费者，调用服务提供的功能(即对外接口)来实现某种结果。
它可以是一个应用程序、一个软件模块或者另一个服务，它发起对服务管理中心的服务查询、绑定服务， 然后执行服务提供的能力。
- Samgr：服务管理中心是一个中介者，它管理着Provider提供的能力，同时帮助Consumer发现Provider的能力。
它们的关系如下图所示：
前文《系统服务框架子系统-2》4.6 小节对PubSubFeature 和PubSubImplement结构体的分析，提到了它们是SOA(面向服务的架构)的实现，本节我们就来具体分析一下。
代码结构为 Hi3861/distributedschedule/samgr_lite/communication/
我们还是先对PubSubFeature 和PubSubImplement结构体做比较完整的展开，如下图：
两个全局变量g_pubSubImplement和g_broadcastFeature也分别展开：
- g_pubSubImplement 的展开
如前文《系统服务框架子系统-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的展开
这里的重点是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_example和user_button_test，以及它们跑起来的log，感兴趣的朋友请自行编译和做验证。
- broadcast_example
以官方的samgr例程为样本，框架是一样的，跑的内容做了一些修改，按照我的习惯对log做了整理，基 本上相当于重写了这个测试用例。
以CASE_AddAndUnsubscribeTopic()为例，我添加了4个Topic，三个Consumer对Topic的订阅情况如下表:
当某个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/4776
