namespace <SI-Namespace>::skeleton

In module com of the AUTOSAR Adaptive Platform (Release R25-11), namespace <SI-Namespace>::skeleton encapsulates the server-side mediation layer for service interfaces via class <SI>Skeleton. It serves to forward incoming method calls to the application-specific business logic and to transmit events and fields to connected clients. The server application instantiates the skeleton, offers the service via the platform, and stops offering it before destroying the object. Since communication presumably occurs concurrently, the provided method calls must be implemented in a thread-safe manner. Question (open)

more ›

Context

Within the communication module com of the AUTOSAR Adaptive Platform (Release R25-11), namespace <SI-Namespace>::skeleton forms the standardized namespace for server-side service components. At the center of this namespace is the service skeleton class <SI>Skeleton, which represents the mediation layer between the application-specific implementation of a service provider and the underlying communication middleware. The identifier <SI> acts as a placeholder for the concrete name of the service interface, while <SI-Namespace> reflects the configured namespace of the interface definition.

The primary responsibility of the namespace lies in providing type-safe structures for server-side handling of service-oriented communication. The essential interaction partners here are the service application itself and the platform middleware. Class <SI>Skeleton presumably serves as a base class for the application-specific implementation of the service provider, from which the service application inherits or which it instantiates to receive method calls and provide events. Question Q-d43c51f8b475898f (open)

Lifecycle

The lifecycle of the components in the namespace is oriented around the provision and operation of class <SI>Skeleton. An instance of the service skeleton represents the active presence of a service on an instance of the Adaptive Platform. Creation and configuration of the object are the responsibility of the providing application, which binds the instance to a concrete service identifier and instance identifier.

The lifecycle of the skeleton instance is likely tied to the service offering, whereby the instance must be fully initialized before active offering and may only be destroyed after the service offering has been properly stopped. Question Q-de1059259cadf8ee (open) During the operational phase, the skeleton handles the dispatching of incoming requests to the registered method bodies as well as the management of outgoing events.

Regarding the execution model, it must be taken into account that calls arrive from the network. Communication between the skeleton and the middleware is likely asynchronous and concurrent, so method calls and event dispatching must be handled in a thread-safe manner. Question Q-3ff7109db2f3f381 (open) When the service is deactivated, the application ensures an orderly termination of communication before the <SI>Skeleton object is destroyed.

Usage Path

The typical sequence when using the namespace is divided into the phases implementation, deployment, communication, and deinitialization. First, the developer realizes the required interface logic by implementing an application-specific class based on <SI>Skeleton. Within this class, the methods specified in the service interface are provided with the concrete business logic.

At runtime, the service application instantiates the derived skeleton object and offers it to the platform. After offering, the skeleton instance accepts requests from connected clients, forwards them to the implemented methods, and transmits return values back to the middleware. In parallel, the application can use the skeleton to publish events or field updates to subscribing service clients. After operation is completed, the service is deregistered and the instance of <SI>Skeleton is released.