Exemple : HorlogeHelper

La classe Helper contient la méthode narrow qui converti :

Horloge horloge = HorlogeHelper.narrow(obj);

Classe Holder

Le paramètre d'une méthode en Java est inchangé :

    public void Add2(int i)
      { i = i + 2;
      }    

Si le paramètre est déclaré out ou inout dans l'interface IDL, il doit changer !

Méthode : l'enrober dans une classe, et créer un objet de cette classe :

    public class conteneur
      { public int val;
      }
    
    public void Add2(conteneur i)
      { i.val = i.val + 2;
      }

Si n est un conteneur, n.Add2() modifie la valeur de n.i.

L'exemple complet

 // fichier Horloge.idl :
      interface Horloge
	      { String getTime();
	      };

En plus de l'interface, il faut écrire l'implémentation du servant :

    public class HorlogeImpl extends _HorlogeImplBase
        { public String getTime()
           { java.util.Calendar calendar =
                                   new java.util.GregorianCalendar();
             String str = "[" + calendar.get(java.util.Calendar.HOUR_OF_DAY);
             str = str + ":" + calendar.get(java.util.Calendar.MINUTE) + "]";
             return str;
           }
        }

... puis le serveur :

    public class Serveur
	      {
          public static void main( String[] args)
            { // init ORB 
              org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
              // init BOA voir p 29
              org.omg.CORBA.BOA boa = orb.BOA_init(args, null);
              // création de l'objet de traitement
              HorlogeImpl horloge = new HorlogeImpl();
              // enregistrement et activation de l'objet
              boa.connect(horloge);
              boa.obj_is_ready(horloge);
              // création du fichier référence
      
        try
                { String ref = orb.object_to_string(horloge);
                  java.io.FileOutputStream file =
                                 new java.io.FileOutputStream("ObjectId");
                  java.io.PrintStream pfile = new java.io. PrintStream (file);
                  pfile.println(ref);
                  pfile.close();
                }
              catch (java.io.IOException ex)
                { ex.printStackTrace();
                }
      
        // attente du client...
              try
               { System.out.println("le serveur est prêt");
                 boa.impl_is_ready();
               }
              catch (org.omg.CORBA.SystemException e)
               { e.printStackTrace();
               }
            }
	      }      

et enfin le client :

    public class Client
	      {	public static void main(String[] args)
			      {	// init ORB 
				      org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
				      // création de l'objet
				      org.omg.CORBA.Object obj = null;
				      try
					      {	java.io.FileInputStream file =
                                 new java.io. FileInputStream ("ObjectId");
						      java.io.InputStreamReader myInput =
                                 new java.io.InputStreamReader (file);
						      java.io.BufferedReader reader =
                                 new java.io.BufferedReader (myInput);
						      String ref = reader.readline();
						      obj = orb.string_to_object(ref);
					      }
      
				      catch (java.io.IOException ex)
					      {	ex.printStackTrace();
					      }
				      try
					      {	Horloge horloge = new HorlogeHelper.narrow(obj);
						      System.out.println("Heure = " + horloge.getTime());
					      }
				      catch (org.omg.CORBA.SystemException ex)
					      {	ex.printStackTrace();
					      }
			      }
	      }      

Schéma

Schéma simplifié d'une application répartie conforme à CORBA

Le bus CORBA

C'est l'ensemble des modules qui permettent l'utilisation d'objets répartis Ses fonctions sont :

• la transparence d'invocation pour client et serveur ;
• l'abstraction des langages COBOL, C, C++, Smaltalk, Ada, Java ;
• la gestion des objets sur le serveur (créés lorsque nécessaires) ; l'objet fantôme est créé sur le client lorsqu'il a besoin d'accéder à l'objet sur le serveur ; il lance alors une invocation ; le bus crée l'objet sur le serveur.
• l'invocation statique et dynamique ;
• la liaison entre bus différents (GIOP et IIOP).

Ces fonctions sont assurées par un ensemble de composants :

Schéma détaillé

Tout ceci est décrit en IDL.

Implémentations diverses possibles :

