namespace <SI-Namespace>::proxy::methods

Le namespace <SI-Namespace>::proxy::methods fournit les classes côté proxy pour les appels de méthodes d’une ServiceInterface dans le module com de l’AUTOSAR Adaptive Platform. Pour chaque ClientServerOperation, selon l’attribut de métamodèle ClientServerOperation.fireAndForget, soit la classe <Method> pour les appels réguliers, soit <FnFMethod> pour les appels unidirectionnels est instanciée. Tandis que les méthodes régulières prennent en charge les valeurs de retour côté serveur et les messages d’erreur, les méthodes Fire-and-Forget ne traitent, par principe, aucun message de réponse. La durée de vie des objets de méthode devrait être alors directement liée à l’existence de l’instance de proxy de niveau supérieur. Question (ouverte)

plus ›

Contexte

L’espace de nommage <SI-Namespace>::proxy::methods représente, au sein du module com de l’AUTOSAR Adaptive Platform, les classes d’interface spécifiques aux méthodes pour les proxys de service. Chaque ClientServerOperation modélisé dans un ServiceInterface est mis en correspondance avec une classe de méthode correspondante en fonction de ses propriétés de configuration. L’espace de nommage contient pour l’essentiel deux modèles de classes : <Method> pour les opérations avec comportement de réponse et <FnFMethod> pour les opérations dites « fire-and-forget » .

La responsabilité principale de ces classes consiste à réceptionner les appels de méthode d’une application cliente, à préparer les paramètres de transmission pour le transport et à gérer la communication avec la couche middleware sous-jacente. Les partenaires d’interaction sont, du côté appelant, les composants clients spécifiques à l’application ainsi que, du côté médiation, la classe proxy de niveau supérieur de l’espace de nommage <SI-Namespace>::proxy, qui agrège les instances de méthode.

La différenciation entre les deux classes dépend de l’attribut de métamodèle ClientServerOperation.fireAndForget :

• <Method> est généré pour les opérations pour lesquelles ClientServerOperation.fireAndForget == FALSE est configuré. Vraisemblablement, une instance de cette classe encapsule l’appel asynchrone d’un service et met à disposition le résultat ou les éventuelles erreurs d’application par l’intermédiaire d’un type de résultat tourné vers l’avenir. Question Q-75c8a4495ee9c1cb (ouverte)
• <FnFMethod> est généré lorsque ClientServerOperation.fireAndForget == TRUE est configuré. Une méthode de cette classe devrait être implémentée sous la forme d’un appel unidirectionnel qui n’attend aucune réponse du serveur et ne fournit aucune valeur de retour à l’appelant. Question Q-1f9698a27137b73d (ouverte)

Cycle de vie

La création et la destruction des classes de méthode définies dans cet espace de nommage sont étroitement couplées au proxy de niveau supérieur. La durée de vie des objets de méthode devrait être liée à la durée de vie de l’instance de proxy englobante dans l’espace de nommage <SI-Namespace>::proxy. Question Q-ec1ef4d1ebc90d5a (ouverte) Lors de l’instanciation de l’objet proxy, les instances associées de <Method> et <FnFMethod> sont initialisées en tant que membres et sont immédiatement mises à la disposition de l’application pour les appels.

En ce qui concerne l’état interne, les objets de méthode restent prêts pour les appels de manière permanente après leur initialisation, tant que l’instance de proxy demeure valide. Les transitions d’état des appels individuels ne concernent pas l’instance de méthode elle-même, mais les contextes d’appel individuels. En cas d’accès concurrents depuis plusieurs threads de l’application cliente, il convient de garantir que les appels parallèles d’une même instance de méthode puissent être initiés de manière sûre au niveau des threads. La destruction a lieu implicitement lors de la sortie de la portée ou lors de la destruction explicite de l’instance de proxy, les ressources de communication ouvertes étant alors libérées.

Parcours d'utilisation

Le déroulement typique lors de l’utilisation des classes de méthode par une application cliente suit une séquence définie :

1. Mise à disposition du proxy : l'application crée ou obtient une instance initialisée du proxy de service à partir de l'espace de noms <SI-Namespace>::proxy.
2. Accès aux méthodes : l'appel de l'opération souhaitée s'effectue via les membres de type méthode de l'instance de proxy, lesquels instancient les classes <Method> ou <FnFMethod>.
3. Exécution d'une opération régulière : lors de l'appel d'une instance de <Method>, le client transmet les paramètres d'entrée requis. L'appel déclenche la transmission vers le système cible. L'objet de retour permet à l'application d'attendre la réception du résultat ou de poursuivre son exécution de manière asynchrone.
4. Exécution d'une opération Fire-and-Forget : lors de l'appel d'une instance de <FnFMethod>, les paramètres sont transmis et immédiatement acheminés vers la couche de transport. La méthode retourne le contrôle à l'appelant directement après le transfert.
5. Traitement du résultat : lors d'appels de méthodes réguliers, le client évalue le résultat mis à disposition et vérifie si l'opération s'est achevée avec succès.

Scénarios d'erreur

Le traitement des erreurs diffère fondamentalement entre les deux types de méthodes : pour les opérations régulières via <Method>, des erreurs de la couche de transmission tout comme des erreurs d’application spécifiques définies dans la spécification d’interface peuvent survenir. Étant donné que ClientServerOperation.fireAndForget == FALSE est configuré, les messages de réponse, y compris les éventuels messages d’erreur, sont renvoyés par le serveur au proxy. L’application cliente peut évaluer ces erreurs via l’objet de retour de l’appel et engager des routines de traitement appropriées.

En revanche, la conception de <FnFMethod> par ClientServerOperation.fireAndForget == TRUE exclut par principe tout renvoi d’erreur côté serveur vers l’appelant. Les erreurs qui se produisent sur le serveur pendant le traitement de l’opération ne peuvent pas être transmises au proxy. Les préconditions et postconditions se limitent au côté appelant local : les préconditions exigent des valeurs de paramètres valides et une infrastructure de communication prête à l’emploi. Si une erreur locale survient lors de l’envoi, celle-ci peut être immédiatement signalée lors de l’appel de méthode, tandis que les erreurs d’exécution côté serveur passent inaperçues pour l’appelant.