Figure 7.2: Service-Oriented Communication

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Informelles UML-Sequenzdiagramm (Darstellung des Architekturmusters Service-Oriented Architecture / Publish-Find-Bind).
• Technischer Zweck: Grundlegende Illustration des serviceorientierten Kommunikationsparadigmas in der AUTOSAR Adaptive Platform (ara::com / Communication Management).
• Architektonische Einordnung: Veranschaulicht die strikte Entkopplung von Dienstanbieter und Dienstkonsument zur Laufzeit. Es bildet den konzeptionellen Gegenentwurf zur statischen, signalbasierten Kommunikation der AUTOSAR Classic Platform (RTE/Com).

2. Komponenten, Entitäten & Schnittstellen

• Application 1 (Service provider): Adaptive Application (AA), die ein definiertes Service-Interface über ein generiertes ara::com-Service-Skeleton implementiert und exportiert.
• Service Registry: Logische Vermittlungs- und Adressierungsentität (Service Discovery). Im Adaptive-Stack entweder realisiert als:
  • Verteilter Dienst über das Netzwerk via SOME/IP-SD (Multicast/Unicast SD-Messages).
  • Lokaler IPC-Broker/Daemon für knoteninterne Inter-Prozess-Kommunikation.
• Application 2 (Service requester): Adaptive Application (AA), die über ein typisiertes ara::com-Service-Proxy auf Funktionen des Services zugreift.
• Schnittstellen & Interaktionen:
  • offer: Registrierungs-Schnittstelle (OfferService()). Publikation der Dienstinstanz (InstanceIdentifier, Network Endpoints, Port-Konfiguration).
  • find: Lookup-Schnittstelle (FindService() / StartFindService()). Abfrage passender Service-Instanzen anhand von Service-ID / Instance-Specifier.
  • call: Direkte Punkt-zu-Punkt-Kommunikation (Remote Procedure Call / Method Call via ara::core::Future, Event-Streaming via Subscribe oder Field-Zugriffe) zwischen Proxy und Skeleton unter Umgehung der Registry.

3. Dynamisches Verhalten & Sequenzablauf

1. Service Registration (offer):
   • Trigger: Application 1 initialisiert das Service-Skeleton und ruft OfferService() auf.
   • Ablauf: Bereitstellung der Service-Metadaten und Kommunikations-Endpunkte an die Service Registry (bzw. Aussenden von SOME/IP-SD Offer-Messages).
2. Service Discovery (find):
   • Trigger: Application 2 initiiert die Suche nach kompatiblen Dienstinstanzen.
   • Ablauf: Synchron (FindService()) oder asynchron (StartFindService() mit FindServiceHandler-Callback). Die Service Registry liefert die passenden Instanz-Handles (ServiceHandleType).
3. Point-to-Point Execution (call):
   • Trigger: Application 2 instanziiert den Service-Proxy mit dem ermittelten Handle und setzt einen Methodenaufruf ab.
   • Ablauf: Der Aufruf erfolgt direkt über das Middleware-Transport-Binding (IPC/Domain Socket oder Ethernet/SOME/IP-Payload) direkt an Application 1.
   • Rückgabepfad: Typischerweise asynchron über ara::core::Future / ara::core::Promise zur Entkopplung von Aufrufer-Thread und Ausführungskontext.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::com):
  • Vor Ausführen von offer muss der interne Zustand des Service-Providers vollständig initialisiert sein; bei Shutdown/Termination muss zwingend StopOfferService() aufgerufen werden.
  • Der Requester darf keine statischen Endpunkt-Adressen hart codieren. Methodenaufrufe (call) sind erst nach erfolgreichem Handle-Erwerb über FindService() und anschließender Proxy-Instanziierung zulässig.
• Lifecycle & Startup-Entkopplung:
  • Es existiert keine deterministische Startreihenfolge. Applikationsentwickler müssen Re-Try- bzw. Asynchron-Mechanismen (StartFindService) nutzen, um temporäre Nichtverfügbarkeit von Diensten abzufangen.
• E2E-Absicherung & Serialisierung (RS_E2E_08540, SWS_CM_90402):
  • Die Entkopplung durch die Registry entbindet nicht von der Datenintegrität: Der direkte call-Pfad unterliegt bei sicherheitskritischen Schnittstellen (ASIL) der End-to-End-Absicherung (E2E-Protection über Header, CRC und Message Counter) sowie den Serialisierungsregeln der Transport-Bindings.