Caractéristiques de CORBA

CORBAest une norme pour définir une architecture distribuée de type client/serveur ainsi qu’un certain nombre de services associés. Nous décrivons dans les sections suivantes deux élé- ments centraux (ORB et IDL) de la technologie CORBA et l’usage que nous en faisons. ORB

Un ORB est un bus d’objets répartis qui offre un support d’exécution masquant les couches techniques d’un systèmes réparti (système d’exploitation, processeur et réseau). Il prend en charge les communications entre les composants logiciels formant les applications réparties hétérogènes. Le bus CORBA propose un modèle orienté objet client/serveur d’abstraction et de coopération entre les applications réparties. Chaque application peut exporter certaines de ses fonctionnalités (services) sous la forme d’objets CORBA : c’est la composante d’abstraction (structuration) de ce modèle. Les interactions entre les applications sont alors matérialisées par des invocations à distance des méthodes des objets : c’est la partie coopération. La notion client/serveur intervient uniquement lors de l’utilisation d’un objet : l’application implantant l’objet est le serveur, l’ap- plication utilisant l’objet est le client. Bien entendu, une application peut tout à fait être à la fois cliente et serveur.

Dans notre atelier, les applications qui doivent exporter des fonctionnalités sous forme d’ob- jet CORBA sont principalement les prototypes. Par conséquent, chaque prototype est encapsulé

3.2. Ar hite ture del'atelier 69

dans un objet CORBA. De plus, nous avons montré qu’un service de formatage des connais- sances et qu’un service de gestion des interfaces graphiques sont nécessaires. Ces services donnent lieu à deux composants de services implantés dans des objets CORBA. Nous avons par consé- quent plusieurs applications implantant les «objets services» : une application par prototype, une pour le gestionnaire de formats et une pour le gestionnaire d’interfaces graphiques. Toutes ces applications sont implantées en tant que serveurs CORBA.

Dans notre atelier l’application cliente est le gestionnaire d’activités.

Application Cliente (objet CORBA) Application Serveur (objet CORBA) Requête Réponse Activation Objet CORBA

Figure 3.3 – Le modèle objet client/serveur CORBA

La figure 3.3 présente les différentes notions intervenant dans ce modèle objet client/serveur. L’application cliente invoque les méthodes objets à travers le bus CORBA. Le bus CORBA achemine les requêtes de l’application cliente vers l’objet. Larequête est le mécanisme d’invo- cation d’une opération ou d’accès à un attribut de l’objet. L’activation est le processus d’asso- ciation d’un objet d’implantation à un objet CORBA. L’application serveur est la structure d’accueil des objets d’implantation et des exécutions des opérations de l’objet CORBA. Chacune de ces notions se traduit par des composantes technologiques fournies par l’implantation de la norme CORBA. En résumé, l’ORB assure la communication entre la partie client et la partie serveur.

IDL

L’ORB achemine les requêtes. Mais il faut pouvoir être compris des différentes parties en présence : le client et le serveur. Pour cela, CORBA définit un langage standard commun à toutes les parties pour exprimer les interfaces de tous les objets CORBA à travers lesquelles l’ORB accède aux composants. Ce langage est appelé IDL∗_(pour

Interfa eDes riptionLanguage). C’est

un langage de spécification indépendant du langage d’implantation. La syntaxe et sémantique complètes d’IDL sont disponibles dans le chapitre 3 de la spécification de l’OMG, sur le site de l’OMG [OMG http].

La technologie CORBA permet d’utiliser différents langages de développement. Les compo- sants peuvent être écrits dans tout langage qui implante les bindings CORBA. Cela signifie à la fois qu’une correspondance (binding) IDL–langage est adoptée et que le compilateur intègre les

outils nécessaires pour que le composant soit utilisé par un ORB. C’est le cas des langages Ada, C, C++, COBOL orienté objet, JAVA et SmallTalk. Par conséquent, une fois l’interface d’un serveur défini, nous sommes libres de changer le code (ou le langage d’implantation, si la cor- respondance IDL–langage existe) tant que la spécification des services offerts reste la même. De plus, si les langages actuels deviennent obsolètes, nous pourrons toujours utiliser les composants existants tant que leur langage est conforme à la norme CORBA et développer de nouveaux composants dans le dernier langage «à la mode», si une correspondance IDL–langage est adoptée. Ainsi, CORBA rend possible la publication (c’est-à-dire le fait de rendre public) des attributs et des méthodes des serveurs de façon à ce qu’ils soient accessibles par les autres composants.

70 Chapitre 3. Propositions détaillées pour la réalisation de l'atelier

Cette publication est rendue possible via une interface, que nous appelonsvitrine ( f. page 11).

Dans sa vitrine, un composant affiche ses services (opérations/méthodes, exceptions et attri- buts) en masquant les divers problèmes liés à l’interopérabilité, l’hétérogénéité et la localisation de ceux-ci. Toute opération a une signature qui définit son nom, ses paramètres, ses résultats et ses exceptions. La vitrine ne comprend pas l’implantation des opérations ; en effet, IDL n’est qu’un langage pour définir les interfaces. Ainsi, la vitrine va permettre d’afficher ce que fait le composant indépendamment de son implantation. L’utilisation de CORBA assure ainsi une cer- taine flexibilité.

Projection des vitrines

La traduction d’une vitrine, exprimée en IDL, dans un langage d’implantation s’appelle une projection. En pratique, les vitrines sont projetés d’une part en souches38_{IDL (ou interface d’in-}

vocation statique SII) dans l’environnement de programmation du client et et d’autre part en squelettes39

IDL (ou interface de squelettes statiques SSI) dans l’environnement de programma- tion du serveur (voir figure 3.4).

Bus CORBA Client

Souche IDL

Serveur

Squelette IDL

Figure 3.4 – IDL client/serveur CORBA

Le client invoque localement les souches pour accéder aux objets. Les souches IDL construisent des requêtes, qui vont être transportées par l’ORB, puis délivrées par celui-ci aux squelettes IDL qui les délégueront aux objets. Ainsi le langage IDL est la clé de voûte du bus d’objet répartis CORBA. En résumé, CORBA nous permet de faire communiquer des systèmes hétérogènes avec un langage commun.