structure ara::com::FindServiceHandle

La structure ara::com::FindServiceHandle sert de jeton de contrôle unique pour commander une surveillance de service s'exécutant en arrière-plan (AUTOSAR_AP_EXP_ARAComAPI p. 34). Le constructeur par défaut étant supprimé ([SWS_CM_00353]), le handle est exclusivement créé par StartFindService et permet, après réception de rappels d'état asynchrones, d'arrêter de manière ciblée la recherche via StopFindService (AUTOSAR_AP_EXP_ARAComAPI p. 30). Les opérateurs de comparaison pris en charge garantissent en outre la gestion mémorisable de plusieurs requêtes de recherche dans des conteneurs standard ([SWS_CM_11526], [SWS_CM_11527]).

plus ›

Contexte

La structure ara::com::FindServiceHandle fait office, dans le module com de l'Adaptive Platform, d'identifiant unique et de jeton de contrôle pour une recherche de service asynchrone et continue. Tandis qu'une requête synchrone via FindService détermine ponctuellement les instances de service correspondantes et renvoie directement des conteneurs de handles, StartFindService initie une surveillance permanente de la disponibilité du service en arrière-plan (AUTOSAR_AP_EXP_ARAComAPI p. 34). L'instance d'application, la classe proxy spécifique au type (par exemple RadarServiceProxy) ainsi qu'une fonction de rappel personnalisée de type FindServiceHandler participent typiquement à ce processus (AUTOSAR_AP_EXP_ARAComAPI p. 30). La représentation interne concrète de ara::com::FindServiceHandle est conçue de manière spécifique à l'implémentation pour le Communication Management concerné, mais fournit des interfaces C++ standardisées pour la manipulation.

Cycle de vie

Le cycle de vie d'un ara::com::FindServiceHandle est étroitement couplé au processus de recherche actif dans le Communication Management :

• Création : le constructeur par défaut est explicitement supprimé ([SWS_CM_00353]). Une application ne peut donc pas créer d'instances de handle non initialisées ou de sa propre initiative. Au lieu de cela, un handle valide est généré exclusivement comme charge utile d'un ara::core::Result par la méthode statique StartFindService (AUTOSAR_AP_EXP_ARAComAPI p. 30).
• Gestion et possession : un handle prend en charge l'affectation via l'opérateur d'affectation par copie [SWS_CM_11528]. Afin de permettre à l'application de stocker et d'organiser plusieurs requêtes de recherche dans des conteneurs standard (tels que des ensembles ordonnés ou des conteneurs associatifs), le type satisfait les concepts C++ [equalitycomparable] et [lessthancomparable] via les opérateurs operator== ([SWS_CM_11526]) et operator< ([SWS_CM_11527]).
• Terminaison et destruction : le handle reste valide tant que la surveillance en arrière-plan est active. L'arrêt de la recherche s'effectue en transmettant le handle à StopFindService (AUTOSAR_AP_EXP_ARAComAPI p. 30, AUTOSAR_AP_EXP_ARAComAPI p. 34). Après cet appel, le handle ne représente plus aucun processus de recherche en cours.

Parcours d'utilisation

Le déroulement régulier comprend l'enregistrement de la requête de recherche, la réception continue des mises à jour de disponibilité et l'arrêt ordonné du processus de surveillance :

1. Démarrage de la recherche : l'application enregistre un FindServiceHandler via StartFindService afin d'être informée des instances de service nouvellement disponibles ou disparaissant (AUTOSAR_AP_EXP_ARAComAPI p. 30, AUTOSAR_AP_EXP_ARAComAPI p. 34).
2. Obtention du descripteur : en cas de démarrage réussi, l'appel renvoie un ara::core::Result avec le FindServiceHandle (AUTOSAR_AP_EXP_ARAComAPI p. 30), que l'application conserve pour de futurs appels de contrôle.
3. Notification asynchrone : le Communication Management exécute la recherche en arrière-plan et appelle le gestionnaire fourni lors des changements d'état (AUTOSAR_AP_EXP_ARAComAPI p. 34).
4. Arrêt de la recherche : dès que les instances ont été trouvées ou que la surveillance n'est plus nécessaire, l'application transmet le descripteur à StopFindService (AUTOSAR_AP_EXP_ARAComAPI p. 30, AUTOSAR_AP_EXP_ARAComAPI p. 34).

Diagramme de séquence : déroulement typique de la recherche asynchrone de services, de l'enregistrement jusqu'à l'arrêt via FindServiceHandle en passant par les notifications. Sources : AUTOSAR_AP_EXP_ARAComAPI p. 30, AUTOSAR_AP_EXP_ARAComAPI p. 34.

Scénarios d'erreur

Lors de l'utilisation de ara::com::FindServiceHandle, les contraintes spécifiques au système suivantes doivent être prises en compte :

• Échec du démarrage de la recherche : si les liaisons techniques ne sont pas disponibles ou si la configuration de déploiement du service est incorrecte (AUTOSAR_AP_EXP_ARAComAPI p. 34), StartFindService échoue. Dans ce cas, le ara::core::Result renvoyé ne contient pas de descripteur valide, mais un code d'erreur (AUTOSAR_AP_EXP_ARAComAPI p. 30).
• Sécurité vis-à-vis des exceptions : les opérateurs de comparaison et d'affectation implémentés operator== ([SWS_CM_11526]), operator< ([SWS_CM_11527]) et operator= ([SWS_CM_11528]) sont explicitement déclarés dans la spécification comme n'étant pas sûrs vis-à-vis des exceptions (not exception safe).
• Arrêt multiple : un appel répété de StopFindService avec le même descripteur devrait probablement rester sans effet ou entraîner une erreur d'exécution, car l'activité de surveillance sous-jacente a déjà été supprimée. Question Q-f44130c33fa1caea (ouverte)