Interface de description du dépôt de schémas d’interactions

La fonctioncreateFolderrenvoie un nouveau dossier vide. Si un dossier du même nom existe déjà l’exception CANNOT_PROCEED est déclenchée avec nameAlreadyExist comme raison. Le dossier pourra être rempli grâce à certaines fonctions définies dans l’interfaceFolder(décrite ci-après) ou grâce à la fonction Contained::move.

9.4.4 Interface de description des dossiers

Folderest une interface qui fournit les opérations nécessaires à la gestion des objets de dépôt repré-sentants les dossiers. Un dossier peut contenir d’autres dossiers et des schémas d’interactions. Héritant des interfacesRepositoryetContained, un objet de dépôt représentant un dossier peut être utilisé pour na-viguer à travers l’arborescence hiérarchique des dossiers ainsi que pour rechercher les objets de dépôts représentant les schémas d’interactions définis dans le dossier (ou l’un de ses sous-dossiers). L’interface Folderest présentée par la figure 9.14.

La fonctionschemesContentsrenvoie la liste des objets de type schéma d’interactions contenus dans le dossier. Elle est équivalente à l’appel de la fonction contentsavec la valeurisrInteractionSchemepour le paramètrelimitKindetTRUEpour le paramètreexclureInherited. La fonctionschemesDescribeContentsest la restriction de la fonctionContainer::describeContentssur les objets de dépôt de typeisrInteractionScheme.

La fonctioncreateScheme renvoie un nouveau schéma d’interactions vide. Si un schéma d’interac-tions du même nom existe déjà l’exception CANNOT_PROCEED est déclenchée avec nameAlreadyExistcomme raison. Les méta-informations du schéma d’interactions nouvellement créé pourront être remplies grâce à certaines fonctions définies dans l’interfaceInteractionSchemeou grâce à la fonctionContained::move. La coucou

1: module CosInteraction 2: {

3: interface Folder : Repository, Contained

4: {

5: // read interface

6: ContainedSeq schemesContents ();

7: DescriptionSeq schemesDescribeContents (in long maxItems); 8:

9: // write interface

10: InteractionScheme createScheme (in Identifier name) raises (CANNOT_PROCEED); 11: InteractionScheme duplicateScheme (in Identifier name, in InteractionScheme scheme)

raises (CANNOT_PROCEED); 12: }; 13: 14: struct FolderDescription 15: { 16: Identifier name; 17: Login owner; 18: }; 19: };

fonctionduplicateSchemeest similaire à la précédente mais les méta-informations du schéma d’interac-tions créé sont remplies avec celles de l’objet de dépôt du schéma d’interacd’interac-tions fourni en paramètre.

L’appel de la fonctiondescribe, héritée de l’interfaceContained, sur un objet de dépôt représentant un dossier retourne un objet de typeFolderDescriptiondans le champvaluede la structureDescription.

9.4.5 Interfaces de description des opérateurs réactifs

Chaque comportement réactif dispose de sa propre interface pour décrire ses méta-informations dans le dépôt de schémas d’interactions. À l’opposé des interfaces des dossiers ou des schémas d’interac-tions qui définissent une structure de contenant / contenu, un comportement réactif définit une structure d’arbre (celui de la syntaxe abstraite). Ainsi, une interface de base à tous les comportements réactifs a été définie.

Celle-ci offre à toutes les interfaces des comportements réactifs les deux fonctions suivantes : – la fonctiondescriberenvoie une structure contenant les méta-informations stockées par l’objet de

dépôt. La description exacte de la structure associée à chaque type d’objet de dépôt est fournit ci-dessous lors de la définition réelle de l’interface de l’objet de dépôt. Le champ opKindde la structure Description retournée fourni le type de l’objet le plus approprié vis-à-vis des énumé-rations définies dans OperationKind et le champvalue contient, sous la forme d’un objet any, les méta-informations décrites par le type de l’objet de dépôt.

– la fonctionduplicaterenvoie une copie de l’objet de dépôt. Le type réellement retourné par cette fonction est celui de l’objet sur lequel a été appliquée la fonction (c’est-à-dire une interface héri-tant de l’interfaceOperation).

