Introduction à CORBA. Contents. Pierre Gançarski. Octobre 2002

Transcription

1 Introduction à CORBA Pierre Gançarski Octobre 2002 Département d'informatique UFR de Mathématique et Informatique Université Louis Pasteur - Strasbourg Contents 1 Introduction Plate-forme La norme CORBA Construction et lancement d'une application Création des classes (cas de C++) Utilisation Le langage d'interfaces IDL Modules et interfaces Types de base et types construits Types de base et projection : Typedef Séquences Structures Attributs Opérations Déclaration Traitement des exceptions (cas de C++) Héritage Implantation par héritage de code Implantation par délégation Divers Gestion de la mémoire : Conversion de références d'objets Pierre.Gancarski@dpt-info.u-strasbg.fr 1

2 3 Compléments sur l'architecture globale de CORBA Le bus CORBA Caractèristiques principales du bus Les composantes du bus CORBA : Adaptateur d'objets Composantes CORBA Services d'objets communs - SO Utilitaires communs - UC Objets applicatifs - OA Interfaces du domaine - ID POA Présentation Servant Serveur Premier exemple Interface Implantation du service Le client Objets notoires et services Présentation Nommage Appel direct Binder Service de nommage Le référentiel des interfaces Le graphe des objets du référentiel Hiérarchie des interfaces IDL Exemples d'utilisation Appel dynamique 31 Bibliographie Corba, des concepts à la pratique, Jean-Marc Geib, Christophe Gransart & Philippe Merle, Ed Masson Mico, User's Guide Au coeur de Corba avec Java, Jérome Daniel, Ed.Vuibert 2

3 1 Introduction 1.1 Plate-forme Rappel sur les caractéristiques des applications distribuées : communication hétérogénéité au niveau des matériels et des systèmes intégration de l'existant à l'intérieur d'une entreprise intéropérabilité entre diérents systèmes de diérentes entreprises (mise en place de normes) Si il existe de nombreuses solutions pour faire communiquer des processus, celles-ci sont souvent de bas-niveau et ne sont pas intégrées directement dans les langages de programmation. De plus, même les RPC associés à XDR ne résolvent que les problèmes liés à la communication et à l'hétérogénéité (reste donc, l'intégration et l'interopérabilité) utilisation de plates-formes réparties (middleware) qui orent : l'indépendance entre les applications et le système : chaque système ore des interfaces de programmation spéciques pour contrôler les couches de communication. La plate-forme fournit aux applications des interfaces standardisées masquant les spécicités du système la portabilité des applications : ces interfaces standardisées permettent de concevoir des applications distribuées portables et indépendantes de l'environnement (peuvent être aisément recompilées) des services partagés : fonctionnalités système tels que la communication, la sécurité, les transactions, la localisation, la désignation, l'administration, etc. De fait, ces plates-formes sont standardisées pour être portables et interopérables dénitions entre constructeurs de middelware ouverts : DCE de l'osf, ou X/Open Une plate-forme répartie peut être vue aussi comme un bus qui permet d'interconnecter une ou plusieurs applications avec des services distribués et hétérogènes. Les interfaces standardisées permettant d'encher les applications et les services. Application Application Application Interfaces standardisées Plate-forme d intégration (services partagés distribués) communication environnement d exécution gestion réseau localisation sécurité outils... Interfaces spécifiques aux systèmes d exploitation Système d exploitation Système d exploitation réseau réseau matériel matériel 3

