Figure 8.10: Variants of the Offer/StopOffer Pattern

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm (Entwurfsmuster- und Strukturgegenüberstellung).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Teilsystem Communication Management (ara::com) im Rahmen der serviceorientierten Architektur (SOA).
• Technischer Zweck: Gegenüberstellung zweier grundlegender Entwurfsmuster für die Bereitstellung (Offer/StopOffer) und Methoden-Implementierung serverseitiger Service-Instanzen (Service Provider):
  • Variante 1 (Skeleton-Pattern): Vererbungsbasierte Bindung über eine abstrakte Middleware-Basisklasse (ServiceSkeleton).
  • Variante 2 (Callback-Pattern): Delegations- und funktionsbasierte Bindung über Callback-Registrierung an einer konkreten Service-Entität (Service).

2. Komponenten, Entitäten & Schnittstellen

Variante 1: Skeleton (Vererbung / Subclassing)

• ServiceSkeleton (Abstrakte Klasse / kursiv):
  • Vom AUTOSAR-Generator aus dem formalen Schnittstellenmodell (ARXML / Service Interface) erzeugte Basisklasse.
  • Schnittstellen:
    • + Offer(): Result – Veröffentlicht die Service-Instanz über das jeweilige Transport-Binding (z. B. SOME/IP SD, IPC). Liefert typischerweise ein ara::core::Result<void>.
    • + ServiceOperation(): void (rein virtuell) – Signatur der im ServiceInterface definierten Methode; erzwingt Override in der abgeleiteten Klasse.
    • + StopOffer(): void – Zieht die Verfügbarkeit der Service-Instanz im Service Discovery zurück.
• ServiceImpl (Konkrete Applikationsklasse):
  • Realisiert die eigentliche Applikationslogik.
  • Beziehung: Generalisierung/Spezialisierung (ServiceImpl erbt von ServiceSkeleton).
  • Schnittstellen:
    • + ServiceOperation(): void – Konkrete Implementierung des Methodenaufrufs.

Variante 2: Callback (Komposition / Delegation)

• Service (Konkrete Middleware-Klasse):
  • Vollständig instanziierbarer Service-Container ohne zwingende Subklassierung.
  • Schnittstellen & interne Methoden:
    • - executeCallback(): T – Private Dispatching-Methode, die bei eintreffenden Client-Aufrufen den hinterlegten Callback ausführt und dessen Rückgabetyp T handhabt.
    • + Offer(): Result – Startet das Service Discovery Angebot.
    • + RegisterCallback(function): void – Injektion des aufzurufenden Handlers (Funktionszeiger, Funktor oder std::function).
    • + StopOffer(): void – Beendet das Service-Angebot.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Verdrahtung:
   • Variante 1: Instanziierung des ServiceImpl-Objekts. Die Methodenzuordnung ist zur Compile-Zeit via VTable fest gebunden.
   • Variante 2: Instanziierung des Service-Objekts gefolgt von RegisterCallback(function) zur Laufzeit, bevor Anfragen verarbeitet werden können.
2. Service Announcement (Offer):
   • Aufruf von Offer() signalisiert der Kommunikationslaufzeit (Daemon / Binding) die Betriebsbereitschaft.
   • Trigger für das Service Discovery (Versand von SOME/IP SD Offer Messages bzw. IPC-Registry-Eintrag).
   • Rückmeldung über Result: Synchroner Erfolg oder Fehlercode (z. B. Service Instance ID bereits vergeben, Network Binding nicht bereit).
3. Request Dispatching (Eingehende ServiceOperation):
   • Eingehender RPC-Request über das Netzwerk/IPC.
   • Variante 1: Laufzeitumgebung ruft ServiceOperation() polymorph direkt auf der ServiceImpl-Instanz auf.
   • Variante 2: Middleware ruft intern executeCallback() auf, welche die registrierte Callback-Funktion ausführt und das Ergebnis serialisiert zurücksendet.
4. Terminierung (StopOffer):
   • Aufruf von StopOffer() initiiert das Senden von StopOffer-Nachrichten im Netzwerk.
   • Laufende Aufrufe werden geordnet beendet; nachfolgende Client-Requests werden abgewiesen.

4. Normative Relevanz & Entwickler-Hinweise

• AUTOSAR AP Standard-Paradigma: In der normativen ara::com-Spezifikation (SWS Communication Management) ist Variante 1 (Skeleton) das primäre Architekturmuster (class <Service>Skeleton). Die Methodenimplementierung erfolgt über rein virtuelle Methoden (häufig asynchron über ara::core::Future).
• Verwendung von Variante 2: Findet Einsatz in generischen Adaptern, dynamischen Gateway-Komponenten, Test-Stubs oder Middleware-Abstraktionsschichten, bei denen Vererbungshierarchien vermieden oder Callbacks dynamisch zur Laufzeit ausgetauscht werden sollen.
• Speicher- und Laufzeitimplikationen (Embedded C++):
  • Variante 1: VTable-Overhead (ein Pointer pro Instanz), deterministisches Dispatching, minimale Laufzeitkosten, keine dynamischen Speicherallokationen für Funktions-Wrapper.
  • Variante 2: Bei Verwendung von std::function für RegisterCallback drohen je nach Closure-Größe dynamische Heap-Allokationen (Verletzung von MISRA C++ / AUTOSAR C++14 Richtlinien bezüglich dynamischem Speichermanagement nach der Startphase).
• Nebenläufigkeit & Thread-Safety:
  • Bei beiden Varianten erfolgt der Aufruf von ServiceOperation() bzw. des registrierten Callbacks im Kontext des Worker-Thread-Pools der ara::com-Laufzeit.
  • Entwickler müssen Reentrancy und Thread-Sicherheit bei parallelen Client-Anfragen garantieren.
• Lebenszyklus-Restriktionen:
  • Ein Aufruf von RegisterCallback() (Variante 2) darf nicht nach oder parallel zu Offer() erfolgen, um Race Conditions mit eingehenden Requests zu verhindern.
  • Zerstörung von ServiceImpl bzw. Service erzwingt zwingend den vorherigen Aufruf von StopOffer(), um Deadlocks oder Use-After-Free-Zustände im Dispatcher zu vermeiden.