Présentation de Corba

L'ORB fournit les mécanismes par lesquels des objets font des requêtes et reçoivent des réponses, et ce de manière transparente. Il fournit également l'interopérabilité entre des applications sur différentes machines dans des environnements distribués hétérogènes et il interconnecte sans coutures de multiples systèmes objets. D'une façon simplifiée, on peut définir l'ORB comme une entité qui fournit des mécanismes d'interrogations permettant de récupérer des objets, des procédures qui constituent une application.

L'ORB est défini plutôt par ses interfaces que comme un unique composant. Il comprend les composants suivants :

• ORB Core/ORB interface
• Interface Definition Language (IDL)
• Dynamic Invocation Interface (DII)
• Interface Repository (IR)
• Basic Object Adapter (BOA)

L'ORB est responsable de tous les mécanismes nécessaires pour :

• Trouver l'implémentation de l'objet pour la requête
• Préparer cette implémentation à recevoir la requête
• Communiquer les données constituant la requête

L'interface que voit le client est complètement indépendante :

• De l'endroit où l'objet est situé
• Du langage dans lequel l'objet est implémenté

L'implémentation objet, ie. le serveur, fournit la sémantique de l'objet, définit les données pour une instance d'objet, définit le code pour les méthodes des objets. Elle peut utiliser d'autres objets ou peut manipuler d'autres systèmes softwares qui ne sont pas eux-mêmes des objets.

Le client exécute une requête en ayant accès à une référence objet (ObjRef) pour un objet et en ayant connaissance du type de l'objet et de l'opération destinée à être exécutée.

Le client initie la requête en appelant des routines stubs spécifiques à l'objet (invocation statique) ou bien par construction dynamique de la requête (via la DII).

Les invocations statiques et dynamiques satisfont la même sémantique et donc le récepteur du message ne sait pas comment la requête a été construite. L'ORB localise le code d'implémentation approprié, transmet le contrôle de paramètres et de transfert à l'implémentation objet via un skeleton IDL. Les skeletons sont spécifiques à l'interface et à l'OA.

En exécutant la requête, l'implémentation objet peut obtenir certains services de l'ORB via l'OA.

Quand la requête est complétée, le contrôle et les valeurs de sortie sont retournés au client.

L'ORB interface est une interface aux fonctions de l'ORB qui sont indépendantes de l'OA utilisé. Ces opérations sont les mêmes pour tous les ORB et toutes les implémentations objet, et peuvent être exécutées soit par un client, soit par une implémentation (Par exemple la conversion d'ObjRef en String).

Développer des applications distribuées flexibles sur des plateformes hétérogènes nécessite une séparation stricte interface/implémentation(s). IDL aide à accomplir cette séparation.

En effet, IDL est un langage de définition d'interface orienté objet. Il définit les types des objets en spécifiant leurs interfaces. Une interface consiste en un jeu d'opérations et de paramètres pour ces opérations.

IDL est le moyen par lequel une implémentation d'un objet indique à ses clients potentiels quelles opérations sont disponibles et comment elles doivent être invoquées.

IDL a été conçu pour assurer la correspondance avec des langages de programmation (C,C++,SmallTalk sont actuellement standardisés).

