Tolérance aux fautes sur CORBA par protocole à
métaobjets et langages réflexifs

Alternatives à CORBA

 Bien que CORBA s’impose en tant que standard dans l’élaborations de systèmes distribués orientés-objet, certaines alternatives existent avec leurs avantages et leurs inconvénients. On notera que l’inconvénient principal de ces technologies est de ne pas être toujours compatible avec CORBA lui-même.

 Java et les technologies associées 

Java s’est récemment imposé comme un des meilleurs langages de programmation orienté-objet. En effet, il dispose de nombreux avantages comme par exemple : • une portabilité à priori sans limite puisqu’il est basé sur l’utilisation d’une machine virtuelle et d’un interpréteur ; • il est très adapté à la programmation distribuée, notamment au travers de l’Internet ; • son modèle à objet est très propre, contrairement à celui de C++ qui hérite de certaines caractéristiques du langage C. Aux avantages issus du langage de programmation proprement dit, s’ajoutent ceux issus de deux technologies développées autour de celui-ci, JavaRMI et les JavaBeans : • JavaRMI (pour Java Remote Method Invocation) est un moyen de faire interopérer, de façon transparente, différents objets Java au sein d’un réseau. On peut faire le parallèle avec le bus à objet de l’architecture CORBA : transparence de la localisation grâce à l’utilisation de références, nommage des objets, etc. De plus, dans une récente évolution, JavaRMI, grâce à l’utilisation du protocole de transport IIOP, peut interopérer avec les systèmes CORBA. • JavaBeans quant à lui est un système qui permet à des composants logiciels d’être intégrés facilement : des outils sont fournis pour les composer telles des briques de Lego. On peut les interroger pour découvrir dynamiquement leur interface. En ce sens, ils sont équivalents à ce que permet l’interface d’invocation dynamique de CORBA. Ces technologies représentent une bonne alternative à CORBA pour qui se contente du langage Java. Il est de plus important de noter que leur utilisation s’avère être bien plus simple que celle d’un ORB. 

 DCOM et OLE

 DCOM et Network OLE sont deux technologies développées par Microsoft pour la conception et l’intégration de composants logiciels : 16 Chapitre I Systèmes à objets, réflexivité et protocoles à métaobjets • DCOM [Rogerson 1997] définit un modèle d’objets distribués et remplit les fonctions d’ORB telles que définition d’interfaces, gestion de références, invocation dynamique, etc. Ce système est intégré aux systèmes d’exploitation de Microsoft et leur est propriétaire. • Network OLE permet d’intégrer des composants entre eux à la manière des JavaBeans pour faciliter le développement et la réutilisation de code. En effet, dans les systèmes d’exploitation et de fenêtrage graphiques comme Windows, de nombreux éléments sont communs aux applications : le presse-papier, l’impression de documents et aujourd’hui, les services multimedias ou liés à l’Internet. Ces deux technologies peuvent donc être comparées à CORBA mis à part qu’elles ne sont disponibles que sur les systèmes d’exploitation Windows. Contrairement aux technologies Java, elles permettent l’interopérabilité des langages et non l’interopérabilité des systèmes.

 Réflexivité et protocoles à métaobjets

De nombreuses classes d’applications nécessitent des propriétés totalement indépendantes de leurs fonctionnalités, comme la persistance ou la sécurité. On qualifie parfois ces propriétés de non fonctionnelles car elles sont orthogonales à l’application. Des outils issus du modèle orienté-objet ont été développés pour traiter certains mécanismes orthogonaux récurrents comme les «fabriques abstraites d’objets» ou encore les «adaptateurs». Ces outils sont des modèles de conception qui utilisent la délégation et l’héritage afin d’augmenter leur réutilisabilité et leur généralité ; on appelle ces outils les «Design Patterns» [Gamma et al. 1995]. Une autre solution pratique pour l’implémentation de mécanismes orthogonaux à l’application est l’utilisation de la réflexivité [Stroud 1993], particulièrement sous la forme de protocole à métaobjets. En effet, ces notions ont prouvé qu’elles permettent non seulement d’implémenter ces mécanismes d’une façon élégante et efficace mais surtout qu’elles fournissent une grande flexibilité, tout en étant transparentes pour l’utilisateur.

 Réflexivité 

La réflexivité est la propriété d’un système qui est capable de raisonner à propos de lui-même [Maes et Nardi 1988]. Cette définition élémentaire, qui peut paraître obscure, introduit la notion de moyens d’analyse, de modification ou d’extension a posteriori du comportement initial du système. Ce concept est à la base même de celui de métaobjets, nous en donnons ici une définition. 

  Définition 

Le terme réflexif est issu de la philosophie. Il est défini comme suit [Larousse 1972] : Qui concerne la conscience se connaissant elle-même : la méthode réflexive remonte des conditions de la pensée à l’unité de la pensée. Le terme de réflexivité a, quant à lui, été introduit en logique pour désigner un moyen d’étendre les théories. Ensuite, il a été utilisé pour exprimer la relation entre la théorie et la méta-théorie dans les systèmes de raisonnement logique. Plus récemment, la réflexivité a été adoptée comme un outil puissant et général des langages de programmation. On peut en donner la définition suivante [Maes et Nardi 1988] : Un système informatique est dit réflexif lorsqu’il fait lui-même partie de son propre domaine. Plus précisément cela implique que (i) le système a une représentation interne de lui-même, et (ii) le système alterne parfois entre calcul «normal» à propos de son domaine externe et calcul «réflexif» à propos de lui-même. Ces définitions nécessitent des éclaircissements. On peut dire que le système réflexif contient une auto-représentation qui décrit la connaissance qu’il a de luimême. Le système et son auto-représentation sont liés de manière causale : si l’un d’entre eux est modifié, l’autre l’est en conséquence. Un système réflexif peut donc s’auto-modifier en modifiant son auto-représentation, et son auto-représentation reste toujours cohérente avec son état réel. On appelle niveau de base le système lui même. Le méta-niveau contient le modèle du niveau de base (l’auto-représentation du système) qu’il peut interpréter et modifier. Ces deux notions, illustrées par la figure 6, sont liées par deux processus d’interaction, la réification qui s’opère du niveau de base vers le méta-niveau lorsque le premier subit une modification devant être reflétée dans le second, et l’intercession, qui va du méta-niveau vers le niveau de base lorsqu’une modification du premier doit s’opérer sur le dernier .