namespace <SI-Namespace>::skeleton

L’espace de nommage <SI-Namespace>::skeleton encapsule, dans le module com de l’AUTOSAR Adaptive Platform (version R25-11), la couche de médiation côté serveur pour les interfaces de service par l’intermédiaire de la classe <SI>Skeleton. Il sert à transmettre les appels de méthode entrants à la logique métier spécifique à l’application ainsi qu’à acheminer les événements et les champs vers les clients connectés. L’application serveur instancie le squelette, propose le service via la plateforme et met fin à l’offre avant la destruction de l’objet. La communication s’effectuant vraisemblablement de façon concurrente, les appels de méthode mis à disposition doivent être implémentés de manière sûre au niveau des threads. Question (ouverte)

plus ›

Contexte

L’espace de nommage <SI-Namespace>::skeleton constitue, au sein du module de communication com de l’AUTOSAR Adaptive Platform (version R25-11), l’espace de nommage standardisé pour les composants de service côté serveur. Au cœur de cet espace de nommage se trouve la classe squelette de service <SI>Skeleton, qui représente la couche de médiation entre l’implémentation spécifique à l’application d’un fournisseur de service et le middleware de communication sous-jacent. L’identifiant <SI> fait office de caractère générique pour le nom concret de l’interface de service, tandis que <SI-Namespace> reflète l’espace de nommage défini par configuration de la définition d’interface.

La responsabilité première de l’espace de nommage réside dans la mise à disposition de structures sûres du point de vue des types pour le traitement côté serveur de la communication orientée services. Les partenaires d’interaction essentiels sont ici l’application de service elle-même ainsi que le middleware de la plateforme. La classe <SI>Skeleton sert vraisemblablement de classe de base pour l’implémentation spécifique à l’application du fournisseur de service, dont hérite l’application de service ou qu’elle instancie afin de recevoir les appels de méthode et de mettre à disposition des événements. Question Q-d43c51f8b475898f (ouverte)

Cycle de vie

Le cycle de vie des composants de l’espace de nommage s’articule autour de la mise à disposition et de l’exploitation de la classe <SI>Skeleton. Une instance du squelette de service représente la présence active d’un service sur une instance de l’Adaptive Platform. La création et la configuration de l’objet incombent à l’application fournissant le service, qui associe l’instance à un identifiant de service et d’instance concret.

Le cycle de vie de l’instance de squelette devrait être couplé à la mise à disposition du service, l’instance devant être entièrement initialisée avant d’être activement proposée et ne devant être détruite qu’après l’arrêt en bonne et due forme de l’offre de service. Question Q-de1059259cadf8ee (ouverte) Durant la phase d’exploitation, le squelette prend en charge la répartition des requêtes entrantes vers les corps de méthode enregistrés ainsi que la gestion des événements sortants.

Concernant le modèle d’exécution, il convient de prendre en compte le fait que les appels proviennent du réseau. La communication entre le squelette et le middleware devrait s’effectuer de manière asynchrone et concurrente, de sorte que les appels de méthode et l’envoi d’événements doivent être gérés de manière sûre au niveau des threads. Question Q-3ff7109db2f3f381 (ouverte) Lors de la désactivation du service, l’application veille à une interruption ordonnée de la communication avant que l’objet <SI>Skeleton ne soit détruit.

Parcours d'utilisation

Le déroulement typique de l’utilisation de l’espace de nommage se divise en phases d’implémentation, de mise à disposition, de communication et de désinitialisation. Dans un premier temps, le développeur concrétise la logique d’interface requise en implémentant une classe spécifique à l’application sur la base de <SI>Skeleton. Au sein de cette classe, les méthodes spécifiées dans l’interface de service sont dotées de la logique métier concrète.

Au moment de l’exécution, l’application de service instancie l’objet squelette dérivé et le rend disponible pour la plateforme. Après cette mise à disposition, l’instance de squelette reçoit les requêtes des clients connectés, les transmet aux méthodes implémentées et renvoie les valeurs de retour au middleware. Parallèlement, l’application peut utiliser le squelette pour publier des événements ou des mises à jour de champs à destination des clients de service abonnés. Une fois l’exploitation terminée, le service est désenregistré et l’instance de <SI>Skeleton est libérée.