Common Object Request Broker Architecture (CORBA)

Présentation au sujet: "Common Object Request Broker Architecture (CORBA)"— Transcription de la présentation:

1 Common Object Request Broker Architecture (CORBA)
Jean-Louis Pazat - IRISA/INSA

2 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

3 Introduction

4 Pratiques du “génie logiciel” Indépendance
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

5 Comment passer du centralisé au réparti ?
Casser les structures existantes insérer des appels de procédure/de méthode à distance Appelant Appelé Appelant Appelé Souche Squelette Network Nouveaux problèmes nommage, localisation, transparence, interoperabilité

6 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

7 CORBA = Common Object Request Broker Architecture
What is CORBA ? CORBA = Common Object Request Broker Architecture 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 Before presenting our work, I introduce what it is CORBA, the Common Object Request Broker Architecture. CORBA is an open standard for distributed object computing from the Object Management Group. As this standard wants to be independent from underlying platforms and from programming languages, it is not concern by implementation aspects. A CORBA application can be seen as a collection of independent software components which are called CORBA objects. Each object is described by an interface which lists operations that can be remotely invoked. Such interface is written using the Interface Description Language (IDL). The IDL is just a specification language. Objects within a CORBA application communicate through the Object Request Broker (ORB). The ORB provides remote procedure call mechanism with transparent location so that client invokes a method of a remote object as it invokes a local method. interopérabilité

8 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

9 Le modèle objet de CORBA (suite)
Interfaces (Interfaces) signature des méthodes qu’un client peut invoquer sur un objet Requêtes (requests) : action créée par un client et dirigée vers un objet contient des infos sur la méthode à invoquer et les paramètres réels

10 Architecture de CORBA

11 Ma_méthode(in mon_paramètre out mon_résultat)
Paramètres d’entrée (in) valeur de retour Paramètres de sortie (out) Vue du programmeur Implementation de l’objet Client DII Souche IDL Interface ORB squelette IDL DSI Adaptateur d’objet Niveau interstitiel (middleware) Coeur de l’ORB Protocoles GIOP / IIOP / ESIOP

12 Implementation de l’objet
ORB Implementation de l’objet client Interface ORB Cœur de l’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) GIOP / IIOP / ESIOP

13 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

14 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

15 Souche et squelette IDL
IDL stub IDL skeleton Object Implementation client ORB core GIOP / IIOP / ESIOP 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) Cœur de l’ORB GIOP / IIOP / ESIOP Adaptateur d’objet client Implémentation de l’objet Spécification IDL Compilateur IDL souche IDL Squelette IDL

16 Contient les proxies des objets distants auxquels le client accède
IDL stub Object Implementation client ORB core GIOP / IIOP / ESIOP 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)

17 Contient un aiguilleur de requêtes compilé (dispatcher)
IDL Skeleton Object Implementation client ORB core GIOP / IIOP / ESIOP 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

18 DII DSI Object Implementation client ORB core GIOP / IIOP / ESIOP 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

19 Dynamic Skeleton Interface
DSI Object Implementation client ORB core GIOP / IIOP / ESIOP 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

20 Dynamic invocation interface
DII Object Implementation client ORB core GIOP / IIOP / ESIOP 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”

21 Utilisation de DSI+DII si rien n’est connu à la compilation
Object Implementation User’s view client DII DSI Middleware IDL stub ORB interface Object Adapter ORB core

22 DII+IDL Skeleton method invocation le serveur possède une IDL mais le client ne la connaît pas …
Object Implementation client IDL skeleton DII ORB interface Object Adapter Interface repository ORB core

23 Basic Object Adapter Pas à l’usage du programmeur Rôle
Implementation client ORB core GIOP / IIOP / ESIOP Pas à l’usage du programmeur sauf pour init/enregistrement Object Adapter Rôle 1 1. activation de l’implémentation Object Implementation + divers “services” 4 4. invocation des méthodes (“upcalls” sur l’implémentation via le squelette IDL skeleton 3 3. activation des objets 2 2. enregistrement des implémentations

24 Communication

25 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)

26 “twoway method invocation”
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 x = S2->opB(10.2);

27 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 S2->opB(10.2);

