☞返回总目录

相关总结：本地 / 网络多绑定用例总结

7.3.2 本地/网络多绑定用例

在前一节中，我们看到了的一种多绑定特殊变体，现在来看，也可认为是一种真实情况的变体。

假设有一个与上一章节相似的情景，唯一的区别是服务实例2位于与AP产品相同以太网的不同ECU上，而服务消费者（及其用于实例1和实例2 的代理）驻留在AP产品ECU 上。由于以太网对于AP的标准协议是SOME/IP，所以期望两个 ECU之间的通信基于SOME/IP。对于我们的具体例子，这意味着代理实例1 通过Unix域套接字与服务实例1 通信（如果AP供应商做好了IPC实现，针对进程本地通信优化为直接方法调用），而代理实例2通过符合SOME/IP 的消息格式的网络套接字与服务实例2通信。

对于以上所述SOME/IP部署，因为AP软件组件（SWCs）不会直接打开到远程节点的网络套接字连接，所以，可能会被人指摘不正确：我们将在这里（第 7.3.3 小节）更详细地介绍这一点，但目前假设这是一个现实场景。（对于其他网络协议，这确实可能是现实的）。

因此，AP产品ECU上的注册表（服务发现）的守护进程已经看到了服务实例2的服务提供，这个服务提供包含了基于IP网络端点的寻址信息。对于服务实例2的服务提供，没有任何变化：仍然与一些 Unix域套接字名称相关联，本质上是一个文件名。在这个例子中，从 ProxyClass::FindService返回的服务实例1和服务实例2的两个句柄在内部看起来非常不同：服务实例1的句柄包含它是一个 Unix域套接字和一个名称的信息，而句柄2包含它是一个网络套接字以及一个IP地址和端口号的信息。所以，与第一个例子（子章节 7.3.1）相比，这确实算得上是一个完全成熟的多绑定，我们的代理类构造函数从句柄1和句柄2 实例化两个完全不同的传输机制！在调用构造函数期间，如何做出使用哪种传输机制的动态决策，在技术上如何解决，这再次取决于中间件实现者：生成的代理类实现可能已经包含任何支持的机制，并且句柄中包含的信息仅用于在不同的行为之间切换，或者所需的传输功能（也称为绑定）可以在运行时在通过共享库机制从给定的句柄检测到特定需求后加载。