Adaptive Autosar通讯层：ARA::COM中的Instance Identifiers

一般概念

实例标识符。在收发两端都是要用的。是很核心的概念。

proxy端用来搜索服务，skeleton端用来创建服务实例。
站在API的角度来看，这样的识别符是和特定的技术绑定的。所以，标识符的结构和内容都是按照使用的通讯协议来的。

在namespace ara::com 中定义了一个类class InstanceIdentifier来描述描述符，那么独立于绑定的技术，大家都应该有相同的结构。这个类提供了从string构造的构造函数和tostring的转换方法。可以将描述符转换为字符串意味着可以传输、存储等等。

基于ara::com开发应用的人员不需要关心描述符的具体内容，因为你可以看到，上面说的那个类里除了标识符这个字符串没有别的任何技术细节。具体的绑定由集成人员在部署应用的时候实现。

通讯层标识符
ara::com::InstanceIdentifier

ara::com提供了将应用程序开发人员在自己本地的命名空间定义的名称翻译为ara::com::InstanceIdentifier的能力。
本地命名其实一般也是直接从AUTOSAR的模型里面选已选构造的。
本地名称需要在当前可执行文件中具有唯一性。（那是当然了），基本是下面的形式:
<context 0>/<context 1>/.../<context N>/<port name>

在C++中本地名称是ara::core::InstanceSpecifier。然后他的类结构和上面com 的是基本上一样的。

集成人员通过manifest把具体的跟技术有关的ID和这些本地标识符绑定。换句话说，也可以让具有相同的ara::core::InstanceSpecifier的执行文件同时启动N多次，只要给他们不同的manifest。

下面的API将ara::core::InstanceSpecifier翻译为ara::com::InstanceIdentifier:

namespace ara::com::runtime{
ara::com::InstanceIdentifierContainer ara::com::runtime::ResolveInstanceIDs(ara::core::InstanceSpecifier modelName);

}

有人可能会问了，为什么返回的是个Container？这是因为AUTOSAR想告诉你，我们可能在一个标识符后面绑定了好几个通讯技术。多绑定对服务器来讲是一个很常见的use case(汽车行业软件能力还是弱啊，写文档的人还要负责教),这样可以很容易的允许各种各样的客户端在链接服务器的时候选择他们喜欢的技术。对于客户端来说，多技术绑定一般是为了冗余设计。（A挂了用B，这样）
技术上来讲，ResolveInstanceIDs()会查找进程绑定的 service instance manifest，在里面找ara::core::InstanceSpecifier。ara::core::InstanceSpecifier必须在service instance manifest中是独一无二的。

用哪个？

如上所示，我们发现要从ara::core::InstanceSpecifier转换到ara::com::InstanceIdentifier需要调用ResolveInstanceIDs()。实际上我们做了函数的重载，你可以随便用ara::com::InstanceIdentifier OR ara::core::InstanceSpecifier。ara::com::InstanceIdentifier的优点在于他包含了技术绑定的信息，可以在不同的APP进程中反复构造，不需要再经过服务实例manifest解析。比较适合更牛逼的开发者。