# Explanation of ara::com API ###### tags: `專題` ## Introduction * Some properities: * Proxy (or Stub)/Skeleton approach * Protocol independent API * Queued communication with configurable receiver-side caches * Zero-copy capable API with possibility to shift memory management to the middleware * Data reception filtering * ara::com only defines the API signatures and its behavior visible to the application developer. * ara::com does not provide any kind of component model or framework, which would take care of things like component life cycle, management of program flow or simply setting up ara::com API objects according to the formal component description of the respective application ### High Level Structure * ara::com uses **classical Proxy/Skeleton architectural pattern** * data types: * pointer types: for pointers to data transmitted via middleware * collection types: for collections of data transmitted via middleware * Types for async operation result management: ara::com relies on AUTOSAR AP specific data types * Function wrappers: for various application side callback or handler functions to be called by the middleware * (note: ara::com defines signature and expected behavior of those types, but does not provide an implementation. The idea of this approach is, that platform vendors could easily come up with their own optimized implementation of those types.) * Error notification: * Checked Errors/Exceptions: Checked Errors within ara::com API can only occur in the **context of a call of a service interface method**. * Unchecked Errors/Exceptions: Unchecked Errors within ara::com API can occur in the context of any ara::com API call.