NFP111 — Systèmes et Applications Répartieslitis.univ-lehavre.fr/~duvallet/enseignements/Cours/CNAM/CNAM-NFP... · Plan La notion de contrat Exemple Constructions IDL Limites

Plan

La notion de contrat

Exemple

Constructions IDL

Limites d’IDL

Projection IDL vers unlangage deprogrammation

Corba par la pratique

NFP111 — Systèmes et Applications Réparties 1 de 32

NFP111 — Systèmes et Applications RépartiesCours 8 - CORBA/Partie 2 - Le langage IDL

Claude Duvallet

Université du HavreUFR Sciences et Techniques

25 rue Philippe Lebon - BP 54076058 LE HAVRE CEDEX

Courriel : [email protected]://litis.univ-lehavre.fr/∼duvallet/

Plan


Exemple

Constructions IDL

Limites d’IDL




La notion de contrat (1/3)

Le langage OMG-IDL (Interface Definition Language) :Permet d’exprimer sous la forme de contrats IDL lacoopération entre les fournisseurs et les utilisateurs deservices.Sépare l’interface de l’implantation des objets.Masque les divers problèmes liés à l’interopérabilité dontl’hétérogénéité des langages.

Un contrat IDL spécifie les types manipulés pour unensemble 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 etmatérielle.Les met en relation à travers le bus CORBA.

Plan


Exemple

Constructions IDL

Limites d’IDL





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 auxobjets.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éguerontaux objets.

Plan


Exemple

Constructions IDL

Limites d’IDL





C l i e n t S e r v e u r

SqueletteSouche Bus CORBA

IDLContrat

Plan


Exemple

Constructions IDL

Limites d’IDL




Exemple (1/3)

#pragma prefix "univ-lehavre.fr"module date {typedef short Annee;typedef sequence<Annee> DesAnnees;

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

Plan


Exemple

Constructions IDL

Limites d’IDL




Exemple (2/3)

typedef sequence<Date> DesDates;union DateMultiFormatswitch(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);

};

Plan


Exemple

Constructions IDL

Limites d’IDL




Exemple (3/3)

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

Plan


Exemple

Constructions IDL

Limites d’IDL




Bilan sur l’exemple

Le langage IDL permet :d’exprimer simplement les types de données et d’objetsmanipulés par un service CORBA,indépendamment de tout aspect d’implantation (langages,systèmes d’exploitation, machines et réseaux) et/ou derépartition.

Le choix des identificateurs de ces types est déterminantpour une lecture aisée d’une spécification IDL.

Plan


Exemple

Constructions IDL

Limites d’IDL




Constructions IDL (1/7)

Un pragma permet de fixer les identifiants désignant lesdéfinitions IDL à l’intérieur du référentiel des interfaces.Les identifiants assurent une désignation unique desdéfinitions IDL quel que soit le référentiel des interfacesconsulté.Ils sont utilisés pour fédérer des IFR.La forme la plus utilisée est le pragma prefix qui fixel’organisation définissant un contrat IDL en utilisant son nomde domaine Internet.Le pragma version permet de définir le numéro de versiond’une spécification IDL.Un module sert à regrouper des définitions de types qui ontun intérêt commun.Permet aussi de limiter les conflits de noms pouvantintervenir entre plusieurs spécifications.

Plan


Exemple

Constructions IDL

Limites d’IDL




Constructions IDL (2/7)Les conflits de nom de module sont réglés par le pragmaprefix.Les types de données de base sont :

void, short, unsigned short, long, unsignedlong, long long (64 bits), unsigned long long,float, double, long double (128 bits), boolean,octet, char, string, wchar et wstring (format decaractères international) et fixed pour les nombres àprécision fixe.

Le format binaire de ces types est défini par la norme afin derégler les problèmes d’échanges de données entreenvironnements hétérogènes.Les types de méta-données (TypeCode et any) sont unecomposante spécifique à IDL :

Le type TypeCode permet de stocker la description den’importe quel type IDL.Le type any permet de stocker une valeur IDL de n’importequel type en conservant son TypeCode.

Plan


Exemple

Constructions IDL

Limites d’IDL





Ces méta-types permettent de spécifier des contrats IDLgé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 unevaleur évaluable à la compilationconst 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érationretourne un Jour plutôt qu’un entier signé.

Une énumération (enum) définit un type discret via unensemble d’identificateurs.

Par exemple : énumérer les jours de la semaine plutôt qued’utiliser un entier.

Plan


Exemple

Constructions IDL

Limites d’IDL





Une structure (struct) définit une organisation regroupantdes champs :

Cette construction est fortement employée car elle permet detransférer des structures de données composées entre objetsCORBA.

Une union juxtapose un ensemble de champs, le choix étantarbitré par un discriminant de type simple (entiers, caractère,booléen ou énumération).Un tableau (array) sert à transmettre un ensemble de taillefixe de données homogènes.Une séquence permet de stocker/transférer un ensemble dedonné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 exceptionnelspouvant survenir lors de son invocation.

Plan


Exemple

Constructions IDL

Limites d’IDL





Une interface décrit les opérations fournies par un typed’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 pashériter de deux interfaces qui définissent des opérations demê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 interfaceIDL. CORBA 3.0 doit intégrer la notion d’interfaces multiples(Java, COM).

Plan


Exemple

Constructions IDL

Limites d’IDL





Une opération se définit par :Une signature qui comprend le type du résultat, le nom del’opération, la liste des paramètres et la liste des exceptions.Un paramètre se caractérise par un mode de passage, untype 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 queltype 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.

Plan


Exemple

Constructions IDL

Limites d’IDL





CORBA ne spécifie pas complètement l’opération oneway :l’invocation peut échouer, être exécutée plusieurs fois sansque l’appelant ou l’appelé en soient informés.Un attribut exprime une paire d’opérations pour consulter etmodifier 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 attributIDL peut être faite par un traitement quelconque.

Plan


Exemple

Constructions IDL

Limites d’IDL




Les limites d’IDL (1/2)

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 furet à mesure des besoins :

Les entiers 64 bits, les réels 128 bits, les caractèresinternationaux (Unicode) n’étaient pas présents dans lespremières versions de la norme CORBA.

L’impossibilité de spécifier des types intervalles (pratiquepour exprimer des intervalles de temps).L’impossibilité de sous-typer (d’étendre) la définition d’unestructure ou d’une union.L’interdiction de conflits de noms à l’intérieur d’un module oud’une interface :

implique l’interdiction de surcharger des opérations.

Plan


Exemple

Constructions IDL

Limites d’IDL




Les limites d’IDL (2/2)

Le passage par valeur de structures de données et nond’objets :

Si l’on veut transférer un graphe d’objets, il faut l’aplatir dansune séquence de structures (évolutions de CORBA 3.0).

Le langage OMG-IDL ne sert pas à exprimer la sémantiquedes objets :

Comme des contraintes, des pré et post conditions sur lesopé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 lescaractéristiques d’une implantation.

Plan


Exemple

Constructions IDL

Limites d’IDL




Projection IDL vers un langage deprogrammation (1/2)

Projection (mapping, correspondance) est la traduction d’unespécification IDL dans un langage d’implantation.Pour permettre la portabilité des applications d’un bus versun autre :

les règles de projection sont normalisées,elles fixent précisément la traduction de chaque constructionIDL en une ou plusieurs constructions du langage cible,ces règles existent pour les langages C, C++, SmallTalk, Ada,Java et Cobol orienté objet.

Plan


Exemple

Constructions IDL

Limites d’IDL




Projection IDL vers un langage deprogrammation (2/2)

Réalisation de la projection :La projection est réalisée par un pré-compilateur IDLdépendant du langage cible et de l’implantation du busCORBA :

chaque produit CORBA fournit un pré-compilateur IDL pourchacun des langages supportés.

Le code des applications est alors portable d’un bus à unautre :

Les souches/squelettes générés s’utilisent toujours de lamême manière quel que soit le produit CORBA.

Par contre, le code des souches et des squelettes IDL n’estpas forcément portable :

il dépend de l’implantation du bus pour lequel ils ont étégénéré.

Plan


Exemple

Constructions IDL

Limites d’IDL




Étapes (1/3)

1 Définition du contrat IDL :définir les objets composants l’application à l’aide d’uneméthodologie orientée objet.cette modélisation est ensuite traduite sous la forme decontrats IDL.

2 Pré-compilation du contrat IDL :les interfaces des objets sont décrites dans des fichierstextes,le pré-compilateur prend en entrée un tel fichier et opère uncontrôle des définitions IDL,le pré-compilateur peut aussi charger ces définitions dans leréférentiel des interfaces.

Plan


Exemple

Constructions IDL

Limites d’IDL




Étapes (2/3)

3 Projection vers les langages de programmation :le pré-compilateur IDL génère :

le code des souches qui sera utilisé par les applicationsclientes des interfaces décrites dans le fichier IDL,le code des squelettes pour les programmes serveursimplantant ces types.

4 Implantation des interfaces IDL :en complétant et/ou en réutilisant le code généré pour lessquelettes, le développeur implante les objets.

5 Implantation des serveurs d’objets :Le développeur écrit les programmes serveurs qui incluentl’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 parexemple du service Nommage,se mettre en attente de requêtes pour ces objets.

Le nombre de programmes serveurs est souvent limité.

Plan


Exemple

Constructions IDL

Limites d’IDL




Étapes (3/3)

6 Implantation des applications clientes des objets :Le développeur écrit un ensemble de programmes clients quiagissent sur les objets.Ces programmes incluent le code des souches, le code pourl’IHM et le code spécifique à l’application.Les clients obtiennent les références des objets serveurs enconsultant le service Nommage.

7 Installation et la configuration des serveurs :Cette phase consiste à installer dans le référentiel desimplantations les serveurs pour automatiser leur activationlorsque des requêtes arrivent pour leurs objets.

8 Diffusion et la configuration des clients.9 Exécution répartie de l’application.

Plan


Exemple

Constructions IDL

Limites d’IDL




Conclusion

L’interopérabilité entre langages, systèmes d’exploitation,machines et réseaux.

La portabilité du code : les fragments de code présentés sonttotalement portables d’une implantation du bus à une autre.Encapsulation de l’existant :

La réutilisation de codes existants (voire même d’applicationscomplètes) peut être réalisée par encapsulation de ceux-cidans des objets CORBA.Ces objets sont alors utilisables pour bâtir de nouvellesapplications.

Plan


Exemple

Constructions IDL

Limites d’IDL




Perspectives

CORBA 1.0 avait pour objectif l’interopérabilité entre objetsdistribués.CORBA 2.0 avait donc comme objectif principal d’offrir cetteinteropérabilité via le protocole GIOP et IIOP.CORBA 3.0 :

Multiples Interfaces and Composition fournira lesmécanismes permettant à un objet CORBA d’implanterplusieurs interfaces IDL.Messaging Service définit un nouveau modèle decommunication asynchrone lorsque l’objet appelant et l’objetappelé ne sont pas présents simultanément sur le bus (viades requêtes persistantes).Persistent State Service 2.0 sera une spécification simplifiéedu service Persistance.CORBA Component Model définira un modèle decomposants pour le monde CORBA en s’inspirant parexemple du modèle JavaBeans.

Plan


Exemple

Constructions IDL

Limites d’IDL





Comment construire de programmes utilisant CORBA ? Ilvous faut un ORB permmetant de mettre en œuvre le busCORBA.

On peut utiliser celui qui est intégré au JDK mais alors on nepourra programmer qu’en JAVA.D’autres ORB permettent de programmer dans des langagesdivers. On prendra comme exemple l’ORB ORBacus quipermet de programmer en C++ et en JAVA.

On va commencer simplement en utilisant l’ORB du JDK.Soit l’exemple du programme HelloWorld programmé dedeux manières différentes :

1 sans utiliser de Naming Service mais avec un fichiercontenant la référence de l’objet sur le bus CORBA.

2 en utilisant le Naming Service pour enregistrer et retrouver laréférance de l’objet sur le bus CORBA.

Plan


Exemple

Constructions IDL

Limites d’IDL




Le programme HelloWorld sans Naming Service(1/6)

On commence par définir la structure de l’objet à partager aumoyen d’un fichier IDL :

// Hello.idlinterface Hello {

void sayHello();};

Ensuite, il nous faut compiler (effectuer une projection vers lelangage JAVA) au moyen de la commande suivante idlj-fallTIE Hello.idl.Examiner les fichiers JAVA qui ont été automatiquementgénérés lors de la projection.

Plan


Exemple

Constructions IDL

Limites d’IDL





Il faut passer à l’implémentation de l’objet distribué et de sesfonctionnalités :// Hello_impl.javapackage hello;

public class Hello_impl extends HelloPOA {

public void sayHello (){System.out.println ("Bonjour le monde !");

}

}

Plan


Exemple

Constructions IDL

Limites d’IDL





Maintenant il nous faut construire un serveur qui sera chargerde mettre à disposition l’objet distribué :// HelloServer.javapackage hello;

public class HelloServer{

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

Plan


Exemple

Constructions IDL

Limites d’IDL





Implémentation du serveur (suite) :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_initial_references("RootPOA"));org.omg.PortableServer.POAManager manager = rootPOA.the_POAManager();

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;

}

manager.activate();orb.run();return 0;

}}

Plan


Exemple

Constructions IDL

Limites d’IDL





Construison maintenant un client qui effectuerait une requêtesur le bus CORBA pour tester les fonctionnalités de l’objetdistribué :

// HelloClient.javapackage 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);}

Plan


Exemple

Constructions IDL

Limites d’IDL





Implémentation du client (suite) :static int run(org.omg.CORBA.ORB orb) {

org.omg.CORBA.Object obj = null;

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;

}

Hello hello = HelloHelper.narrow(obj);hello.sayHello();return 0;

}}

Plan


Exemple

Constructions IDL

Limites d’IDL




Le programme HelloWorld avec Naming Service

On ne change rien au fichier IDL.

Génération du code : idlj -fallTIE -oldImplBaseHello.idl.

Télécharger le client et le serveur (version avec NamingService) à l’adresse suivante :

Compiler le tout : javac *.java.Pour tester :

1 Lancer orbd -port 900.2 Lancer java HelloServer.3 Lancer java HelloClient.

Documents

NFP111 — Systèmes et Applications Répartieslitis.univ-lehavre.fr/~duvallet/enseignements/Cours/CNAM/CNAM-NFP... · Plan La notion de contrat Exemple Constructions IDL Limites