namespace <SI-Namespace>::proxy

Le namespace <SI-Namespace>::proxy fournit, au sein du module com, l’interface côté client pour interagir avec une ServiceInterface. Son composant central est la classe proxy <SI>Proxy, qui abstrait la communication du middleware et permet les appels de méthodes ainsi que les abonnements aux événements. L’instanciation du proxy devrait typiquement nécessiter un handle valide issu de la recherche de service. Question (ouverte) Comme contrainte essentielle, l’application appelante doit gérer de manière robuste les interruptions de connexion et les temps de réponse asynchrones lors des appels distants.

plus ›

Contexte

Le namespace <SI-Namespace>::proxy constitue, au sein du module de communication com de l’AUTOSAR Adaptive Platform, la représentation côté client d’une ServiceInterface. Il regroupe l’ensemble des artefacts et des types nécessaires aux consommateurs de service pour interagir avec un service proposé sur le réseau de communication. Au cœur de cet espace de noms se trouve la classe proxy générée <SI>Proxy. Cette classe abstrait la configuration interprocessus et réseau sous-jacente basée sur des messages et fournit une interface C++ par laquelle le logiciel applicatif peut appeler des méthodes, s’abonner à des événements, ainsi qu’interroger et observer des champs.

D’un point de vue architectural, le proxy sert d’intermédiaire entre la logique client spécifique à l’application et l’environnement d’exécution de l’Adaptive Platform. Au lieu d’interagir directement avec le réseau ou la mémoire partagée, le développeur d’applications interagit exclusivement avec les instances issues de <SI-Namespace>::proxy. Un découplage est ainsi réalisé, permettant de laisser le middleware sous-jacent de la plateforme gérer de manière transparente les protocoles de communication, les formats de transfert de données et les détails de localisation.

Cycle de vie

Le cycle de vie des objets dans le namespace <SI-Namespace>::proxy est étroitement lié à la disponibilité de l’instance de service correspondante. Avant qu’une instance de proxy puisse être créée, une découverte d’instance doit avoir lieu. L’instanciation du proxy <SI>Proxy devrait typiquement exiger un handle résultant de la recherche de service. Question Q-3dcfd734b218f865 (ouverte) Après une instanciation réussie, l’objet proxy représente une connexion logique vers le fournisseur de service respectif.

Pendant la phase de fonctionnement actif, l’instance de proxy gère les états relatifs aux événements abonnés et aux appels de méthodes asynchrones en attente. Concernant la concurrence, il convient de noter que les appels au proxy doivent être conçus pour être thread-safe ou doivent être synchronisés en conséquence par le client si plusieurs threads utilisent le même objet proxy. La libération ou la destruction de l’objet proxy devrait mettre fin à la liaison avec l’instance de service trouvée et résilier les abonnements en cours. Question Q-e9d55205ba1bf55b (ouverte)

Parcours d'utilisation

Un chemin d’utilisation typique pour l’emploi du proxy de ServiceInterface se divise en plusieurs phases successives :

• Découverte de l’instance de service : le client initialise une recherche des instances disponibles du service via les mécanismes de plateforme du module com et reçoit en retour les structures de handle correspondantes.
• Construction du proxy : en utilisant un handle valide, une instance de <SI>Proxy est instanciée, établissant ainsi le canal de communication vers le serveur.
• Interaction avec les éléments de service : via l’instance, des méthodes sont appelées de manière synchrone ou asynchrone, des événements sont abonnés et des rappels sont enregistrés. Les modèles de communication asynchrones devraient probablement être représentés par des wrappers typés d’événements et de méthodes au sein de l’instance de proxy. Question Q-2e6b91c7e5f88567 (ouverte)
• Clôture et nettoyage : une fois la communication terminée, les abonnements aux événements sont résiliés et l’instance de proxy est détruite en bonne et due forme afin de libérer les ressources occupées.

Scénarios d'erreur

