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

Die Klasse dient als serverseitige Basisklasse zur Implementierung eines Service-Interface in ara::com, von der die Dienstanbieter-Anwendung ableitet. Beim Erzeugen wird über den Konstruktor festgelegt, ob eintreffende Methodenaufrufe ereignisgesteuert oder per Polling verarbeitet werden [SWS_CM_00130]. Fehlerhafte Abläufe werden bei ausnahmesicher deklarierten Methoden über das zurückgegebene ara::core::Future als Fehlercode signalisiert [SWS_CM_00191].

mehr ›

Kontext

Die Klasse {<hierarchical-namespace-list-lower-skeleton>}::skeleton::{ <service-interface-name>}Skeleton dient in der Adaptive Platform im Modul com als generierte, abstrakte Basisklasse für die serverseitige Bereitstellung eines Service-Interface. Eine anwendungsspezifische Dienstanbieter-Komponente leitet von dieser Skeleton-Klasse ab, um die funktionale Geschäftslogik des Dienstes zu implementieren. Die Klasse vermittelt zwischen der konkreten Dienstanbieter-Anwendung und der Kommunikations-Middleware bzw. dem zugrunde liegenden Protokoll-Binding wie SOME/IP (SWS CommunicationManagement §8.1 „Method invocation“). Zu den Interaktionspartnern gehören die Dienstanbieter-Anwendung, welche die Instanz erzeugt und besitzt, die Skeleton-Klasse selbst sowie die Kommunikationsinfrastruktur, welche eingehende Service-Anfragen empfängt, deserialisiert und an das Skeleton weiterleitet ([SWS_CM_10306], [SWS_CM_10307]).

Kontextdiagramm: Zusammenspiel von Dienstanbieter-Anwendung, ServiceSkeleton und Kommunikations-Middleware. Quellen: [SWS_CM_10306], [SWS_CM_10307], SWS CommunicationManagement §8.1 „Method invocation“.

Lebenszyklus

Die Erzeugung der Skeleton-Instanz erfolgt über den Konstruktor, dem der gewünschte Verarbeitungsmodus ara::com::MethodCallProcessingMode übergeben wird [SWS_CM_00130]. Dieser Modus legt die Nebenläufigkeitsstrategie für eintreffende Methodenaufrufe fest: Wird kEvent oder kEventSingleThread konfiguriert, werden ankommende Methodenaufrufe unmittelbar ereignisgesteuert durch die Kommunikations-Middleware aufgerufen [SWS_CM_10306]. Wird stattdessen kPoll übergeben, erfolgt die Abwicklung abfragebasiert durch die Anwendung [SWS_CM_10307]. Interpretation: Die Skeleton-Instanz verbleibt vermutlich während der gesamten aktiven Dienstbereitstellung im Besitz der Dienstanbieter-Anwendung und wird erst beim Herunterfahren des Service zerstört. Frage Q-ce25321f79393024 (offen)

Nutzungspfad

Der typische Ablauf umfasst die Implementierung der rein virtuellen Methoden durch die abgeleitete Anbieterklasse und die spätere Ausführung bei eintreffenden Anfragen. Für reguläre Methodenaufrufe (Request-Response) definiert das Skeleton eine Schnittstelle, die ein ara::core::Future mit dem entsprechenden Ausgabe-Objekt zurückliefert [SWS_CM_00191], [SWS_CM_99556]. Für Fire-and-Forget-Methoden ohne Rückantwort stellt das Skeleton rein virtuelle Operationen mit dem Rückgabetyp void bereit [SWS_CM_90434]. Bei eingehenden Anforderungen deserialisiert die Kommunikations-Middleware die Nutzdaten und leitet den Aufruf gemäß des konfigurierten Verarbeitungsmodus an die konkrete Implementierung der Skeleton-Klasse weiter ([SWS_CM_10306], [SWS_CM_00191]).

Sequenzdiagramm: Ablauf eines Methodenaufrufs über das Skeleton. Quellen: [SWS_CM_00191], [SWS_CM_10306], SWS CommunicationManagement §8.1 „Method invocation“.

Fehlerszenarien

Sowohl Request-Response-Methoden als auch Fire-and-Forget-Methoden sind auf Schnittstellenebene mit noexcept annotiert und als ausnahmesicher deklariert ([SWS_CM_00191], [SWS_CM_90434]). Fehler bei der Bearbeitung regulärer Methodenaufrufe werden nicht über C++-Ausnahmen übermittelt; stattdessen transportiert das zurückgegebene ara::core::Future im Fehlerfall einen entsprechenden Fehlercode vom Typ ara::com::ComErrc oder einen ApApplicationError [SWS_CM_00191]. Für Fire-and-Forget-Methoden sind spezifikationsgemäß weder Rückgabewerte noch standardisierte Fehlercodes vorgesehen [SWS_CM_90434].