structure <SI-Namespace>::skeleton::<SI>Skeleton::<Method>Output

La structure regroupe l'ensemble des arguments de sortie d'une méthode de service-interface côté serveur en vue de leur transmission à l'appelant. Lors de l'exécution d'une méthode skeleton, l'implémentation du service instancie cette structure de données, remplit ses attributs avec les résultats calculés et la transmet à la couche de communication. Le middleware sérialise ensuite les paramètres contenus et transmet le paquet de réponse au proxy appelant. Comme aucune exigence explicite de spécification n'est enregistrée dans le payload, les types des éléments devraient correspondre directement aux types de données des paramètres de sortie modélisés dans l'interface de service. Question Q-55d242e98cd76967 (ouverte)

plus ›

Contexte

La structure C++ <SI-Namespace>::skeleton::<SI>Skeleton::<Method>Output est un composant généré de la partie service dans le module com de l'AUTOSAR Adaptive Platform (version R25-11). Au sein de l'interface de service, ce type regroupe l'ensemble des arguments de sortie (paramètres Out) d'une méthode de service définie côté fournisseur. La structure fait office de couche intermédiaire entre l'implémentation concrète de service du fournisseur de service et le middleware de communication ara::com. Les signatures de fonctions C++ ne prenant généralement en charge qu'une seule valeur de retour, ce type fournit un agrégat structuré permettant de renvoyer de manière sûre au niveau du typage les méthodes comportant plusieurs paramètres de sortie à l'environnement d'exécution appelant.

Cycle de vie

La création d'une instance de <Method>Output s'effectue dans le contexte applicatif du fournisseur de service dès qu'une méthode de service a terminé les calculs requis. L'implémentation du service instancie localement l'agrégat de données, initialise les variables membres déclarées en son sein avec les valeurs déterminées et transmet ensuite l'instance à la couche de communication. Avec la transmission au framework, les droits de propriété immédiats de l'implémentation de méthode spécifique à l'application prennent fin ; l'objet est transféré dans le périmètre de responsabilité du middleware. La durée de vie de l'instance est transitoire et se termine dès que la couche de communication a sérialisé les paramètres contenus dans les payloads de protocole en aval et libéré le tampon. En ce qui concerne la concurrence, chaque appel de méthode est isolé : chaque contexte d'appel opère sur sa propre instance, de sorte qu'aucun mécanisme de synchronisation n'est requis au niveau de la classe tant que les valeurs transportées ne partagent pas de ressources communes non protégées.

Parcours d'utilisation

Le déroulement typique lors de l'utilisation de <Method>Output s'effectue selon une séquence d'interactions fixe entre l'environnement d'exécution, l'implémentation de la méthode skeleton et la structure de sortie. Dès la réception d'une requête de méthode, le middleware transmet l'appel à la classe skeleton implémentée. La logique applicative procède au traitement, crée la structure <Method>Output et renseigne tous les paramètres de sortie. L'instance est ensuite transmise au système d'exécution, qui effectue la sérialisation et envoie le message de réponse sur le réseau au proxy demandeur.

Diagramme de séquence : chemin d'appel et de retour lors de l'utilisation de la structure Output dans le skeleton. Sources : aucune référence spécifiée dans le payload.

Scénarios d'erreur

En tant que pur agrégat de données, <Method>Output ne dispose d'aucune routine de traitement des erreurs ni d'aucune méthode d'état propre. Les états erronés surviennent principalement aux interfaces en raison d'une initialisation incomplète ou de violations de préconditions. Si l'implémentation côté application omet de renseigner correctement certaines variables membres avant le retour, des valeurs non initialisées ou des états nuls peuvent être sérialisés. Si le calcul fonctionnel de la méthode de service échoue en amont, aucune instance valide de <Method>Output n'est transmise dans le flux de contrôle normal ; l'implémentation signale plutôt l'erreur survenue via les canaux d'erreur prévus à cet effet de l'interface de service. Si des erreurs d'allocation mémoire surviennent pour des structures de données dynamiques au sein des arguments de sortie, celles-ci doivent être interceptées au sein de la méthode appelée avant toute transmission au middleware.