AUTOSAR_EXP_ARAComAPI的7章笔记(2)
☞返回总目录
相关总结:服务发现实现策略总结
7.2 服务发现的实现策略
如前面章节所述,ara::com 期望产品供应商实现服务发现的功能。服务发现功能基本上是在 API 级别通过 FindService、OfferService 和 StopOfferService 方法定义的,协议和实现细节是开放的。
当一个 AP 节点(更具体地,是一个 AP 软件组件)通过网络提供服务或向另一个网络节点请求服务时,服务发现 / 服务注册表显然是通过网络进行的。通过网络进行服务发现的协议需要由所使用的通信协议完全指定,比如 SOME/IP,在 SOME/IP 服务发现协议规范 [13:AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol.pdf] 中完成。但是,如果一个 ara::com 应用程序想要与同一节点上同一 AP 供应商的另一个 ara::com 应用程序通信,那么必须有一个本地版本的服务发现可用。这里唯一的区别是,在本地进行服务发现的协议实现完全取决于 AP 产品供应商。
7.2.1 集中式与分布式方法
一、集中式方法
抽象来看,AP 产品供应商可以在两种方法进行选择:
第一种是集中式方法,供应商决定拥有一个中央实体(例如一个守护进程):
- 维护所有服务实例及其位置信息的注册表。
- 为本地 ara::com 应用程序的所有 FindService、OfferService 和 StopOfferService 请求提供服务,从而更新注册表(OfferService、StopOfferService)或查询注册表(FindService)。
- 为网络的所有 SOME/IP SD 消息提供服务,要么更新其注册表(接收到 SOME/IP Offer Service),要么查询注册表(接收到 SOME/IP Find Service)。
- 通过发送 SOME/IP SD 消息将本地更新的注册表传播到网络。
下图大致勾勒了这种方法。
二、分布式方法
另一种略有不同 —— 更加分布式的方法是,在节点内的 ara::com 应用程序之间分布服务注册表信息(可用性和位置信息)。因此,对于节点的本地通信用例,不需要突出服务发现守护进程,可以通过类似广播的通信技术实现。这意味着任何服务提供和查找都被传播到所有本地 ara::com 应用程序,以便每个应用应用程序进程内都有服务注册表的本地视图。这种方法可能有好处,因为本地通信可能更加灵活 / 稳定,因为它不依赖于单个注册表守护进程。
然而,网络服务发现的通信节点无论如何都需要一个单一的负责实例,分布式方法不可行,因为 SOME/IP SD 需要一组固定的端口,而这只能由单个应用程序进程(在典型的操作系统 / 具网络栈中)提供。
最后,我们也确实只有一个单例,略有不同的是,它负责充当节点本地发现协议和网络 SOME/IP SD 协议之间的服务发现协议桥梁。除此之外 —— 由于注册表在节点内的所有 ara::com 应用程序之间被复制 —— 这个桥梁也持有一个本地注册表。