Les IDL des schémas d’interactions et des comportements réactifs sont directement déduites de la syntaxe abstraite d’ISL et sont décrites en annexe A.

9.5 Propositions partiellement mises en œuvres

L’architecture du modèle à interactions distribuées présentée dans le chapitre précédent propose une projection complète du modèle défini dans les chapitres 5 et 6 en tenant compte de toutes les contraintes imposées par les langages cibles (C++ et Java notamment). Cependant, lors de notre mise en œuvre, nous avons délaissé certaines propositions afin de nous focaliser sur d’autres propositions nous paraissant plus essentielles.

9.5.1 Gestion du typage

Du fait que l’on se projette dans un langage compilé fortement typé, la vérification du typage (afin de s’assurer de la cohérence des envois de messages à l’exécution) est une propriété réalisée par le compilateur lors de la compilation. Les comportements réactifs doivent, eux aussi, être soumis à cette vérification. Or, à ce moment du développement, les interactions, et donc les comportements réactifs, n’existent pas encore. La vérification du typage des messages contenus dans les comportements réactifs doit donc être réalisée dynamiquement et ne peut, par conséquent, être déléguée au langage lui-même. De plus, cette vérification devrait être personnalisable afin de permettre, par exemple, la définition de méthodes de délégation (les méthodes contrôlées n’existent pas à priori dans l’interface des objets).

Ainsi, cette vérification est réalisée lors de l’instanciation d’un schéma d’interactions. Il est à no-ter que, sous certaines conditions, elle pourrait être réalisée au moment de la définition des schémas d’interactions. Dans ces deux cas, cela implique une introspection de l’application (pouvoir connaître à l’exécution l’ensemble des méthodes définies sur un objet) ou du dépôt d’interfaces (afin de connaître ses opérations publiques).

Cette mise en place d’une gestion du typage implique de distinguer trois vérifications distinctes : 1. La vérification de l’existence des messages déclencheurs dans les classes des objets liés 2. La vérification que les messages contenus dans la réaction existent sur les objets.

3. La vérification que les types des participants d’un schéma d’interactions soient compatibles (au niveau du typage du langage) avec ceux déclarés lors de la définition du schéma d’interactions. Dans le cas du langage C++ ceci signifie que chaque participant est du type déclaré dans le schéma d’interations, soit d’un type dérivé (par héritage).

Ainsi, soit lors de l’instanciation de l’interaction, soit lors de l’activation d’une interaction par la méthodeactivate, il est nécessaire de réaliser cette vérification du typage.

A priori, et à condition de disposer d’un mécanisme d’introspection sur la structure des objets (et plus spécifiquement de la liste des méthodes définies sur un objet), les vérifications concernant la cohé-rence des interactions ne posent pas de problème particulier et peuvent être réalisées lors de la définition d’un schéma d’interactions (introspection sur les classes) ou lors de l’instanciation d’un schéma d’in-teractions (introspection sur les objets participants).

Malheureusement, certains des langages cibles (tel que C++ par exemple) ne disposent d’aucun réel mécanisme d’introspection disponible lors de l’exécution de l’application. De ce fait, nous n’avons pas mis en œuvre de mécanisme spécifique permettant la vérification de la cohérence des interactions.

Cependant, le métaobjet d’un objet dispose d’une table d’association (hashtable) dont la clef est la signature des méthodes. Celle-ci est utilisée par le mécanisme d’évaluation dynamique des messages contenus dans les comportements réactifs (se reporter au paragraphe 9.2). Ainsi, lors de l’exécution d’un comportement réactif, le mécanisme d’évaluation dynamique des messages réalise, de facto, une vérification de la cohérence des méthodes contenues dans les comportements réactifs et qui doivent être exécutées.

NOTE. — Cette solution peut, lorsqu’une règle d’interaction est incohérente (car faisant appel à une méthode n’existant pas), rendre incohérent le système puisqu’une partie seulement de la règle d’inter-ation à exécuter le sera réellement².

Personnalisation de la vérification

Il a également été mentionné que la gestion du typage des interactions devrait être personnalisable pour chacune des trois vérifications proposées.

