Modélisation des systèmes temps-réel répartis embarqués pour la ...

Chapitre VI – Construction et configuration de l’interface avec l’intergiciel d’exécution
avec elle. Ainsi, un objet de liaison est un subrogé de l’entité réelle, qui prend en charge le transfert
des invocations.
Dans le cadre de PolyORB, lorsque la référence renvoie à une entité locale au nœud, l’objet
de liaison est l’entité encapsulant le code de l’utilisateur. Lorsque la référence pointe vers un
objet distant, l’objet de liaison regroupe l’ensemble des mécanismes permettant le dialogue avec
l’objet distant : pile protocolaire, fonction de représentation, connexion, etc. La fonction de liaison
nécessite alors plusieurs fabriques d’objets, et une fonction de choix sélectionner la fabrique
appropriée. Cette fonction de choix utilise des informations de configuration et de contexte pour
choisir un mécanisme.
Dans le cadre de la modélisation en AADL de l’intergiciel, le service de liaison permet d’orienter
les requêtes vers la couche applicative ou protocolaire adéquate, selon la référence transportée
par la requête. Afin de permettre la mise en place de politiques d’ordonnancement des requêtes,
il est nécessaire de découpler la réception des requêtes par le service de liaison de leur traitement
effectif. Pour cela, nous modélisons le service de liaison par trois composants principaux :
– un composant de donnée représentant une file d’attente ;
– un sous-programme prenant en charge l’insertion des requêtes dans la file d’attente ;
– un sous-programme extrayant les requêtes de la file pour les traiter.
Les dimensions de la file d’attente sont fixées à la construction de l’intergiciel, en fonction
du nombre d’entités à prendre en charge et de la politique d’ordonnancement. Le composant de
donnée AADL correspondant peut donc avoir la sémantique d’un tableau. Ce composant est partagé
entre les différents threads AADL du nœud local ; le service de liaison consiste en effet en un
aiguillage commun entre les différentes entités, c’est-à-dire entre les différents threads AADL.
Le sous-programme d’insertion prend une requête en paramètre et nécessite un accès à la file
d’attente afin de l’y insérer. Son implantation ne change pas d’une configuration d’intergiciel à
une autre.
L’implantation du sous-programme de traitement dépend en revanche de la configuration de
l’intergiciel. Le sous-programme possède autant de séquences d’appel que de personnalités définies
dans l’intergiciel. Il doit avoir un accès aux composants de donnée du service d’adressage,
afin de déterminer si la requête s’adresse à une entité locale ou non. Le code source de son implantation
extrait l’identité de l’entité destinataire de la requête, décide si l’entité est locale ou distante
et exécute la séquence d’appel correspondante.
Pour les requêtes qui sont orientées vers une personnalité protocolaire, le service de liaison
doit également fournir un modèle AADL du subrogé correspondant. Les subrogés sont des sousprogrammes
qui correspondent à chaque élément d’interface de l’entité AADL distante (c’est-àdire
du thread distant). Le subrogé coordonne les services de transport et de protocole.
Le listing VI.4 représente la définition des composants constituant le service de liaison. Nous
n’en présentons que les interfaces ; la définition exacte de ces composants doit être construite par
extension de ces composants de base, afin de préserver l’implantation du tampon et de composant
de donnée modélisant les requêtes.
1 package Ipao::Bind
2 public
3 data Buffer
4 properties
5 Language_Support::Data_Format => Array;
6 Language_Support::Data_Type => classifier (Ipao::Request);
7 end Buffer;
8
9 subprogram Add_Request
c○ 2007 Thomas Vergnaud 111