• client et serveur sur la même machine (logiciel embarqué)
• client et serveur sur des machines différentes reliées par un même réseau (Internet)
• client et serveur sur des machines différentes reliées par des réseaux différents.

GIOP fournit :

• CDR (Common Data Representation) représentation standard des objets ;
• IOR (Interoperable Object Reference) mise en forme standard des références aux objets ;
• messages de transport : Request, Reply...).

GIOP est un protocole abstrait ; IIOP est une implémentation de GIOP.

Les références

Dans le protocole GIOP, les références sont codées selon le format IOR (Interoperable Object References).

Le format IOR contient :

• le nom complet de l'interface IDL correspondant à l'objet ;
• l'adresse IP de la machine hôte de l'objet ;
• le port du serveur de l'objet ;
• une clé désignant l'objet. Son format dépend de l'implantation du bus.

Les IOR sont des chaînes de caractères hexadécimaux ; Les IOR sont définies dans un module IDL A la description IDL correspond une implémentation. D'autres formats sont en cours de réalisation.

Les services CORBA

Les services sont des appels standardisés à des fonctions du système réparti CORBA.

Les références initiales

Le passage de références du serveur au client se fait rarement par un fichier :

• méthode lourde ;
• coûteuse sur le réseau ;
• lente à l'initialisation.

On a développé d'autres mécanismes :

• références initiales ;
• service annuaire.

Les références initiales sont des références qui font partie de l'ORB. Elles mettent en correspondance un nom et une référence. Elles permettent donc d'accéder par nom à un objet.

On obtient la liste des références initiales par une méthode de l'ORB :

String [] liste = orb. list_initial_services();

On obtient la référence correspondant à un nom par :

    org.omg.CORBA.Object ref = null;
    try
	     {	ref = orb.resolve_initial_reference("nom ");
	     }
    catch (org.omg.CORBA.ORBPackage.InvalidName e)
       {	
	     }

Attention :

• la référence obtenue est vers le type Object ; il faut la convertir par narrow()
• ce mécanisme n'est pas standard, et dépend de l'ORB.

Naming Service

Ce service met en relation un nom et une référence. Il permet d'accéder aux objets qui n'ont pas de référence initiale.

// module CosNaming
	  {	typedef Istring;
                                                    
		struct NameComponent
			{	Istring id;
				Istring kind;
			}
                                                    
		typedef sequence <NameComponent> Name;

		.......
	  }

Dans NameComponent :

• id est l'identificateur,
• kind est une description de classification

Un Name est une collection de NameComponent. Un NameComponent est appellé une liaison.

Les objets étant identifiés par nom, on peut mettre dans la collection un ident de Name. Ceci hiérarchise l'annuaire sous forme arborescente.

On peut accéder à un élément par le chemin qui le représente dans l'arbre, comme dans les directories.

Contextes de désignation

Un contexte de désignation regroupe des références. Pour le décrire, il existe l'interface :

org.omg.CosNaming.NamingContext

Il offre toutes les méthodes de gestion :

• ajout et suppression d'une liaison ;
• ajout d'un contexte de désignation (construction de l'arbre) ;
• changement de liaison ;
• changement de contexte.

Création d'un contexte

On crée un contexte par définition d'un objet qui implante l'interface NamingContext, ou bien création d'une implantation standard par la fonction new_context(). On l'ajoute à l'annuaire par bind_context().

Recherche d'une référence

C'est celle qu'utilise le client pour accéder à un objet. Elle se fait par la fonction resolve (Name). C'est l'opération de résolution de nom. Cette fonction s'applique à un contexte ou à un sous-contexte. Elle recherche le nom dans le sous-contexte auquel elle s'applique. Elle retourne soit une référence d'objet, soit une référence de contexte.

