Figure 6.5: Service Discovery

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Vereinfachtes UML-Sequenzdiagramm / Interaktionsdiagramm (SOA Find-Bind-Execute-Muster).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ara::com).
• Funktionaler Zweck: Veranschaulichung des grundlegenden Service-Discovery-Musters (Broker-/Registry-basiert) zur dynamischen Kopplung zwischen Service-Providern (Skeletons) und Service-Consumern/Requestern (Proxies) zur Laufzeit vor dem direkten Datenaustausch.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Entitäten:
  • Application 1 (Service provider): Adaptive Application in der Rolle des Dienstanbieters. Implementiert und instanziiert die typspezifische Skeleton-Klasse (<Service>Skeleton).
  • Service Registry: Logische Registry- bzw. Broker-Instanz (in POSIX/SOME/IP-Umgebungen entweder realisiert als zentraler Routing-Daemon/IPC-Broker auf Knotenebene oder über verteiltes SOME/IP-SD via Multicast über das Kommunikations-Subsystem).
  • Application 2 (Service requester): Adaptive Application in der Rolle des Dienstkonsumenten. Verwendet die typspezifische Proxy-Klasse (<Service>Proxy).
• Interaktionsschnittstellen (ara::com API-Mapping):
  • offer: Registrierungsschnittstelle des Providers (ara::com::Skeleton::OfferService()).
  • find: Discovery-Schnittstelle des Requesters (ara::com::Proxy::FindService() [synchron/Polling] oder ara::com::Proxy::StartFindService() [asynchron mit FindServiceHandler-Callback]).
  • call: Punkt-zu-Punkt-Nutzdateninteraktion (Method-Calls ara::core::Future, Event-Empfang oder Field-Zugriffe) direkt zwischen Requester-Proxy und Provider-Skeleton über das konfigurierte Binding (IPC oder SOME/IP).

3. Dynamisches Verhalten & Sequenzablauf

1. Service Registration (offer):
   • Aktion: Application 1 initialisiert die Service-Instanz und ruft OfferService() auf.
   • Wirkung: Ankündigung der Service-Instanz (InstanceSpecifier, Service ID, Instance ID, Major/Minor Version) an die Service Registry bzw. Aussenden von SOME/IP-SD Offer-Messages.
2. Service Resolution (find):
   • Aktion: Application 2 sucht nach verfügbaren Instanzen (FindService() oder StartFindService()).
   • Wirkung: Abfrage an die Service Registry nach passenden Service-Deskriptoren. Bei Übereinstimmung erhält der Requester ein oder mehrere ara::com::ServiceHandleType-Objekte zurück, mit denen der Proxy konstruiert wird.
3. Direkte Interaktion (call):
   • Aktion: Application 2 initiiert Methodenaufrufe oder Subscriptions direkt auf der Provider-Instanz (Application 1).
   • Mechanik: Die Service Registry ist nicht mehr im Nutzdatenpfad involviert; die Kommunikation erfolgt Peer-to-Peer über das konfiguriert gebundene Transportmedium (Shared Memory / Unix Domain Sockets bei lokaler IPC, Ethernet/SOME/IP bei knotenübergreifender Kommunikation).

4. Normative Relevanz & Entwickler-Hinweise

• Binding-Transparenz: Die Applikationslogik interagiert ausschließlich über die C++14/C++17 ara::com-Standardschnittstellen (OfferService, FindService, Service-Handle). Die physische Ausprägung der Service Registry (zentraler Broker vs. SOME/IP Service Discovery Multicast) wird deklarativ im ARXML-Manifest (ServiceInstanceManifest, Port-Interfaces, Network Binding) konfiguriert.
• Lebenszyklus & Thread-Sicherheit:
  • Vor Zerstörung der Skeleton-Instanz muss zwingend StopOfferService() ausgeführt werden, um unberechtigte Aufrufe und Dead-Locks zu verhindern.
  • Proxies müssen ungültige Service-Handles behandeln, falls der Provider terminiert oder den Dienst deregistriert.
• Synchronisationsverhalten:
  • Synchrones FindService() blockiert nicht im Netzwerk, sondern liefert nur die zum Abfragezeitpunkt in der lokalen Middleware bekannten Instanzen (Snapshot-Semantik).
  • Für asynchrone bzw. dynamisch nachstartende Provider ist zwingend StartFindService() mit Callback-Registrierung zu verwenden.