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

L’espace de nommage encapsule les classes de champ côté serveur pour chaque champ déclaré dans une ServiceInterface au sein de l’architecture de squelette du module com. Les fournisseurs de service utilisent ces classes générées pour gérer la valeur de champ actuelle et la transmettre aux clients connectés lors des modifications de valeur. L’instanciation et la durée de vie des objets de champ devraient ici être directement liées à l’instance de squelette de niveau supérieur. Question Q-bd1d4d2cab97eada (ouverte) Lors de la mise à jour et de la mise à disposition des données, il convient de veiller à la synchronisation conformément au modèle de threading du squelette de service.

plus ›

Contexte

L’espace de nommage <SI-Namespace>::skeleton::fields fait partie intégrante de l’architecture de communication (module com) de l’AUTOSAR Adaptive Platform dans la version R25-11. Il contient les classes générées côté serveur pour tous les champs modélisés dans un ServiceInterface avec le rôle field. Pour chaque champ défini dans l’interface, il existe une classe de champ de squelette de service correspondante suivant le schéma de nommage générique <Field>. Ces classes constituent le lien entre l’implémentation spécifique à l’application d’un service et la couche de communication sous-jacente afin de proposer de manière structurée des structures de données relatives aux champs.

Dans les architectures orientées services, les champs représentent des propriétés d’un service qui peuvent typiquement être composées d’une combinaison d’accès en lecture (getters), d’accès en écriture (setters) et de notifications basées sur des événements (notificateurs). Tandis que des interfaces correspondantes sont générées côté client dans l’espace de nommage proxy pour l’accès consommateur, skeleton::fields fournit les classes avec lesquelles le fournisseur de service (serveur) gère l’état interne et l’expose vers l’extérieur. Les classes de l’espace de nommage <SI-Namespace>::skeleton::fields encapsulent la communication et la transmission spécifique au protocole, permettant ainsi au développeur d’application de se concentrer sur la logique fonctionnelle du service.

Cycle de vie

Concernant la création et les relations de possession, la durée de vie d’une classe de champ dans l’espace de nommage skeleton::fields devrait être directement liée à la classe squelette de niveau supérieur de l’interface de service. Question Q-375f07429819a937 (ouverte) Dans les implémentations basées sur C++ de l’Adaptive Platform, les instances de champ sont typiquement instanciées en tant qu’objets membres directs au sein du squelette généré. Par conséquent, le cycle de vie des objets de champ débute avec l’appel du constructeur du squelette de service et se termine automatiquement avec la destruction de celui-ci.

Pendant la phase d’exploitation, l’objet de champ demeure dans la mémoire du fournisseur de service. Avant ou pendant la proposition du service sur le réseau (par exemple avant l’enregistrement du service ou immédiatement après), l’instance de champ est initialisée avec une valeur initiale valide. Le squelette restant disponible pour les interrogations et les mises à jour tout au long de sa durée de vie, l’instance de champ reste elle aussi accessible de manière persistante.

En ce qui concerne la concurrence et le threading, la gestion des accès aux champs devrait fortement dépendre du modèle de traitement choisi pour le skeleton. Question Q-d3456f67c7a4ba8d (ouverte) Dans la mesure où la classe de champ fournit des mécanismes de rappel pour les requêtes entrantes d'écriture ou de lecture ou propose des méthodes de mise à jour de la valeur de champ, les accès concurrents doivent être synchronisés par l'implémentation de service utilisatrice afin d'éviter les conditions de concurrence en cas de traitement concurrent.

Parcours d'utilisation

Le chemin d'utilisation typique pour les classes issues de <SI-Namespace>::skeleton::fields commence dans le cadre de l'initialisation du fournisseur de service. Lors de la construction de l'instance de skeleton, l'objet de champ respectif est créé pour chaque champ configuré. L'implémentation du service attribue généralement de manière initiale une valeur de départ valide à la classe de champ, afin que les clients demandeurs trouvent dès le début des données cohérentes.

En cours de fonctionnement, l'interaction s'effectue principalement par des mises à jour de valeurs. Dès que des états internes, des valeurs de capteurs ou des données de calcul changent dans l'application de service, le skeleton appelle la méthode de mise à jour correspondante de l'instance de champ. La classe de champ prend alors en charge la distribution des nouvelles données vers le framework de communication, qui transmet les valeurs sous forme de messages de notification à tous les proxys de service intéressés et abonnés sur le réseau.

Si le champ est configuré pour des accès en écriture par des clients, la classe de champ traite les requêtes de mise à jour entrantes (opérations Set). L'implémentation de service reçoit les valeurs modifiées, les valide et met à jour l'état interne. Grâce à ce déroulement fonctionnel composé d'initialisation, de transmission périodique ou événementielle des valeurs et de terminaison contrôlée à la fin de vie du skeleton, les classes de champs s'intègrent de manière transparente dans le modèle d'interaction de la couche de service AUTOSAR Adaptive.