class {<hierarchical-namespace-list-lower-skeleton>}::skeleton::{ <service-interface-name>}Skeleton

The class serves as a server-side base class for implementing a service interface in ara::com, from which the service provider application derives. During creation, the constructor determines whether incoming method calls are processed in an event-driven manner or via polling [SWS_CM_00130]. For methods declared exception-safe, faulty executions are signaled as an error code via the returned ara::core::Future [SWS_CM_00191].

more ›

Context

Class {<hierarchical-namespace-list-lower-skeleton>}::skeleton::{ <service-interface-name>}Skeleton serves in the Adaptive Platform in module com as a generated, abstract base class for server-side provision of a service interface. An application-specific service provider component derives from this skeleton class to implement the functional business logic of the service. The class mediates between the concrete service provider application and the communication middleware or the underlying protocol binding such as SOME/IP (SWS CommunicationManagement §8.1 “Method invocation”). Interaction partners include the service provider application that creates and owns the instance, the skeleton class itself, and the communication infrastructure that receives, deserializes, and forwards incoming service requests to the skeleton ([SWS_CM_10306], [SWS_CM_10307]).

Context diagram: Interaction between service provider application, ServiceSkeleton, and communication middleware. Sources: [SWS_CM_10306], [SWS_CM_10307], SWS CommunicationManagement §8.1 “Method invocation”.

Lifecycle

Creation of the skeleton instance takes place via the constructor, to which the desired processing mode ara::com::MethodCallProcessingMode is passed [SWS_CM_00130]. This mode determines the concurrency strategy for incoming method calls: If kEvent or kEventSingleThread is configured, incoming method calls are invoked immediately in an event-driven manner by the communication middleware [SWS_CM_10306]. If kPoll is passed instead, processing is handled on a polling basis by the application [SWS_CM_10307]. Interpretation: The skeleton instance presumably remains owned by the service provider application throughout active service provisioning and is destroyed only upon service shutdown. Question Q-ce25321f79393024 (open)

Usage Path

The typical sequence comprises the implementation of the pure virtual methods by the derived provider class and subsequent execution upon incoming requests. For regular method calls (request-response), the skeleton defines an interface that returns a ara::core::Future with the corresponding output object [SWS_CM_00191], [SWS_CM_99556]. For fire-and-forget methods without a response, the skeleton provides pure virtual operations with return type void [SWS_CM_90434]. Upon incoming requests, the communication middleware deserializes the payload and forwards the call to the concrete implementation of the skeleton class in accordance with the configured processing mode ([SWS_CM_10306], [SWS_CM_00191]).

Sequence diagram: Sequence of a method call via the skeleton. Sources: [SWS_CM_00191], [SWS_CM_10306], SWS CommunicationManagement §8.1 “Method invocation”.

Error Scenarios

Both request-response methods and fire-and-forget methods are annotated at the interface level with noexcept and declared exception-safe ([SWS_CM_00191], [SWS_CM_90434]). Errors during processing of regular method calls are not transmitted via C++ exceptions; instead, in the event of an error, the returned ara::core::Future conveys a corresponding error code of type ara::com::ComErrc or an ApApplicationError [SWS_CM_00191]. According to the specification, neither return values nor standardized error codes are provided for fire-and-forget methods [SWS_CM_90434].