User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active
 

 

Corba pour développer des applications distribuées interopérables

 

 

Les objectifs de Corba.

 

Corba est une norme qui permet de développer des applications distribuées interopérables

 

Ca fonctionne en Client-serveur à base d’objets.

 

On a un langage IDL qui permet une séparation entre les méthode distantes (interfaces fonctionnelles) et la couche métier (implémentation des objets)

L’IDL va être projetée dans les différents langages, Java, C++ et va permettre à un client écrit dans un langage objet 1 de diagloguer avec un serveur écrit dans un langage objet 2.

CORBA : c’est un object broker, un négociateur

Bus logiciel, il y a un protocole pour dialoguer, c’est IIOP : internet interopérable general

IOP c’est l’instanciation de GOP sur TCP IP

Dans Corba il y a un certain nombre de services, les COS, services de nommages, d’événements, etc.

 

Modèle client-serveur

 

IDL à objet Coraba à Servant

 

Une question? Posez-la ici

 

L’ORB, est appelé bus logiciel

 

C’est là où vont transiter les informations

Il va identifier grace à l’IOR les objets CORBA

On parle d’emballage et de déballage des requêtes et des réponses. Ou en anglais on parle de « marshaling »

L’IDL permet de générer la souche (stub) et le squelette (skeleton)

Invocation statique et dynamique de requêtes.

 

Les souches ou Static Invocation Interface

 

la souche (stub) coté client

 

Le squelette ou statik Skeleton Interface xxxPOA

 

Les classes IMPL héritent des squellettes

Interface TOTO, on a une classe TotoPoa qui est le squelette qui doit être héritée par la classe métier.

 

Le noyau de l’ORB

 

L’architecture de l’ORB coté client

 

La souche SSI

 

SII : static Invocation Interface : boite noire de la projection de l’IDL dans la langage cible.

 

Le pavé DDI

 

Le pavé DDI Dynamic Invocation Interface DII, dans ce cas là il n’y a plus la souche, mais on construit dynamiquement la requête.

 

L’interface Repository IT

 

Représentation des spécifications IDL consultable durant l’exécution du programme

 

L’architecture de l’ORB coté serveur

 

Le static Skeleton Interface (SSI)

 

Le DSI Dynamic Skeleton interface

 

Se sert de métadonnées pour composer les classes

 

L’OA, object Adapter

 

L’implementation REpository (IR)

 

Les interoperable Object Reference

 

Une question? Posez-la ici

 

 

L’IOR sur IOP

 

Ca identifie l’interface IDL avec :

Le repository ID

@ du host de connexion + numero de port

Le POA name + l’object id

Clé

Le POA va retourné l’objet demandé en fontion de l’ID.

 

Propriétés des interopérable Object Référence

 

Les ORB sont interopérables : l’ORB java va communiquer avec l’ORB mico qui est un ORB ++

 

IDL : Interface Description langage

 

C’est la patie publique des objets CORBA, accessible à distance

A l’intérieur, on a une description syntaxique

Les opérations : signatures des requêtes

Exceptions : notifications des erreurs

Un exemple d’IDL :

On peut utiliser un module, qui est un espace de nommage, un package

On peut définir des types comme un entier long non signé

On peut avoir des séquences, un tableau par exemple

Et puis il faut une interface, pour avoir un objet CORBA, car c’est l’interface qui va contenir les opérations accessibles au client de façon distance. A l’intérieur de l’interface on définit un certain nombre d’opérations.

 

Une question? Posez-la ici

 

 

Le développement

 

On construit l’IDL

On compile l’IDL (idlj)

Ca génère un répertoire, et des classes dont le stub et le squelette.

Au niveau du squelette : code metier + code serveur , compilation = application serveur

Au niveau du stub : code client, compilation = application cliente (avec objet proxy représentant l’objet distant, l’interface)

 

Développement statique

 

  1. On définit le contrat IDL
  2. Compilation de l’IDL
  3. Ecriture couche métier
  4. Ecriture code serveur
  5. Compilation serveur
  6. Ecriture code client
  7. Compilation client

 

Une question? Posez-la ici

 

Approche statique avec diffusion de l’IOR par fichier coté client

 

  1. Initialisation de l’environnement CORBA : iorinit
  2. Récupération de l’IOR du servant, déstringnifiaction de l’IOR sous format texte
  3. Opération de narrowing, cast sur l’objet proxy
  4. Invocation de la raquête
  5. Placer l’ORB en écoute

Approche statique avec diffusion de l’IOR pa fichier côté serveur

  1. Initialisation de l’environnement CORBA, orbinit
  2. Récupération et activation d’un POA
  3. Instanciation d’un servant
  4. Création de l4IOR du servant, enregistrement dans le POA
  5. Diffusion de l’IOR, écriture dans un fichier, stringification de l’IOR
  6. Placer l’ORB en écoute

Approche statique avec service de nommage coté client

 

  1. Initialisation de CORBA
  2. Récupération du service de nommage
  3. Narrowing, passage du mode CORBA au monde objet
  4. Récupération de l’IOR du servant
  5. Narrowing
  6. Invoquer la requête
  7. Placer l’ORB sur écoute

Approche statique ave service de nommage coté serveur

 

  1. Initialisation de CORBA
  2. Récupération et activation POA

 

Une question? Posez-la ici

 

Récupération et activation du RootPOA

 

 

  1. Résoudre la référence initiale « RootPOA »
  2. Narrowing
  3. Récupération POAManager
  4. Activation POAManager

Pour aller plus loin : voir ensuite la projection Java du DynamicImplementation et la délégation, le TIE model en anglais.

 

Besoin d'aide avec Corba? Remplissez ce formulaire: