Common Object Request Broker Architecture (CORBA)

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

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. 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. Appelant Souche Appelant Appelé Squelette Appelé Network Comment passer du centralisé au réparti ? • Casser les structures existantes • insérer des appels de procédure/de méthode à distance • 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. What isCORBA ? • 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 • CORBA = Common Object Request Broker Architecture • 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. Paramètres d’entrée (in) Ma_méthode(in mon_paramètre out mon_résultat) valeur de retourParamètres de sortie (out) Vue duprogrammeur DSI squelette IDL InterfaceORB SoucheIDL DII Adaptateur d’objet Protocoles GIOP / IIOP / ESIOP Coeur de l’ORB Implementationde l’objet Client Niveau interstitiel (middleware)

12. ORB Implementation de l’objet client InterfaceORB • 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) Cœur de l’ORB 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. Object Implementation client IDL skeleton IDL stub ORB core GIOP / IIOP / ESIOP Implémentation de l’objet client Squelette IDL Compilateur IDL soucheIDL Adaptateur d’objet Cœur de l’ORB GIOP / IIOP / ESIOP 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) Spécification IDL

16. Object Implementation client IDL stub 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. Object Implementation client IDL Skeleton 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. Object Implementation client DSI DII 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. Object Implementation client DSI 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. Object Implementation client DII 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. DSI DII Utilisation de DSI+DIIsi rien n’est connu à la compilation User’s view Object Implementation client Middleware IDL stub ORB interface Object Adapter ORB core

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

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

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. x = S2->opB(10.2); 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

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

28. 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()

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

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

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

48. Implémentation du serveur int main( int argc, char* argv[] ) { // initialisation de l’ORB et du BOACORBA::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’objettty_impl *afficheur = new tty_impl; // Récupérer la référence du service de nommageCORBA::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’objetCosNaming::Name name;name.length( 1 );name[0].id = CORBA::string_dup( "mytty" );name[0].kind = CORBA::string_dup( "" ); //l’enregistrer sur le service de nommagenc->bind( name, afficheur ); //activer l’objet attendre les invocationsboa->impl_is_ready(CORBA::ImplementationDef::_nil() );orb->run();}

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