classe <SI-Namespace>::proxy::methods::<Method>

La classe de méthode proxy <SI-Namespace>::proxy::methods::<Method> permet aux applications clientes d'exécuter des appels de méthode avec valeur de retour pour les opérations client-serveur définies dans ServiceInterface [SWS_CM_00196]. L'appel s'effectue de manière non bloquante via operator(), qui renvoie immédiatement un ara::core::Future pour une interrogation flexible, synchrone ou asynchrone, du résultat [SWS_CM_00196]. De plus, GetE2EStateMachineState() permet de lire l'état de protection de la machine d'état End-to-End associée [SWS_CM_00148]. Les opérations étant spécifiées comme étant sûres vis-à-vis des exceptions, les erreurs de transmission et d'exécution sont signalées via Future avec des codes d'erreur standardisés.

plus ›

Contexte

La classe <SI-Namespace>::proxy::methods::<Method> constitue l'interface côté client pour les appels de méthode synchrones et asynchrones au sein de la gestion de la communication AUTOSAR Adaptive. Pour chaque opération client-serveur déclarée dans ServiceInterface pour laquelle l'attribut ClientServerOperation.fireAndForget == FALSE est configuré, le framework de communication génère précisément une classe de méthode proxy propre dans le rôle d'une méthode. La classe est déclarée comme final et incluse via l'en-tête #include "<SiNamespaceDerivedDirectoryPath>/<SiShortname>_proxy.h" SWS Communication Management, p. 39. L'application cliente appelante ainsi que le Network Binding, qui transmet le transfert de la méthode à l'instance de service distante et reçoit sa réponse [SWS_CM_00196], agissent comme partenaires d'interaction directs. La méthode proxy reçoit les paramètres d'appel et encapsule le déroulement asynchrone au moyen d'un objet ara::core::Future via lequel le client interroge l'achèvement et le résultat de l'appel.

Cycle de vie

L'instanciation de <SI-Namespace>::proxy::methods::<Method> s'effectue conjointement avec le service proxy parent. Interprétation : la classe de méthode devrait être instanciée et détruite conjointement avec l'objet proxy généré en tant que partie intégrante de celui-ci, raison pour laquelle l'utilisateur n'alloue pas l'instance séparément. Question Q-546c9b1bceedef6b (ouverte) Concernant la concurrence, l'appel de méthode via operator() est conçu pour être non bloquant ; la fonction initie la transmission et retourne immédiatement à l'appelant [SWS_CM_00196]. Un état central de l'instance réside dans la protection par des mécanismes End-to-End (E2E). L'application peut déterminer l'état actuel de la machine d'état spécifique à la méthode (ara::com::e2e::SMState) via la méthode GetE2EStateMachineState() [SWS_CM_00148]. Cet état est déterminé par la fonction de vérification interne E2E_Check(), qui est exécutée pendant le traitement du dernier appel de operator() [SWS_CM_00148], SWS Communication Management, p. 55. Interprétation : la mise à jour de l'état de la machine d'état E2E devrait devenir effective de manière asynchrone avec l'arrivée et la vérification du message de réponse. Question Q-283a9927420e2952 (ouverte)

Parcours d'utilisation

L'ordre d'appel typique comprend l'initiation de l'appel de méthode, la synchronisation sur le résultat ainsi que le contrôle d'intégrité subséquent :

1. Déclencher l'appel : l'application cliente appelle l'objet fonction via operator() avec les paramètres d'entrée déclarés [SWS_CM_00196], [SWS_CM_00191].
2. Retour immédiat : l'appel ne bloque pas le thread demandeur, mais renvoie immédiatement un objet de type ara::core::Future<Output> [SWS_CM_00196].
3. Interrogation du résultat : l'appelant décide de manière autonome d'une attente synchrone (par exemple via l'objet Future) ou d'une surveillance asynchrone de l'achèvement de l'appel [SWS_CM_00196]. En cas d'achèvement avec succès, Future fournit l'objet Output contenant les valeurs de réponse [SWS_CM_00196], [SWS_CM_99333].
4. Vérifier l'état de protection E2E : après l'achèvement de l'appel, l'application peut interroger l'état de la machine d'état E2E via GetE2EStateMachineState() afin de garantir la validité de la transmission de données [SWS_CM_00148].

Diagramme de séquence : déroulement typique d'un appel de méthode avec retour asynchrone via Future et interrogation subséquente de l'état E2E. Sources : [SWS_CM_00196], [SWS_CM_00148].

Scénarios d'erreur

Les opérations operator() et GetE2EStateMachineState() sont spécifiées comme étant sûres vis-à-vis des exceptions (exception safe) et sont déclarées avec noexcept [SWS_CM_00148], [SWS_CM_00196]. Les erreurs de communication et de mise à disposition ne sont donc pas signalées par des exceptions C++, mais transportées via l'objet ara::core::Future résultant, qui encapsule en cas d'erreur un ara::core::FutureErrc correspondant ou des codes d'erreur [SWS_CM_00196]. Les causes d'erreur spécifiées comprennent notamment :

• CommunicationFailure : le Network Binding signale une erreur de communication récupérable ou l'échec d'une connexion sécurisée ; en cas de dépassement de délai de communication, cela peut conduire à un état incertain sur le serveur distant [SWS_CM_00196].
• ComErrc::kServiceNotAvailable : l'instance de service n'est plus accessible après avoir été mise à disposition [SWS_CM_00196].
• ComErrc::kUnknownApplicationError : un service distant signale une erreur d'application non configurée [SWS_CM_00196].
• ComE2EErrc::kUnspecifiedE2EError : le service distant signale une erreur End-to-End non spécifiée [SWS_CM_00196].
• ComErrc::kMinimumSendIntervalViolationError : la demande d'appel a été effectuée plus rapidement que ne l'autorise l'intervalle d'émission minimal minimumSendInterval configuré pour l'élément d'interface [SWS_CM_00196].
• Violation de droits (InsufficientPermissionsViolation) : si l'appelant ne dispose pas des autorisations requises, l'exécution est refusée par le Grant Enforcement [SWS_CM_00196].

Des sémantiques de retour arrière (rollback_semantics) sont définies conformément à la spécification pour ces erreurs applicatives et de communication [SWS_CM_00196].