Interface NamingContext

    interface NamingContext 
	     { enum NotFoundReason 
			    { missing_node, 
	 			  not_context, 
				  not_object 
			    };
                      
		   exception NotFound 
			    { NotFoundReason why; 
				  Name rest_of_name; 
			    };
                      
		   exception CannotProceed 
			    { NamingContext cxt; 
				  Name rest_of_name;
			    };
                      
		   exception InvalidName { };
                      
		   exception AlreadyBound { };
                      
		   exception NotEmpty { };
                      
		   void bind(in Name n, in Object obj) 
			    raises (Notfound, CannotProceed, InvalidName, AlreadyBound); 
                      
		   void rebind(in Name n, in Object obj) 
			    raises (Notfound, CannotProceed, InvalidName); 
                      
		   void unbind(in Name n) 
			    raises (Notfound, CannotProceed, InvalidName);
                      
		   void bind_context(in Name n, in NamingContext nc) 
			    raises (Notfound, CannotProceed, InvalidName, AlreadyBound);
                       
		   void rebind_context(in Name n, in NamingContext nc) 
			    raises (Notfound, CannotProceed, InvalidName);

                      
		   Object resolve (in Name n) 
			    raises (Notfound, CannotProceed, InvalidName);
                      
		   NamingContext new_contextO; 
                      
		   NamingContext bind_new_context(in Name n)
			    raises (Notfound, AlreadyBound, CannotProceed, InvalidName);
                      
		   void destroy() 
			    raises (NotEmpty);
                      
		   void list(in unsigned long how_many, out BindingList bl, 			
                   out BindingIterator bi);  
	     }

Utilisation d'un annuaire

Le serveur crée des fonctions ; il les ajoute à l'annuaire.

Le client doit connaître la désignation de l'objet ; il l'utilise pour résoudre la désignation et obtenir la référence.

L'annuaire est un objet de type NamingContext ; il se nomme NameService ; il fait l'objet d'une référence initiale.

Initialisation de l'ORB, du BOA...

Création d'un objet assurant le nouveau service :

    ImprimeImpl imp = new ImprimeImpl();
	  boa.connect(imp);
	  boa.obj_is_ready(imp);

Accès à l'annuaire :

    org.omg.CORBA.Object obj = null;
	  org.omg.CosNaming.NamingContext naming = null;
	  try
		 { obl = orb.resolve_initial_reference("NamingService ");
		   naming = org.omg.CosNaming.NamingContextHelper.narrow(obj);
		 }
    catch (org.omg.CORBA.ORBPackage.InvalidName e)
		 { System.out.println("nom erroné");
		   System.exit(0);
		 }
	  if (naming == null)
		 { System.out.println("service indisponible");
		   System.exit(0);
		 }

Création de la liaison :

    org.omg.CosNaming.NameComponent[] name = 
		            new org.omg.CosNaming.NameComponent[1];
	  name[0] = new org.omg.CosNaming.NameComponent();
	  name[0].id = "imprime";
	  name[0].kind = "";        

Ajout de la liaison :

    try
      { naming.bind(name, imp);
      }
    catch (org.omg.CosNaming.NameContextPackage.NotFound e)
          { System.out.println("objet introuvable");
		      System.exit(0);
		    }
	  catch (org.omg.CosNaming.NameContextPackage.AlreadyBound e)
          { System.out.println("objet déjà inscrit");
		      System.exit(0);
		    }
	  catch (org.omg.CosNaming.NameContextPackage.InvalidName e)
          { System.out.println("nom invalide");
		      System.exit(0);
		    }
	  catch (org.omg.CosNaming.NameContextPackage.CannotProceed e)
          { System.out.println("traitement impossible");
		      System.exit(0);
          }

Enfin, lancement de l'utilisation :

     try
		 { boa.impl_is_ready();
		 }
	   catch (java.lang.Exception e)
		     { e.printStackTrace();
           }

Initialisation de l'ORB (pas de BOA sur le client).

Accès à l'annuaire :

    org.omg.CORBA.Object obj = null;
	  org.omg.CosNaming.NamingContext naming = null;
    try
		{ obl = orb.resolve_initial_reference("NamingService ");
		  naming = org.omg.CosNaming.NamingContextHelper.narrow(obj);
		}
    catch (org.omg.CORBA.ORBPackage.InvalidName e)
      { System.out.println("nom erroné");
		  System.exit(0);
      }

