classe ara::com::InstanceIdentifier

La classe ara::com::InstanceIdentifier représente l'identifiant technique univoque d'une instance concrète de service dans l'AUTOSAR Adaptive Platform et permet l'adressage via des bindings de communication spécifiques (AUTOSAR_AP_EXP_ARAComAPI p. 22 §4.1 « InstanceIdentifier class »). En tant que type valeur sérialisable, elle peut être créée à partir de chaînes de caractères, comparée et gérée dans des conteneurs ([SWS_CM_11520], [SWS_CM_11523]). Alors que les applications standard utilisent principalement des identifiants de modèle abstraits, l'emploi direct de cet identificateur technique est réservé à des cas particuliers tels que le multi-binding et les solutions de basculement (fail-over) (AUTOSAR_AP_EXP_ARAComAPI p. 25 « InstanceIdentifier Usage »).

plus ›

Contexte

La classe ara::com::InstanceIdentifier sert à l'identification univoque d'une instance concrète de service sur l'Adaptive Platform (AdaptivePlatformServiceInstance), afin de distinguer les différentes instances d'exactement un même service. Elle encapsule l'adressage spécifique à la technologie du binding de communication sélectionné, mais ne contient délibérément aucun nom pleinement qualifié comportant des informations sur le type de service. Pour le développeur logiciel standard, l'interaction directe avec ara::com::InstanceIdentifier est généralement abstraite : tandis que des noms logiques sont principalement employés via ara::core::InstanceSpecifier dans le modèle de composants logiciels (AUTOSAR_AP_EXP_ARAComAPI p. 23 §4.2 « InstanceSpecifier class »), l'intégrateur les associe aux bindings techniques et à leurs ID d'instance respectifs via des fichiers manifestes (AUTOSAR_AP_EXP_ARAComAPI p. 23 §4.2 « InstanceSpecifier class »).

Dans le cadre de ce que l'on appelle le multi-binding, un identifiant abstrait unique peut être mis en correspondance avec plusieurs bindings techniques. La résolution via ResolveInstanceIDs() renvoie donc un ara::com::InstanceIdentifierContainer qui regroupe plusieurs ara::com::InstanceIdentifier (ARAComAPI p. 1 « Figure 6.6: InstanceIdentifier Resolution », AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 « InstanceSpecifier Resolution »). Cela permet aux serveurs (skeletons) de desservir des clients via différentes technologies de transport, ou aux clients (proxies) d'implémenter des chemins de basculement (fail-over) (ARAComAPI p. 1 « Figure 6.6: InstanceIdentifier Resolution »).

Diagramme de contexte : interaction entre l'application, le manifeste de déploiement, la résolution d'instances et les interfaces de service. Sources : ARAComAPI p. 103 « Figure 6.5: Service Discovery », AUTOSAR_AP_EXP_ARAComAPI p. 23 §4.2 « InstanceSpecifier class », AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 « InstanceSpecifier Resolution »

Cycle de vie

Les instances de ara::com::InstanceIdentifier possèdent une sémantique de valeur complète. Elles satisfont aux exigences equalitycomparable, lessthancomparable ainsi que copyassignable conformément à l'ISO/IEC 14882:2014, ce qui permet de les gérer dans des conteneurs standard, de les trier et de les journaliser. La classe fournit les constructeurs et fonctions de cycle de vie suivants :

• Création sans exception via la méthode de fabrique statique Create ([SWS_CM_11520]) avec noexcept.
• Constructeur explicite basé sur une représentation sous forme de chaîne de caractères ([SWS_CM_11521]), qui n'est expressément pas sûr vis-à-vis des exceptions (not exception safe).
• Constructeur de copie ([SWS_CM_00056]) et constructeur de déplacement ([SWS_CM_00053]), tous deux spécifiés en tant que noexcept.
• Opérateur d'assignation par copie ([SWS_CM_11525]) et opérateur d'assignation par déplacement ([SWS_CM_00054]), chacun avec noexcept.
• Opérateurs de comparaison operator== ([SWS_CM_11523]) et operator< ([SWS_CM_11524]) pour la vérification de l'égalité et de l'ordre.
• Destructeur ~InstanceIdentifier() ([SWS_CM_00055]) avec noexcept.

