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

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

Introduction

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

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

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

Norme CORBA

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)

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

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

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.

Qu'est ce que CORBA ? Common Object Request Broker Architecture 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 Before presenting our work, I introduce what it is CORBA, the Common Object Request Broker Architecture. CORBA is an open standard for distributed object computing from the Object Management Group. As this standard wants to be independent from underlying platforms and from programming languages, it is not concern by implementation aspects. A CORBA application can be seen as a collection of independent software components which are called CORBA objects. Each object is described by an interface which lists operations that can be remotely invoked. Such interface is written using the Interface Description Language (IDL). The IDL is just a specification language. Objects within a CORBA application communicate through the Object Request Broker (ORB). The ORB provides remote procedure call mechanism with transparent location so that client invokes a method of a remote object as it invokes a local method.  interopérabilité 12

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.

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

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

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

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

Architecture CORBA

Modèle CORBA

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

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)

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.

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.

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

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

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) Cœur de l’ORB GIOP / IIOP / ESIOP Adaptateur d’objet client Implémentation de l’objet Spécification IDL Compilateur IDL souche IDL Squelette IDL

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)

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

GIOP = General Inter ORB Protocol 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

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

Interface Definition Language (IDL)

Le concept

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

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.

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

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

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

La liste des paramètres peut Décrire une méthode Les opérations décrites dans une interface respectent le format suivant : type_de_retour ma_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.

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.

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

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

Renommage ou types def. par le programmeur 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;

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.

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

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

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;

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;

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.

Exemples interface Exemple { // … On pourra grâce à « f » échanger des }; 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 ».

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

Concept de « mapping » Une description IDL est traduite vers un langage de programmation. Les règles de traduction sont appelées « mapping » et font partie de la spécification CORBA. Grâce au mapping, deux fournisseurs d'ORBs offriront le même modèle de programmation. portabilité des applications

Compilation d'une description IDL La description doit être compilée afin de générer les amorces ( souche et squelette ) requises pour l'établissement de la communication inter-processus. Exemple de compilation IDL (projection en Java): idlj –fall –v Hello.idl A l'issu de la compilation, plusieurs fichier sont créés : HelloPOA.java : il s'agit du squelette, _HelloStub.java : il s'agit de la souche, Hello.java : il s'agit de l'interface HelloOperations.java : il s'agit des opérations de l'interface

Conclusion

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

Anatomie de CORBA

Comparaison RMI RPC DCOM CORBA SOAP Plate-formes Multi Win32 Java Langages de Programmation Java C, C++, … C++, VB, VJ, OPascal, … Langages de Définition de Service RPCGEN ODL IDL XML Réseau TCP, HTTP, IIOP customisable TCP, UDP IP/IPX GIOP, IIOP, Pluggable Transport Layer RPC,HTTP SNMP Transaction Non MTS OTS, XA Extension applicative dans le header Extra Chargement dynamique des classes Services Communs Services Sectoriels Firewall Tunneling HTTP HTTP Tunneling CORBA Firewall HTTP Qui SUN SUN/OSF MicroSoft OMG W3C Nommage RMI, JNDI,JINI IP+Port IP+Nom COS Naming COS Trader IP+Port, URL 56

Merci pour votre attention