Création de la liaison :

    org.omg.CosNaming.NameComponent [] 
             name = new org.omg.CosNaming.NameComponent [1];
	  name[0] = new org.omg.CosNaming.NameComponent();
	  name[0].id = "imprime";
	  name[0].kind = "";
    try
      { obj = naming.resolve(name);
      }
   catch (org.omg.CosNaming.NameContextPackage.InvalidName e)
      { System.out.println("nom invalide");
		  System.exit(0);
		}
	 catch (org.omg.CosNaming.NameContextPackage.NotFound e)
      { System.out.println("objet introuvable");
		  System.exit(0);
		}
	 catch (org.omg.CosNaming.NameContextPackage.CannotProceed e)
      { System.out.println("traitement impossible");
		  System.exit(0);
		}

Création d'un objet d'accès au service :

    ImprimeImpl imp = ImprimeHelper.narrow(obj);

Accès au service

    try
		{ imp.print("texte à transmettre au serveur");
		}
	  catch (org.omg.CORBA.SystemException e)
		{ System.out.println(e.getMessage());
      }

Annuaire interopérable

L'annuaire interopérable ajoute une représentation standard sous forme de chaîne des chemins d'accès. Il étend l'annuaire :

interface NamingContextExt : NamingContext

Il définit les URL CORBA.

Méthodes

Constitution de la chaîne

id et kind d'un NameComponent sont séparés par un point, s'ils existent tous deux ;

les NameComponent sont séparés par des / ;

les caractères . et / dans les NameComponent sont codé \. et \/

Exemple a.b/c séquence de NameComponent <a, b> et <c>

Les URL CORBA

resolve() retourne un référence à un Object. La méthode object_to_string() la transforme en chaîne.

Il existe 6 formes d'URL : IOR, corbaloc, corbaname, ftp, http, file.

• Les IOR sont les références dont nous avons parlé jusqu'ici.
  
• URL corbaloc
  • Représentation simple des accès aux objets.
  • Elles sont moins complètes que les IOR.
  • Leur format est : corbaloc:// { [protocole]@machine [: port]} / clef
  Les éléments entre [] sont optionnels. Les {} signifient la répétition éventuelle.
  • La version par défaut du protocole est 1.0, le port par défaut est 9999.
  • La clef de l'objet est un identifiant unique retourné par le BOA, en utilisant l'opération connect sous sa seconde forme : boa.connect(objet, clef);
    Exemple : corbaloc://1.2@dil:1234/clef
  • Ceci n'est pas standard avec le BOA.
    
• URL corbaname
  • Identique à la précédente, en remplaçant la clef par une liaison dans l'annuaire.
    Exemple : corbaloc://1.2@dil:1234/a.b/c
    
• URL correspondant aux protocoles réseau
  Optionnels, ils référencent un fichier contenant l'IOR de l 'objet.

Le POA Portable Object Adaptor

Ajoute des spécifications par rapport au BOA pour le rendre portabe.

Spécifications

Tout comme le BOA, le POA est situé du côté serveur. Donc la nouvelle définition ne change rien au client.

Le servant est une abstraction de l'objet tel que nous l'avons utilisé : à un même servant peuvent être associés plusieurs références d'objets. Les divers objets pourront avoir des comportements différents.

Arborescence de POA

Le comportement du POA est régi par un ensemble de règles. On peut donc créer plusieurs POA, avec des règles distinctes. Chaque POA gère un ensemble de servants, en fonction des règles édictées. Il existe un POA standard, nommé RootPOA.

Il est possible de créer de nouveaux POA, et de les ranger en arbre. Chacun aura ses propres paramètres.

Mécanismes dynamiques

Les mécanismes de référencement que nous venons de voir sont statiques. La suite traite du mécanisme de référencement dynamique.

Pour reconstruire des références vers les bons objets, côté client, on a utilisé les classes Helper. Le mécanisme d'invocation dynamique ne les utilise pas.

Pour pouvoir opérer la liaison, on utilisera le type IDL Any, qui est compatible avec tout type. C'est un type de métadonnée auto-descriptif : il comprend la valeur et sa description.

