Common Object Request Broker Architecture (CORBA)

1. Common Object Request Broker Architecture(CORBA) GL4 G1 05/01/2007 El Amouri Annowar Hammami Wael Ben Salem Aicha Farhat Mohamed Kharrat Houceme Eddine Zine Alabidine Nabih

2. Plan Introduction Norme CORBA Architecture CORBA Services Utilitaires Interfaces de domaines Communication Langage de Définition d’Interface: IDL Conclusion

3. Introduction

4. Application réparties Application répartie = traitements coopérants sur des tâches et des données réparties Coopération= communication + synchronisation Problèmes généraux Tolérance aux pannes (reliability) Nommage  nommer et localiser les ressources Sécurité  authentification Disponibilité (availability)  deux appels sur un même serveur ? Outils pour le développement  génie logiciel

5. Modèle Client/Serveur Client/Serveur « à procédure » RPC Client/Serveur « à objet » RMI, Corba, DCOM Client/Serveur « de données » Requêtes SQL Client/Serveur « WEB » CGI, servlet, asp, jsp, php...

6. Client/Serveur à objets Paradigmes objets : encapsulation polymorphisme, composition, généricité Objet = unité de désignation et de distribution Ex. RMI, CORBA

7. Norme CORBA

8. Qu'est ce que l'OMG ? O.M.G. ( Object Management Group ) est un consortium qui regroupe plus 800 entreprises du monde entier. Consortium ouvert aux horizons autres que les concepteurs de logiciels ( industriels, chercheurs, université, etc... ). Ce consortium définit des spécifications pour fournir un modèle de coopération entre objets répartis. CORBA 1.0 : 1991 (modèle objet) CORBA 2.0 : 1995 (interopérabilité, IIOP) CORBA 3.0 : 2002 (modèle composant)

9. Les spécifications de l'OMG L'OMG spécifie tous les constituants d'un modèle objet global appelé O.M.A. ( Object Model Architecture ) CORBA est une partie de ce modèle, Utilitaires communs ( services ), Eléments spécifiques à des corps de métier ( objets de domaines ).

10. Vue du modèle OMA Client Serveur Applications utilisateurs Objets de domaines Services Electronique Médecine Annuaire Transaction Le bus CORBA Administration Impression Utilitaires communs

11. Objectifs de CORBA Fournir un environnement ouvert les membres participent aux spécifications Fournir un environnement portable les API sont définis pour rendre les applications portables ( quelque soit le produit CORBA utilisé ) Fournir un environnement interopérable Permettre aux applications CORBA de collaborer entre elles.

12. Qu'est ce que CORBA ? standard ouvert pour les applications réparties bus logiciel, orienté objet communication par appel de méthode à distance géré par l’ “Object Management Group” (OMG). indépendant du matériel, du système, des langages Mais aussi des vendeurs • Common Object Request Broker Architecture  interopérabilité

13. Un environnement complet... CORBA est une architecture qui définit un environnement pour permettre la collaboration entre applications réparties. CORBA est disponible sur de nombreuses plate-formes, dans de nombreux langages et chez de nombreux fournisseurs. CORBA est simple à programmer en comparaison des environnements équivalent. CORBA offre une homogénéisation du système d'informations.

14. Le bus CORBA Le bus CORBA = ORB NT UNIX UNIX PC PC Sparc

15. Le concept de “bus logiciel” ajouter/supprimer des objets sans recompiler l’ensemble de l’application enregistrer/retrouver des références globales sur des objets connaître à priori ou découvrir les méthodes d’un objet réaliser les appels de méthode à distance passage de paramètres (par valeur) indépendance vis à vis de la localisation des objets

16. La vue réelle du bus CORBA Réseau TCP/IP ORB PC/NT ORB PC/UNIX ORB Sparc/UNIX NT UNIX UNIX PC PC Sparc

