在Adaptive AUTOSAR CM模块介绍(一)中介绍了 AP CM模块的功能和定位，这一篇主要是讲解AP CM模块的ara::com API的内容：
为什么AUTOSAR发明了另一种通信中间件API/技术？在当时中间件技术有很多啊？在当时特别有名的中间件有：
• ROS API
• DDS API
• CommonAPI (GENIVI)
• DADDY API (Bosch)
1.当时工程师的设想是当时的中间件还是很复杂并且有各自的功能，AUTOSAR肯定是想要构建一个统一的接口，各个OEM都遵守的协议。它必须支持SOM/IP协议。好，又是SOME/IP。
这里稍微说一下SOME/IP的历史，后面我想要着重讲述一下SOME/IP的事情。
SOME/IP于2011年由BMW设计，2014年纳入AUTOSAR规范。不得不说当时SOME/IP是非常的好用的。
2.既然支持SOME/IP,所以就需要支持AUTOSAR服务模型，它将服务定义为所提供的方法、事件和字段，必须根据用户的需求进行改变和配置。
3.ara::com API应支持事件驱动和轮询模型。实时应用程序通常需要轮询的方法来避免不必要的上下文切换，而事件驱动方法则需要对于没有实时要求的应用程序更加方便。
4.提供端到端保护，无缝集成，满足ASIL的要求。
5.支持静态（预配置）和动态（运行时）选择要与之通信的服务。这是SOA的思想。
因此，综上所述的发考虑，AUTOSAR考虑的还是比较全面的，从实时通信、SOME/IP、安全、SOA思想等融于一体的考虑，才有了这个ara::com API的想法架构和设计。
于是，ara::com的最终考虑到的设计为：
- Proxy (or Stub)/Skeleton的方法，这个来源于COMMON-API，Java RMI等技术
- 独立协议的API,同样是借鉴的COMMON-API，Java RMI等技术
- 可配置的接收器侧高速缓存的排队通信，借鉴DDS、DADDY等技术
- 支持零拷贝的API（DADDY）
- 数据接收过滤系统
因此，ara::com 的方法论是：ara::com提供的这些API接口是由应用程序开发人员进行调用即可，其内部的实现这些数据传输以及零拷贝等需要AUTOSAR AP供应商负责。
整体的架构图，如下所示：
解释一下：
Proxy/Skeleton分别是客户端和给服务端的服务，这两个的服务是可以通过用户定义生成的抽象类，用户通过这些类去创建各自的对象，调用各自的方法进行通信。
都有哪些方法，这个需要下一章节来解释说明。
