namespace <SI-Namespace>::proxy::triggers

L’espace de nommage <SI-Namespace>::proxy::triggers fournit, dans le module com de l’AUTOSAR Adaptive Platform, des classes de proxy côté client <Trigger> pour chaque déclencheur défini dans la ServiceInterface avec le rôle trigger. L’instanciation s’effectue vraisemblablement de manière implicite via le proxy de service, par l’intermédiaire duquel l’application adresse l’objet de déclenchement afin de transmettre un signal de déclenchement au fournisseur de service. Question Q-3f5a464441664c95 (ouverte) La durée de vie des déclencheurs est liée à l’instance de proxy de niveau supérieur, une synchronisation côté application étant requise en cas d’accès concurrent par plusieurs threads d’application.

plus ›

Contexte

L’espace de nommage <SI-Namespace>::proxy::triggers fait partie intégrante du module de communication (com) dans l’AUTOSAR Adaptive Platform pour la version R25-11. Il sert à encapsuler des classes de proxy côté client pour les éléments déclencheurs modélisés dans une interface de service. Pour chaque déclencheur déclaré dans une ServiceInterface avec le rôle trigger, une classe de déclencheur de proxy de service spécifique <Trigger> est fournie dans cet espace de nommage.

Dans l’interaction de l’architecture orientée services, cet espace de nommage fait office d’intermédiaire ciblé entre l’application cliente utilisatrice et les points d’interaction du proxy de service de niveau supérieur. Vraisemblablement, les instances de la classe générée <Trigger> sont mises à disposition sous la forme de membres ou par le biais de méthodes d’accès du proxy de service respectif et partagent sa liaison avec une instance de service résolue. Question Q-821f73ddacf7a754 (ouverte) Tandis que les appels de méthode dans com représentent typiquement des appels de fonction synchrones ou asynchrones avec paramètres et valeurs de retour et que les événements servent à la réception continue de données, un déclencheur côté proxy devrait agir comme un mécanisme de déclenchement léger afin de transmettre, depuis le côté client, un signal ou une notification au fournisseur de service.

Cycle de vie

Puisque l’espace de nommage <SI-Namespace>::proxy::triggers fournit principalement des éléments d’interface générés en fonction du type pour les déclencheurs de proxy de service, il ne définit aucune phase d’initialisation globale autonome ni aucune transition d’état au niveau de l’espace de nommage. La durée de vie et les relations de possession des objets de déclenchement devraient plutôt être intégralement couplées au cycle de vie de l’instance de proxy de niveau supérieur, de sorte qu’aucune création séparée via des fabriques ou des routines de libération manuelles ne soit nécessaire pour l’application cliente. Question Q-34d5346fed668f0b (ouverte)

La création de l’instance de déclencheur a lieu implicitement pendant la construction du proxy de service, après qu’une instance de service appropriée a été trouvée via la découverte de services. Tant que le proxy de service existe en mémoire et demeure valide, la classe <Trigger> intégrée est également disponible pour les interactions. Si le proxy de service est détruit ou libéré, la durée de vie des objets de déclenchement associés prend également fin. En ce qui concerne la concurrence et la sécurité des threads, il convient de veiller à la synchronisation côté application en cas d’accès simultané de plusieurs threads d’application au même objet de déclencheur, car la spécification ne décrit aucune garantie supplémentaire à ce sujet au niveau de l’espace de nommage.

Parcours d'utilisation

Le déroulement typique de l’utilisation des éléments de l’espace de nommage <SI-Namespace>::proxy::triggers suit le modèle régulier de la communication orientée services côté proxy et se divise en découverte de service, création du proxy et déclenchement.

Dans un premier temps, l’application Adaptive recherche une instance disponible du service cible au moyen des mécanismes de la plateforme et instancie le proxy de service associé. Dans un deuxième temps, l’application accède, par le biais du proxy, à l’instance <Trigger> mise à disposition dans l’espace de nommage, qui correspond au déclencheur modélisé dans la ServiceInterface. Dans un troisième temps, l’application exécute l’appel sur l’objet de déclenchement, envoyant ainsi le signal de déclenchement au fournisseur de service. Une fois la communication terminée, l’instance de proxy de service est correctement désallouée, ce qui clôture le chemin d’utilisation de la classe de déclencheur.