17. Le modèle objet de CORBA Un serveur CORBA peut héberger plusieurs objets CORBA. Chaque objet est accessible indépendamment des autres objets du serveur. Chaque objet exprime son offre de services sous forme d’une interface IDL Pour cela, on utiliser un langage de description de services appelé IDL CORBA. Il s'agit de décrire au sein d'une interface (vue cliente de l'objet) la liste des services offerts ( ensemble de méthodes).

18. Architecture CORBA

19. Modèle CORBA

20. Les services CORBA Pour accélérer et faciliter le développement d'applications avec CORBA, l'O.M.G a spécifiée un ensemble de services. A l'heure actuelle, plus de 17 services ont été définis. Les services sont vendus séparément du bus CORBA. Seul quelques services sont actuellement disponibles sur le marché.

21. Service de nommage Rôle : retrouver les références d’objet à partir de noms symboliques Définition du service : dans une interface IDL Module CosNaming Structure : arborescence appelé graphe de désignation (Naming Graph) Une racine Des répertoires, appelés « contexte de nommage » Des feuilles : les références d’objet Un contexte est un objet qui gère une liste de liaisons (= associations nom-référence)

22. Les utilitaires CORBA Les utilitaires communs (CORBAfacilities) sont des canevas d’objets (« Frameworks ») qui répondent plus particulièrement aux besoins des utilisateurs. Ils standardisent l’interface utilisateur, la gestion de l’information, l’administration, le Workflow, etc. Ils définissent un cadre de haut niveau pour la création de logiciels à l’aide de composants réutilisables. Ils sont à ce jour bien moins avancés que les services.

23. Les interfaces de domaines Les interfaces de domaines concernent des marchés verticaux et définissent donc des interfaces spécialisées répondant aux besoins spécifiques de tel ou tel marché comme les télécommunications ou la finance par exemple. Objectif : interopérabilité sémantique entre les systèmes d'informations des entreprises, Objets métiers spécifiques à des secteurs d'activités : Finance, santé, télécoms.

24. Vue de l'architecture CORBA SERVEUR Objet CORBA CLIENT Squelette D.S.I. souche D.I.I. Adaptateur d'objets le bus CORBA

25. La compilation IDL Une description IDL est compilée pour générer les souches nécessaires au mécanisme d’invocation à distance. souche Génération de l'amorce cliente description IDL Génération de l'amorce serveur squelette

26. Souche et squelette IDL Générés par le compilateur IDL à partir de la description IDL de l’objet serveur(doit être connue lors de l’écriture du client) Implémentation de l’objet client Squelette IDL Compilateur IDL soucheIDL Adaptateur d’objet Cœur de l’ORB GIOP / IIOP / ESIOP Spécification IDL

27. Normalisation des communications Protocoles d’interopérabilité entre ORBs conformes à CORBA 2 GIOP : General Inter-ORB Protocol Messages : request, reply, cancelrequest, … nécessite un protocole de transport fiable, orienté connexion IIOP (Internet IOP) : instanciation de GIOP sur TCP Autres implantations de GIOP au-dessus de HTTP, RPC DCE, RPC Sun Composants du protocole CDR : Common Data Representation Format de données d’encodage des données IOR : Interoperable Object References (références d’objets)

28. Les communications avec CORBA Les participants à un échange CORBA communiquent à l'aide d'un protocole spécifique à CORBA : IIOP (Internet Inter-ORB Protocol). Le protocole IIOP est indépendant du langage de programmation, du système d'exploitation et de la machine utilisée. Un client Java pourra utiliser un serveur C++ Transparence de l’appel / indépendance de la localisation de l’objet Même espace mémoire  simple appel de fonction Même machine  communication inter-processus Machine distance  communication réseau

29. GIOP/IIOP GIOP = General Inter ORB Protocol spécification qui permet l’interopérabilité entre différents ORBs spécifie le protocole de transmission + format des requêtes IIOP = Internet Inter ORB Protocol protocole d’interopérabilité standard pour Internet construit sur IP ESIOP = Environment Specific IOP spécification qui permet de définir des protocoles spécifiques

30. IIOP Livré avec toute implémentation de CORBA Utilise CDR (plus efficace que XDR) Certains serveurs WEB peuvent dialoguer via IIOP

31. Interface Definition Language(IDL)

32. Le concept

33. Langage de description d’interface (IDL) Est indépendant des langages Peut être “mappé” dans de nombreux langages : Cobol, ADA, C++, C, Java, Python, SmallTalk... Permet de décrire des interfaces contenant des opérations des attributs accessibles à distance une interface IDL est similaire à une interface Java une classe abstraite C++

34. Décrire les services offerts Le développement d'une application CORBA commence par l'énumération des services offerts par chaque objet corba. Une même description IDL peut contenir plusieurs descriptions d'objets. Une description IDL s'effectue au sein d'un fichier texte comportant par convention l'extension « .idl » Chaque objet offre une interface qui contient une liste d'opérations qui seront par la suite offertes aux applications clientes.

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

36. Le module IDL La notion de module est similaire à celle de package de Java. Un module introduit un espace de désignation supplémentaire. On notera qu'un module peut contenir un autre module, une interface, une description de type complexe. La description d'un module respecte la syntaxe suivante : module nom_du_module { // corps du module }; Un module est traduit en un package (sous-répertoire).

37. Premières règles sur l'IDL Une interface est une énumération d'opérations et de définitions de types de données. interface Exemple { // contenu de l'interface }; Une interface supporte l'héritage multiple. interface AutreExemple : Exemple1, Exemple2 { // contenu de l'interface };

38. Décrire une méthode Les opérations décrites dans une interface respectent le format suivant : type_de_retourma_methode( liste_des_paramètres ) ; CORBA offre plusieurs types de données : - les types de bases - les types complexes La liste des paramètres peut être vide.

39. Les paramètres d'une opération La description d'un paramètre comporte trois parties : le modificateur le type de l'argument ( type de base ou type complexe ) le nom de l'argument Le modificateur spécifie le sens d'échange du paramètre : in : du client vers l'objet CORBA out : en retour, de l'objet CORBA le client inout : équivalent à un passage par adresse.

40. Un exemple de description IDL Cet exemple décrit un objet qui offre une interface appelée« Premier ». Cette interface comporte une opération dénommée « affiche » qui entraîne l'affichage d'un message sur le serveur ( message passé en tant que paramètre ). interface Hello { void sayHello ( in string message ) ; };

41. Types de données Any Types constuits Référence objet sequence union Types de base array enum struct Floating Point Integer Boolean Octet Char String UShort ULong Float Double Short Long

42. Déclarations de types Renommage ou types def. par le programmeur énumeration, structures, tableaux, unions enum couleurs { rouge, vert, bleu}; struct ecole { Interessant tutoriels, exposes; Bon repas; Sympatique station; }; typedef Char BadDate[2]; sequences (tableaux de taille variable) typedef sequence<ecole> formation;

43. Les attributs IDL Il est possible dans une description IDL de définir des attributs d'interface. Un attribut est une donnée accessible soit en lecture/écriture, soit en lecture seulement. Pour décrire un attribut, on respecte le format suivant : [ readonly ] attribute type_de_l'attribute nom_de_l'attribut; Optionnel, ce mot clef signale que l'attribut est accessible en lecture seule.

44. Exceptions Assure qu’un client reçoit toujours une réponse lors d’une invocation distante 2 sortes d’exceptions “CORBA Standard Exceptions” levées par CORBA même si elle peuvent avoir été levées par l’implémentation d’un objet exceptions définies par le programmeur exception EntryNotAllowed{string reason;};

45. Exceptions Exemple interface Account { exception OverdrawnException {}; void deposit( in float amount ); void withdraw( in float amount ) raises ( OverdrawnException ); float balance(); };

46. Notion de séquence IDL Une séquence est une donnée similaire à un tableau. Une séquence se décrit en IDL par le mot clef « sequence ». La description d'une séquence est couplée à celle d'un alias. On distingue deux types de séquences : les séquences bornées : sequence< type, borne > les séquences non bornées : sequence< type > Exemples : typedef sequence<String> liste; typedef sequence<String, 100> liste_bornee;

47. Notion de structure IDL Une structure IDL est une description qui permet de regrouper plusieurs données appelées membres. Les structures IDL doivent contenir au minimum un membre. Chaque structure respecte le format suivant : struct nom_de_la_structure { liste_des_membres; }; chaque membre est décrit par : type nom;

48. Echange de référence d'objets Parmi les types de bases de l'IDL il existe celui de référence d'objet symbolisé par « Object ». Ainsi, à l'aide de ce paramètre un client pourra échanger des références avec un objet CORBA. On peut également échanger des références d'objets typées en utilisant comme paramètre le nom d'une interface IDL.

49. Exemples interface Exemple { // … }; interface AutreExemple { void f ( in Object obj ); void g ( in Exemple obj ); }; On pourra grâce à « f » échanger des références d'objets dont celle de « Exemple ». Avec « g » on ne pourra échanger que des références d'objets vers « Exemple » où des références d'objets héritants de « Exemple ».

50. Exemple # pragma prefix «ensai.fr» module annuaire typedef string Nom; struct Personne { Nom nom ; String tel ; } interface Repertoire { readonly attribute string libelle ; exception Inconnu (Nom nom ) ; Personne obtenirPersonne (in Nom nom) raises (Inconnu) ; }