Cours sur CORBA - LITIS
publicité
NFP111 — Systèmes et Applications Réparties 1 de 32 Plan La notion de contrat Exemple NFP111 — Systèmes et Applications Réparties Cours 8 - CORBA/Partie 2 - Le langage IDL Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Claude Duvallet Université du Havre UFR Sciences et Techniques 25 rue Philippe Lebon - BP 540 76058 LE HAVRE CEDEX Courriel : [email protected] http://litis.univ-lehavre.fr/∼duvallet/ NFP111 — Systèmes et Applications Réparties 2 de 32 Plan La notion de contrat (1/3) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Le langage OMG-IDL (Interface Definition Language) : Permet d’exprimer sous la forme de contrats IDL la coopération entre les fournisseurs et les utilisateurs de services. Sépare l’interface de l’implantation des objets. Masque les divers problèmes liés à l’interopérabilité dont l’hétérogénéité des langages. Un contrat IDL spécifie les types manipulés pour un ensemble d’applications réparties : Les types d’objets (ou interfaces IDL). Les types de données échangées entre les objets. Le contrat IDL : Isole les clients et fournisseurs de l’infrastructure logicielle et matérielle. Les met en relation à travers le bus CORBA. NFP111 — Systèmes et Applications Réparties 3 de 32 Plan La notion de contrat (2/3) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Les contrats IDL sont projetés : En souches IDL (ou interface d’invocations statiques SII) dans l’environnement de programmation du client. En squelettes IDL (ou interface de squelettes statiques SSI) dans l’environnement de programmation du fournisseur. Le client invoque localement les souches pour accéder aux objets. Les souches construisent des requêtes : qui vont être transportées par le bus, puis délivrées par celui-ci aux squelettes qui les délégueront aux objets. NFP111 — Systèmes et Applications Réparties 4 de 32 Plan La notion de contrat (3/3) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Client Souche Contrat IDL Bus CORBA Serveur Squelette NFP111 — Systèmes et Applications Réparties 5 de 32 Plan Exemple (1/3) La notion de contrat Exemple Constructions IDL #pragma prefix "univ-lehavre.fr" module date { typedef short Annee; typedef sequence<Annee> DesAnnees; Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique enum Mois { Janvier, Fevrier, Mars, Avril, Mai, Juin, Juillet, Aout, Septembre, Octobre, Novembre, Decembre }; typedef sequence<Mois> DesMois; enum JourDansLaSemaine { Lundi, Mardi, Mercredi, Jeudi, Vendredi, Samedi, Dimanche }; typedef sequence<JourDansLaSemaine> DesJoursDansLaSemaine; typedef unsigned short Jour; typedef sequence<Jour> DesJours; struct Date { Jour le_jour; Mois le_mois; Annee l_annee; }; NFP111 — Systèmes et Applications Réparties Plan Exemple (2/3) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique typedef sequence<Date> DesDates; union DateMultiFormat switch(unsigned short) { case 0: string chaine; case 1: Jour nombreDeJours; default: Date date; }; typedef sequence<DateMultiFormat> DesDateMultiFormats; exception ErreurInterne {}; exception MauvaiseDate { DateMultiFormat date; }; interface Traitement { boolean verifierDate(in Date d); JourDansLaSemaine calculerJourDansLaSemaine(in Date d) raises(ErreurInterne, MauvaiseDate); long nbJoursEntreDeuxDates(in Date d1, in Date d2) raises(MauvaiseDate); void dateSuivante (inout Date d, in Jour nombreJours) raises(MauvaiseDate); }; 6 de 32 NFP111 — Systèmes et Applications Réparties 7 de 32 Plan Exemple (3/3) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique interface Convertisseur { Jour convertirDateVersJourDansAnnee(in Date d) raises(MauvaiseDate); Date convertirChaineVersDate(in string chaine) raises(MauvaiseDate); string convertirDateVersChaine(in Date d) raises(MauvaiseDate); attribute Annee annee_courante; // Fixer l’année courante pour l’opération suivante. Date convertirJourDansAnneeVersDate(in Jour jour); readonly attribute Annee base_annee ; // L’année de référence pour les opérations suivantes. Date convertirJourVersDate(in Jour jour); Jour convertirDateVersJour(in Date d) raises(MauvaiseDate); void obtenirDate (in DateMultiFormat dmf, out Date d) raises(MauvaiseDate); }; interface ServiceDate : Traitement, Convertisseur { }; NFP111 — Systèmes et Applications Réparties 8 de 32 Plan Bilan sur l’exemple La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Le langage IDL permet : d’exprimer simplement les types de données et d’objets manipulés par un service CORBA, indépendamment de tout aspect d’implantation (langages, systèmes d’exploitation, machines et réseaux) et/ou de répartition. Le choix des identificateurs de ces types est déterminant pour une lecture aisée d’une spécification IDL. NFP111 — Systèmes et Applications Réparties 9 de 32 Plan Constructions IDL (1/7) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Un pragma permet de fixer les identifiants désignant les définitions IDL à l’intérieur du référentiel des interfaces. Les identifiants assurent une désignation unique des définitions IDL quel que soit le référentiel des interfaces consulté. Ils sont utilisés pour fédérer des IFR. La forme la plus utilisée est le pragma prefix qui fixe l’organisation définissant un contrat IDL en utilisant son nom de domaine Internet. Le pragma version permet de définir le numéro de version d’une spécification IDL. Un module sert à regrouper des définitions de types qui ont un intérêt commun. Permet aussi de limiter les conflits de noms pouvant intervenir entre plusieurs spécifications. NFP111 — Systèmes et Applications Réparties 10 de 32 Plan Constructions IDL (2/7) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Les conflits de nom de module sont réglés par le pragma prefix. Les types de données de base sont : void, short, unsigned short, long, unsigned long, long long (64 bits), unsigned long long, float, double, long double (128 bits), boolean, octet, char, string, wchar et wstring (format de caractères international) et fixed pour les nombres à précision fixe. Corba par la pratique Le format binaire de ces types est défini par la norme afin de régler les problèmes d’échanges de données entre environnements hétérogènes. Les types de méta-données (TypeCode et any) sont une composante spécifique à IDL : Le type TypeCode permet de stocker la description de n’importe quel type IDL. Le type any permet de stocker une valeur IDL de n’importe quel type en conservant son TypeCode. NFP111 — Systèmes et Applications Réparties 11 de 32 Plan Constructions IDL (3/7) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Ces méta-types permettent de spécifier des contrats IDL génériques indépendants des types de données manipulés, Par exemple une pile d’any stocke n’importe quelle valeur. Une constante se définit par un type simple, un nom et une valeur évaluable à la compilation const double PI = 3.1415 ; Un alias (typedef) permet de créer de nouveaux types : Par exemple, il est plus clair de spécifier qu’une opération retourne un Jour plutôt qu’un entier signé. Une énumération (enum) définit un type discret via un ensemble d’identificateurs. Par exemple : énumérer les jours de la semaine plutôt que d’utiliser un entier. NFP111 — Systèmes et Applications Réparties 12 de 32 Plan Constructions IDL (4/7) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Une structure (struct) définit une organisation regroupant des champs : Cette construction est fortement employée car elle permet de transférer des structures de données composées entre objets CORBA. Une union juxtapose un ensemble de champs, le choix étant arbitré par un discriminant de type simple (entiers, caractère, booléen ou énumération). Un tableau (array) sert à transmettre un ensemble de taille fixe de données homogènes. Une séquence permet de stocker/transférer un ensemble de données homogènes dont la taille sera fixée à l’exécution. Une exception spécifie une structure de données permettant à une opération : de signaler les cas d’erreurs ou de problèmes exceptionnels pouvant survenir lors de son invocation. NFP111 — Systèmes et Applications Réparties 13 de 32 Plan Constructions IDL (5/7) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Une interface décrit les opérations fournies par un type d’objet CORBA (Traitement et Convertisseur). Une interface IDL peut hériter de plusieurs autres interfaces (ServiceDate). L’héritage multiple est autorisé : On parle d’héritage de spécifications. La seule contrainte imposée est qu’une interface ne peut pas hériter de deux interfaces qui définissent des opérations de mêmes noms. Ce problème doit être résolu manuellement en évitant/éliminant les conflits de noms. La surcharge est donc interdite en IDL. Un objet CORBA ne peut implanter qu’une seule interface IDL. CORBA 3.0 doit intégrer la notion d’interfaces multiples (Java, COM). NFP111 — Systèmes et Applications Réparties 14 de 32 Plan Constructions IDL (6/7) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Une opération se définit par : Une signature qui comprend le type du résultat, le nom de l’opération, la liste des paramètres et la liste des exceptions. Un paramètre se caractérise par un mode de passage, un type et un nom formel : Les modes de passages autorisés sont in, out et inout. Le résultat et les paramètres peuvent être de n’importe quel type exprimable en IDL. Par défaut, l’invocation d’une opération est synchrone, cependant, il est possible de spécifier qu’une opération est asynchrone (oneway), le résultat est de type void, tous les paramètres sont en mode in, aucune exception ne peut être déclenchée. NFP111 — Systèmes et Applications Réparties 15 de 32 Plan Constructions IDL (7/7) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique CORBA ne spécifie pas complètement l’opération oneway : l’invocation peut échouer, être exécutée plusieurs fois sans que l’appelant ou l’appelé en soient informés. Un attribut exprime une paire d’opérations pour consulter et modifier une propriété d’un objet : Il se caractérise par un type et un nom. On peut spécifier si l’attribut est en lecture seule (readonly) ou consultation/modification (mode par défaut). Le terme IDL attribut est trompeur, l’implantation d’un attribut IDL peut être faite par un traitement quelconque. NFP111 — Systèmes et Applications Réparties 16 de 32 Plan Les limites d’IDL (1/2) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Types limités en nombre : L’utilisateur ne peut pas en ajouter facilement. L’OMG ne s’interdit pas d’introduire de nouveaux types au fur et à mesure des besoins : Les entiers 64 bits, les réels 128 bits, les caractères internationaux (Unicode) n’étaient pas présents dans les premières versions de la norme CORBA. L’impossibilité de spécifier des types intervalles (pratique pour exprimer des intervalles de temps). L’impossibilité de sous-typer (d’étendre) la définition d’une structure ou d’une union. L’interdiction de conflits de noms à l’intérieur d’un module ou d’une interface : implique l’interdiction de surcharger des opérations. NFP111 — Systèmes et Applications Réparties 17 de 32 Plan Les limites d’IDL (2/2) La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Le passage par valeur de structures de données et non d’objets : Si l’on veut transférer un graphe d’objets, il faut l’aplatir dans une séquence de structures (évolutions de CORBA 3.0). Le langage OMG-IDL ne sert pas à exprimer la sémantique des objets : Comme des contraintes, des pré et post conditions sur les opérations. Des invariants. L’expression de la sémantique permettrait : De tester et valider automatiquement les objets. De décrire la qualité de service, c’est-à-dire les caractéristiques d’une implantation. NFP111 — Systèmes et Applications Réparties 18 de 32 Plan La notion de contrat Projection IDL vers un langage de programmation (1/2) Exemple Constructions IDL Limites d’IDL Projection (mapping, correspondance) est la traduction d’une spécification IDL dans un langage d’implantation. Projection IDL vers un langage de programmation Pour permettre la portabilité des applications d’un bus vers un autre : Corba par la pratique les règles de projection sont normalisées, elles fixent précisément la traduction de chaque construction IDL en une ou plusieurs constructions du langage cible, ces règles existent pour les langages C, C++, SmallTalk, Ada, Java et Cobol orienté objet. NFP111 — Systèmes et Applications Réparties 19 de 32 Plan La notion de contrat Projection IDL vers un langage de programmation (2/2) Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Réalisation de la projection : La projection est réalisée par un pré-compilateur IDL dépendant du langage cible et de l’implantation du bus CORBA : chaque produit CORBA fournit un pré-compilateur IDL pour chacun des langages supportés. Le code des applications est alors portable d’un bus à un autre : Les souches/squelettes générés s’utilisent toujours de la même manière quel que soit le produit CORBA. Par contre, le code des souches et des squelettes IDL n’est pas forcément portable : il dépend de l’implantation du bus pour lequel ils ont été généré. NFP111 — Systèmes et Applications Réparties 20 de 32 Plan Étapes (1/3) La notion de contrat Exemple 1 définir les objets composants l’application à l’aide d’une méthodologie orientée objet. cette modélisation est ensuite traduite sous la forme de contrats IDL. Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Définition du contrat IDL : 2 Pré-compilation du contrat IDL : les interfaces des objets sont décrites dans des fichiers textes, le pré-compilateur prend en entrée un tel fichier et opère un contrôle des définitions IDL, le pré-compilateur peut aussi charger ces définitions dans le référentiel des interfaces. NFP111 — Systèmes et Applications Réparties 21 de 32 Plan Étapes (2/3) La notion de contrat Exemple 3 le pré-compilateur IDL génère : le code des souches qui sera utilisé par les applications clientes des interfaces décrites dans le fichier IDL, le code des squelettes pour les programmes serveurs implantant ces types. Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Projection vers les langages de programmation : 4 Implantation des interfaces IDL : en complétant et/ou en réutilisant le code généré pour les squelettes, le développeur implante les objets. Corba par la pratique 5 Implantation des serveurs d’objets : Le développeur écrit les programmes serveurs qui incluent l’implantation des objets et les squelettes prégénérés. Ces programmes contiennent le code pour : se connecter au bus, instancier les objets racines du serveur, rendre publiques les références sur ces objets à l’aide par exemple du service Nommage, se mettre en attente de requêtes pour ces objets. Le nombre de programmes serveurs est souvent limité. NFP111 — Systèmes et Applications Réparties 22 de 32 Plan Étapes (3/3) La notion de contrat Exemple 6 Le développeur écrit un ensemble de programmes clients qui agissent sur les objets. Ces programmes incluent le code des souches, le code pour l’IHM et le code spécifique à l’application. Les clients obtiennent les références des objets serveurs en consultant le service Nommage. Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique Implantation des applications clientes des objets : 7 Installation et la configuration des serveurs : Cette phase consiste à installer dans le référentiel des implantations les serveurs pour automatiser leur activation lorsque des requêtes arrivent pour leurs objets. 8 9 Diffusion et la configuration des clients. Exécution répartie de l’application. NFP111 — Systèmes et Applications Réparties 23 de 32 Plan Conclusion La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique L’interopérabilité entre langages, systèmes d’exploitation, machines et réseaux. La portabilité du code : les fragments de code présentés sont totalement portables d’une implantation du bus à une autre. Encapsulation de l’existant : La réutilisation de codes existants (voire même d’applications complètes) peut être réalisée par encapsulation de ceux-ci dans des objets CORBA. Ces objets sont alors utilisables pour bâtir de nouvelles applications. NFP111 — Systèmes et Applications Réparties 24 de 32 Plan Perspectives La notion de contrat Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique CORBA 1.0 avait pour objectif l’interopérabilité entre objets distribués. CORBA 2.0 avait donc comme objectif principal d’offrir cette interopérabilité via le protocole GIOP et IIOP. CORBA 3.0 : Multiples Interfaces and Composition fournira les mécanismes permettant à un objet CORBA d’implanter plusieurs interfaces IDL. Messaging Service définit un nouveau modèle de communication asynchrone lorsque l’objet appelant et l’objet appelé ne sont pas présents simultanément sur le bus (via des requêtes persistantes). Persistent State Service 2.0 sera une spécification simplifiée du service Persistance. CORBA Component Model définira un modèle de composants pour le monde CORBA en s’inspirant par exemple du modèle JavaBeans. NFP111 — Systèmes et Applications Réparties 25 de 32 Plan Corba par la pratique La notion de contrat Exemple Constructions IDL Comment construire de programmes utilisant CORBA ? Il vous faut un ORB permmetant de mettre en œuvre le bus CORBA. On peut utiliser celui qui est intégré au JDK mais alors on ne pourra programmer qu’en JAVA. D’autres ORB permettent de programmer dans des langages divers. On prendra comme exemple l’ORB ORBacus qui permet de programmer en C++ et en JAVA. Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique On va commencer simplement en utilisant l’ORB du JDK. Soit l’exemple du programme HelloWorld programmé de deux manières différentes : sans utiliser de Naming Service mais avec un fichier contenant la référence de l’objet sur le bus CORBA. 2 en utilisant le Naming Service pour enregistrer et retrouver la référance de l’objet sur le bus CORBA. 1 NFP111 — Systèmes et Applications Réparties 26 de 32 Plan La notion de contrat Le programme HelloWorld sans Naming Service (1/6) Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique On commence par définir la structure de l’objet à partager au moyen d’un fichier IDL : // Hello.idl interface Hello { void sayHello(); }; Ensuite, il nous faut compiler (effectuer une projection vers le langage JAVA) au moyen de la commande suivante idlj -fallTIE Hello.idl. Examiner les fichiers JAVA qui ont été automatiquement générés lors de la projection. NFP111 — Systèmes et Applications Réparties 27 de 32 Plan La notion de contrat Le programme HelloWorld sans Naming Service (2/6) Exemple Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Il faut passer à l’implémentation de l’objet distribué et de ses fonctionnalités : // Hello_impl.java package hello; public class Hello_impl extends HelloPOA { Corba par la pratique public void sayHello (){ System.out.println ("Bonjour le monde !"); } } NFP111 — Systèmes et Applications Réparties 28 de 32 Plan La notion de contrat Le programme HelloWorld sans Naming Service (3/6) Exemple Constructions IDL Maintenant il nous faut construire un serveur qui sera charger de mettre à disposition l’objet distribué : Limites d’IDL // HelloServer.java package hello; Projection IDL vers un langage de programmation public class HelloServer{ Corba par la pratique public static void main (String args[]){ java.util.Properties props = System.getProperties (); //props.put ("org.omg.CORBA.ORBClass", "com.ooc.CORBA.ORB"); //props.put ("org.omg.CORBA.ORBSingletonClass", "com.ooc.CORBA.ORBSingleton"); int status = 0; org.omg.CORBA.ORB orb = null; try{ orb = org.omg.CORBA.ORB.init (args,props); status = run (orb); } catch (Exception ex){ ex.printStackTrace (); status = 1; } System.exit (status); } NFP111 — Systèmes et Applications Réparties 29 de 32 Plan Le programme HelloWorld sans Naming Service (4/6) La notion de contrat Exemple Implémentation du serveur (suite) : Constructions IDL static int run(org.omg.CORBA.ORB orb) throws org.omg.CORBA.UserException { org.omg.PortableServer.POA rootPOA = org.omg.PortableServer.POAHelper.narrow(orb.resolve_i org.omg.PortableServer.POAManager manager = rootPOA.the_POAManager(); Limites d’IDL Projection IDL vers un langage de programmation Hello_impl helloImpl = new Hello_impl(); Hello hello = helloImpl._this(orb); try { String ref = orb.object_to_string(hello); String refFile = "Hello.ref"; java.io.PrintWriter out = new java.io.PrintWriter(new java.io.FileOutputStream(refFile out.println(ref); out.close(); } catch(java.io.IOException ex){ ex.printStackTrace(); return 1; } Corba par la pratique manager.activate(); orb.run(); return 0; } } NFP111 — Systèmes et Applications Réparties 30 de 32 Plan La notion de contrat Le programme HelloWorld sans Naming Service (5/6) Exemple Construison maintenant un client qui effectuerait une requête sur le bus CORBA pour tester les fonctionnalités de l’objet distribué : Constructions IDL Limites d’IDL Projection IDL vers un langage de programmation Corba par la pratique // HelloClient.java package hello; public class HelloClient { public static void main(String args[]) { java.util.Properties props = System.getProperties (); //props.put ("org.omg.CORBA.ORBClass", "com.ooc.CORBA.ORB"); //props.put ("org.omg.CORBA.ORBSingletonClass", "com.ooc.CORBA.ORBSingleton"); int status = 0; org.omg.CORBA.ORB orb = null; try{ orb = org.omg.CORBA.ORB.init (args,props); status = run (orb); } catch (Exception ex){ ex.printStackTrace (); status = 1; } System.exit (status); } NFP111 — Systèmes et Applications Réparties 31 de 32 Plan Le programme HelloWorld sans Naming Service (6/6) La notion de contrat Exemple Implémentation du client (suite) : Constructions IDL static int run(org.omg.CORBA.ORB orb) { org.omg.CORBA.Object obj = null; Limites d’IDL try { String refFile = "Hello.ref"; java.io.BufferedReader in = new java.io.BufferedReader(new java.io.FileReader(refFile) String ref = in.readLine(); obj = orb.string_to_object(ref); } catch(java.io.IOException ex) { ex.printStackTrace(); return 1; } Projection IDL vers un langage de programmation Corba par la pratique Hello hello = HelloHelper.narrow(obj); hello.sayHello(); return 0; } } NFP111 — Systèmes et Applications Réparties 32 de 32 Plan Le programme HelloWorld avec Naming Service La notion de contrat Exemple Constructions IDL On ne change rien au fichier IDL. Limites d’IDL Génération du code : idlj -fallTIE -oldImplBase Hello.idl. Projection IDL vers un langage de programmation Télécharger le client et le serveur (version avec Naming Service) à l’adresse suivante : Corba par la pratique Compiler le tout : javac *.java. Pour tester : 1 Lancer orbd -port 900. 2 Lancer java HelloServer. 3 Lancer java HelloClient.