Pour la vérification de l’existence des messages déclencheurs, une méthode devrait être invoquée, lors de l’instanciation du schéma d’interactions, et renverrait la liste de toutes les règles d’interactions dont les messages déclencheurs ne sont pas définis. Ceci permet de personnaliser le cas 1 de la vérifica-tion de la cohérence des interacvérifica-tions et, par exemple, de permettre dynamiquement l’ajout de nouvelles méthodes à un objet³(méthodes de délégation).

Pour le test des méthodes invoquées par les comportements réactifs (cas 2), la solution est moins immédiate car les méthodes non définies dans l’interface de l’objet peuvent être des méthodes de délé-gation définies par d’autres interactions. Ainsi cette vérification s’apparente à la détection dynamique du type des objets (ce qui est aussi le cas pour le cas 3).

9.5.2 Critère de non discrimination des objets

Le modèle à interactions défini au chapitre 5 permet de faire interagir de manière distribuée aussi bien des objets prévus pour être distribués que des objets non prévus pour cela (prise en compte du critère C3.2 de non discrimination des objets pour le support des interactions). Or si un objet non distribué doit être accessible depuis un site distant (par exemple si l’on veut lui envoyer un message) il est nécessaire de rendre cet objet accessible à distance.

Or la mise en œuvre d’un mécanisme générique permettant de manipuler de manière strictement identique les objets distribués et les objets non prévus pour être distribués est loin d’être aisée. Par exemple, l’invocation d’une méthode nécessite de lui transmettre ses paramètres. Dans le cas d’un objet distant, ceci implique que ces derniers transitent par le bus réseau de CORBA. Or seuls les types de base (entiers, chaînes de caractères, flottants, etc.) et les objets distribués savent être traités par CORBA. De plus, pour tout autre type de données, seules les personnes utilisant ces données sont en mesure de définir comment elles doivent être transmises par le bus réseau.

Par conséquent, et afin de nous focaliser sur d’autres points sensibles, nous nous sommes restreints, lors de notre mise en œuvre du modèle à interactions distribuées, à la possibilité de faire interagir entre eux soit des objets non prévus pour être distribués, soit des objets distribués, mais pas un panachage des deux types d’objets (nous décrivons dans l’annexe C une solution répondant partiellement à ce problème).

2. Lorsqu’une incohérence est détectée lors de l’exécution d’un comportement réactif le mécanisme d’évaluation dynamique des messages émet une exception.

3. Il est à noter que cette solution de définition de méthodes de délégation soulève un certain nombre de problèmes liés au fait, que d’une certaine façon, l’on change dynamiquement l’interface de l’objet et donc son type.

9.6 Conclusion

Dans ce chapitre, nous venons de montrer comment nous avons mis en œuvre le modèle à interac-tions distribuées, présenté dans la partie II et dont l’architecture a été définie dans le chapitre 8, dans l’environnement compilé et fortement typé du langage C++ grâce à l’utilisation de différents schémas de conception.

Parmi ces schémas de conception, on peut citer :

– Schémas de conception Stratégie et Constructeur Virtuel pour mettre en œuvre le mécanisme de réification des paramètres et celui de capture des messages.

– Schémas de conception Commande, Constructeur Virtuel et Poids Mouche pour mettre en œuvre le mécanisme de réification des méthodes et le mécanisme d’évaluation dynamique des messages. Nous avons proposé, dans cette partie, une mise en œuvre modulaire du protocole à métaobjet défini par notre modèle à interactions distribuées. La conception d’un protocole à métaobjet est une tâche ardue et délicate. Ainsi, la mise en œuvre du protocole présenté dans ce mémoire de thèse est issu de plusieurs définitions successives du protocole, assurant par là même sa maturation.

Par conséquent, nous sommes conscients que ce protocole et, par voie de fait, sa mise en œuvre possède des limites. Nous montrons, dans la partie qui suit, que cette mise en œuvre est cependant suffisamment évoluée pour permettre la réalisation d’applications grandeurs natures : nous présentons un système à base de connaissances.

Source de l'application (C++ / Java)

Compilateur personnalisé pour le support des interactions

Bus Réseau Expert du domaine Dépôt de schémas d'interactions Définition de schémas d'interactions Utilisation des schémas d'interactions Installation de l'application Installation de l'application 1 2 3 Utilisateur final Utilisation des schémas d'interactions 4 CorbaScript