SNIP_ADAPTIVE_CAN_FIGURE_Figure_5_1_ARACOMAPI

Figure 5.1: Proxy Skeleton Pattern The basic idea of this pattern is, that from a formal service definition two code artifacts are generated: • Service Proxy: This code is - from the perspective of the service consumer, which wants to use a possibly remote service - the facade that represents this service on code level. In an object-oriented language binding, this typically is an instance of a generated class, which provides methods for all functionalities the service provides. So the service consumer side application code interacts with this local facade, which then knows how to propagate these calls to the remote service implementation and back. • Service Skeleton: This code is - from the perspective of the service implementation, which provides functionalities according to the service definition - the code, which allows to connect the service implementation to the Communication Management transport layer, so that the service implementation can be contacted by distributed service consumers. In an object-oriented language binding, this typically is an instance of a generated class. Usually the service implementation from 12 of 90 — AUTOSAR CONFIDENTIAL — Document ID 846: AUTOSAR_EXP_ARAComAPI