Common Object Request Broker Architecture (corba) Jean-Louis Pazat irisa/insa

Common Object Request Broker Architecture (CORBA)

• Jean-Louis Pazat - IRISA/INSA

• [e-mail]

Plan

• Introduction

• Architecture de CORBA

• Communications

• Service de nommage

• Langage de description d’interfaces (IDL)

• Exemple

• Compléments

• Services, “Facilities” & Domaines
• CORBA et le parallélisme

• Conclusion

Introduction

motivation

• Calcul réparti

• le réseau est au cœur du calcul

• Pratiques du “génie logiciel”

• modélisation et programmation objet/composant

• Indépendance

• vitale pour les applications
• vis à vis des plateformes
• vis à vis des vendeurs

• Integration de programmes existants

• nécessaire

Comment passer du centralisé au réparti ?

• Casser les structures existantes

• insérer des appels de procédure/de méthode à distance

Le concept de “bus logiciel”

• ajouter/supprimer des objets sans recompiler l’ensemble de l’application

• enregistrer/retrouver des références globales sur des objets
• connaître à priori ou découvrir les méthodes d’un objet

• réaliser les appels de méthode à distance

• passage de paramètres (par valeur)
• indépendance vais à vis de la localisation des objets

What is CORBA ?

• standard ouvert pour les applications réparties
• bus logiciel, orienté objet
• communication par appel de méthode à distance
• géré par l’ “Object Management Group” (OMG).
• indépendant
• du matériel, du système, des langages
• et surtout des vendeurs

Le modèle objet de CORBA

• Types (Types) :

• définis sur des domaines de valeurs
• indépendants des langages d’implémentation

• Objets (objects) :

• entité encapsulée qui offre des services à des clients
• peut être créé/détruit

• méthodes (operation)

• entité qui définit les points d’entrée qu’un client peut invoquer

Le modèle objet de CORBA (suite)

• Interfaces (Interfaces)

• signature des méthodes qu’un client peut invoquer sur un objet

Architecture de CORBA

ORB

• Niveau interstitiel (Middleware)

• n’est pas partie intégrante du système
• sépare le reste de l’architecture du système

• Permet l’ interopérabilité

• indépendant des plateformes matérielles ou logicielles
• différents ORB peuvent communiquer
• à travers un protocole “Inter ORB” (xIOP)

ORB (suite) GIOP / IIOP / ESIOP

• GIOP = General Inter ORB Protocol

• spécification qui permet l’interopérabilité entre différents ORBs
• spécifie le protocole de transmission + format des requêtes

• IIOP = Internet Inter ORB Protocol

• protocole d’interopérabilité standard pour Internet
• construit sur IP

• ESIOP = Environment Specific IOP

• spécification qui permet de définir des protocoles spécifiques

ORB (suite) IIOP

• Livré avec toute implémentation de CORBA

• Utilise CDR

• plus efficace que XDR (0/1 codage/décodage max)

• Certains serveurs WEB peuvent dialoguer via IIOP

Souche et squelette IDL

• Générés par le compilateur IDL

• à partir de la description IDL de l’objet serveur (doit être connue lors de l’écriture du client)

Souche IDL

• Contient les proxies des objets distants auxquels le client accède

• génère les requêtes à partir de l’invocation de méthode locale

• encapsule requête et arguments

• envoie la requête sur le bus (ORB Core)

Squelette IDL

• Contient un aiguilleur de requêtes compilé (dispatcher)

• extrait l’invocation de méthode et les paramètres de la requête reçue du bus

• transmet l’invocation de méthode vers le bon objet

DII / DSI

• Interfaces dynamique d’invocation de méthodes (Dynamic Invocation/Skeleton Interface)

• permet de découvrir dynamiquement de nouvelles interfaces ou de les enregistrer
• pas recommandé aux programmeurs débutants
• historiquement était la seule interface disponible en CORBA
• beaucoup moins efficace que les interfaces statiques

DSI

• Dynamic Skeleton Interface

• utile lorsqu’une implémentation n’a pas d’IDL
• peut tenir compte d’objets créés/enregistrés dynamiquement
• transfère les invocations de méthodes du coté serveur

DII

• Dynamic invocation interface

• API prédéfinie pour tout appel de méthode
• permet de découvrir dynamiquement des interfaces
• les requêtes doivent être construites “à la main”
• syntaxiquement différent d’une invocation de méthode
• utilisée aussi dans des cas particuliers
• “deferred synchronous call”

Utilisation de DSI+DII si rien n’est connu à la compilation

DII+IDL Skeleton method invocation le serveur possède une IDL mais le client ne la connaît pas …

Basic Object Adapter

• Pas à l’usage du programmeur

• sauf pour init/enregistrement

Communication

Appel de méthode à distance

• paramètres passés par valeur

• types de base, types construits
• références aux objets

• modes de passage de paramètres

