Corba, une introduction par l'exempleDate de publication : 18/11/2000
L'informatique répartie est un des enjeux principaux de l'informatique actuelle et à venir. De l'architecture de terminaux centralisée qui servait encore de modèle il y a peu de temps, nous somme passé à l'architecture client/serveur. L'information est maintenant répartie entre différents serveurs du système et non plus centralisée sur un seul et même serveur : elle est répartie et distribuée aux clients de façon transparente. L'information distribuée, voilà donc le maître mot. Le world wide web, qui nous est si familier, est un exemple réussi d'application distribuée. Les clients, par l'intermédiaire d'un navigateur, se connectent à des serveurs sur lesquels des pages web nous sont proposées (le plus souvent encore statiques). Cependant, rien ne vous empêche de proposer vous aussi de l'information ou même d'installer votre serveur (sauf peut être l'InterNIC...), vous êtes alors client... mais aussi serveur : le web se sont des clients mutliples mais aussi des serveurs multiples.
I. La norme CORBA II. Le langage de définition d'interfaces : IDL III. Le bus d'objets de CORBA IV. Exemple V. Bibliographie I. La norme CORBA
CORBA ou Common Object Request Broker Architecture est né dans les années 1990 du besoin de faire communiquer ensemble des applications en environnement hétérogène (plusieurs systèmes et plusieurs langages).
CORBA n'est qu'un sous ensemble du projet ODP-RM ou Open Distributed Processing Référence Model vise à mettre en place une norme d'architectures distribuées ouvertes.
L'
Object Management Group
, créé en 1989 et regroupant plus de 750 membres (vendeurs de logiciels, développeurs et utilisateurs), collabore avec l'ODP pour la mise en place d'une norme sur le middleware, et a créé à cet effet la norme CORBA.
CORBA est donc une norme et rien ne contraint l'implémentation les développeurs de produits CORBA.
Ils ont le libre choix de l'implémentation.
La popularité de l'Internet à ensuite amené les concepteurs de la norme CORBA à définir un protocole de communication entre les objets adaptés à Internet.
Ce protocole s'appelle IIOP, pour Internet Inter-ORB Protocol.
Sommairement, l'Object Management Architecture Guide défini :
A l'heure où j'écris ces lignes, la norme CORBA en est à sa version 2.2 mais on parle déjà de la version 3.
Si CORBA constitue la première initiative majeure dans le domaine des objets distribués, quelques alternatives sont aujourd'hui possibles.
Ainsi, il m'a semblé important ici de noter quelques différences entre CORBA et d'autres solutions proposées pour l'informatique répartie et les objets distribués : RPC et RMI et DCOM.
Le cas de RMI ou Remote Method Invocation ne concerne que les dialogues Java/Java et donc se différencie de Java par le fait que cette méthode est attachée à un langage particulier.
RPC ou Remote Procedure Call permet comme son nom l'indique d'invoquer des procédures distantes mais se trouve mal adapté aux dialogues d'objets distants.
Enfin, le cas de DCOM est plus complexe car DCOM est l'alternative CORBA proposée par Microsoft.
Si CORBA défini une norme, DCOM défini aussi son implémentation et se limitait jusque récemment à l'interface Windows.
De très bonnes études sont disponibles sur le Web au sujet de la comparaison des deux systèmes.
Ayant personnellement pratiqué les deux, CORBA me parait beaucoup plus simple et pratique d'utilisation.
II. Le langage de définition d'interfaces : IDL
A la base de CORBA, est défini l'IDL ou Interface Definition Language.
Il permet de définir dans un langage commun à l'ensemble des compilateurs, la partie visible d'un objet : méthodes et propriétés.
Le principe utilisé ici est la séparation de l'interface d'un objet et de son implémentation.
A titre d'exemple, le listing 1.
Présente l'interface IDL d'un service minimal de gestion du compte d'un client (cet exemple est l'équivalent CORBA du fameux hello.c,hello.java, hello.pl...)
:
Listing 1.
Au premier coup d'oeil, les développeurs familiers de C++ auront sans doute remarqué certaines ressemblances entre ce dernier et IDL.
Peut importe l'implémentation de l'interface CompteClient du moment qu'elle répond à l'interface spécifiée.
IDL génère une souche (stub) pour le client et un squelette (skeleton) pour le serveur.
Cette opération est effectuée simplement par la commande :
qui génère les classes C++ requises dans le fichier CompteClient.cc.
III. Le bus d'objets de CORBA
Le coeur de CORBA est constitué par l'ORB qui est le conduit/bus par lequel les requêtes sur les objets transitent.
L'Object Request Broker ou ORB n'est pas directement accessible au programmeur d'applications CORBA qui n'utilise qu'une référence.
L'ORB gère les transferts entre les clients et les serveurs.
L'adaptateur d'objets, est quand à lui chargé de la gestion des références aux objets et de l'activation des implémentations : l'adaptateur d'objets est donc, comme son nom l'indique, le " canal " par lequel l'ORB est connectée à l'implémentation de l'objet.
Différents types d'adaptateur d'objets peuvent être implémenté mais la norme CORBA 2.0 ne requière que le BOA ou Basic Object Adapter.
Ainsi, à l'aide d'un compilateur idl et de vos fichiers idl (présenté dans la section précédente), vous générez des souches pour les clients et des squelettes pour les serveurs.
Vous n'avez qu'à programmer l'implémentation de votre classe serveur (ici une classe est assimilée à une classe C++) qui doit hériter du squelette généré par idl.
Une fois vos programmes clients et serveurs compilés, vous pourrez lancer votre serveur et l'ORB fera tout le travail de pliage/dépliage des requêtes des clients sur les objets locaux et distants à vôtre place.
Pour plus de clarté un schéma explicatif du bus CORBA est donné ci-dessous.
IV. Exemple
Afin d'illustrer les concepts d'ORB et de BOA voiçi le code d'un serveur CORBA (avec nommage) associé à l'interface CompteClient :
Le client n'implante pas d'objets et n'a donc pas besoin du BOA
V. Bibliographie
Je remercie les auteurs cités dans la bibliographie pour leurs ouvrages dans lesquels j'ai largement puisé pour écrire cette note.
[GGM97] J.M. Geib, C.
Gransart, P.
Merle, CORBA : des concepts à la pratique, Masson, 1997.
[POP97] A.
Pope, The CORBA référence guide : understanding the common object request broker architecture, Addison Wesley, 1997.
[PUD98] A.
Puder, The MICO CORBA compliant system, DDJ, p.44-51, november 1998.
|
Copyright © 2000 2000-2006. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.