I.3.3.4 Mise en oeuvre d'une application C.O.R.B.A.
En reprenant les concepts décrits dans cette première partie sur C.O.R.B.A., un schéma
type de mise en place d'une application distribuée peut être décrit comme suit :
- Ecriture du contrat I.D.L.
Dans une approche orientée objet (en O.M.T. par exemple), on définit dans un premier temps les objets de l'application distibuée,
puis dans un second temps on modélise les objets sous forme de contrats I.D.L.
Ces contrats en I.D.L. décrivent les interfaces des objets et des types de données.
On les enregistre dans un fichier texte (Banque.idl) .
- Compilation des sources I.D.L.
Le compilateur choisi opère un contrôle syntaxique et sémantique des définitions I.D.L contenues
dans le fichier texte.
Les définitions sont chargées dans le référentiel des interfaces.
- Projection vers les langages de programmation
Le compilateur a généré le code des souches :
- stub, utilisé par les applications clientes
- squelettes, pour les programmes serveurs implantant ces objets.
La projection est spécifique à chaque langage de programmation.
- Implantation des objets
L'implantation d'un objet définit le comportement pour les opérations et attributs de son interface.
L'implantation complète ou réutilse le code généré par les squelettes et stubs.
Le développeur implante les objets dans le langage de son choix en respectant les règles de projection vers
le langage choisi.
- Ecriture des applications serveurs d'objets
Le développeur code les programmes serveurs qui incluent implantation des objets et squelettes pré-générés.
Ces programmes contiennent le code pour :
- se connecter à un O.R.B.,
- instancier les objets sur le serveur,
- rendre publiques les références sur ces objets à l'aide du service nommage,
- se mettre en attente des requêtes des clients pou ces objets.
- Ecriture des applications clientes, utilisatrices des objets
Ce sont dans ces programmes que l'on invoque les opérations sur les objets.
Ces programmes incluent :
- le code des souches (méthodes de liaison avec les serveurs, ...),
- les références aux objets utilisés,
- le code pour l'Interface Homme Machine,
- le code spécifique à l'application
- Installation et configuration des serveurs
On enregistre les serveurs d'objets auprès du référentiel des implantations. Ceci permet d'automatiser leur activation lorsque
les requêtes vont arriver.
- Diffusion et configuration des clients
Après avoir écrit les programmes clients, il est nécessaire de diffuser les exécutables sur les sites
clients.
- Lancement de l'application distribuée
Le bus C.O.R.B.A. : l'O.R.B assure alors les communications entre
les clients et les objets disponibles sur tels serveurs via le
protocole I.I.O.P.
Premier exemple applicatif réalisé avec Orbix Web 3.0 de IONA
Orbix Web 3.0 de IONA est un logiciel qui permet de développer des applications distribuées C.O.R.B.A.
C'est un outil dédié au langage Java, il intègre un O.R.B., un compilateur d'I.D.L vers Java, et toutes les autres fonctionnalités
nécéssaires au dévelopement de systèmes distribués.
Considérons un objet Banque sur lequel nous souhaitons effectuer les opérations élémentaires de gestion de comptes
bancaires : ouvrirCompte(nomclient), fermerCompte(numerocompte), crediterCompte(montant, numerocompte),
debiterCompte(montant, numerocompte) ...
Nous spécifions l'interface de la banque en I.D.L. (cf plus haut exemple dans le document).
Après avoir écrit ce contrat I.D.L, le compilateur choisi (ici I.D.L vers Java) fait le reste.
Effectivement, de la projection vers le langage Java, sont générés principalement :
- l'interface java correspondante (Banque.java),
- les souches stub et squelttes (_BanqueStub.java), (_BanqueSkeleton.java),
- d'autres fichiers utiles à la programmation distribuée.
Dans un second temps, nous implantons notre objet Banque en java (langage de programmation choisi) :
écriture de la classe BanqueImplementation qui réutilise les squelettes générés par le compilateur d'I.D.L.
BanqueImplementation implante l'interface Banque et hérite de la classe _BanqueSkeleton.
Une fois notre objet banque implanté, nous écrivons un programme serveur en Java :
classe BanqueServeur qui "met" les objets (Banque en l'occurence) à la disposition des clients.
Ecriture du programme serveur
import IE.Iona.OrbixWeb._CORBA;
import IE.Iona.OrbixWeb.CORBA.ORB;
import IE.Iona.OrbixWeb.CORBA.ORB;
public class BanqueServeur{
public static void main(String args[]){
Banque b=null;
ORB orb;
// création et initialisation de l'orb
orb=(ORB)org.omg.CORBA.ORB.init();
// création de l'objet Banque : b
b=new BanqueImplementation("Crédit Agricole");
// enregistrement avec l'orb de la Banque b (de nom "ca" sur le serveur)
orb.connect(b,"ca");
// BanqueSr: serveur de la banque "ca"
_CORBA.Orbix.impl_is_ready("BanqueSr");
try { Thread.sleep(500000); }
catch (InterruptedException ex) {}
// déconnexion de b de l'orb
orb.disconnect(b);
System.out.println("déconnexion");
}
}
Un objet Banque (b) est maintenant disponible sur le serveur BanqueSr.
Pour que le(s) client(s) puisse(nt) l'utiliser, cet objet doit être identifiable.
Dans ce court exemple, il n'a pas été nécessaire d'employer le service nommage car l'application réalisée est simple.
En effet, un seul et unique objet (Banque b) est enregistré sur le serveur.
Regardons maintenant le programme client qui va utiliser b et c.
Ecriture du programme client
import org.omg.CORBA.ORB;
import IE.Iona.OrbixWeb._CORBA;
import javax.swing.*;
public class BanqueClient {
public static void main(String args[]){
//initialisation de l'O.R.B.
ORB.init();
//référence x à une Banque
Banque x=null;
//référence x à l'objet Banque b du serveur "BanqueSr"
x=BanqueHelper.bind(":BanqueSr","mass-171315.univ-tlse2.fr");
JOptionPane.showMessageDialog(null,
"Bienvenue à la banque du " + x.nombanque());
//saisie du nom d'un futur client
String S = JOptionPane.showInputDialog(null,
"A quel nom souhaitez-vous ouvrir un compte ?");
//ouverture du compte pour S
int a=x.ouvrirCompte(S);
};
}
Schéma récapitulatif des classes écrites et générées
Remarque :
Jusqu'à présent, en java, dans un systeme non distribué, une référence désignait un objet lorsque celui ci etait "alloué"
par l'opérateur new.
La machine virtuelle java (J.V.M.) renvoyait alors l'objet à l'application qui l'utilisait.
Par analogie, dans un systeme distribué corba, les objets sont "renvoyés" du serveur au client par la méthode
bind(identificateur_obj, hote_obj) du stub BanqueHelper.