• in : valeur transmise à la méthode
• out : valeur calculée par la méthode
• inout : valeur transmise puis renvoyée (modifiée)

Appel blocant

• “twoway method invocation”

• l’appelant est bloqué jusqu’à la terminaison de la méthode appelée
• out, inout et des resultats ou des exceptions peuvent être retournées

Appel non blocant 1

• “oneway method”

• l’appelant n’est pas bloqué
• aucun résultat ou paramètre inout ou out ne peuvent être utilisés

Appel non blocant 2

• “asynchronous call”

• uniquement en utilisant le DII
• permet de récupérer des résultats

• méthodes du DII :

• send_deferred()
• get_response()
• poll_response()

Communication par passage de messages

• Modèle d’événements (push / pull)

• communication asynchrone
• multiple producteurs / multiples consommateurs

Service de nommage

• Un des serveurs standard livrés avec l’ORB (service)

• Service de nommage générique

• Associe des noms et des références CORBA (IOR)
• nommage uniforme

• Contexte de nommage

• organisé en DAG
• conventions de nommage

• Opérations

• bind / unbind / rebind / resolve

Interface Definition Language (IDL)

présentation

• Est indépendant des langages

• Peut être “mappé” dans de nombreux langages :

• C++, C++, C++, C++, C, Java, ...

• Permet de décrire

• des interfaces contenant
• des opérations
• des attributs accessibles à distance

• une interface IDL est similaire à

• une interface Java
• une classe abstraite C++

exemple de spécification IDL

éléments du langage IDL

• Modules

• Interfaces

• Opérations (oneway, twoway)
• Attributs

• Déclarations de

• constantes
• types
• exceptions

Modules

• espaces de nommage pour les définitions IDL

• évite les conflits de noms

• les modules peuvent être imbriqués

• les noms sont visibles (préfixer)

• module simulation { typedef ::MatrixComputation::Matrix constraints; … };
• module MatrixComputation { typedef double Matrix[N][N]; …};

Interfaces

• Description de la partie publique d’un objet

• Héritage entre interfaces possible (restrictions)

• redéfinitions interdites
• héritage multiple autorisé
• interface coffee { // coffee interface definitions }; interface Drinks: coffee { // inherits all coffee definitions // then adds other definitions };

Constantes

• Seulement pour certains types

• integer, character, Boolean, Floating point, String, renamed types
• peuvent être des expressions
• pas de constantes pour les types construits
• const char etoileu_des_neigeu = ‘*’
• typedef Long Entier;
• Entier 600+60+6

Déclarations de types

• Renommage ou types def. par le programmeur

• énumeration, structures, tableaux, unions

• enum couleurs { rouge, vert, bleu};
• struct ecole {
• Interessant tutoriels, exposes;
• Bon repas;
• Sympatique station;
• };
• typedef Char BadDate[2];

• sequences (tableaux de taille variable)

• typedef sequence formation;

types de données

type dynamique IDL Any

• N’est pas un type générique au sens objet

• Défini des types “auto-identifiés”

• contient des informations sur
• son type dynamique (CORBA type code)
• sa valeur
• les types définis par l’utilisateur ont un “type code”

• utile pour définir des services “génériques”

attributs

• attributs public des objets

• peuvent être en “lecture seule” ou en “lecture/écriture” (par défaut)

• seuls les types nommés sont autorisés

• interface time {
• attribute unsigned long nanosecond;
• readonly attribute date Y2K;
• attribute long notAllowed[10];
• …
• }

exceptions

• Assure qu’un client reçoit toujours une réponse lors d’une invocation distante

• 2 sortes d’exceptions

• “CORBA Standard Exceptions”
• levées par CORBA
• même si elle peuvent avoir été levées par l’implémentation d’un objet
• exceptions définies par le programmeur
• exception EntryNotAllowed{string reason;};

exceptions (suite)

• Exemple

• interface Account {

• exception OverdrawnException {};

• void deposit( in float amount );

• void withdraw( in float amount )

• raises ( OverdrawnException );

• float balance();

• };

IDL mappings

• Existent pour plusieurs langages

• orientés objet
• non orienté objet

• Un nouveau “mapping” ne peut pas être facilement ajouté

• nécessite la modif du compilateur IDL, du BOA, …
• son intégration dans la norme
• connecter 2 ORBs est plus simple ...

• mapping

• trivial pour C++, assez simple pour Java

Mon premier programme CORBA

Mon premier programme CORBA

Mon premier programme CORBA

Conclusion

Nombreuses mise en œuvre existantes

• Nombreuses mise en œuvre existantes
• Orbix (Iona), Visibroker (Inprise), ... comm
• MICO (Université de Francfort)
• ORBit, TAO, JacORB, ...
• Intérêts
• Utilisation assez facile
• Réelle interopérabilité !
• Défauts
• Trop bas/haut niveau :-)
• Architecture complexe
• Performances limitées sur les réseaux haut débit
• Et ...