☞返回总目录
相关总结：服务发现实现策略总结
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 应用程序之间被复制 —— 这个桥梁也持有一个本地注册表。
