Dépôt des schémas d’interactions

Les modèles d’architectures distribuées proposant des mécanismes de découverte dynamique de nouveaux services (CORBA, Java RMI, .Net framework par exemples) offrent un mécanisme de dépot des services distribués (service repository) sous la forme de méta-informations. Par exemple en CORBA, le modèle Object Management Architecture (OMA) définit le concept de dépôt d’interfaces (Interface Repository) permettant de déposer dans une « base de données » un ensemble de méta-informations concernant les interfaces des objets distribués présents sur le bus CORBA. Ainsi une représentation objet du code IDL est stockée dans une base de données accessible à partir du bus réseau (l’ORB).

Ainsi, les schémas d’interactions étant des interfaces, ils disposent d’une représentation, disponible à l’exécution, dans ce dépôt d’interfaces. Cependant cette représentation est incomplète puisque les comportements réactifs, étant des données statiques (similaires aux variables de classes), ne peuvent être représentées en IDL. En fait le dépôt d’interfaces offre les mécanismes nécessaires pour parcourir le graphe des interfaces IDL, mais n’offre aucun support au parcours du graphe des comportements réactifs définis dans un schéma d’interactions. Pour ce faire, le modèle à interactions distribuées inclut un mécanisme de dépot de schémas d’interactions et rend ce dépot de schémas d’interactions accessible à distance via le bus réseau.

Ainsi, un dépôt de schémas d’interactions (Interaction Scheme Repository, ISR) est un service qui fournit une représentation objet des informations d’un code écrit en ISL concernant les schémas d’in-teractions sous la forme de « méta-descriptions » disponibles lors de l’exécution des applications. Les informations du dépôt de schémas d’interactions peuvent être utilisées par le modèle à interactions pour vérifier, par exemple, la validité d’une pose d’un schéma d’interactions sur un ensemble d’objets.

De plus, grâce aux informations contenues dans le dépôt de schémas d’interactions, une application peut découvrir un schéma d’interactions qui n’était pas connu lors de la compilation et être en mesure de déterminer quelles sont ses caractéristiques (et notamment le type des objets sur lesquels peut être posé le schéma d’interactions). Ainsi un dépôt de schémas d’interactions est une représentation, sous la forme de « méta-informations », de schémas d’interactions définis à l’aide d’un code source ISL. Afin

de répondre parfaitement au caractère dynamique des interactions, les informations contenues dans un dépôt de schémas d’interactions peuvent être modifiées à l’exécution. De plus, le pouvoir d’expression du dépôt de schémas d’interactions est le même que celui du langage ISL.

8.5.1 Rôle du dépôt de schémas d’interactions

Un dépot de schémas d’interactions fournit un ensemble de fonctions pour interroger, stocker ou détruire les méta-descriptions ISL. Il est en tous points similaire au dépôt d’interfaces (Interface Repo-sitory) de CORBA. Il permet la manipulation de toute information ISL à partir de n’importe quel site distant (un navigateur est présenté dans la partie IV de ce mémoire de thèse).

À l’instar des butineurs des environnements de programmation, on peut consulter, ajouter ou suppri-mer les schémas d’interactions du dépôt de schémas d’interactions. Une fois l’information stabilisée, le source ISL peut être reconstuit directement à partir des méta-informations contenues dans un dépôt de schémas d’interactions.

Les mécanismes du modèle à interactions peuvent utiliser les définitions des schémas d’interactions maintenues par un dépôt de schémas d’interactions pour (la figure 8.14 montre des utilisations possibles du dépot de schémas d’interactions) :

– Vérifier une hiérarchie de schémas d’interactions : le mécanisme du modèle à interactions en charge de l’ajout et de la suppression d’un schéma d’interactions dans le système peut vérifier la conformité du graphe d’héritage. Il peut ainsi vérifier que, lors de l’ajout, tous les schémas d’interactions dont dérive un schéma d’interactions sont bien présents dans le dépôt et que, lors de la suppression, aucun schéma d’interactions n’hérite du schéma d’interactions qui doit être supprimé.

– Vérifier les droits d’accès à un schéma d’interactions : le dépôt de schémas d’interactions peut vérifier que l’opération demandée par une application est autorisée (notion de sécurité).

I.S.L. I.S.L.

générateur instanciation des

schémas d'interactions Parcours du graphe des

schémas d'interactions

Applications du système

Dépôt de schémas d'interactions

compilateur

FIG. 8.14 –Utilisations possibles du dépôt de schémas d’interactions

Les définitions des schémas d’interactions maintenues par le dépôt de schémas d’interactions étant publiques, ces définitions peuvent aussi être utilisées par les clients et d’autres services. Par exemple, le dépôt de schémas d’interactions peut servir à :

– Administrer les schémas d’interactions :

Le client peut gérer l’installation et la distribution des schémas d’interactions à travers le réseau. – Construire des outils :

Le dépôt de schémas d’interactions fournit des méta-informations permettant de construire des outils de style CASE comme, par exemple, des butineurs (browsers) de schémas d’interactions, des compilateurs ISL, etc.