Le serveur gère, en plus des objets, une base de données comportant les descriptions de toutes les interfaces IDL des objets disponibles sur le bus CORBA : le référentiel d'interface (IFR Interface repository). L'implantation de cette BD est libre ; elle peut être relationelle ou autre.

L'interface d'invocation dynamique (DII, Dynamic Invocation Interface) permet à un client d'invoquer les opérations sur les objets sans passer par les souches IDL prédéfinies. Il découvre la structure de l'interface d'objet à l'exécution. Il est interrogeable par le client pour retrouver la définition des types.

C'est une souche générique.

Réalisation d'un Object Browser.

L'interface de squelette dynamique (DSI, Dynamic Skeleton Interface).

C'est un squelette générique. Il remplace et étend les squelettes statiques. Il a été défini au départ pour réaliser des passerelles avec des ORB propriétaires.

Application

A partir de cet ensemble, il est possible au client de construire une requête, sans utiliser le mécanisme statique précédent.

Construction d'une application générique

Consiste à réaliser un programme capable d'invoquer n'importe quelle opération de n'importe quel objet.

• recherche de la référence d'un objet ;
• accès à l'interface de l'objet ;
• accès à la description de l'opération à invoquer ;
• construction de la liste des arguments à transmettre ;
• création de la requête ;
• lancement de la requête ;
• récupération des résultats.

La recherche de la référence se fait par string_to_object() ou par le NamingService ; L'accès à l'interface par get_interface() appliquée à la référence précédente ; il fourni des métadonnées de description de l'objet.

L'accès à la description de l'opération se fait :

• soit en connaissant l'opération dont on obtient la description par look_up_name ; ensuite on obtient la signature IDL par describe ;
• soit en consultant la liste des opérations possibles sur l'objet, et la présentant à l'utilisateur qui choisira.

La signature obtenue permet de construire la liste des arguments : create_list, puis add, add_item et add_value. Création de la requête par _create_request, en donnant le nom de l'opération et la liste des arguments. Invocation de la requête en synchrone, différée ou asynchrone.

Avantages de CORBA

• CORBA est une solution ouverte, indépendante des éditeurs de logiciel ;
• elle est ouverte, car l'OMG apporte constamment des améliorations ;
• composition hétérogène : systèmes d'exploitation, réseaux et langages différents ;
• par voie de conséquence, possibilité de réutiliser des logiciels existants en les encapsulant dans des objets CORBA ;
• portabilité du code, grâce au langage IDL ;
• simplicité de mise en oeuvre, en utilisant des outils existants ;
• la base d'entreprises qui supportent CORBA.

Précautions

Comme pour Java : il faut éviter à tout prix les extensions alléchantes proposées par les fournisseurs d'ORB, car elles ne seront pas portables !

Faut-il choisir Corba, ou préférer autre chose ?

Il n'y a pas de règle générale pour le choix d'un environnement réparti : ce sont vos besoins immédiats ou futurs qui guideront votre choix.

Toutefois, le principe d'économie nous incite à choisir l'environnement le plus facile à utiliser. Or Corba est assez complexe. Alors, une bonne règle pourrait être :

• si vous devez construire une application répartie ex-nihilo, sans réutiliser des programmes existants, choisissez un environnement orienté vers un langage unique, tel que Java RMI ; ses possibilités limitées seront bien suffisantes pour programmer votre projet, mais ses limitations vous offriront une certaine souplesse et simplicité d'utilisation ;
• si par contre vous disposez de programmes existants, bien au point et rodés, qu'il serait coûteux de réécrire, le seul choix est Corba, qui sera capable de les incorporer tels qu'il s sont. Ceci vaut également si votre projet doit évoluer dans l'avenir, en incorporant de nouveaux environnement.

CORBA est un outil extrêmement puissant, qui comporte les défauts inhérents à sa puissance. Sachez l'utiliser comme un langage d'assemblage : si vous ne pouvez pas faire autrement, profitez à fond de sa puissance.

La base industrielle de Corba est aussi un argument important en sa faveur : si vous achetez des composants Corba, vous n'êtes pas lié à un éditeur particulier ; vous aurez toujours la possibilité d'acheter le produit équivalent d'iun concurent, ce qui n'est pas négligeable...