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

Le namespace <SI-Namespace>::proxy::fields encapsule, dans le module com de l’Adaptive Platform, les classes proxy générées <Field> pour chaque champ de données défini dans une ServiceInterface. Les applications clientes accèdent à ces classes de champs via le proxy de service de niveau supérieur afin d’interroger des valeurs de champs distantes, de les définir ou de traiter des notifications relatives à des modifications de valeur. Les appels sur les champs devraient alors être traités de manière asynchrone via l’infrastructure de communication, afin de garantir des interactions non bloquantes. Question (ouverte) La durée de vie des différentes instances de champ est probablement liée de manière fixe au cycle de vie de l’objet proxy de niveau supérieur et ne peut pas être gérée indépendamment de celui-ci.

plus ›

Contexte

Le namespace C++ <SI-Namespace>::proxy::fields assume, dans le module com de l’AUTOSAR Adaptive Platform, une fonction de structuration clairement délimitée pour les interfaces orientées service. Les interfaces de service (ServiceInterfaces) définissent souvent, en plus des méthodes et des événements, des champs de données qui représentent un état actuel. Afin de mettre ces champs à disposition des consommateurs de service du côté client avec une sûreté de typage et une sémantique univoque, le générateur de code classe les classes de champs spécifiques dans ce sous-espace de noms dédié. Pour chaque champ modélisé dans la ServiceInterface respective, exactement une classe de champ proxy <Field> est générée. Cette encapsulation structurelle empêche les conflits de noms avec des méthodes ou événements de même nom au sein du namespace proxy de niveau supérieur. Interprétation : les classes de champs générées <Field> fournissent typiquement des fonctions d’interface spécialisées pour les fonctionnalités Get, Set et de notification, afin d’interroger ou de modifier des valeurs de manière ciblée, ou de recevoir des modifications abonnées. Le partenaire d’interaction direct des classes de champs est la logique applicative du consommateur de service d’une part, et le middleware de communication sous-jacent d’autre part. Question Q-f088d0c5052459d3 (ouverte)

Cycle de vie

L’instanciation et la gestion des objets issus de <SI-Namespace>::proxy::fields sont indissociables de l’architecture du proxy de service. En règle générale, les développeurs d’applications ne créent pas manuellement d’instances de la classe générée <Field> sous forme de variables autonomes sur le tas ou sur la pile. Au lieu de cela, la durée de vie d’une instance de <Field> devrait être probablement entièrement liée au cycle de vie du proxy de service de niveau supérieur, qui conserve ces champs en tant que membres. Question Q-4da7e86f88f269b1 (ouverte) Dès la construction réussie de l’instance de proxy après la découverte d’un point de terminaison de service approprié, les objets de champ sont initialisés et placés dans un état opérationnel. Pendant la phase active, l’objet de champ gère les ressources de communication internes ainsi que les éventuels enregistrements pour les mises à jour d’état. Si l’instance de proxy est détruite par l’application ou sort de sa portée de validité, les instances de champ associées sont par conséquent également déconstruites en bonne et due forme, libérant ainsi les ressources du middleware associées.

Parcours d'utilisation

Le déroulement typique de l’utilisation des classes du namespace <SI-Namespace>::proxy::fields se divise en une séquence fixe d’étapes d’interaction. Dans un premier temps, l’application cliente détermine l’instance du service souhaité via les mécanismes de recherche de l’Adaptive Platform et instancie le proxy de service correspondant. Dans un second temps, l’application accède, via le proxy, à l’instance membre correspondante de la classe générée <Field>. En fonction des propriétés du champ définies dans le modèle d’interface, l’application initie alors un accès en lecture, un accès en écriture ou enregistre un rappel pour les notifications de modifications de valeur. Les appels sur les champs devraient alors être traités de manière asynchrone via ara::core::Future ou via des mécanismes de rappel de l’infrastructure de communication, afin d’éviter les appels bloquants dans le thread appelant. Question Q-33586a48d8777f7f (ouverte) Après l’arrivée de la réponse ou de la notification, l’appelant évalue le résultat fourni et réagit à l’état du champ distant.