28 Appel non blocant 2 “asynchronous call” méthodes du DII :
uniquement en utilisant le DII permet de récupérer des résultats méthodes du DII : send_deferred() get_response() poll_response()

29 Communication par passage de messages
Modèle d’événements (push / pull) communication asynchrone multiple producteurs / multiples consommateurs Prod 1 Prod 2 Cons 1 Cons 2 Cons 3 Pas en attente En attente Event Server Channel push(event) pull(event) push(event) pull(event)

30 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

31 Interface Definition Language (IDL)

32 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++

33 exemple de spécification IDL
const long N = 10; typedef double Vector[N]; interface example { typedef double Matrix[N][N]; attribute short status; boolean operation( in Vector A, out Matrix B ); }; Interface specification attribute specification method specification

34 éléments du langage IDL
Modules Interfaces Opérations (oneway, twoway) Attributs Déclarations de constantes types exceptions

35 espaces de nommage pour les définitions IDL
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]; …};

36 Description de la partie publique d’un objet
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 };

37 Seulement pour certains types
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

38 Renommage ou types def. par le programmeur
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<ecole> formation;

39 types de données Any Types constuits Référence objet Sequence Union
Types de base Array Enum Struct Floating Point Integer Boolean Octet Char String UShort ULong Float Double Short Long

40 N’est pas un type générique au sens objet
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”

41 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]; … } Interdit !

42 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;};

43 exceptions (suite) Exemple interface Account {
exception OverdrawnException {}; void deposit( in float amount ); void withdraw( in float amount ) raises ( OverdrawnException ); float balance(); };

44 Existent pour plusieurs langages
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

45 Mon premier programme CORBA

46 Mon premier programme CORBA
interface tty { void print(in string msg); }; spécification IDL class tty_impl : virtual public tty_skel { public: tty_impl() {}; ~tty_impl() {}; void print(const char* msg) { cout << msg << endl; }; implementation de l’objet

47 Mon premier programme CORBA
Serveur 1 1. Init ORB + BOA 2 2. Créer l’objet Service de nommage 4 4. construire le nom de l’objet et l’enregistrer (ref + nom) 3 3. Recup. ref. service de nommage 3 3. construire le nom de l’objet et recup. ref. objet à partir du nom 5 5. Activer l’objet puis attendre des invocations ORB 4. Invoquer une méthode 4 Client 1 1. Init ORB 2 2. Recup. ref. service de nommage Geek off

48 Implémentation du serveur
int main( int argc, char* argv[] ) { // initialisation de l’ORB et du BOA CORBA::ORB_var orb = CORBA::ORB_init(argc, argv, "mico-local-orb"); CORBA::BOA_var boa = orb->BOA_init( argc, argv, "mico-local-boa" ); // Créer l’objet tty_impl *afficheur = new tty_impl; // Récupérer la référence du service de nommage CORBA::Object_var nsobj = orb->resolve_initial_references("NameService"); CosNaming::NamingContext_var nc = CosNaming::NamingContext::_narrow( nsobj );

49 Implémentation du serveur
// Construire le nom de l’objet CosNaming::Name name; name.length( 1 ); name[0].id = CORBA::string_dup( "mytty" ); name[0].kind = CORBA::string_dup( "" ); //l’enregistrer sur le service de nommage nc->bind( name, afficheur ); //activer l’objet attendre les invocations boa->impl_is_ready( CORBA::ImplementationDef::_nil() ); orb->run(); }

50 Implémentation du client
int main( int argc, char* argv[] ) { // initialisation de l’ORB CORBA::ORB_var orb = CORBA::ORB_init(argc, argv, "mico-local-orb"); // Récupérer la référence du service de nommage CORBA::Object_var nsobj = orb->resolve_initial_references("NameService"); CosNaming::NamingContext_var nc = CosNaming::NamingContext::_narrow( nsobj );

51 Implémentation du client
//Construire le nom de l’objet CosNaming::Name name; name.length (1); name[0].id = CORBA::string_dup( "mytty" ); name[0].kind = CORBA::string_dup( "" ); //Retrouver la référence grâce au //service de nommage CORBA::Object_var obj = nc->resolve( name ); tty_var proxy = tty::_narrow( obj ); // Invocation de la méthode proxy ->print( ”là haut sur la montagne ..." ); }

52 Conclusion

53 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 ...