Lors de l’interaction avec l’espace de noms du proxy, différents schémas d’erreur peuvent survenir. Parmi ceux-ci figurent les coupures de connexion vers le serveur, les timeouts lors des appels distants ainsi que l’indisponibilité des instances de service demandées pendant l’initialisation. La communication s’effectuant au-delà des frontières de processus et de calculateurs, les erreurs d’infrastructure ou les défaillances de l’interlocuteur se reflètent dans les valeurs de retour. Les appels avant une liaison réussie ou après la destruction de l’instance conduisent à des états invalides, raison pour laquelle les préconditions relatives à la validité du handle doivent être strictement respectées.

Le namespace <SI-Namespace>::proxy fournit les structures côté client, notamment la classe <SI>Proxy, permettant aux applications de consommer les services définis par l'interface <SI> dans AUTOSAR Adaptive (module com, R25-11). Interprétation : Il prend en charge l'instanciation locale à partir d'un descripteur de service ainsi que l'invocation des méthodes et la gestion des événements distants. Question (ouverte) En contrepartie, le consommateur doit obligatoirement obtenir un descripteur d'instance valide avant toute instanciation et veiller à la libération des ressources associées au terme de l'utilisation.

plus ›

Contexte et responsabilités

Le namespace <SI-Namespace>::proxy regroupe les types et classes générés côté client pour permettre la consommation d'une interface de service <SI> dans le module com d'AUTOSAR Adaptive (plateforme adaptive, version R25-11). Au sein de cette organisation logicielle, la classe <SI>Proxy constitue l'entité centrale mise à la disposition des applications consommatrices.

Interprétation : La classe <SI>Proxy agit comme un mandataire typé qui encapsule l'ensemble des mécanismes de communication inter-processus et réseau requis pour interagir avec une instance distante fournissant l'interface <SI>. Question (ouverte) Elle masque ainsi aux composants applicatifs la complexité des couches de transport sous-jacentes et la sérialisation des messages.

Cycle de vie

La gestion d'une instance de proxy s'inscrit dans le cadre global de la découverte et de l'accès aux services. Selon toute vraisemblance, le cycle de vie d'une instance de <SI>Proxy est directement conditionné par la disponibilité de l'instance de service découverte sur la plateforme Adaptive.

L'initialisation d'un objet <SI>Proxy requiert un descripteur d'instance valide, préalablement obtenu par le mécanisme de résolution de service d'AUTOSAR Adaptive. Une fois l'objet construit, le client peut solliciter les fonctionnalités du service. Le consommateur assure la propriété de l'instance locale du proxy ; sa destruction à la fin des opérations entraîne la libération ordonnée des ressources allouées, la rupture de la session de communication et l'interruption automatique de tout abonnement aux événements rattaché à cette instance.

Chemin d'utilisation

Il est à présumer que le chemin d'utilisation standard suit une séquence stricte : résolution du descripteur de service, instanciation locale du proxy, puis invocation synchrone ou asynchrone des fonctionnalités du service.

Le flux d'interaction débute par l'acquisition d'un handle auprès de la couche de gestion de service. L'application consommatrice crée ensuite l'instance de <SI>Proxy en lui transmettant ce handle. Par l'intermédiaire de cette instance, l'application peut déclencher des invocations de méthodes distantes, s'abonner aux événements publiés par le service ou consulter l'état des champs de données.

Diagramme de séquence : Déroulement type de l'utilisation d'un proxy de service entre le client, l'instance locale <SI>Proxy et l'infrastructure de communication. Sources : aucune (interprétation architecturale).

Gestion des erreurs

L'utilisation des éléments du namespace <SI-Namespace>::proxy expose l'application à différents contextes de défaillance inhérents aux systèmes distribués. Lors de la phase de création, la fourniture d'un descripteur expiré ou invalide empêche l'établissement de la liaison de service. Pendant la phase opérationnelle, des ruptures de connectivité, des indisponibilités temporaires du fournisseur ou des dépassements de délai de garde peuvent interrompre l'exécution des requêtes. Les applications doivent systématiquement traiter les valeurs de retour et les structures d'erreur émises par le proxy pour maintenir la robustesse du système.