I.3.3 La norme C.O.R.B.A.

C.O.R.B.A. a été développé par l'O.M.G. (Object Management Group).
L'O.M.G. est un consortium international regroupant des fournisseurs de matériels (SUN, HP, IBM, ...), des fournisseurs de logiciels (I.O.N.A., Borland, Oracle, Microsoft, ...) et des grands utilisateurs comme Motorola, Alcatel, Boeing.
Son but est de définir des standards pour l'intégration d'applications distribuées hétérogènes.
Pour que ces applications répondent aux besoins de communication, de portabilité et d'interopérabilité, l'O.M.G. a défini un modèle de référence : la norme C.O.R.B.A .
C.O.R.B.A. utilise:

• les technologies orientées objet :
  • l'architecture O.M.A. (Object Management Architecture) de gestion des objets,
  • un bus d'objets répartis C.O.R.B.A . : l'O.R.B. (Object Request Broken / distributeur de requêtes objet), qui facilite la communication entre objets distribués hétérogènes,
  • un langage de description d'interfaces: l'O.M.G. - I.D.L. (Interface Definition Language / langage de définition d'interfaces), qui assure l'interopérabilité entre les objets implantés,
  • des services objet et des utilitaires communs qui fournissent une large gamme de composants logiciels destinés à la construction d'applications distribuées.
• les mécanismes de l'approche orientée objet :
  • encapsulation,
  • polymorphisme,
  • héritage.

I.3.3.1 L'architecture O.M.A.

Cette architecture globale de l'O.M.A. propose une classisfication des types d'objets C.O.R.B.A. selon leur fonctionnalité dans les applications distribuées.
Elle structure ces fonctionnalités en quatre catégories de composantes :

• Les services objet communs sont des objets C.O.R.B.A. spécifiés par des interfaces I.D.L.
  Ils offrent des services système de bas niveau communs à la majorité des applications distribuées (nommage, persistance, sécurité et transaction entre les objets répartis).
• Les utilitaires communs apportent des fonctionnalités de plus haut niveau.
  Ils offrent des composants logiciels réutilisables (interface utilisateur, gestion de l'information, administration du système et gestion des tâches).
  
• Les interfaces de domaine fournissent les standards ID.L. pour assurer l'interopérabilité entre des objets de métier destinés à des secteurs économiques (Santé, Finance, Télécom)
  
• Les objets applicatifs décrits en I.D.L permettent d'assembler et d'intégrer les composants pré-existants.

I.3.3.2 Le bus C.O.R.B.A. : O.R.B.

Caractéristiques

A l'image d'un bus matériel, l'O.R.B. est un outil de communication entre différents éléments logiciels répondant à la norme C.O.R.B.A. Il permet de résoudre les besoins d'interopérabilité et d'intégration de technologies informatiques hétérogènes.
Il gère de façon tranparente :

• les différences entre les langages d'implantation des objets, les systèmes d'exploitation et les architectures matérielles.
  Cela est dû à la séparation entre l'interface et l'implantation des objets offerte par le langage I.D.L.
• la localisation des objets sur le réseau, ainsi que leur mécanisme d'invocation (statique ou dynamique)

Distributeur de requêtes objet

Comme son nom l'indique, l'O.R.B. assure le transport des requêtes entre les objets distribués.
Il fonctionne selon un modèle objet de type client/serveur.

• L'application implantant l'objet est le serveur.
• L'appplication utilisant l'objet est le client.

• ni la localisation de l'objet,
• ni son implantation,
• ni quel O.R.B. est utilisé pour accéder à l'objet.

L'O.R.B est utilisé aussi bien par le client que par le serveur via des souches de communication (appelées aussi talons ou proxy).

Ces souches masquent les communications à travers le reseau.
Elles sont générées automatiquement par le compilateur d'I.D.L. (décrit plus loin) à partir des sources I.D.L.
A chaque objet décrit en I.D.L. sont générées une souche client et une souche serveur.

Du côté client, la souche s'appelle le "stub"; elle est stockée dans l'espace d'adressage du client et représente l'objet distant. C'est à ce représentant que le client adressera ses requêtes.
De façon symétrique, le serveur dispose d'une souche serveur de l'objet : le "skeleton" qui reçoit la requête du client et invoque l'objet.

Principe d'invocation en mode statique

1. Le client d'un objet C.O.R.B.A. dispose d'une référence de l'objet dans son espace mémoire.
   Il utilise celle-ci pour manipuler l'objet.
2. Le client invoque une méthode spécifique sur la référence de l'objet.
3. Si l'objet est distant, son stub associé emballe les arguments de la requête et la transmet à l'O.R.B.
4. Le réseau transporte l'invocation via l'O.R.B.
5. La souche serveur associée à l'objet déballe les arguments et invoque l'objet.
6. L'objet transmet le résultat au squelette qui l'emballe.
7. Le réseau transporte le résultat via l'O.R.B.
8. Le stub déballe le résultat et le transmet au client.

Architecture

• L'O.R.B. transporte les requêtes.
• Les interfaces d'invocations statiques.
• L'interface d'invocation dynamique.
• Le référentiel des interfaces contient toutes les définitions I.D.L. des objets du bus.
• L'interface de l'O.R.B. fournit les primitives de base de C.O.R.B.A.
• Les interfaces de squelettes statiques.
• Les interfaces de squelettes dynamiques.
• L'adaptateur d'objets qui exécute les requêtes et active les objets.
• Le référentiel des implantations décrit l'implantation des objets.

• l'invocation statique (la plus simple et la plus utilisée) :
  le programmeur écrit les invocations sur les objets en utilisant les souches de communication (produites par un précompilateur d'I.D.L). Les invocations sont contrôlées à la compilation.
  C'est une approche bien adaptée pour la compilation et l'exécution d'applications ayant des spécifications I.D.L. stabilisées.
• l'invocation dynamique :
  les requêtes d'invocation sont construites dynamiquement à l'aide du référentiel des interfaces (R.I. Repository Interface). Les invocations sont controlées à l'exécution.
  Cette approche convient aux applications dont certaines spécifications évoluent au cours du temps.

I.3.3.3 Le langage de définition d'interfaces : I.D.L.

Développer des applications distribuées sur des plate-formes hétérogènes nécessite une séparation stricte interface / implantation.
En effet rappelons que c'est selon l'interface que les applications clientes peuvent manipuler les objets.
Ainsi, pour pouvoir décrire ces interfaces, l'O.M.G. a conçu l'I.D.L.
L'I.D.L. assure aussi la correspondance avec différents langages de programmation.

Définition

L'I.D.L. permet de décrire les interfaces des objets.
C'est un langage déclarartif orienté objet dont la syntaxe est très inspirée du langage C++ ou Java.
L'I.D.L. définit pour un objet distribué :

• des opérations,
• des attributs,
• des types,
• et des exceptions.

Les constructions du langage I.D.L.

• des types élémentaires de données (void, long, char, string, ...),
• des constantes,
• des types construits,
• des exceptions,
• des interfaces (opérations, attributs, ...),
• des modules,
• des valeurs,
• des pragmas,
• des types de méta-données.

Interface d'une Banque en I.D.L. :

/*classe de définition d'une banque */
interface Banque { 
	readonly attribute string nombanque;
	long ouvrirCompte(in string nom); 
	void fermerCompte(in long numero); 
	void crediterCompte(in float montant,in long numero ); 
	void debiterCompte(in float montant,in long numero); 
	float soldeCompte(in long numero); 
	string listeClients(); 
};

Projection vers un langage de programmation

Pour pouvoir exploiter les défintions I.D.L., l'environnement C.O.R.B.A. fournit des compilateurs I.D.L. qui dépendent du langage cible et de l'implantation du bus.
Ces précompilateurs transforment ces définitions I.D.L. en des constructions utilisables depuis des langages de programmation.
Précompilateurs existants : I.D.L. vers Java, C, C++, Corba-script, Smalltalk, Cobol, Ada.
Pour chaque interface I.D.L., le précompilateur génère :

• une interface dans le langage cible,
• un stub client dans l'environnement de programmation du client,
• un squelette serveur dans l'environnement de programmation du serveur,
• d'autres fichiers dans le langage cible nécesaires à la distribution entre client et serveur.

• une interface java (Banque.java),
• un stub client en java (_BanqueStub.java),
• un squelette serveur en java (_BanqueSkeleton.java),
• et d'autres fichiers java (BanqueHelper.java , BanqueHolder.java) nécessaires pour l'ecriture du client et du serveur.