Derrière cet acronyme se cache sans aucun doute toute l'informatique de l'avenir « tout objet ». CORBA signifie Common Object Request Broker Architecture. Il s'agit d'une solution proposée par l'Object Management Group (OMG) visant à standardiser la création d'applications distribuées et à faciliter l'hétérogénéité, la communication, l'intégration et l'interopérabilité. Si, comme nous, la phrase précédente vous est complètement hermétique, lisez la suite...
La notion d'objets
Lorsque vous écrivez une application, vous faites appel à des bibliothèques de fonctions. Celles-ci fournissent au programme des réponses aux demandes qui lui sont faites.
Exemple :
Pour connaître l'heure système, on utilise une fonction qui renvoie l'heure dans un format numérique. Ensuite, le programme utilise cette donnée pour autre chose (l'afficher par exemple). Il ne s'agit pas là d'un objet car, lors de la compilation du programme, cette fonction sera intégrée dans l'application.
En utilisant un objet pour le même programme, l'application compilée va envoyer un message à l'objet qui donne l'heure système. L'objet en question va répondre en retournant un autre message contenant l'heure.
Changeons d'échelle... Dans un environnement orienté objet, une kyrielle d'objets s'acquittent de petites tâches parfois aussi anodines que récupérer l'heure actuelle. Cette masse d'objets forme un ensemble de briques permettant de créer des applications. Lorsqu'une application objet doit être créée, il ne reste plus qu'à définir quels objets doivent être utilisés et ensuite maçonner le tout. Les objets sont indépendants : vous pouvez écrire une application en C et utiliser des objets écrits en Fortran, C++, Java, Eiffel, etc.
Cela va encore plus loin car on entend par hétérogénéité le fait qu'il soit possible de communiquer avec des objets qui se trouvent sur des machines et systèmes d'exploitation différents via un réseau. A titre d'exemple, une application sous Linux peut demander à un objet sous Windows ou MacOS de compacter le contenu d'un fichier s'il n'y a pas d'objet pouvant faire la manipulation sur la machine locale.
Corba
Certains d'entre vous ont déjà fait connaissance avec PVM (Linux Mag 1). Il s'agit d'un logiciel permettant de répartir, par exemple, le calcul d'une image en raytracing (PvmPov) sur plusieurs machines. PVM envoie des ordres à toutes les machines pour qu'elles calculent de petites portions de l'image globale. En retour, les machines revoient les pixels au fur et à mesure du calcul. A la différence de Corba, PVM est un logiciel. Il ne communique qu'avec des machines se servant également de PVM et fait fonctionner des versions PVM de différentes applications.
Corba n'est pas un logiciel mais un ensemble de règles définissant comment doivent communiquer les objets. Une version Corba d'un client Pov demandera simplement aux objets de rendu Pov de lui fournir des pixels. Peu importe le type de machines sur lequel ils fonctionnent (PC, Mac, Station Sun, Alpha...), quel OS les fait "tourner" (Linux, Unix, Windows, MacOS...), dans quel langage ils ont été écrits ou même quelle implémentation de Corba ils utilisent. A partir du moment où l'application et les objets utilisent le langage (au sens général du terme) Corba ou plus exactement IDL pour communiquer, l'ensemble fonctionne.
Le bus Logiciel
Un des éléments les plus importants de l'architecture Corba est le bien nommé "bus logiciel". Pour facilement comprendre son fonctionnement, on peut le comparer aux bus qui se trouvent sur la carte mère de votre ordinateur. Sur le bus circulent les données que s'échangent les différents composants de l'ordinateur : carte vidéo, mémoire, contrôleurs de disques, carte modem, contrôleur clavier... Un composant spécifique s'occupe de faire circuler les informations sur le bus. En ramenant grossièrement tout ceci au niveau de Corba, les objets et applications sont enfichés sur le bus logiciel et communiquent entre eux. Ce bus ne se limite pas à la machine mais traverse le réseau. Ainsi, les applications "enfichées" sur le bus logiciel peuvent communiquer avec des objets "enfichés" sur une autre machine. La marque du bus n'entre pas en ligne de compte puisqu'il s'agit toujours d'un bus Corba.
Dans la réalité, il existe plusieurs manières de gérer la continuité du bus d'une architecture à l'autre. En effet, Corba ne définit pas le protocole à utiliser pour la communication à l'intérieur du bus :
‰ La première solution consiste à faire appel à un traducteur pour passer d'une implémentation du bus à une autre. Son travail est de traduire le langage d'un bus à l'autre (dans les deux sens). On parle alors de pont. Il faut autant de ponts que de différences entre bus.
‰ La seconde solution utilise deux demi-traducteurs. Sur chaque implémentation du bus, un interprète traduit le langage du bus dans un langage commun. Les informations d'échange dans ce langage et les deux demi-traducteurs s'acquittent de leur tâche envers "leur" bus. Le terme utilisé est, tout naturellement, "demi-pont". Il faut autant de demi-ponts sur une implémentation du bus qu'il y a d'implémentations de bus avec lesquelles on désire communiquer.
‰ Enfin, troisième et dernière solution, les deux bus utilisent un protocole commun. Ici, plus besoin d'artifices entre les bus, ils communiquent avec le même protocole.
Afin de mettre tout le monde d'accord sur le protocole commun, l'OMG a défini GIOP pour General Inter ORB Protocol. Ainsi, les implémentations souhaitant utiliser un protocole commun sont sûres d'être en mesure de communiquer avec d'autres implémentations ayant fait le même choix. Sans entrer dans le domaine technique, signalons simplement que GIOP est une couche se plaçant par-dessus TCP/IP, un protocole de transport déjà largement utilisé (InterNet).
Idl
Les objets et les applications clientes qui souhaitent se connecter au bus logiciel doivent respecter une interface donnée. Pour en revenir à notre exemple matériel, l'interface pourrait être le slot lui-même avec une dimension et un nombre de broches donné. Rappelons encore une fois que Corba est indépendant du langage de programmation. Il faut donc trouver une solution afin d'éviter les diversifications du genre : "Avec tel langage et telle implémentation, il faut interfacer comme ceci, avec tel autre langage, comme cela, etc." Un programmeur, ne se limitant jamais à un seul langage, cela tourne vite au calvaire.
La solution s'appelle IDL pour Interface Definition Language. Il s'agit d'un langage propre à la déclaration d'objets Corba. Lorsque le programmeur souhaite créer un objet, il écrit un petit bout de code en langage IDL, le compile (ou plutôt le précompile) et l'utilise dans son programme. Comme IDL est normalisé par l'OMG, le langage est toujours identique. Une source IDL est précompilée par les utilitaires fournis avec l'implémentation de Corba présente sur la machine du programmeur.
Pour résumer, si les objets sont des briques logicielles, IDL est tout simplement le mortier qui les lie.
Nous finirons cet article en précisant que la plupart des gros projets sous Linux s'intéressent à CORBA, comme GNOME et KDE. A la rentrée, nous verrons comment écrire des applications utilisant CORBA. En attendant, nous vous conseillons un excellent ouvrage écrit par :
Web Bibliographie
J.M. Geib, C. Gransart et P. Merle :
« Corba - Des concepts à la pratique »,
édité chez InterEdition,
ISBN 2-225-83046-0.