4 La norme CORBA CORBA (Common Object Request Brocker Architecture) est une telle plate-forme. Il est issus des travaux de l'omg (Object Management Group) et est basé sur la notion d'objets distribués : cette norme propose une architecture de gestion d'objets répartis (Object Management Architecture - OMA). Elle vise à prendre en compte toutes les fonctionnalités nécessaires à la construction d'applications réparties. Corba a été conçu pour permettre à des composants intelligents (des objets) de se découvrir les uns les autres et d'interopérer sur un bus. Mais en plus, cette norme dénit un vaste ensemble de services associés au bus qui permettent de créer/supprimer des objets, de leur assigner un nom, de les rendre persistant, d'externaliser leur état, de dénir des relations entre eux, de traiter des transactions,... Ainsi, grâce à ces services, on peut créer un objet ordinaire puis le rendre persistant et/ou fonctionnel par la simple utilisation de ces services. Ainsi, les objets Corba peuvent être distribués sur plusieurs sites nécessité de mécanisme d'appel de méthodes à distance. Le langage objet doit coopérer avec le système d'exploitation et les couches de communication réseau pour réaliser les invocations entre les objets localisés sur des sites distants. CORBA intègre donc un bus permettant la connection d'applications. Les objets communiquent alors de manière transparente par l'intermédiaire d'objets souche appelés aussi mandataire, proxies ou surrogates : Une souche-cliente (intégrée dans une interface) est un représentant local d'un objet distant : il connaît la localisation de l'objet et implante les mécanismes de communication pour invoquer l'objet (extension des RPC). Une souche-serveur (intégré dans le serveur) est une extension à un objet, cette extension étant chargée de transférer une demande distante (d'une souche-client) en un appel local de méthode. L'appel de méthode à distance peut se shématiser par : client 2 souche cliente 4 souche serveur objet serveur Processus client Processus serveur Réseau CORBA est construit sur ce mécanisme qui donne aux objets la capacité via des interfaces décrites initialement dans un langage propre à CORBA, le langage IDL (Interface Description Language) d'utiliser des services distants. 1.3 Construction et lancement d'une application. La mise en place d'une application CORBA nécessite : la construction des services, c'est-à-dire la création des classes d'objets capables de recevoir des demandes distantes (serveur) d'en envoyer (clients) 4

5 l'utilisation d'objets issus de ces classes. Création et utilisation d'une application Création des classes (cas de C++) Etape 1 : Description du service par une interface en ID, stockées dans un chier texte (par exemple Idate.idl) interface Idate { boolean Date(out string ladate); boolean Heure(inout short lheure); Etape 2 : Projection dans les langages cible (avec MICO 2.3.5, il faudra utiliser : idl boa no-poa Idate.idl) étape 2-a : Description de l'interface dans les langages cible (par exemple C++, chier Idate.h) class Idate { public: virtual CORBA::Boolean Date( CORBA::String_out date ) = 0; CORBA::Boolean Heure ( int *& lheure) = 0; ; étape 2-b : Création de l'interface client dans le langage cible (chier Idate.cc) soit approximativement class Idate { public: CORBA::Boolean Date ( CORBA::String_out ladate ) { CORBA::StaticRequest req( this, "Date" ); req.add_out_arg( &_ladate ); req.set_result( & res ); req.invoke(); return _res; ; // idem pour Heure 5

6 On voit que cette classe contient le code qui permet de traduire une demande à cette interface en une invocation distante : la méthode Date est traduite en l'appel distant req.invoke(). étape 2-c : Création du squelette de la classe, appelé aussi souche-serveur, des objets serveur (chier Idate.cc) class Idate_skel : public virtual Idate { public: // remarque : virtual CORBA::Boolean Date( CORBA::String_out date ) = 0; est héritée de Idate bool dispatch( CORBA::StaticServerRequest_ptr _req) { if( strcmp( _req->op_name(), "Date" ) == 0 ) { char* ladate;... _res = Date( ladate ); _req->write_results(); CORBA::string_free( ladate ); return true; if( strcmp( _req->op_name(), "Heure" ) == 0 ) {... // idem sauf que la fonction est : _res = Heure(lheure);... Cette classe contient le code qui permet de réceptionner une invocation distante et de la traduire en une demande de méthode locale : la fonction dispatch sert donc à recevoir les requêtes et à enclencher la méthode localement : elle est le pendant de invoke. Remarque importante Les étapes 2-a à 2-c sont automatiques et sont réalisées dans la commande idl Etape 3 : Création du serveur par dénition d'une classe d'objets capables de réaliser localement les fonctions. class Cdate : public virtual Idate_skel / / crée une classe héritant du squelette de serveur { // implantation des méthodes // remarque : virtual CORBA::Boolean Date( CORBA::String_out date ) = 0; est héritée de Idate // il faut maintenant la dénir : virtual CORBA::Boolean Date( CORBA::String_out date ) { date=corba::string_dup("vendredi "); return true; ; CORBA::Boolean Heure(int *& lheure) { if (lheure>=0) lheure =... ; return true; ; Utilisation Rappel : Pour pouvoir appeler un méthode distante l'objet doit : avoir une description de l'interface dans SON langage ; connaître l'identiant CORBA de l'objet serveur. En eet, pour pouvoir associer une interface à un objet distant, il est indispensable de connaître son IOR (Indentier Object Request) qui est son identiant universel. A partir de celui-ci, on peut le retrouver où qu'il soit dans le monde. L'opération d'association prendra donc comme parametre un tel IOR. Etape 4 : Utilisation 6

7 étape 4-a : Lancement du serveur int main(int argc, char *argv[]) { CORBA::ORB_ptr orb = CORBA::ORB_init(argc,argv,"mico-local-orb"); // Init. du Bus CORBA::BOA_ptr boa = orb->boa_init(argc,argv,"mico-local-boa"); // et du Basic OA 1 Cdate *mon_serveur = new Cdate; // Création d'un objet_serveur de Date // Traduction d'une référence d'objet en une chaîne de caractères : CORBA::String_var p = orb->object_to_string(mon_serveur); cerr < < (char *)p < < endl; // Achage de l'ior boa->impl_is_ready(); // Le BOA est prêt à recevoir des invocation distantes orb->run() Etape 4-b : Lancement du client. Du coté client on peut alors utiliser le service par : main (int argc, char **argv) { CORBA::ORB_ptr orb = CORBA::ORB_init(argc,argv,"mico-local-orb"); // Init. du Bus // Création d'un objet générique connecté avec l'objet d'ior argv[1] : CORBA::Object_var obj = orb->string_to_object(argv[1]); // Création d'un objet Idate connecté avec l'objet d'ior argv[1] via l'objet précédent : Idate_var mon_interface_client =Idate::_narrow(obj); CORBA::String_out date; mon_interface_client->date(date); // Appel au service cout < < "La date sur le serveur : " < < date < < endl; 2 Le langage d'interfaces IDL En Corba, toutes les interfaces doivent être dénies à l'aide du langage de dénition d'interface (Interface Denition Language) IDL. L'intérêt majeur du langage IDL est de permettre la dénition de contrats entre des fournisseurs de services et des utilisateurs. Ce contrat s'exprime sous la forme d'un ensemble d'interfaces clairement spéciées avec IDL : les clients ne voient pas les détails d'implantation. Les contrats IDL sont projetés dans les environnement de programmation pour donner des souches IDL pour les programmes clients et des squelettes IDL pour les fournisseurs. La norme Corba, donne des régles pour la projection des descriptions IDL en un langage cible. Elles représentent, par exemple pour C++, 4 chapîtres de la norme. Attention Le langage IDL est fortement inspiré de C++ mais ce n'est pas du C++!!!! 2.1 Modules et interfaces Un module est un espace de dénition décrivant d'une part une ou plusieurs interfaces et d'autre part, l'environnement (types, attributs, exceptions) nécessaire à celles-ci: espace de dénition : module < nom > { <ensemble de déclarations> ; 1 nous verrons dans le chapitre?? l'utilité du BOA 7

8 interface : interface <nom > { <ensemble de déclarations> ; exemple : module Planning { struct UneDate { short jour,mois,annee; ; typedef short Int; Attribute UneDate Aujourdhui; exception PasUneDate { UneDate d; interface Idate {... La traduction en MICO, nous donne (en gros) le type : struct Planning::UneDate { int jour,mois,annee; ; (cf 2.2) une classe Planning::Aujourdhui pour l'attribut (cf 2.3 ) une classe Planning::PasUneDate pour l'exception (cf 2.4.2) les classes Planning::Idate et Planning::Idate_skel 2.2 Types de base et types construits. Comme dit, IDL est proche de C++. Ainsi par exemple, les commentaires, les déclarations de type (typedef), de variables, les constructions de structures (struct), de classes sont identiques 2 à C++. Quelques ajouts dont principalement les séquences qui permettent de dénir des ensembles dynamiques de valeurs homogènes : le nombre d'éléments d'une séquence est xé à l'exécution Types de base et projection : CORBA IDL C++ Java short CORBA::Short short char CORBA::Char char double CORBA::Double double string CORBA::String String boolean CORBA::Boolean boolean Typedef Même syntaxe et utilisation qu'en C++ Exemple : typedef short Int; sera traduit par idl de MICO en C++ en : typedef CORBA::Short Int; Attention si le type C++ existe, la régle change : typedef CORBA::Short int; est traduit par : typedef CORBA::Short _cxx_int; 2 mais n'ont pas nécessairement les mêmes eets ou comportements! 8

9 2.2.3 Séquences Ce sont des tableaux de taille dynamique. Ainsi, typedef sequence<short> DesEntiers; ou typedef sequence<short,10> DesEntiers; déclare un tableau d'entiers de taille dynamique Leur projection en C++ sera, par exemple en MICO : typedef SequenceTmpl<CORBA::Short,MICO_TID_DEF> DesEntiers; et typedef BoundedSequenceTmpl<CORBA::Short,MICO_TID_DEF,10> DesEntiers_10; Structures Déclaration identique qu'en C++ Exemple : struct UneDate { short jour, mois, annee ; ; Sa projection en C++ sera, par exemple en MICO : struct UneDate { CORBA::Short jours; CORBA::Short mois; CORBA::Short annee; UneDate(); ~UneDate(); UneDate( const UneDate& s ); UneDate& operator=( const UneDate& s ); // toutes ces méthodes sont dénies automatiquement dans le.cc associé ; 2.3 Attributs Un attribut est une spécication décrivant une propriété d'un objet clairement dénie dans son interface. <mode> attribute <type> <nom>; Un attribut peut être accédé en lecture-écriture (mode par défaut) ou en lecture seulement (mode : readonly) Ainsi, interface Idate { attribute short Aujourdhui; sera traduit en MICO dans la classe Idate par une méthode : void Aujourdhui(int value) : qui donne une valeur à l'attribut d'une interface de type Idate int Aujourdhui() : qui rend la valeur de l'attribut Si le mode est readonly, il n'y a pas de méthode void Aujourdhui(int value). 9

10 2.4 Opérations Déclaration <mode d'invocation> <type> <nom> (<parametres>) [raises (<liste exception>)] [context (<liste contextes)]; avec : mode d'invocation : par défaut, un appel est synchrone (le client attend la n de l'opération). Le mode d'invocation oneway rend l'appel asynchrone. liste des paramètres : pour TOUS les paramètres il faut dénir leur mode de passage in : transport du client vers l'objet ; out : transport en retour de l'objet vers le client ; inout : transport dans un sens puis dans l'autre. liste des exceptions : indique les exceptions pouvant être déclenchées par cette opération (interdit en oneway) (cf 2.4.2) liste des contextes : permet de transmettre l'équivalent de variables d'environnement depuis le client vers les objets (peu utilisé) Exemple : interface Idate { exception NumeroNonValide { short num; ; Boolean DonnerDate(in short Numero_jours, out UneDate D) raises (NumeroNonValide); Le raises est indispensable pour que l'interruption soit transmise (du serveur) au client. Lors de l'implantation, l'invocation d'opération et l'accès à des attributs se font à travers le mécanisme d'appel de méthode du langage d'implantation (. en Java, -> ou. en C++). ATTENTION : IDL n'admet pas la surcharge des opérateurs. Passage de paramètres : langages. Les trois modes de passages des paramètres ne sont pas disponibles dans tous les Ainsi, en Java, seul le mode de passage par valeur est présent. Pour les modes inout ou out, le pré-compilateur génére, pour chaque type IDL, une classe conteneur composée d'un unique attribut. Ainsi, pour recevoir une valeur en sortie, le programmeur crée une instance d'une classe conteneur et l'opération stocke la valeur à retourner dans cet objet. C++ autorise les divers modes. 10

11 2.4.2 Traitement des exceptions (cas de C++) C++ permet de dénir des classes d'exceptions par : class mon_exception { ; mon_exception() {; mon_exception(< parametres >) { /* traitement */ ;... L'émission d'une exception se fait alors par : throw mon_exception(); ou throw mon_exception(< parametres >); On peut essayer d'exécuter une fonction (en gros, tester si elle s'est correctement terminée ou s'il y a eu l'émission d'une exception) par : try { fonction() catch (exception_1) { /* traitement 1 */ catch (exception 2) { /* traitement 2 */ /* etc. */ L'exception par défaut se note : catch (...) Ainsi, dans interface Idate { exception NumeroNonValide { short num; ; Boolean DonnerDate(in short Numero_jours, out UneDate D) raises (NumeroNonValide); l'exception sera traduite par : class Idate::NumeroNonValide { public: int num; NumeroNonValide(int N) { this->num = N ; // Corba dénit automatiquement ce constructeur NumeroNonValide() { ; ; Lorsque l'on écrira la fonction dans le serveur, on pourra émettre des exceptions grâce à throw : int Idate::DonnerDate(const int Numero_jours, UneDate & D) { if (Numero_jours >366) throw (Idate::NumeroNonValide(Numero_jours)); else... Lorsque l'on utilisera une interface S du type Idate, on pourra essayer la fonction par : try { 11

12 S.DonnerDate(i); catch (Idate::NumeroNonValide N) { cerr < < L'entier < < N.num < < est trop grand catch ( CORBA::COM_Failure) // Une exception CORBA pré-dénie { cerr < < Le serveur ne repond pas \n; catch (... ) { cerr < < Une erreur s'est produite lors de DonnerDate \n ; ; 2.5 Héritage IDL admet un héritage multiple à la seule condition qu'il n'y ait pas de conit d'héritage sur les attributs ou les opérations. Par contre, l'héritage répété ne pose pas de problemes. interface <nom-interface-derivee> : <nom classe mere> {... ; Prenons l'exemple suivant : interface Iecho { string Hello(in string msg); double Compte(in string msgr); ; interface Icar : Iecho { void EtVoila() ; ; Au niveau de l'implantation, deux approches possibles Implantation par héritage de code Avec un BOA class Cecho : virtual public Iecho_skel { public: virtual char *Hello(const char *msg) {... virtual double Compte(const char * msgr) {... ; class Ccar : virtual public Cecho, virtual public SD::Icar_skel { public: void EtVoila() {... ; Avec un POA (cf. 4) class Cecho : virtual public POA_Iecho {... ; class Ccar : virtual public Cecho, virtual public POA_Icar {... ; 12

13 2.5.2 Implantation par délégation Etape 1 : On dénit des classes d'objets à qui les interfaces transmettront les opérations à eectuer. class Cecho_Tie { public: virtual char *Hello(const char *msg) {... ; virtual double Compte(const char * msgr) {... ; class Ccar_Tie : virtual public Cecho_Tie { public: void EtVoila() {... ; ; Etape 2 : On instantie des objets de ce type, puis on crée les objets serveur qui recevront les requêtes int main( int argc, char *argv[] ) { // On crée les objets operations Cecho_Tie _cecho; Ccar_Tie _ccar; // On crée les serveurs POA_Iecho_tie<Cecho_Tie> echo_serveur (_cecho); POA_Icar_tie<Ccar_Tie> car_serveur (_ccar); Ces serveurs s'utilisent alors tels quels. 2.6 Divers Gestion de la mémoire : La gestion de la mémoire allouée dynamiquement est assurée en Java, par le mécanisme de ramasse-miette de Java. En C++, le précompilateur génére des classes assurant automatiquement de manière transparente la désallocation de la mémoire. Par convention, ces classes sont désignées par la concaténation du nom et du suxe _ptr (pour déclarer des pointeurs dits intelligents smart pointer) ou du suxe _var pour des variables simples. Dans les deux cas, la zone mémoire allouée sera automatiquement désallouée lorque plus aucune référence ne pointera dessus Conversion de références d'objets L'opération orb->string_to_object(argv[1]) permet de créer un objet a partir d'une chaîne de caracteres. Cet objet est du type CORBA::Object. C'est le type racine de la hiérarchie des classes. Pour pouvoir l'utiliser comme un objet sous-classe, il faut le convertir par Idate_var service = Idate::_narrow(obj); D'une manière générale, pour pouvoir se connecter à un objet, il faut connaitre sa référence. Il y a plusieurs possibilités : cette référence est connue par le client (écrit en dur) ; cette référence est stockée dans un chier ; cette référence est donnée en paramètre (c'est notre cas) ; 13

14 cette référence est notoire ; cette référence sera connue par un serveur de nom ; etc. 3 Compléments sur l'architecture globale de CORBA Corba décrit aussi 4 grandes catégories de composantes : des objets applicatifs ; des interfaces du domaine ; des utilitaires communs ; des services objets communs connectées via un bus de communications : Objets Applicatifs spécifiques et non standardisés Interfaces du domaine Utilitaires communs gestion administ. santé finance télécom gestion info taches système Bus de communication entre les objets répartis (bus Corba) Nommage Transactions Sécurite Services objet communs Temps Evénements Licences services orientés système 14

15 3.1 Le bus CORBA Caractèristiques principales du bus liaison avec les langages de programmation (C++, C, Eiel, Java, Smalltalk,...) via des interfaces en IDL (qui décrivent les services rendus, mais qui devront être traduites dans le langage cible) transparence totale des invocations : le bus CORBA transporte les invocations d'opérations sur les objets en choisissant automatique le meilleur moyen de transport un utilisateur a toujours l'impression de faire un appel local. invocation statique ou dynamique : CORBA fournit deux mécanismes distincts pour invoquer des objets statique : les invocations sont construites avant la compilation et vériées lors de celle-ci. Le résultat de la projection des descriptions IDL dans le langage cible forme alors le Static Invocation Interface (SII) : à chaque interface IDL est associée une interface d'invocation statique dynamique : à partir d'informations contenues dans le Référentiel des Interfaces (base de données encapsulées dans des objets CORBA, contenant toutes les dénitions IDL des objets) un programme peut via la Dynamique Invocation Interface (DII), construire dynamiquement une invocation. C'est plus souple mais ça ralenti l'exécution. De plus, l'utilisateur doit spécier chaque élément de la requête (objet cible, opération, paramètres, etc.) système auto-descriptif : le bus CORBA contient des métadonnées décrivant les interfaces des objets. Elles sont stockées dans le référentiel des interfaces. Ce référentiel contient aussi une version compilée de TOUS les composants logiciels du bus lui-même. Toute application peut donc invoquer directement les objets du bus activation automatique des objets : CORBA se charge d'activer les objets c'est-à-dire de réserver si nécessaire, de la place en mémoire et de leur trouver un environnement d'exécution. Plusieurs stratégies : un processus par objet, un processus pour plusieurs objet ou un processus par exécution d'opération communication entre diérents bus : CORBA dénit, sans imposer de technologie pour l'implanter, un ensemble de règles et de protocoles permettant le dialogue entre diérentes implantations de ce bus soit par des passerelles ou des demi-ponts convertissant les requêtes entre les diérents bus soit par l'utilisation de protocoles communs au niveau des requêtes : GIOP (General Inter-ORB Protocol) : permet d'instantier des protocoles d'interopérabilités réseau entre diérents fournisseur. Ainsi, le protocole d'interopérabilité sur internet, IIOP (Internet Inter-ORB Protocol) est une instance de GIOP pour TCP/IP ESIOP (Environment Specic Inter-ORB Protocol) : permet d'instantier des protocoles d'interopérabilités entre diérents environnements. Ainsi, DCE/CIOP (Distributed Computing Environment/Common Inter-ORB Protocol) permet, à partir de CORBA d'utiliser le mécanisme d'appel de DCE. 15

16 3.1.2 Les composantes du bus CORBA : Client Programmes utilisateur d objets Client & serveur Programmes fournisseurs d objets Serveur 4 Référentiel des interfaces 9 Référentiel des implantation 2 Interface d invocation Statique (SII) 3 Interface d Invocation Dynamique (DII) 5 Interface ORB 6 Interfaces de Squelettes Statiques 7 Interfaces de Squelettes Dynamique (DSI) Adaptateur d Objets 8 Interfaces de l Adaptateur d Objets 1 Noyau de l Object Request Brocker Protocole Inter-ORB Interbnet (IIOP) 1. noyau de communication : assure le transport des invocations 2. Interface invocation statique : vue précédemment 3. la DII remplace les stubs IDL dans le cas d'une découverte dynamique d'un service. Il permet d'obtenir la référence d'un service, de générer les paramètres, d'eectuer l'invocation et d'obtenir les résultats. 4. Référentiel d'interfaces : contient la base de données qu'utilise la DII pour obtenir les interfaces des services enregistrés. 5. interface de l'orb : fournit les primitives de base pour l'initialisation, le paramètrage de l'environnement de CORBA, l'instanciation des références ainsi que la gestion de la mémoire 16

17 6. interface de squelettes statiques (Static Skeleton Interface) : s'occupe de déballer les requêtes (et leurs paramètre) et d'emballer les résultats. C'est la partie serveur des stubs IDL. 7. interface de squelettes dynamiques (Dynamic Skeleton Interface) : permet de recevoir les requêtes sans disposer a priori des squelettes de déballages. Cette interface est par exemple, utilisée pour implanter des passerelles entre le bus et un autre environnement. 8. (interface de l') adaptateur d'objets (cf 17): Il se place au dessus des services de communication de l'orb. Il accepte les requêtes d'accès aux services des objets du serveur. Il constitue l'environnement d'exécution pour instancier, invoquer, assigner des référence objets. Il forme donc, le bloc fonctionnel auquel le noyau de communication délègue l'exécution des requêtes -> activation des processus portant les objets, requêtes à des bases de données, etc 9. référentiel des implantations : constitue la base de données des classes supportées, des objets instanciés et de leurs références objets. Il conserve aussi des informations complémentaires comme celles de suivi, d'audit, de sécurité et d'administration Adaptateur d'objets A un instant donné, tous les objets existant dans CORBA, ne sont pas nécessairement utilisés. L 'OMG a donc proposé un mécanisme associant DYNAMIQUEMENT une implantation à un objet CORBA C'est-à-dire : un espace mémoire pour stocker l'état d'un objet un contexte d'exécution pour ses opérations. Ce mécanisme est totalement transparent et est réalisé par les adaptateurs d'objets. Un AO se place au dessus des services de communication de l'orb. Il accepte les requêtes d'accès aux services des objets du serveur. Il constitue l'environnement d'exécution pour instancier, invoquer et assigner des référence objets, activer des processus portant les objets, traiter des requêtes à des BD, etc 4 catégories d'ao en fonction du mode d'activation: serveur partagé : 1 processus pour tous les objets serveur non partagé : 1 processus ou thread par objet serveur par méthode : 1 processus par requête serveur persistant : l'ao fonctionne en serveur partagé mais ses requêtes sont traitées par un ordonnanceur Il existe diérents types d'adaptateur d'objets : adaptateur élémentaire (Basic Object Adapter) 3, présent dans TOUTES les implantation de Corba. Il considère que les objets sont implantés directement dans des processus pouvant être indépendants ; adaptateur de bibliothèques d'objets (Library Object Adapter) prend en charge les objets Corba dont l'implantation est stockée dans des bibliotheques de codes ; 3 obsolète : remplacé par le POA (cf 4) 17

18 adaptateur de bases de donnéees objets (Object-Oriented Database Adapter) fait le liaison entre le bus Corba et une BDOO. Le BOA 4 constituait l'adaptateur objet minimal et orait les fonctionnalités suivantes : il pouvait gèrer le référentiel d'implantation qui contient par exemple, le nom des exécutables stockant le code d'implantation des objets ; il génèrait et interprètait les références objets ; il activait et désactivait les implémentations ; il appellait les méthodes à travers les squelettes et transfèrait les paramètres ; il authentiait le client. Malheureusement, cet adaptateur avait été sous-spécié et a donc donné lieu à des implantations diérentes des fonctionnalités. De plus, il s'est avéré insusant et incomplet. Un nouvel adaptateur a donc été spécié : le POA Portable Object Adaptator. (cf 4) 3.2 Composantes CORBA Services d'objets communs - SO (Corba Commun Object Services) : fournissent des abstractions aux fonctions système de base. Ils permettent d'écrire des applications réparties indépendantes des mécanismes sous-jacents du système. Actuellement environ 16 services ont été spéciés. Cycle de vie : décrit les interfaces et les opérations IDL pour la création, la copie, le déplacement et la destruction des objets du bus Nommage : fournit un système de désignation pour retrouver les objets à partir de noms symboliques Persistance : ore un ensemble uniforme d'interfaces an que les objets puissent être stockés Événement : permet aux objets de produire des événements asynchrones à destination d'autres objets via un canal d'événements Transaction : assure l'exécution de traitement transactionnel avec validation à deux phases Concurrence d'accès : fournit des mécanismes de verrous Relations : gère les relations (appartenance, inclusion, auteur,...) entre des objets Externalisation : apporte un mécanisme standard pour xer ou extraire des objets du bus Interrogations : permet d'interroger les attributs des objets (repose sur un SQL orienté objet ) Collections : permet de manipuler et eectuer des traitements itératifs sur des ensembles d'objets Licences : fournit des mécanismes pour mesurer, contrôler et limiter l'utilisation des objets CORBA ; Propriétés : permet aux utilisateurs d'associer dynamiquement des valeurs nommées (ou propriétés) à des objets en général sous forme de nouveaux attributs 4 encore disponible dans quelques implantations CORBA, dont Mico. 18

19 Sécurité : fournit les fonctions système permettant d'identier et d'authentier les clients des objets, de chirer et de certier les communications,... Temps : fournit des interfaces standards permettant d'obtenir une horloge globale sur le bus, de mesurer le temps et de synchroniser des objets Vendeur : équivaut à des pages jaunes où les fournisseurs de services décrivent leurs objets Changement : permet de gérer et suivre l'évolution des diérentes versions des objets Utilitaires communs - UC (Corba Facilities) : ce sont des canevas de composants logiciel orant des abstractions de haut niveau pour les applications. On en trouve actuellement 4 : interface utilisateur : collection de composants pour standardiser l'utilisation des interfaces Homme/Machine. gestion de l'information : regroupe des interfaces IDL pour modéliser l'information, pour son stockage structuré, pour l'échange d'informations entre toutes les applications, et pour le codage et la représentation de tout type d'information administration du système : contient des interfaces pour administrer, tester, congurer, exécuter et réparer des objets répartis donne ainsi, des interfaces : pour collecter des informations sur la charge de travail des composantes, sur les débits de communication, les erreurs et les pannes diverses pour administrer et dénir des politiques de sécurité ; pour suivre les instances pour ordonnancer etc.. gestion des tâches : contient des outils pour gérer les ux d'activités, les transactions longues, les agents, les règles, etc Objets applicatifs - OA (Application Objects ) : sont les objets spécialement développés pour l'application. Ils bénécient des fonctionnalités oertes par les objets standardisés de l'oma (SO,UC,ID) soit par invocation de leurs opérations soit par héritage d'interfaces. Ainsi par exemple, pour retrouver des objets disponibles sur le bus, les OA invoquent les opérations des services Nommage ou Vendeur. Pour recevoir des événements, ils héritent des interfaces IDL décrivant le service Événement et implantent les traitements associés à ces événements Interfaces du domaine - ID Ces interfaces fournissent des standards IDL pour assurer l'interopérabilité entre des objets destinés à des segments de marchés verticaux ou à des secteurs économiques. 19

20 4 POA 4.1 Présentation Le POA fournit un ensemble d'outils qui permettent d'aner le comportement d'un serveur et de contrôler le traitement d'une requête côté serveur. Trois éléments : servant : entité qui implante une interface IDL serveur : entité qui loge un ensemble de servants référence d'objet : vue cliente d'une interface IDL (son IOR) Servant Dans un BOA, c'est l'objet référence qui réalise directement le service : lorsqu'une réquête est envoyée à un IOR, c'est l'objet référencé par cet IOR qui réalise l'opération associée. Dans l'approche POA, un objet réalisant un service n'est pas directement accèdé : lorsqu'il a quelque chose à faire, c'est un objet d'implantation du service (un servant) qui reçoit la requête et qui la transmet à l'objet qui réalise alors réellement le service. Pourquoi? Cela permet d'associer plusieurs servants à un objet service. Les servants pouvant présenter des interfaces diérentes à condition bien sûr que l'objet service implante les méthodes correspondant aux diérentes interfaces Serveur Un serveur ou POA est un objet qui contient un ensemble de servants. Réciproquement, tout servant appartient à un serveur. Ainsi, pour pouvoir réaliser un service, il faut créer l'objet service et d'une part, disposer d'un POA et d'autre part, créer dans celui le(s) servant(s). Un POA dispose d'un ensemble de régles (policies) qui dénissent les traitements des requêtes : gestion de la le d'attentes des requêtes, concurrence, etc. La gestion des requêtes est alors assurée par un objet supplémentaire : le POA manager. 20

21 4.2 Premier exemple Interface interface Iecho { string Hello(in string msg); ; Implantation du service En Java Description du serveur dans le chier : IechoImpl.java public class IechoImpl extends IechoPOA { public String hello(string msg) { return "Hello " + msg + "from " + location; Lancement du serveur dans le chier : Server.java public class Server { public static void main(string[] args) { ORB orb = ORB.init( args, null ); //Initialisation d'un POA : Le RootPOA est le POA par défaut (toujours présent) POA poa = POAHelper.narrow( orb.resolve_initial_references( "RootPOA" )); // L'opération the_poamanager() donne le manager associé au POA : poa.the_poamanager().activate(); // Création de l'objet service IechoImpl UnServeurIecho = new IechoImpl( args[1] ); // Activation de l'objet => associe l'objet service à un servant et retourne la référence de ce servant : org.omg.corba.object obj_servant = poa.servant_to_reference(unserveuriecho); // on l'ache la référence de l'objet_servant : System.out.println(orb.object_to_string( obj_servant )); // on met l'orb en attente de requete : orb.run(); En C++ : class Cecho : virtual public POA_Iecho { public: virtual char *Hello(const char *msg) {... ; ; int main( int argc, char *argv[] ) { 21

22 CORBA::ORB_var orb = CORBA::ORB_init( argc, argv, "mico-local-orb" ); // Création de l'objet service Cecho* echo_serveur = new Cecho (); //Initialisation d'un POA CORBA::Object_var poaobj = orb->resolve_initial_references ("RootPOA"); // Le RootPOA est le POA par défaut : il est toujours présent PortableServer::POA_var poa = PortableServer::POA::_narrow (poaobj); PortableServer::POAManager_var mgr = poa->the_poamanager(); // L'opération the_poamanager() donne le manager associé au POA // Activation de l'objet => associe l'objet service à un servant et retourne l'id de ce servant dans le POA : PortableServer::ObjectId_var oid_echo = poa->activate_object (echo_serveur); // // Création de la référence (l'ior) correspondant au servant; CORBA::Object_var rref_echo = poa->id_to_reference (oid_echo.in()); // Achage de l'ior du servant cout < < " Reference de echo : " < < orb->object_to_string (ref_echo.in());str_echo; // Activation du POA via le POA manager mgr->activate (); // Lancement de l'application orb->run (); Le client En Java Fichier : Client.java public class Client { public static void main( String args[] ) { try { String ior_servant = args[ 0 ]; // on récupère l'ior du servant ORB orb = ORB.init( args, null ); // Création de l'objet de connection org.omg.corba.object obj = orb.string_to_object( ior_servant); // Connection d'une interface via l'objet de connection : Iecho UneInterfaceIecho = IechoHelper.narrow( obj ); // demande du service : 22

23 System.out.println( UneInterfaceIecho.hello("COUCOU ") ); catch( Exception ex ) { System.err.println( ex ); En C++ Aucune modication #include "Iecho.h" int main (int argc, char **argv) { CORBA::ORB_ptr orb = CORBA::ORB_init(argc,argv,"mico-local-orb"); CORBA::Object_var echo_obj = orb->string_to_object(argv[1]); Iecho_var echo=iecho::_narrow(echo_obj); // Accès à l'objet. CORBA::String_var reponse=(const char *)echo->hello("hello"); cout < < "Réponse du service : " < < reponse < < endl; 5 Objets notoires et services 5.1 Présentation Les objets notoires (on dit aussi services initiaux ) sont les objets CORBA primordiaux qui permettent de découvrir les autres objets disponibles sur le bus. Les trois principaux sont : le référentiels des interfaces (permet d'accèder aux métadonnés IDL) et les services Nommage et Vendeur (annuaires qui permettent de trouver des références de tout objet) Extrait de l'interface CORBA::ORB liée aux objets notoires : interface ORB { typedef string ObjectId; // nom symbolique des objets notoires typedef sequence <ObjectId> ObjectIdList ; ObjectIdList list_initial_services (); // donne la liste des objets notoires exception InvalidName {; Object resolve_initial_references (in ObjectId idnt) raises (InvalidName); // donne la référence d'un objet notoire à partir de son nom symbolique Exemple donnant la liste des objets notoires : int main(int argc, char *argv[]) { CORBA::ORB_ptr orb = CORBA::ORB_init(argc,argv,"mico-local_orb"); // demande de la liste des objets notoires 23

24 CORBA::ORB::ObjectIdList_var noms = orb->list_initial_services(); for (int i = 0; i < noms->length(); i++ ) { // achage de leurs noms cout < < " Service "< < i < < " : " < < noms[i] < < endl; // et de leurs IOR CORBA::Object_var myobjet = orb -> resolve_initial_references(noms[i]); CORBA::String_var pobjet = orb->object_to_string(myobjet); cout < < pobjet < < " \n"; 5.2 Nommage Appel direct Il est, en Mico, possible d'appeler directement une interface à la condition de connaitre l'adresse du serveur, adresse donnée par un nom de machine et un numéro de port. Exemple : L'interface module SD { ; interface Iecho { ; string Hello(in string msg); double Compte(in string msgr); Le serveur int main( int argc, char *argv[] ) { CORBA::ORB_var orb = CORBA::ORB_init( argc, argv, "mico-local-orb" ); CORBA::BOA_var boa = orb->boa_init (argc, argv, "mico-local-boa"); SD::Iecho_ptr serveur = new Cecho (); boa->impl_is_ready (CORBA::ImplementationDef::_nil()); orb->run (); Il faut alors le lancer en donnant un numéro de port : server -ORBIIOPAddr inet:ada.u-strasbg.fr:9911 Le client : 24

25 int main (int argc, char **argv) { CORBA::ORB_ptr orb = CORBA::ORB_init(argc,argv,"mico-local-orb"); CORBA::BOA_ptr boa = orb->boa_init(argc,argv,"mico-local-boa"); cout < < " Récupération de l'ior associé à l'objet. " < < endl; CORBA::Object_var obj = orb->bind("idl:sd/iecho:1.0", "inet:ada.u-strasbg.fr:9911"); SD::Iecho_var echo=sd::iecho::_narrow(obj); CORBA::String_var reponse=(const char *)echo->hello("hello"); // etc Binder Il est aussi possible d'obtenir une interface en interrogant directement le démon d'implantation des objets (le BOA) : Au lieu de lancer le serveur par : server -ORBIIOPAddr inet:ada.u-strasbg.fr:9011, on le lance normalement par server. Par contre l'adresse déclarée dans le client sera celle du serveur micod sur la machine serveur : inet:ada.u-strasbg.fr: Service de nommage Le service Nommage (Naming service) fourni un système de désignation pour retrouver les objets à partir de noms symboliques. Il est structuré en graphes de répertoires contenant les références des objets. Un objet notoire du type CosNaming appelé NameService assure l'interface avec le service de noms. Il faut donc avant tout l'obtenir par :(cf 5) CORBA::Object_var initserv; initserv = orb->resolve_initial_references("nameservice"); Le service étant organisé en contextes, il faut interroger le contexte racine par une interface appropriée : CosNaming::NamingContext_var ContexteRacine; ContexteRacine = CosNaming::NamingContext::_narrow(initServ); Le serveur Il va créer les contextes et associer des noms symboliques de service avec des références d'objets (IOR). en C++ s.a) création d'un contexte appelé Systemes CosNaming::Name PremierNom; PremierNom.length(1); PremierNom[0].id = (const char*) "Systemes"; // string copied PremierNom[0].kind = (const char*) "my_context"; 25

26 Remarque : on peut voir le type CosNaming::Name comme un formulaire permettant de décrire un nom. Ce formulaire permet de demander au serveur de noms de réaliser une action : tant que ce formulaire n'est pas envoyé au serveur de noms, RIEN n'est fait! D'ou l'appel suivant // ajout de ce contexte au contexte racine CosNaming::NamingContext_var PremierContexte = ContexteRacine->bind_new_context(PremierNom); qui demande au serveur de noms de créer réellement le contexte. s.b) création d'un sous contexte nommé Distribues : CosNaming::Name DeuxiemeNom; DeuxiemeNom.length(1); DeuxiemeNom[0].id = (const char*) "Distribues"; DeuxiemeNom[0].kind = (const char*) "my_context"; CosNaming::NamingContext_var DeuxiemeContexte= => on obtient donc un contexte Systemes/Distribues. PremierContexte->bind_new_context(DeuxiemeNom); s.c) Association dans le contexte Systemes/Distribues, d'un objet 5 avec un nom symbolique donné par le nouveau formulaire objectname : CosNaming::Name objectname; objectname.length(1); objectname[0].id = (const char*) "Echo"; objectname[0].kind = (const char*) "Object"; DeuxiemeContexte->bind(objectName,serv); Le client c.a) Crée un nom par : CosNaming::Name UnNom; UnNom.length(3); UnNom[0].id = (const char*) "Systemes"; UnNom[0].kind = (const char*) "my_context"; UnNom[1].id = (const char*) "Distribues"; UnNom[1].kind = (const char*) "my_context"; UnNom[2].id = (const char*) "Echo"; UnNom[2].kind = (const char*) "Object"; c.b) puis demande l'association d'un objet avec ce nom : CORBA::Object_ptr obj; obj = ContexteRacine->resolve(UnNom); c.c) enn, il fait la conversion explicite vers le type d'interface qu'il désire utiliser : 5 en l'occurence, serv qui est l'objet serveur créé précédemment par : Echo_i * serv= new Echo_i() 26

27 Echo_var expl_obj = Echo::_narrow(obj); c.d) Il peut alors utiliser directement les services oerts par le serveur serv a travers l'objet expl_obj. En Java. Le cheminement est totalement similaire 6. Le service public class IechoImpl extends IechoPOA { public double Compte(String msgr) { return 100; Le serveur :::::::::::::: Server.java :::::::::::::: import org.omg.cosnaming.*; public class Server { public static void main(string[] args) { ORB orb = ORB.init( args, null ); POA poa = POAHelper.narrow( orb.resolve_initial_references( "RootPOA" )); poa.the_poamanager().activate(); // creation d'un objet Iecho IechoImpl UnServeurIecho = new IechoImpl( "Un ESSAI" ); org.omg.corba.object obj = poa.servant_to_reference(unserveuriecho); // ======Declaration de cet objet au serveur de nom ============== // 1 - Connection sur le serveur de noms org.omg.corba.object initserv = null; try { initserv = orb.resolve_initial_references("nameservice"); catch ( org.omg.corba.orbpackage.invalidname name ) { System.out.println(" Gasp..."); // 2 - Interfaçace du serveur de nom NamingContextExt rootcontext = org.omg.cosnaming.namingcontextexthelper.narrow(initserv); // 3 - Declaration d'un contexte NameComponent[] namecomp = new NameComponent[1]; namecomp[0] = new NameComponent("rst","context"); NamingContext repo = rootcontext.bind_new_context( namecomp ); NamingContextExt rstsubcontext = NamingContextExtHelper.narrow(repo); // 4 - Association du nom et de l'ior NameComponent[] Objectname = new NameComponent[1]; Objectname[0] = new NameComponent("Iecho","mon_service"); rstsubcontext.bind( Objectname, obj); orb.run() ; 6 les codes donnés dansla suite ne sont pas complets (ils ne comprennent que les parties liées au service de noms) 27

28 Le client :::::::::::::: Client.java :::::::::::::: import org.omg.cosnaming.*; public class Client { public static void main(string[] args) { ORB orb = ORB.init( args, null ); // 1 - Connection sur le serveur de noms org.omg.corba.object initserv = null; try { initserv = orb.resolve_initial_references("nameservice"); catch ( org.omg.corba.orbpackage.invalidname name ) { System.out.println(" Gasp..."); // 2 - Interfaçace du serveur de nom NamingContextExt rootcontext = org.omg.cosnaming.namingcontextexthelper.narrow(initserv); // 3 - Construction du contexte NameComponent[] namecomp = new NameComponent[2]; namecomp[0] = new NameComponent("rst","context"); namecomp[1] = new NameComponent("Iecho","mon_service"); // 4 - Résolution du nom et interfaçage Object obj=rootcontext.resolve(namecomp); Iecho UneInterfaceIecho = IechoHelper.narrow( obj ); // 5 - Invocation: System.out.println( UneInterfaceIecho.Compte("COUCOU ") ); 5.3 Le référentiel des interfaces Le bus CORBA est un environnement auto-descriptif car il permet de découvrir et d'exploiter dynamiquement les interfaces des objets CORBA. Ces dénitions IDL sont entreposées dans une base de données appelée Référentiel des Interfaces (Interface Repository, IR). L'IR est structuré par un ensemble d'objets décrits par des interfaces IDL donc accessibles à travers le bus CORBA Le graphe des objets du référentiel Chaque type d'objets de ce graphe représente un élément syntaxique du langage IDL. Il est structuré par les neuf principales interfaces suivantes : Repository : décrit l'objet racine du référentiel. À partir de cet objet, il est possible de découvrir les autres objets du référentiel ; ModuleDef : décrit les objets encapsulant les modules IDL. Fournit des opérations pour découvrir, ajouter et supprimer des objets encapsulant les dénitions contenues dans les modules ; InterfaceDef : décrit les objets encapsulant les interfaces IDL. Fournit des opérations pour découvrir les opérations et attributs fournis par une interface. 28

29 AttributeDef : décrit les objets encapsulant les attributs IDL ; OperationDef : décrit les objets encapsulant les opérations IDL. Elle permet d'obtenir la liste des paramètres et des exceptions de chaque opération => permet de construire des requêtes grâce à l'interface d'invocation dynamique ; ParameterDef : décrit les objets encapsulant les paramètres des opérations IDL ; ExceptionDef : décrit les objets encapsulant les exceptions IDL ; TypedefDef : décrit les objets encapsulant les types de données IDL ; ConstantDef : décrit les objets encapsulant les constantes IDL ; Hiérarchie des interfaces IDL Les interfaces de ces neuf classes sont dérivées de 4 interfaces abstraites : IRObject : fournit l'opération def_kind indiquant le type de dénition contenue dans un objet IR. IDLType : est l'abstraction de base des objets IR encapsulant un type IDL -> sera dérivée pour représenter les interfaces d'objets, (InterfaceDef), les types nommés (TypedefDef) et les autres types de données (primitifs, chaînes, séquences et tableaux) ; Container : est l'abstraction de base des types de l'ir dénissant des espaces de nommage IDL. Elle permet de rechercher, de découvrir et de créer les objets contenus dans les espaces de nommage -> sera dérivée en Repository, ModuleDef, OperationDef et InterfaceDef ; Contained : décrit le comportement des objets contenus dans des objets Container. L'opération describe retourne pour chacun des objets contenus une structure décrivant les métadonnées associées à l'objet. Les interfaces AttributesDef, ExceptionDef, ConstantDef, ParameterDef et TypedefDef en héritent. Idem pour ModuleDef, OperationDef et InterfaceDef car elles dénissent également des objets pouvant être contenus D'où le graphe d'héritage : IRObject Contained IDLtype Container AttributeDef Repository ExceptionDef ModuleDef ParameterDef OperationDef ConstantDef InterfaceDef TypedefDef PrimitiveDef StringDef SequenceDef ArrayDef StructDef UnionDef EnumDef AliasDef 29