namespace <SI-Namespace>::proxy

Der Namespace <SI-Namespace>::proxy stellt innerhalb des Moduls com die clientseitige Schnittstelle zur Interaktion mit einem Service Interface bereit. Seine zentrale Komponente ist die Proxy-Klasse <SI>Proxy, welche die Middleware-Kommunikation abstrahiert und Methodenaufrufe sowie Ereignisabonnements ermöglicht. Die Instanziierung des Proxys dürfte typischerweise ein gültiges Handle aus der Service-Suche voraussetzen. Frage (offen) Als wesentliche Randbedingung muss die aufrufende Anwendung Verbindungsunterbrechungen und asynchrone Antwortzeiten bei Fernaufrufen robust behandeln.

mehr ›

Kontext

Der Namespace <SI-Namespace>::proxy bildet innerhalb des Kommunikationsmoduls com der AUTOSAR Adaptive Platform die clientseitige Repräsentation eines Service Interface ab. Er bündelt sämtliche Artefakte und Typen, die für Dienstkonsumenten zur Interaktion mit einem über das Kommunikationsnetzwerk angebotenen Dienst erforderlich sind. Im Zentrum dieses Namensraums steht die generierte Proxy-Klasse <SI>Proxy. Diese Klasse abstrahiert die zugrunde liegende nachrichtenbasierte Interprozess- und Netzwerkkonfiguration und stellt eine C++-Schnittstelle bereit, über welche Anwendungssoftware Methoden aufrufen, Ereignisse abonnieren sowie Felder abfragen und beobachten kann.

Architektonisch fungiert der Proxy als Vermittler zwischen der anwendungsspezifischen Client-Logik und der Laufzeitumgebung der Adaptive Platform. Anstelle direkter Netzwerk- oder Shared-Memory-Interaktionen interagiert der Anwendungsentwickler ausschließlich mit den Instanzen aus <SI-Namespace>::proxy. Dadurch wird eine Entkopplung realisiert, die es erlaubt, Kommunikationsprotokolle, Datenübertragungsformate und Lokationsdetails transparent durch die zugrunde liegende Plattform-Middleware verwalten zu lassen.

Lebenszyklus

Der Lebenszyklus von Objekten im Namespace <SI-Namespace>::proxy ist eng an die Verfügbarkeit der korrespondierenden Service-Instanz gekoppelt. Bevor eine Proxy-Instanz erzeugt werden kann, muss eine Instanzerkennung stattfinden. Die Instanziierung des Proxys <SI>Proxy dürfte typischerweise ein Handle erfordern, das aus der Service-Suche resultiert. Frage Q-3dcfd734b218f865 (offen) Nach erfolgreicher Instanziierung repräsentiert das Proxy-Objekt eine logische Verbindung zum jeweiligen Dienstanbieter.

Während der aktiven Betriebsphase verwaltet die Proxy-Instanz die Zustände bezüglich abonnierter Ereignisse und ausstehender asynchroner Methodenaufrufe. Bezüglich der Nebenläufigkeit ist zu beachten, dass Aufrufe an den Proxy thread-sicher gestaltet sein müssen oder vom Client entsprechend synchronisiert werden müssen, sofern mehrere Threads dasselbe Proxy-Objekt verwenden. Die Freigabe oder Zerstörung des Proxy-Objekts dürfte die Bindung an die gefundene Service-Instanz beenden und laufende Abonnements auflösen. Frage Q-e9d55205ba1bf55b (offen)

Nutzungspfad

Ein typischer Nutzungspfad zur Verwendung des Service Interface Proxys gliedert sich in mehrere aufeinanderfolgende Phasen:

• Auffinden der Service-Instanz: Der Client initiiert über die Plattform-Mechanismen des Moduls com eine Suche nach verfügbaren Instanzen des Services und erhält entsprechende Handle-Strukturen zurück.
• Konstruktion des Proxys: Unter Verwendung eines gültigen Handles wird eine Instanz von <SI>Proxy instanziiert, wodurch der Kommunikationskanal zum Server aufgebaut wird.
• Interaktion mit Service-Elementen: Über die Instanz werden Methoden synchron oder asynchron aufgerufen, Ereignisse abonniert und Callbacks registriert. Asynchrone Kommunikationsmuster dürften vermutlich über typisierte Ereignis- und Methoden-Wrapper innerhalb der Proxy-Instanz abgebildet werden. Frage Q-2e6b91c7e5f88567 (offen)
• Beendigung und Bereinigung: Nach Abschluss der Kommunikation werden Ereignisse deabonniert und die Proxy-Instanz wird ordnungsgemäß zerstört, um belegte Ressourcen freizugeben.

Fehlerszenarien

Bei der Interaktion mit dem Proxy-Namensraum können verschiedene Fehlerbilder auftreten. Hierzu zählen Verbindungsabbrüche zum Server, Timeouts bei Fernaufrufen sowie die Nichtverfügbarkeit von angeforderten Service-Instanzen während der Initialisierung. Da die Kommunikation über Prozess- und Rechnergrenzen hinweg erfolgt, spiegeln sich infrastrukturelle Fehler oder Ausfälle der Gegenstelle in den Rückgabewerten wider. Aufrufe vor erfolgreicher Bindung oder nach Zerstörung der Instanz führen zu ungültigen Zuständen, weshalb Vorbedingungen bezüglich der Gültigkeit des Handles strikt eingehalten werden müssen.