Un compilateur IDL génère des stubs client et des skeletons serveurs. Ceux-ci automatisent les actions suivantes (en conjonction avec l'ORB):

• Les factories client (un factory est un objet créant un autre)
• Le codage/décodage des paramètres
• La génération des implémentations des classes d'interfaces
• L'enregistrement et l'activation des objets
• La localisation et les liens des objets

L'interface d'invocation dynamique d'un ORB autorise la création et l'invocation dynamiques de requêtes. Un client utilisant cette interface pour envoyer une requête à un objet obtient la même sémantique qu'un client utilisant l'opération stub générée à partir de la spécification de type IDL.

Pour invoquer une opération sur un objet, un client doit faire appel, et être lié statiquement, au stub correspondant. Puisque le développeur détermine, à l'écriture du code, les stubs qu'un client contient, l'invocation statique ne peut pas accéder à de nouveaux objets qui ont été ajoutés au système plus tard. La DII fournit cette capacité. Cette interface permet à un client, à l'exécution, de :

• Découvrir de nouveaux objets
• Découvrir leurs interfaces
• Retrouver les définitions d'interfaces
• Construire et distribuer des invocations
• Recevoir les réponses

Et ceci de la part d'objets dont les stubs du client ne sont pas liés dans son module.

La DII est donc une interface de l'ORB qui comprend des routines autorisant le client et l'ORB, travaillant ensemble, à construire et invoquer des opérations sur tout objet disponible à l'exécution.

En essence, la DII est un stub générique côté client capable de faire suivre toute requête vers tout objet, cela en interprétant, à l'exécution, les paramètres des requêtes et les identifiants des opérations. Cependant, la flexibilité à l'exécution fournie par la DII peut se révéler coûteuse. Par exemple, Une requête à distance faite à travers une paire stub/skeleton générée par un compilateur peut être accomplie en une seule RPC; mais le même appel via la DII nécessite des appels à :

• Object::getinterface: pour obtenir l'objet InterfaceDef
• InterfaceDef::describe: pour obtenir l'information sur les opérations supportées par l'objet
• Object::createrequest: pour créer la requête
• Request::addarg: pour chaque argument de la requête
• Request::invoke: pour invoquer effectivement la requête

Pour une opération sans argument et un type de retour void, la DII requiert un minimum de deux appels de fonctions, dont au moins une sera une RPC. En fait, pour la plupart des applications, particulièrement celles écrites dans un langage compilé comme C++, il est beaucoup plus efficace de passer les requêtes à travers les stubs statiques IDL.

L'IR est le composant de l'ORB qui fournit un stockage persistant des définitions d'interfaces, il gère et permet l'accès à une collection de définitions d'objets spécifiés en IDL.

L'ORB peut utiliser les définitions d'objets contenues dans l'IR pour interpréter/manipuler les valeurs fournies lors d'une requête :

• Pour permettre la vérification du type des signatures des requêtes
• Pour aider à fournir l'interopérabilité entre différentes implémentations d'ORB

Comme l'interface vers les définitions d'objets maintenue dans une IR est publique, l'information maintenue dans l'IR peut aussi être utilisée par des clients et des services. Par exemple, l'IR peut être utilisé :

• Pour gérer l'installation et la distribution des définitions d'interfaces
• Pour fournir des composants dans un environnement CASE (browser d'interface)
• Pour fournir l'information interface aux compilateurs
• Pour fournir des composants dans des environnements utilisateurs finaux (un constructeur de menus)

L'IR utilise des modules pour grouper des interfaces et pour naviguer à travers ces groupes au moyen de leurs noms. Un module peut contenir :

• Des constantes
• Des définitions de types
• Des exceptions
• Des définitions d'interfaces
• D'autres modules

La spécification de CORBA pour l'IR définit seulement des opérations pour retrouver de l'information dans l'IR. Il peut y avoir plusieurs manières d'insérer de l'information dans l'IR (compiler des définitions IDL, construire des objets repository a travers la DII, copier des objets d'une IR à une autre...)

Un Object Adapter est l'interface principale pour une implémentation objet pour accéder aux services fournis par un ORB. On s'attend à ce qu'il y ait peu d'OA disponibles, avec des interfaces appropriées à des types spécifiques d'objets.

L'éventail important des granularités, temps de vie, politiques et styles d'implémentations d'un objet rend difficile pour l'ORB Core la fourniture d'une seule interface pratique et efficace pour tous les objets. Ainsi, à travers les OA, il est possible pour l'ORB de cibler des groupes particuliers d'implémentations obiet qui ont des besoins similaires.

Le BOA est une interface visant à supporter un large éventail d'implémentations objet. Il fournit les fonctions suivantes :

• Génération et interprétation des ObjRef
• Authentification du principal effectuant l'appel
• Activation/désactivation des objets individuels
• Activation/désactivation de l'implémentation
• Invocation des méthodes à travers des skeletons

Le BOA supporte des implémentations objet construites d'un ou plusieurs programmes. Il communique avec ces programmes en utilisant les facilités du système d'exploitation. Il nécessite donc des informations qui sont, de façon inhérente, non-portables.

Bien qu'il ne définisse pas cette information, le BOA définit le concept d'une Implementation Repository qui peut détenir cette information, autorisant chaque système à installer et démarrer des implémentations de manière appropriée à chaque système.

Le BOA est donc l'interface qui permet aux implémentations objet de pouvoir communiquer avec l'ORB et d'accéder à ses services (cf. Fig 2: Structure et scénario d'un BOA)

1. Le BOA démarre un programme pour fournir l'implémentation objet
2. L'implémentation objet notifie le BOA que son initialisation est terminée et qu'elle est prête à manipuler des requêtes.
3. Quand la première requête pour un objet particulier arrive, l'implémentation est avertie qu'elle doit activer l'objet.
4. Dans les requêtes suivantes, le BOA appelle la méthode appropriée en utilisant les skeletons.
5. A certains moments, l'implémentation objet peut accéder aux services du BOA tels que création d'un objet, désactivation...