Le dépôt de schémas d’interactions joue un rôle majeur dans cette architecture distribuée, tout comme le dépôt d’interfaces de CORBA pour l’ORB. En effet, c’est lui qui rend accessible aux

ap-plications les informations sur les schémas d’interactions à l’exécution, informations indépendantes de tout langage.

Des opérations sont définies permettant de manipuler le contenu du dépôt de schémas d’interactions. D’autres opérations permettent d’extraire un ensemble d’informations décrivant dans leur intégralité un schéma d’interactions ou une règle d’interaction.

Un dépôt de schémas d’interactions offre une notion de droit d’accès aux différentes opérations possibles sur les schémas d’interactions. En effet, un schéma d’interactions ne doit pas nécessairement pouvoir être détruit par n’importe quel utilisateur dans le système. De même, un butineur, qui surveille-rait l’état du dépôt de schémas d’interactions par le biais d’interactions posées entre les objets du dépôt de schémas d’interactions et ceux du butineur, peut vouloir interdire aux autres applications de modifier ou supprimer les descriptions des schémas d’interactions et des interactions qu’il a définis.

Le modèle à interactions distribuées définit deux classes d’utilisation, chaque classe ayant des droits d’accès par défauts différents. Le choix de la classe d’utilisation par une application est réalisée lors de sa connexion au dépôt de schémas d’interactions.

Les droits d’accès en fonction de la classe d’utilisation sont les suivants : – La classe utilisateur :

L’application qui enregistre un schéma d’interactions sera la seule à pouvoir modifier ou sup-primer les méta-informations du schéma d’interactions dans le dépôt de schémas d’interactions, mais toute application du système sera en mesure d’accéder en lecture au schéma d’interactions et de l’instancier. De plus, lorsque l’application cessera d’exister dans le système, tous les schémas d’interactions (et indirectement les interactions instances de ces schémas d’interactions) définis par cette application avec l’accès utilisateur seront automatiquement supprimés du dépôt de sché-mas d’interactions.

– La classe administrateur :

L’application qui enregistre le schéma d’interactions va partager, aussi bien en lecture qu’en écri-ture, les méta-informations du schéma d’interactions avec toutes les applications du système. De plus, sauf pour le cas décrit ci-après, les méta-informations du schéma d’interactions ne seront pas automatiquement enlevées du dépôt de schémas d’interactions, ni toutes les interactions instances de ce schéma d’interactions détruites, lorsque l’application cessera d’exister dans le système. Il est à noter, cependant, qu’un schéma d’interactions définissant sa propre classe et enregistré avec les droits d’accès administrateur sera automatiquement supprimé du dépôt de schémas d’in-teractions lorsque l’application qui l’a défini cessera d’exister dans le système.

8.5.2 Nommage des schémas d’interactions dans un dépôt de schémas

d’interactions

Les schémas d’interactions étant des classes, ils disposent d’un nom permettant de les désigner. Le modèle à objets impose que chaque classe (et par conséquent chaque schéma d’interactions) dispose d’un nom qui lui soit propre et qui soit différent des noms des autres classes du système. Par conséquent, le nom d’un schéma d’interactions permet d’identifier sans ambiguïté ce dernier. A priori, le dépôt de schémas d’interactions peut donc utiliser le nom des schémas d’interactions comme clef primaire pour permettre l’accès aux méta-informations des schémas d’interactions.

Cependant, un nom de classe est défini par rapport à un espace de nommage donné. Cet espace de nommage participe à la résolution du nom complet de la classe (qui doit lui aussi être unique). Ainsi, dans deux espaces de nommages différents, deux classes peuvent avoir le même nom « relatif ».

Par conséquent, le modèle à interactions distribuées doit prendre en compte ce concept d’espace de nommage pour éviter d’avoir deux schémas d’interactions possèdant le même nom (dans deux espaces de nommages différents). Ainsi, le modèle à interactions distribuées va représenter, dans le dépôt de schémas d’interactions, les différents espaces de nommages par la notion de dossier : une arborescence hiérarchique de dossier est donc mise en place dans le dépôt de schémas d’interactions.

8.6 Conclusion

Dans ce chapitre, nous avons présenté, de manière détaillée, une description structurelle et fonction-nelle de la projection de l’architecture du modèle à interactions distribuées dans un langage tel que C++ ou Java. Cette projection est basée sur la définition d’un noyau de sept classes (dont quatre métaclasses).

Nous avons présenté les relations entre les comportements de ces différentes classes par le biais d’al-gorithmes. Nous avons également détaillé le fonctionnement des comportements réactifs et notamment précisé qu’ils étaient les responsables de la fusion comportementale.

Cette description structurelle et fonctionnelle a été validée lors de la mise en œuvre du modèle à interactions distribuées à la fois en C++ / CORBA(que nous décrivons de manière détaillée dans les deux chapitres suivants) et en Java.

Chapitre 9

Mise en œuvre en C++ et

CORBA : utilisation de

schémas de conception

« The design patterns require neither unusual language features nor amazing program-ming tricks [...]. All can be implemented in standard object-oriented languages, though they might take a little more work than ad hoc solutions. But the extra effort invariably pays dividends in increased flexibility and reusability. » [GHJ+