原文连接：AUTOSAR_EXP_ARAComAPI的7章笔记（4）
情景设定
在前一节的基础上，假设有类似情景，区别在于服务实例 2 位于与 AP 产品相同以太网的不同 ECU 上，服务消费者及其代理驻留在 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 实例化两个完全不同的传输机制。
传输机制动态决策及解决方式
在调用构造函数期间，如何做出使用哪种传输机制的动态决策以及技术上如何解决，取决于中间件实现者。生成的代理类实现可能已包含支持的机制，句柄中信息用于切换不同行为，或者所需传输功能（绑定）可在运行时通过共享库机制从给定句柄检测到特定需求后加载。