Grâce à l'interaction entre le constructeur de chaîne et la méthode toString() ([SWS_CM_11522]), la classe est sérialisable (AUTOSAR_AP_EXP_ARAComAPI p. 22 §4.1 « InstanceIdentifier class »). Cela permet la persistance, la transmission et la réutilisation ultérieure d'un identifiant. Une interprétation du contenu (introspection) de la chaîne sérialisée par la logique applicative n'est pas prévue, car la structure dépend entièrement du produit middleware et du binding (AUTOSAR_AP_EXP_ARAComAPI p. 22 §4.1 « InstanceIdentifier class »).

Parcours d'utilisation

Étant donné que ara::com propose pour les méthodes courantes des surcharges qui acceptent directement ara::core::InstanceSpecifier, la manipulation manuelle de ara::com::InstanceIdentifier s'adresse principalement à des cas d'utilisation avancés tels que des bindings spécialisés ou un basculement (fail-over) ciblé (AUTOSAR_AP_EXP_ARAComAPI p. 25 « InstanceIdentifier Usage »). Le déroulement typique se divise selon les étapes suivantes :

1. Résolution : l'application convertit l'identifiant de modèle abstrait au moyen de ResolveInstanceIDs() en identifiants techniques d'instance assignés (AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 « InstanceSpecifier Resolution »).
2. Sélection : à partir du ara::com::InstanceIdentifierContainer résultant, l'application sélectionne le ara::com::InstanceIdentifier souhaité (ARAComAPI p. 1 « Figure 6.6: InstanceIdentifier Resolution »).
3. Recherche de service : l'identifiant est transmis à la méthode statique FindService(ara::com::InstanceIdentifier instance) de la classe proxy (ARAComAPI p. 103 « Figure 6.5: Service Discovery »).
4. Traitement : la recherche de service renvoie un ServiceHandleContainer à partir duquel des proxies sont instanciés (ARAComAPI p. 103 « Figure 6.5: Service Discovery »). L'identifiant d'instance peut être interrogé via GetInstanceId() (AUTOSAR_AP_EXP_ARAComAPI p. 30 « GetInstanceId »).

Diagramme de séquence : résolution de l'identifiant et recherche de service ciblée via l'InstanceIdentifier technique. Sources : ARAComAPI p. 103 « Figure 6.5: Service Discovery », AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 « InstanceSpecifier Resolution »

Scénarios d'erreur

Lors de la manipulation de ara::com::InstanceIdentifier, deux situations d'erreur doivent en particulier être prises en compte :

• Format de chaîne non valide (InvalidInstanceIdentifierStringViolation) : si un identifiant sérialisé qui est corrompu, non conforme ou dupliqué est transmis à Create ([SWS_CM_11520]) ou au constructeur ([SWS_CM_11521]), cette violation se produit. Interprétation : alors que la méthode de fabrique sans exception Create signale vraisemblablement cela par un objet d'erreur, le constructeur non sûr vis-à-vis des exceptions devrait lever une exception en cas d'erreur. Question Q-45a6fdd0859218bd (ouverte)
• Mappage manquant lors de la résolution : si l'intégrateur n'a défini aucune association pour un ara::core::InstanceSpecifier dans le manifeste de déploiement, l'appel de ResolveInstanceIDs() renvoie une liste vide (ARAComAPI p. 1 « Figure 6.6: InstanceIdentifier Resolution », AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 « InstanceSpecifier Resolution »). Cela constitue généralement une erreur de configuration.
• Instance de service manquante : si aucun OfferService() correspondant n'a été exécuté côté skeleton pour l'identifiant spécifié, le FindService fourni par ServiceHandleContainer reste vide (ARAComAPI p. 103 « Figure 6.5: Service Discovery »).