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

Le namespace <SI-Namespace>::skeleton::triggers met à disposition des classes spécifiques pour les skeletons de service dans le module de communication com de l'AUTOSAR Adaptive Platform, afin d'adresser côté serveur les triggers définis dans ServiceInterface. Pour chaque trigger déclaré dans le rôle trigger, une instance de la classe <Trigger> est mise à disposition, par laquelle les fournisseurs de services peuvent déclencher des signaux d'événement vers les clients connectés. Il est probable que la durée de vie de ces classes de trigger soit strictement liée à l'objet skeleton parent, c'est pourquoi leur utilisation requiert l'initialisation préalable et la mise à disposition du service concerné. Les fournisseurs de services doivent en outre prendre en compte le fait que des appels de triggers simultanés depuis plusieurs threads devraient exiger une synchronisation côté application. Question (ouverte)

plus ›

Contexte

Le namespace <SI-Namespace>::skeleton::triggers est un espace de nommage spécialisé du module de communication com de l'AUTOSAR Adaptive Platform (release R25-11). Au sein de l'architecture orientée services (SOA), ServiceInterface constitue la spécification formelle d'interface qui définit le périmètre fonctionnel et les modèles de communication entre les fournisseurs de services (skeletons) et les consommateurs de services (proxies). Outre les méthodes pour les appels de fonctions synchrones ou asynchrones, les événements pour le transfert de données et les fields pour les propriétés avec état, les interfaces de service peuvent également contenir des triggers. Pour chaque trigger déclaré dans un ServiceInterface sous le rôle trigger, le namespace <SI-Namespace>::skeleton::triggers met à disposition une classe de trigger de skeleton de service <Trigger> dédiée.

Le rôle central de ces classes consiste à fournir à l'application serveur une abstraction dédiée pour signaler des impulsions de commande ou de notification. Contrairement aux événements classiques, qui servent principalement au transport continu ou événementiel de données, un trigger signale généralement la survenance d'un événement défini ou d'un changement d'état. Les partenaires d'interaction clés des classes de triggers comprennent la logique applicative fournisseuse, le skeleton de service agrégateur ainsi que le middleware de communication de com, qui prend en charge l'acheminement des signaux via la liaison de transport respective.

Cycle de vie

Le cycle de vie des classes de triggers dans le namespace <SI-Namespace>::skeleton::triggers est directement couplé au skeleton de service parent. Vraisemblablement, pour chaque trigger défini dans ServiceInterface, exactement une instance de la classe <Trigger> est instanciée lors de la création du skeleton de service et gérée par celui-ci. Question Q-a0d69b49748aa8c4 (ouverte) Une création ou une destruction isolée par l'application de service n'a habituellement pas lieu.

En phase opérationnelle, l'utilisation se divise en trois phases caractéristiques : la phase d'initialisation, la phase d'émission active et la phase de terminaison. Durant l'initialisation, la couche de communication configure les liaisons et les ressources nécessaires pour le trigger. Dès que le fournisseur de service propose officiellement le service dans le système via le skeleton, le trigger passe à l'état prêt à l'emploi. Dans cette phase, la logique applicative peut lancer de manière répétée des opérations de déclenchement. Si la mise à disposition du service prend fin ou si le skeleton est libéré, les ressources de trigger associées sont également nettoyées. En matière de concurrence, une synchronisation côté application devrait être nécessaire en cas d'actionnement simultané du trigger depuis plusieurs threads, dès lors que le framework de communication sous-jacent ne garantit pas de sécurité inhérente des threads pour des appels simultanés de triggers. Question Q-eb23aad9119e9a8f (ouverte)

Parcours d'utilisation

Le chemin d'utilisation typique pour les classes issues de <SI-Namespace>::skeleton::triggers englobe l'ensemble du déroulement, de la définition de l'interface jusqu'à la désactivation du service :

• Conception de l'interface et génération de code : Dans le modèle logiciel, un ServiceInterface est défini, contenant au moins un trigger dans le rôle trigger. Le générateur de code de la plateforme produit à partir de cela le namespace <SI-Namespace>::skeleton::triggers et la classe <Trigger> correspondante.
• Instanciation du skeleton : L'application serveur instancie l'implémentation concrète du skeleton de service. Interprétation : L'accès à l'instance de <Trigger> est exposé au fournisseur de service via l'interface membre du skeleton. Question Q-f287180a040cea33 (ouverte)
• Fourniture du service : Le skeleton de service initie la mise à disposition du service sur le réseau, de sorte que les proxies clients puissent trouver le service et s'enregistrer pour recevoir les notifications de trigger.
• Déclenchement du trigger : Dès qu'une condition de trigger est remplie dans la logique applicative, le logiciel serveur appelle la méthode de déclenchement sur l'objet <Trigger>. La plateforme transmet le signal à tous les consommateurs enregistrés.
• Mise hors service : L'application serveur retire la mise à disposition du service et détruit l'instance de skeleton, ce qui désalloue également les objets de trigger de manière déterministe.