CORBA Common Object Request Broker Architecture

CORBA Common Object Request Broker Architecture
III. Corba CORBA Common Object Request Broker Architecture Architecture permettant de développer des applications distribuées : standardisées dans des environnements hétérogènes indépendants des langages de programmation et des systèmes d’exploitation; basées sur la technologie objet. A utiliser pour l’intégration de systemes propriétaires non ecrit en java Utilise pour ses services… Les enterprise beans peuvent etre appeles par des clients ecrits pour utiliser J2EE et des clients prévus pour des APis Corba. - 1 -

ORB (1/2) ORB : Object Request Broker
I.5. OMA ORB ORB (1/2) ORB : Object Request Broker Middleware qui gère les relations client/serveur entre les objets Définition du concept de Middleware : Courtier d’objets (en Français). Ensemble des logiciels nécessaires pour permettre et organiser la communication et l’échange de messages entre client et serveur. Le bus Corba (Bus d objets répartis) se charge de masquer les différences entre les langages d’implantation des objets (aujourd ’hui C++, CORBA, Smallatlak, COBOL, JAVA, Ada, C), les systèmes d’exploitation et les architectures matérielles. Il rend transparente la localisation des objets.EN capturant les appels il est responsable de retoruver un objet qui implémente une requête... Le bus d’objets répartis CORBA est appelé négociateur ou transitaire de requêtes objet. Son rôle est de fournir une infrastructure ou MiddleWare pour réaliser des applications distribuées à l’aide d’objets hétérogènes. Ce n’est pas nécessairement un seul composant, mais il est défini par son interface. On distingue 3 sortes d’opérations : 1. op. définie qui sont les mêmes pour tous les ORB 2. op spécifiques à un type d’objets 3. op spécifiques à des styles particuliers d’objets implémentation. - 2 - 12 12

ORB (2/2) Composant central du standard CORBA qui gère :
I.5. OMA ORB ORB (2/2) Composant central du standard CORBA qui gère : la localisation d’objet la désignation des objets l’empaquetage des paramètres (marshalling) le dépaquetage des paramètres (unmarshalling) l’invocation des méthodes la gestion des exceptions l ’activation automatique et transparente des objets De plus, il fournit des caractéristiques telles que : la liaison avec « tous » les langages de programmation un système auto-descriptif l ’interopérabilité entre les bus Location transparency The client does not know or care whether the target object is local to its own address space, is implemented in a different process on the same machine, or is implemented in a process on a different machine. Server processes are not obliged to remain on the same machine forever; they can be moved around from machine to machine without clients becoming aware of it (with some constraints, which we discuss in Unit 22). • Server transparency adire dans la transparence The client does not need to know which server implements which objects. La liaison avec les langages de programmation : assurés par des transformations frd IDL en construction directement exploitables via un précompilateur IDL. La transparence des invocations: le choix du moyen de transport en fonction de la localisation des objets qui est alors transparente même processus, différents process même machine, ou … invocations d ’opérations statiques et dynamiques : statique la + utilisée elle permet aux programmeurs d ’écrire les invocations sur les objets en utilisant les souches de communication produites par un précompilateur IDL. (typage est vérifié dans la phase de compilation.) dynamique utilise les interfaces des objets durant l exécution grâce à un référentiel des interfaces. à partir des info extraites , un pgme peut construire dynamiquement les invocations à destination des objets. Les opérations invoquées ne sont connues qu ’à l ’exécution donc mécanisme plus souple mais aussi plus coûteux en temps d ’exécution. Un système auto-descriptif : Le bus contient des métaDonnées décrivant les interfaces des objets. Celles-ci sont stockées dans le référentiel des interfaces. Utilisées entre autres par des outils tels aue les générateurs de code à la volée, ateliers de G.L. ou navigateurs d ’interfaces. Activation automatique des objets : les objets sont en mémoire uniquement s ’ils sont utilisés par une application cliente. communication entre différents bus: pas de technologie imposée pour l ’implantation du bus. cependant des règles et protocoles sont définis pour permettre le dialogue entre différentes implantations. soit par des conversion de requêtes entre bus, soit par l ’usage de protocole commun. 2 familles : 1) Protocoles à usage général instancié à partir du protocol générique (General Inter-ORB Protocol GIOP) et 2) celle dédiée spécifiquement à des environnements distribués (Environment Specific In.. ESIOP) . IIOP (Internet ..) est l ’instanciation de GIOP sur la couche de transport TCP/IP de l ’internet. - 3 -

“Proxies Make Remote Objects Look Local”
I.5. OMA ORB “Proxies Make Remote Objects Look Local” Un proxy est un objet local qui représente un objet distant Le proxy est automatiquement créé par l’ORB Le proxy a l’interface de l’objet distant Si l’objet distant est en C++, et le client est en Java, le proxy sera en Java Client Process Server Process implementation proxy CORBA Software Bus - 4 -

Object reference semantics
I.5. OMA ORB Object reference semantics - 5 -

Transparence de localisation des objets
I.5. OMA ORB Transparence de localisation des objets Si un objet invoque une opération sur un autre objet CORBA dans le même processus, certaines implémentations peuvent éviter le passage par le réseau. Machine 1 Machine 2 Process A Process B Direct Call Inter-Process Call Network Call (IIOP) - 6 -

Bus Corba : fonctions ... Client serveur ORB I.5. OMA ORB Référence
-> faire(param1,param2,...) Return Unmarshaling Unmarshaling faire(param1,param2,...) Return ORB Marshaling Marshaling Facilite la communication entre objets en particulier il permet de localiser un objet seulement à partir d’une référence. 1. Localisation de l ’objet implémentation correspondant à la référence (serveur) . 2. On vérifie que le serveur est prêt 3. on transforme les paramètres de la requête alors du serveur correspond. C’est aussi le marshalling CORBA c’est le standard qui implémente les capacités de l’ORB. on-the-wire format spécifie le format dans lequel les données sont transmises à travers le réseau pour être transformées. Ce mécanisme de conversion est transparent à l ’utilisateur. Cette approche permet une indépendance vis à vis des plateforme. réseau - 7 - 11 11

ORB : Liaison avec « tous » les langages de programmation
I.5. OMA ORB ORB : Liaison avec « tous » les langages de programmation C++ Java Smalltalk Ada Souche Souche Souche Souche Bus Corba Souche = STUB ou squelette Facilite la communication entre objets en particulier il permet de localiser un objet seulement à partir d’une référence. C’est aussi le marshalling CORBA c’est le standard qui implémente les capacités de l’ORB. - 8 - 11 11

Services objet communs
I.5. OMA Services Services objet communs Les Services Objet (CORBA Services) : Fonctionnalités système de bas niveau communes à la majorité des applications distribuées. objectif : étendre les fonctions de l ’ORB interfaces indépendantes des domaines d’application; spécification par des interfaces IDL; leurs fonctionnalités peuvent être étendues ou spécialisées par héritage; Les services objet communs (p. 16) permettent de prendre en charge les opérations systèmes nécessaires au fonctionnement de toute application distribuée : la recherche d ’objets, leur cycle de vie, les transactions, la persistance et la sécurité. Détaillés ultérieurement il y en a 15… Mais il y a une grosse différence entre les specs et les implémentations. On y trouve le vendeur, tradeur, nommage, ... - 9 - 16 16

Services CORBA Naming Persistent Object Events Concurrency LifeCycle
I.5. OMA Services Services CORBA Naming How are objects found? Events Standardized mechanism for client notifications. LifeCycle How are objects created, moved, duplicated and deleted? Trader Find objects that have certain properties Transactions Distributed 2-phase commit Security Complete distributed security Persistent Object Save objects to databases Concurrency Managing simultaneous access Licensing Managing licensed services Externalization External representation of objects Relationship Manage relationships between objects that don't know about each other Query Query objects on the network - 10 -

Utilitaires communs Les utilitaires communs (CORBA Facilities)
I.5. OMA Services Utilitaires communs Les utilitaires communs (CORBA Facilities) (aussi dits canevas horizontaux): ensemble de services orientés utilisateur de plus haut niveau fournissant des fonctionnalités utiles dans de nombreuses applications; spécification par des interfaces IDL; leurs fonctionnalités peuvent être étendues ou spécialisées par héritage; indépendants des domaines d’application; Exemples : interface utilisateur, gestion de l ’information, administration du système et gestion de la tâche. ou encore Utilitaires communs sont des canevas d ’objets construits au dessus des services pour offrir des fonctionnalités de plus haut niveau: interface utilisateur, gestion de l ’information, administration du système et la gestion de la tâche. Interface utilisateur : les scripts CORBA gestion de l ’information : modélisation, administration du système: instrumentation (interface standard pour collecter les infos sur la charge de travail des composants, leur consommation de ressources, leur réactivité, les débits de communication, les erreurs et les pannes diverses); cf. p. 44 à 46 En construction : agents mobiles, échange de données, firewalls, internationalisations, etc… Ce travail est aujourd ’hui mené par ORBServices TaskForce(certains sont partagé avec le Business Object Domain Task Force). - 11 - 15 15

Utilitaires communs : L ’interface Utilisateur
I.5. OMA Services Utilitaires communs : L ’interface Utilisateur Collection de composants pour standardiser l ’utilisation des IHM sophistiquées. gestion du rendu : affichage des fenêtres et des éléments graphiques de dialogue avec l ’utilisateur final. Gestion des documents composites : Coopération visuelle d’applications distinctes (OPenDoc). support de l ’utilisateur : aide en ligne, vérificateur de texte, tableur, …. gestion du bureau scripts ou encore Utilitaires communs sont des canevas d ’objets construits au dessus des services pour offrir des fonctionnalités de plus haut niveau: interface utilisateur, gestion de l ’information, administration du système et la gestion de la tâche. Interface utilisateur : les scripts CORBA gestion de l ’information : modélisation, administration du système: instrumentation (interface standard pour collecter les infos sur la charge de travail des composants, leur consommation de ressources, leur réactivité, les débits de communication, les erreurs et les pannes diverses); cf. p. 44 à 46 En construction : agents mobiles, échange de données, firewalls, internationalisations, etc… Ce travail est aujourd ’hui mené par ORBServices TaskForce(certains sont partagé avec le Business Object Domain Task Force). - 12 - 15 15

Interfaces des domaines
I.5. OMA Services Interfaces des domaines Les interfaces ou objets des domaines (CORBA Domains) (aussi dits canevas verticaux, objets métiers): spécifiques à un domaine d’application (médical, financier, télécommunications, commerce électronique, ...); spécification d’interfaces IDL; standardisées par l’OMG; leurs fonctionnalités peuvent être étendues ou spécialisées par héritage; ou Interfaces de domaine sont dédiés à des segments de marché verticaux ou économiques. Elles permettent, par exemple l’interopérabilité et la collaboration dans les domaines de la santé(objet Patient) , des finances (monnaie, convertissuer de monnaie) des télécom ou du commerce électronique. UML Revision Task force : UML du futur On parle aussi de Businness Objects ou de vertical Common Facilities. - 13 - 14 14

Objets applicatifs Les Objets applicatifs (CORBA Applications) :
I.5. OMA Services Objets applicatifs Les Objets applicatifs (CORBA Applications) : spécification par des interfaces IDL; définis par une application de l’utilisateur; hors du champ de standardisation de l’OMG; possibilité de standardisation pour des objets émergents. Décrits à l’aide d’IDL, ils utilisent les services objets communs, les utilitaires communs et les interfaces de domaines. La conception d’objets applicatifs peut être vue comme un travail d’assemblage et d’intégration de composants pré-existants et un travail de création de nouveaux composants spécifiques. - 14 - 13 13

Vers une industrie du composant logiciel
I.5. OMA Services Vers une industrie du composant logiciel Objets applicatifs (0A) Interfaces de domaine (ID) Utilitaires communs (UC) OA SO UC ID ID SO UC UC SO Bus d’objets répartis (O.R.B.) Décrits à l’aide d’IDL, ils utilisent les services objets communs, les utilitaires communs et les interfaces de domaines. La conception d’objets applicatifs peut être vue comme un travail d’assemblage et d’intégration de composants pré-existants et un travail de création de nouveaux composants spécifiques. cf. p. 52 Les membres de l’OMG prônent au travers de l’architecture globale OMA, une industrie du composant logiciel équivalente à l’industrie du composant électronique. Dans les meilleures situations les bus actuellement disponibles ne fournissent que quelques services communs (nommage, cycle de vie, transactions) . La non disponibilité est due à la lenteur du processus de normalisation, (1 à 2 années) et ensuite 1 à 2 années pour voir les premières implantations apparaître. Services objet communs (SO) - 15 - 13 13

Communication inter-ORB
I.5.OMA Interopérabilité Communication inter-ORB (O.R.B.) composant (O.R.B.) composant RMI/IIOP IIOP IIOP TCP/IP network (O.R.B.) composant BD IIOP IIOP (O.R.B.) Bridge (O.R.B.) BD composant DCE network DCE-CIOP Au dessus des câbles (lignes de téléphone, microfibre, lien avec satellite…) on trouve la couche de transport, qui implique des protocoles ayant la charge de transporter des paquets de données d ’un point à un autre. A l âge de l ’Internet le protocole de transport probablement le plus utilisé est TCP/IP (Transmission contrôle Protocole/ Internet Protocole). La plupart des applications utilise ce protocole, y compris FTP (File Transfer Protocole), Telnet (Host Communication protocole) et HTTP (HyperText Transport Protocole, base du World Wide Web ). GIOP : General Inter ORB protocole spécifie un standard de communications entre ORBs. Il n ’est bien sur pas utilisé directement mais il est spécialisé par un protocole particulier. Le protocole IIOP doit être implémenté pour etre compliant corba 2.0 IIOP : standard protocle de communication entre ORBS et TCP/IP. Un ORB doit supporter IIOP mais peu en supporter d ’autres. On ajoute une couche : inter_ORB un pont... DCE-CIOP - 16 - 13 13

IIOP: CORBA and Interoperability
I.5.OMA Interopérabilité IIOP: CORBA and Interoperability CORBA 1.2 provided portability An application developed for one ORB can be recompiled for another ORB CORBA 2.0 provides interoperability through the IIOP protocol An object on one ORB can communicate with an object on another ORB mandatory optional CORBA 2.0 General Inter-ORB Protocol (GIOP) Internet Inter-ORB Protocol (IIOP) TCP/ IP Environment Specific Inter-ORB Protocol (ESIOP) Other e.g.: OSI IPX/SPX ... DCE RPC Above CORBA IDL Object Request Semantics Message Format Transport - 17 -

CORBA : les composantes du bus
Adaptateur d’objet Interface du bus Interface de Squelettes Statiques Interface d’Invocation Statique Interface de Squelettes Dynamiques Interface d’Invocation Dynamique Application serveur Application cliente SSI DSI SII DII ORB OA Noyau de communication Aucun détail d’implantation n’est fourni mais seulement des blocs fonctionnels prenant en charge la communication entre les objets. Noyau de communication (ORB core?): non directement accessible accessible par les applications il assure le transport des invocations selon des techniques dépendantes de la localisation : par exemple une couche de communication réseau IIOP si les objets sont situés sur des machines différentes, des outils de communication inter-processus (Inter-Process Communication) (tubes, files, mémoire partagée ou encore appel procédural si les objets sont dans le m^me espace d’adressage. ORB fournit des fonctions d ’initialisation du noyau... Interface d ’invocation statique (Static Invocation Interface) : est le résultat de la projection des IDL dans un langage de programmation donné. A travers cette interface, les programmes clients invoquent les opérations des objets de manières transparentes. A chaque IDL est associé une interface d ’invocation statique ou souche IDL. Ces souches servent à emballer les invocations, déballer les résultais, et elles délèguent le transport des invocations au noyau de communication. Interface d ’invocation dynamique (Dynamic Invocation Interface) : permet de construire dynamiquement des requêtes. Le programmeur doit préciser à l ’éxécution chaque élément de la requête : l ’objet cible, le nom de l ’opération ainsi que chaque paramètre. Référentiel des interfaces : il forme une BD stockant toutes les définitions IDL des objets du BUS. Celle-ci est encapsulé dans un ensemble d ’objets CORBA accessible par des mécanismes d ’invocation statiques et/ou dynamiques. (IFR???) Cf. Suite transparent suivant IR Référentiel des interfaces ImplR Référentiel des implantations - 18 -

Architecture générale
fichier IDL Client Implémentation d’objet pré-compilateur SSI DSI Stub client Interface ORB DII SII Interface de l ’adaptateur Adaptateur d’Objet noyau de l ’Object Request Broker (ORB) Interface du bus : fournit les primitives de base pour l ’initialisation, le paramétrage de l environnement Corba, l ’instanciation des références ??, la gestion de la mémoire. Par exemple, elle fournit une primitive pour convertir une référence d’objet en une string et inversement, ce qui permet d’échanger des références via des fichiers de texte ou du courrier électronique. Utilisées à la fois par les applications clientes et serveurs. aussi Object resolve_initial_References(in ObjectId identifier) raises InvalidName l ’interface de squelettes statiques (Static Skeleton Interface) : s ’occupe de déballer les requêtes pour les transmettre aux objets d ’implantation et en retour d ’emballer les résultats à destination des clients. les souches et les squelettes sont générés automatiquement par un précompilateur IDL. Le transport des résultats assuré par le noyau. l ’interface de squelettes dynamiques (Dynamique Skeleton Interface) : équivalent pour le serveur de l ’interface d ’invocation dynamique pour le client. Elle permet de recevoir des requêtes sans disposer à priori des squelettes de déballages. Elle est utilisée pour implanter des passerelles entre un bus et un autre environnement ou encore pour assurer la liaison avec des langages interprétés comme CORBA Script. l ’adaptateur d ’objets :bloc fonctionnel auquel le noyau de communication délègue l ’exécution des requêtes. CORBA vise à supporter aussi bien des BD que des process. l ’adaptateur isole ces supports ??? p. 31 il utilise le référentiel des implantations. Actuellement seul un adpatateur pour processus ou Basic Object Adapter (BOA) a été partiellement spécifié. Il créé les objets CORBA, maintien les associations entre implantation et objets CORBA, activation automatique si nécessaire. Objet Implémentation : donne la sémantique de l ’objet définie par les données de l ’instance et le code des méthode. Souvent elles utilisent d ’autres objets ou logiciels. Svt indépendant de l ’ORB, via l ’interface de l ’adptateur. référentiel des implantations : contient l ’ens. des info décrivant l ’implantation des objets: nom des exécutables contenant le code des objets, la politique d ’activation de ces exécutables, les droits d ’accès aux serveurs et à leurs objets. Il peut aussi contenir des infos pour l ’administration, la gestion, l ’audit ou le déverminage des objets. Non spécifié par l ’OMG, il est donc spécifique à chaque implantation de CORBA. Cette architecture fonctionne clairement seulement un mode client serveur. Cependant un pgme peut être à la fois client d ’objet et fournisseur d ’objets. les fleches = sens des appels Référentiel des interfaces Rint Référentiel des implémentations Rimp - 19 -

OMG-IDL : compilation Projection des descriptions OMG-IDL vers les langages d’implantation des clients et serveurs. mode « statique » Instanciation sous forme d’objets CORBA des descriptions OMG-IDL dans un référentiel des interfaces commun. mode « dynamique » - 20 -

CORBA : le mode statique
III. Corba mode statique CORBA : le mode statique Les clients et serveurs implantent des descriptions OMG-IDL communes, statiquement précisées dans la phase de compilation/projection du source IDL. Contrat IDL Client d ’objets Fournisseur d ’objets Stub IDL Bus CORBA Squelette IDL Les souches générées encapsulent l’utilisation du bus, l’activation et la distribution des composants et l’hétérogénéité de l’architecture. - 21 -

La projection client Compilation vers client ex : IDL/C++ III. Corba
mode statique La projection client Fichier OMG-IDL Application cliente Référence d’objet Compilation vers client ex : IDL/C++ Requête vers le bus Cl_a Cl_b Cl_c stubs Un stub représente le mapping entre le langage d ’implémentation du client et le ORB core. Donc le client peut être écrit dans tous langage pour lequel il y a un tel mapping. Un talon IDL stub ou souche est une interface statique liée à l ’édition de lien au programme client, permettant de créer et délivrer une requête à partir de celui ci. Elle rend accessible l ’interface d ’un serveur particulier accessible depuis le client. Souche ou squelette présentent 2 faces : une client-souche (squelette-serveur), liée à l ’IDL elle est standardisée. l ’autre talon-ORB (resp. squelette-ORB) est propriétaire et permet aux différents vendeurs d implanter librement la couche transport. Pré-compilateur et ORB sont donc directement dépendant l ’un de l ’autre. Si l ’ORB est construit au dessus de socket TCP/IP, les stub vont transformer l ’invocation issue du langage client en la construction d ’un message pour sockets. S ’il est basé sur une machine Virtuelle, les talons masqueront les appels aux primitives de la MV. Les stubs ne sont pas utilisées dans l ’approche dynamique. Mais ca complique le client et c ’est particulier à certaines applications. - 22 -

III. Corba mode statique Stub ou Proxy ….. Partie de code générée automatiquement par un compilateur IDL vers un langage de programmation cible. Code utilisé par le client lors des invocations statiques. Lien entre le client et l’ORB. Traduit les invocations du client en messages transmissibles sur le réseau : opération "marshalling ». Traduit les messages qui proviennent de l'ORB en données compréhensibles du client : opération "unmarshalling". Grâce au talon, on invoque un objet distant de le même manière qu’on invoque un objet local, et la distribution est donc totalement transparente. On bénéficie du contrôle de type. La compilation rend le pgme efficace car bien adapté en pricipe au CORE de l ’ORB. Pas de Stub pour C++ et Smalltalk ?????? mais un seul changement de l’IDL implique de recompiler le client. Une référence dépend du langage hote aussi est_elle traduite par la souche en reference ORB. - 23 -

La projection serveur Compilation vers serveur ex : IDL/Java Obj
III. Corba mode statique La projection serveur Fichier OMG-IDL Application serveur Impl_a Impl_b Impl_c squelettes Compilation vers serveur ex : IDL/Java Cl_a Cl_b Cl_c Obj Requête du bus Un squelette de serveur, également généré par le compilateur IDL, est une pièce de code qui fournit l ’ »impl émentation » (framework…) sur laquelle le code d ’implémentation du serveur pour une interface particulière est construit. Une méthode vide est générée et le programmeur doit la remplir. - 24 -

Squelette statique (skeleton)
III. Corba mode statique Squelette statique (skeleton) Partie de code généré automatiquement par un compilateur IDL vers un langage de programmation cible. Code utilisé par l'Adaptateur d'objet lors des invocations statiques. Lien entre l’ORB et l'objet d'implémentation. Reconstitue la requête du client de façon à invoquer la méthode requise : opération «unmarshalling ». Traduit les paramètres de retour en messages transmissibles sur le réseau : opération «marshalling ». Le squeletette est donc spécifique à l’interface et à l’adaptateur. - 25 -

Invocation statique III. Corba Client Implémentation d’objet réponse
mode statique Invocation statique Client Implémentation d’objet requête réponse squelette statique squelette dynamique Stub client Adaptateur d’Objet ORB noyau L’adaptateur d’objet sert à gérer la communication entre lORB core et l’objet Implémentation. En particulier il a la charge de la génération et intreprétation des références d’objets. - 26 -

Exemple ORBACUS - 27 -

CORBA : le mode dynamique
III. Corba mode dynamique CORBA : le mode dynamique Un « référentiel des interfaces » stocke sous forme d’objets les descriptions d’interfaces OMG-IDL. Une API (DII: Dynamic Invocation Interface) permet de construire des requêtes à l’exécution. Une API (DSI : Dynamic Skeleton Interface) permet de comprendre des requêtes à l’exécution. Dans l’approche statique les souches générées permettent la communication entre Jes objets. Cette approche est bien adaptée pour la conception et l’exécution d’application dont les specs IDL sont stabilisées. mais si les specs évoluent par l ’ajout de nouvelles opérations ... Il y a alors un lien statique entre les application clientes et les interfaces IDL des objets utilisés. Dans l ’approche dynamique le client a besoin de découvrir à l ’exécutions les info relatives à l ’interface des objets. (ex. un browser) - 28 -

Interface d'invocation dynamique (1)
III. Corba mode dynamique Interface d'invocation dynamique (1) Permet la création dynamique de requêtes API (DII) sans passer par des souches pré-générées; Un objet Request = un nom d’opération, une liste de couples valeur - type (au sens de l’IR) et une structure pour le résultat invoke send_deferred + get_response, poll_response send_oneway invoke send-deferred Elles correspondent aux invocations dynamiques du monde COM au travers de COM’s Idispatch interface. Invocation d’un objet coté client. API (DII) de construction de requêtes : coté client elle peut être vue comme un talon générique (Interface valide quelque soit l ’ORB) tandis que DSI comme un squellete générique côté serveur. sans passer par des souches prégénérées Un objet Request = un nom d’opération, une liste de couples valeur - type (au sens de l’IR) et une structure pour le résultat invoke : synchrone bloque l ’application jusqu ’au retour du res de la requête. idem statqie send_deferred + get_response, poll_response Différée gest-response blocquant permet d attendre le résultat poll-response : scrutation non blocquante (uniquement dispo. avec le DII, avec les souches IDL il faut faire du multithreading) send_oneway Asynchrone : op invoquée est dite one-way ou si l ’application ne evut pas connître le résultat de la requête, ni attendre la fin de son exécution. Groupement de requêtes send-multiple….. p. 127 send_oneWay wait get_response - 29 - module acme_com { // IDL:acme_com:1.0 module M { // IDL:acme_com/M:1.0 // ... };

Interface d'invocation dynamique (2)
III. Corba mode dynamique Interface d'invocation dynamique (2) Utilisation du référentiel des interfaces pour récupérer les informations relatives aux interfaces IDL; Avantages : les interfaces peuvent être découvertes dynamiquement; - code client générique indépendant d'une interface IDL;. API (DII) de construction de requêtes sans passer par des souches prégénérées Un objet Request = un nom d’opération, une liste de couples valeur - type (au sens de l’IR) et une structure pour le résultat invoke send_deferred + get_response, poll_response send_oneway - 30 -

invocation dynamique (3)
III. Corba mode dynamique invocation dynamique (3) Etapes 1. trouver la référence d ’un objet 2. recherche et interprétation de son interface dans le référentiel des interfaces; 3. obtenir la description de l ’opération à invoquer 4. construction d'un objet requête; construire la liste des arguments à transmettre 5. invocation de la requête 6. traiter les résultats retournés. (string_to_object) get_interface -> CORBA::InterfaceDef lookup_name, describe, ….. Par exemple on peut utiliser la fonction stringtoObjet ou encore en utilisant un service de nommage ou vendeur. 2. il suffit d ’appliquer get_interface à tout objet qui retourne CORBA::InterfaceDef create_request est fournie par Object et retourne une Request pour les args soit en paramètre de createrequest soit créée séparément grâce à create_lisr et add_arg. Chaque argument est instance de NamedValue type qui encapsule les caractériqtiaues de l ’argument : nom, type, valeur, taille, mode (in, ..) le résulat de la requête lui aussi arg de createRequest est aussi de ce type. create_request, ….. - 31 -

Interface de squelette dynamique
4. Corba Composants Interface de squelette dynamique Permet de délivrer une requête à un objet implémentation qui est inconnu lors de la phase de compilation Interprète une requête et ses paramètres. Analogue au DII mais du côté serveur. Utiliser pour créer des ponts entre des ORBs de vendeurs différents. Utiliser pour intégrer des applications existantes (legacy application). Les applications peuvent ne pas être conformes aux standard CORBA et peuvent également ne pas être OO. Comme le DII pour les application clientes permet d’invoquer dynamiquement n’importe quel objet, le DSI pour la partie serveur permet de recevoir n’importe quelle requête adressée à n’importe quel type . Une opération n ’est plus accédée via un squelette d ’opération spécifique généré par une spec d ’iDL, mais il est pris en main via une interafce qui donne accès au nom de l ’opération et aux paramètres (Comme dans le DII) les info sont retouvées via le Interface Repository. Le serveur n’a donc pas besoin d’intégrer les squelettes statiques générés par les précompilateurs IDL. Permet donc de dévlivere une requête vers l’implentation d’un objet sans squelette compilé. Pas totalement spécifié…. Sert à utilisé des objet d ’implémentation qui à la compilation ne savait pas l ’objet qui impémente. C ’est utile dans des outils de développement basés sur des interpréteurs et débuggers et pour permettre l ’interopérabilité entre ORB. ( Décodage de requêtes) - 32 -

Composants du bus - 33 -

Référentiel d’interfaces
III. Corba Référentiels Référentiel d’interfaces Maintient les informations sur les types, les interfaces etc.....; Un graphe d ’objets « concepts » d ’IDL : ModuleDef, InterfaceDef, OPerationDef, .. Par navigation dans ce graphe ou à partir d’une référence d’objet, on peut retrouver le contenu d’une interface, la signature d’une opération, … Informations pour une interface : son module son nom ses attributs ses opérations (nom, nom et types des paramètres, exceptions, contexte) ses héritages Graphe d’objets « concepts » d ’IDL ModuleDef, InterfaceDef, OperationDef, AttributeDef, TypedefDef, … Le bus Corba est auto-descriptif. Il permet d ’exploiter et de découvrir dynamiquement (i;e; durant l ’exécution) les interfaces des objets CORBA. Ces définitions IDL sont stocké (dans une BD ou un système de fichier chacun fait ce qu’il veut) dite référentiel des interfaces sous une forme compilée (objets accessibles par le client et l ’OrB) . Résultats d ’un précompilateur IDL. ces infos sont dites métaDonnées. Utilisé pour par ex. Coté client : l ’ Distribution des IDL, des objets auto-descriptifs, DII, outils de développement, Coté ORB : le contrôle des graphes d ’héritage (pas de cycle);; vérification de signature, connexions inter ORB - 34 -

Référentiel d’implémentations
III. Corba Référentiels Référentiel d’implémentations . Responsable de l’enregistrement des serveurs dans le système (enregistrement de la commande exécutable). . Spécifié par une interface IDL. (( Avec Orbix Controlé par la commande putit dans les commandes associées lsit, catit, rmit, chmodit. Implémenté par un processus démon.)) L’adaptateur d’objet active et communique avec les serveurs en s’appuyant sur des couches du système d’exploitation qui ne font pas partie de l’ORB. Il requiert donc des info inhérentes au système hôte et au langage d’implémentation qui ne sont pas portables. Le dépôt d’implémentations détient lui les info nécessaires à la description des serveurs (prog et implantation objet) : localisation, politique d’activation, objets activés etc. Il peut être vu comme une Bd dans laquelle BOA enregistre la description des implémentations objets supportées par un serveur particulier. A l’exécution le BOA stocke la référence objet de l’objet invoqué dans le dépôt d’implémentation. ORB et BOA s’en serviront pour localiser les objets actifs ou démarrer l’activation d’un objet inactif. Non spécifié par la norme CORBA. Partie non portable. Il peut aussi contenir des infos relatives à l ’implémentation des serveurs, telles que le debugging, version et autres informations administratives. When a server is using the IMR, object references created by one of its persistent POAs refer to the IMR rather than to the server itself. When the client makes a request using this reference, the IMR receives the request, activates the server (if necessary) using the OAD, and returns a new object reference to the client that identifies the server at its current host and port. The client then establishes a connection with the server using the new object ref-erence and communicates directly with the server, without the intervention of the IMR. However, should the server fail, a well-behaved client will contact the IMR again, which may restart the server and allow the client to resume its activities. - 35 -

Interfaces de base du Bus Object
III. Corba Interfaces de base du Bus Object module CORBA { exception COMM_FAILURE { … }; // Autres exceptions systèmes. interface Object { // Duplique une référence d’objet CORBA. Object _duplicate(); // Libère une référence d’objet. void _release(); // Teste si une référence ne dénote aucun objet. boolean _is_nil(); // Teste si un objet référencé n’existe plus. boolean _non_existent(); ………………………………………... Encapsule les références d ’objets CORBA et fournit des primitives de manipulation de base de ces références. Héritée implicitement par toutes les interfaces IDL définies par les architectes d ’applications. Elles peuvent donc être appliquées sur n ’importe quel type d ’objet. Pour éviter d ’avoir un problème de conflit de noms entre les opérations de Objects et celles de l ’utilisateur, la projection de cette interface dans un langage d ’implantation ajoute le préfixe _ devant les noms des opérations de ces opérations. Par exemple en C++ on écrira _release. J ’ai OTE : // Teste si 2 références désignent la même IOR. boolean _is_equivalent(in Object that); // Calcule une clé de hachage. long _hash(in long maximum); // Teste si un objet est d’un type donné. boolean _is_a(in string type_identifier); // Autres opérations des mécanismes dynamiques. InterfaceDef _get_interface(); Request _request(in string s); Request _create_( ); Request _create_request2( . . .); }; CORBA:: Object_ ptr obj = ...; // Get a reference if (! CORBA:: is_ nil( obj) { if (obj->_ is_ a(" IDL: acme. com/ CCS/ Controller: 1.0")) { // It's a controller } else { // It's something else } // Got a nil reference is_equivalent tests if two object references are identical: if they are equivalent, the two references denote the same object if they are not equivalent, the two references may or may not denote the same object is_equivalent test object identity, not identity! Because a single object may have several different references, a false return from is_equivalent does indicate that the reference denote different objects! is_equivalent is a local operation (never goes out on the wire). - 36 -

Object Adapter : fonctions
III. Corba Adaptateur Object Adapter : fonctions Intermédiaire entre le bus et les implantations possibles des objets Fonctions des Adaptateurs d’objets: 1- Enregistrement des objets implémentation. 2- Génération et interprétation des références d'objets. 3- Activation et désactivation des objets implémentation. 4- Invocation des méthodes à travers les squelettes ou le DSI. 5- Participation à la sécurité Fait la correspondance entre la référence d’un objet et son implémaentation. Si l’objet d’implémentation n’est pas en mémoire l’adaptater l’active (ou l’initialise dans la mémoire) idem deactivate… donne l’illusion au client que les objets cote server sont toujours en etat d’execution. 1 L’adaptateur doit connaître les info décrivant les implantations des objets telles que le nom des exécutables stockant le code d’implantation des objets. Ces infos sont emmagasinées dans un référentiel des implantations. 2 l’adaptateur génère les réf des objets CORBA pour le compte desquels il agit. Quand une requête arrive , il sait interpréter la référence d’objet contenue dans la requête afin d’activer si nécessaire l’objet destinataire. (Mapping des références objet vers leurs objets implémentation correspondant.) 3 Si l’objet est inactif, recherche dans le référentiel de l’implantation la mieux adaptée et l’active et l’adaptateur conserve l’association référence-implantation pour diriger les futures requêtes vers cette implantation. La désactivation décidée ou par l’adaptateur plus d’appel ou par les implantations si elles le jugent nécessaire. Permet de réduire la charge du système. 4 Invocation des opérations Les requ^tes sont dirigées vers les implantations via les interfaces de squelles (SSI ou DSI). Participation à la sécurité : On peut préciser l’émetteur de la requête (autorisé, droits…) Si une requete est invoqué sous toute politique autre aue persistant, l ’objet implementation sera activé par l ’OA de facon spécifique à la politique choisie. Pour cela il a besoin d ’info concernant la localisation des objet et l ’environnement d ’exécution. La BD contenant ces infos est dite repository d ’implémentation. Cette info est obtenue via le OA à l ’activation d ’un objet. A servant can be deactivated. Deactivating a servant breaks the association between the CORBA object and the servant; requests that arrive from clients thereafter result in an OBJECT_NOT_EXIST exception (or a TRANSIENT exception, if the server is down at the time a request is made). Deactivation of a servant in Java is analogous to C++: 1 // Java 2 org.omg.PortableServer.POA poa = impl._default_POA(); 3 byte[] id = poa.servant_to_id(impl); 4 poa.deactivate_object(id); A POA has either the TRANSIENT or the PERSISTENT policy value. A transient POA gen-erates transient object references. A transient object reference remains functional only foras long as its POA remains in existence. Once the POA for a transient reference is destroyed, the reference becomes permanently non-functional and client requests on such a reference raise either OBJECT_NOT_EXIST or TRANSIENT (depending on whether or not the server is running at the time the request is sent). Transient references remain non-func-tional even if you restart the server and re-create a transient POA with the same name as was used previously. Transient POAs almost always use the SYSTEM_ID policy as a mat-ter of convenience (although the combination of TRANSIENT and USER_ID is legal). Object references created on a persistent POA continue to be valid beyond the POA’s life time. That is, if you create a persistent reference on a POA, destroy the POA, and then rec-reate that POA again (with the same POA name), the original reference continues to denote the same CORBA object (even if the server was shut down and restarted). Persis-tent references require the same POA name and object ID to be used to denote the same object. This means that persistent references rely on the combination of PERSISTENT and USER_ID. USER_ID must be used in conjunction with NO_IMPLICIT_ACTIVATION, so servants for persistent references are always activated explicitly. Object Adapter The object adapter mediates calls between the ORB and the server and serves two main purposes: • It keeps track of how to map incoming requests onto programming language artifacts, such as objects or procedures. To do this, the object adapter must know which objects exist and when objects are created or destroyed. The object adapter therefore offers APIs that allow the application code to keep it informed of the life cycle of objects. The object adapter is also involved in creating and tracking the identity of objects. • The object adapter straddles the boundary between language-independent requests received from clients and language-dependent up-calls that need to be made to pass control to the application code in the server. For this reason, object adapters have some components that differ for each language mapping. Only one object adapter, the Portable Object Adapter (POA) is currently standardized. (The Basic Object Adapter (BOA) was deprecated with CORBA 2.2 and is no longer part of the standard.) However, vendors can create other object adapters for special purposes, for example, for real-time systems or object-oriented databases. Servant Proxy POA - 37 -

Interfaces : Portable Object Adapter
III. Corba Adaptateur Interfaces : Portable Object Adapter Interfaces IDL définies dans le module PortableServer : • POA : Interface principale côté serveur quels servants sont instanciés? Activation/désactivation, destruction des servants Création de références, … • POAManager - Contrôle du flot des requêtes vers plusieurs POAs • Servant native Servant; • POA Policies (7 interfaces) • Servant Managers (3 interfaces) - initialisation paresseuse des servants • POACurrent • AdapterActivator (Factory d’adaptateurs) Requetes traites immédiatement, mise en queues, rejette avec transient (a renvoyer plus tard) inactive requetes rejetees) Les policies determinent les characteristiques de l’implémentation des references des objets cres par le POA Destruction d’objet Elles sont aussi utilisées pour la qulité de service Eles gerent les refernces transient ou persitente. Si le serveur tombe et est relance elle désigneront tjs le même objet. Elles represente un servant par objet ou plusieurs objets , l’activation des automatique ou non, thread ou non pour les polices. On peut créer dynamiquement de nouveuax POA The interfaces to the POA are defined in IDL in the PortableServer module: • POA The POA interface is the central server-side interface and contains quite a large number of operations. POAs are concerned with tasks such as keeping track of which servants are currently instantiated and their addresses in memory, the activation and deactivation of servants, the creation of object references, and various other life cycle issues (such as permitting a servant to be deleted at a time when no operation invocation is in progress in that servant). • POAManager Conceptually a POA manager represents a transport endpoint that is used by one or more POAs. POA managers control the flow of requests into POAs. • Servant The IDL Servant type is defined in the specification as follows: module PortableServer { native Servant; // ... }; native is an IDL keyword that may be used only by OMG-defined specifications and ORB vendors. The native keyword indicates that the corresponding IDL construct is highly dependent on the target programming language and therefore does not have an IDL interface; instead, each language mapping must specify how the native type is represented as programming-language artifacts for a specific implementation language. The native keyword was added to IDL after earlier attempts to specify the interface for servants were unsuccessful—as it turns out, to get elegant language mappings, servant implementations must use features that are specific to each programming language and cannot be expressed in IDL. (This is not surprising when you consider that servants straddle the boundary between language-independent IDL definitions and language-specific implementations.) POA Policies (seven interfaces) Each POA has seven policies that are associated with that POA when it is created (and remain in effect without change for the life time of each POA). The policies control aspects of the implementation techniques that are used by servants using that POA, such as the threading model and whether object references are persistent or transient. • Servant Managers (three interfaces) Servant managers permit lazy instantiation of servants. Instead of requiring a server to keep a separate C++ object instantiated in memory for each CORBA object, servant managers allow servers to be written such that C++ instances are created on demand for only those servants that are actually used. • POACurrent POACurrent is an object that provides information about a currently executing operation to the operation’s implementation. This information is useful mainly for interceptors (which are used to implement functionality required by services such as the Transaction and Security Service). • AdapterActivator An adapter activator is a callback object that permits you to create an object adapter on demand, when a request arrives for it, instead of forcing you keep all adapters active in memory at all times. Adapter activators are useful mainly to implement optimistic caching schemes, where entire groups of objects are instantiated in memory when a request for any one of the objects in the group is received. Of these, the first five are used regularly in almost every server; POACurrent and AdapterActivator support advanced or unusual implementation techniques.POA - 38 -

POA Un POA gère les relations entre
III. Corba Adaptateur POA « Pont entre les requêtes arrivants et les objets d’implémentation leur correspondant » Un POA gère les relations entre les références d’objets, les identificateurs et les servants Un serveur peut contenir plusieurs POAs Un POA gère plusieurs servants, tous avec une même politique déterminée par ses « policies » (immuables). Le RootPOA a un ensemble fixé de Policies, il est toujours présent. Un servant est associé à un unique POA. The main purpose of a POA is to bridge the gap between the abstract notion of a CORBA object and the concrete representation of that object’s behavior in form of a servant. In other words, POAs can be seen as a mapping mechanism that associates incoming requests with the correct C++ object in the server’s memory. A server can contain any number of POAs besides the Root POA (which is always present). Each POA, when it is created, is associated with a set of seven policies. These policies remain with the POA for its life time (that is, they become immutable once the POA is created). The policies determine the implementation characteristics of the servants associated with the POA, as well as aspects of object references (such as whether references are transient or persistent). A POA can have any number of servants, but each servant belongs to exactly one POA.1 - 39 -

Architecture du POA et terminologie
Active Object Map: table des objet actifs via leur ID Adapter activator: objet qui peut créer un POA sur demande Object ID: identification de l'objet au sein de l'adaptateur (unique au sein d'un même adaptateur) POA manager: objet qui contrôle l'état du POA Policy: objet qui contrôle le comportement d'un POA et de ses objets rootPOA: chaque ORB (serveur) est créé avec un POA racine qui permet de créer des POA fils. Servant: code qui implante les méthodes d'un objet. Servant Manager: objet gérant l'association servant-objet - 40 -

III. Corba Adaptateur POA manager Associé à un POA lors de la création de ce dernier (il ne peut pas être changé) ORB POA Manager Requête Servants Application serveur dispatch Les états possibles d’un POA manager : • Active : routage normale des requêtes • Holding : Requêtes stockées • Discarding : Requêtes rejetées avec TRANSIENT • Inactive : Requêtes rejetées ; les clients peuvent être redirigés vers un serveur différent pour ré-essayer. The general request flow into a server is shown above. Note that the diagram represents a conceptual view only. In the implementation, requests are not physically passed in this way for efficiency reasons. Conceptually, the request is directed toward a particular ORB within a server.3 If the ORB is processing requests (that is, has created a dispatch loop by calling ORB::run or is dispatching requests explicitly via ORB::work_pending and ORB::perform_work), the request is passed to the POA manager. The POA manager determines whether the request is queued, discarded, or passed on. If the POA manager is in the active state, the request is passed to the correct POA. The POA determines the relationship between the CORBA reference that was used to make the call (and, therefore, the CORBA object represented by that reference) and the servant, and passes the request to the correct servant. Functions of a POA Manager A POA manager acts as a gate that controls the flow of requests to one or more associated POAs. Conceptually, a POA manager represents a transport endpoint (such as a host–port pair for TCP/IP). A POA is associated with its POA manager when the POA is created; thereafter, the POA manager for a POA cannot be changed. A POA manager is in one of four possible states: • Active This is the normal state in which the POA manager passes an incoming request to the target POA, which in turn passes the request to the correct servant. • Holding In this state, the POA manager holds requests in a queue. Once the POA manager enters the active state, it passes the requests to their destination POAs. • Discarding Incoming requests are rejected with a TRANSIENT exception. This exception indicates to the client that the request cannot be delivered right now, but that it may work if retransmitted again later. • Inactive Requests are rejected; however, instead of raising an exception, the POA manager indicates to the client that the connection to the server is no longer usable. Depending on how the client is configured, this may result in an attempt by the client to locate a new instance of the server. Request Flow - 41 -

Diagramme d’état du POA Manager
III. Corba Adaptateur Diagramme d’état du POA Manager The above diagram shows the possible state transitions. The arcs in the diagram are labeled with the corresponding IDL operation name. Initially, when it is first created, a POA manager starts out in the holding state. Before the ORB delivers requests to POAs associated with that POA manager, you must transition to the active state (see page 9-14). Note that, once the POA manager enters the inactive state, it cannot be reactivated again and the only remaining transition is the destruction of the POA manager. POA managers are not destroyed explicitly; instead, a POA manager is destroyed once the last of its POAs is destroyed. You can freely transition among the remaining states by invoking the corresponding transition operation. The IDL for the POAManager interface is as follows: module PortableServer { // ... interface POAManager { exception AdapterInactive {}; enum State { HOLDING, ACTIVE, DISCARDING, INACTIVE }; State get_state(); void activate() raises(AdapterInactive); void hold_requests(in boolean wait_for_completion) raises(AdapterInactive); void discard_requests(in boolean wait_for_completion) void deactivate( in boolean etherealize_objects, in boolean wait_for_completion ) raises(AdapterInactive); }; State get_state() The get_state operation returns the current state of the of the POA manager as an enumerated value. void activate() raises(AdapterInactive) The activate operation transitions the POA manager into the active state. If the POA manager was previously in the holding state, the queued requests are dispatched in the order in which they were received. Attempts to activate an inactive POA manager raise AdapterInactive. raises(AdapterInactive) The hold_requests operation transitions the POA manager into the holding state. Incoming requests are queued up to some implementation-dependent limit.2 If wait_for_completion is false, the operation returns immediately; otherwise, it queues incoming requests but waits until all currently executing requests have completed before returning control to the caller. If you call this operation with wait_for_completion set to true from within a servant that has a POA that is controlled by this POA manager, the operation raises BAD_INV_ORDER (because it would deadlock otherwise). Attempts to invoke this operation on an inactive POA manager raise AdapterInactive. The discard_requests operation transitions the POA manager into the discarding state. Incoming requests are rejected with a TRANSIENT exception. The wait_for_completion parameter has the same semantics as for hold_requests. Attempts to invoke this operation on an inactive POA manager raise AdapterInactive. ) raises(AdapterInactive) The deactivate operation transitions the POA manager into the inactive state. Incoming requests are faced with a closed connection; the behavior that is visible to the client in this case depends on the type of object reference (transient or persistent) and the rebinding policy of the client. The wait_for_completion parameter has the same semantics as for discard_requests. The etherealize_objects parameter determines whether or not servant activators will be asked to destroy existing servants. (See page 15-4.) Attempts to invoke this operation on an inactive POA manager raise AdapterInactive. - 42 -

• LifespanPolicy (références transitoires ou persistantes)
III. Corba Adaptateur POA Policies Chaque POA a un ensemble de politiques. Lorsqu'un nouveau POA est créé on peut utiliser les valeurs par défaut ou les fixer selon les besoins. Un POA n'hérite pas des politiques de son père. • LifespanPolicy (références transitoires ou persistantes) • IdAssignmentPolicy (gestion de la clef) • IdUniquenessPolicy (association servant et objets d’implémentation) • ImplicitActivationPolicy (activation automatique ou non des servants) • RequestProcessingPolicy (gestion ID-to-servant) • ServantRetentionPolicy (gestion mémoire des servants) • ThreadPolicy * References persistentes permettent de relancer un serveur, * Un servant peut correspondre à plusieurs implementations, * permettre des instances multiples distinctes du POA dans un même serveur * objets "transitoires" avec peu d'effort de programmation et un faible surcoût * activation implicite des servants avec des identifiants d'objets alloués par le POA * permettre aux implantations d'objets d'être complètement responsable du comportement de l'objet (ex: déterminer un état pour l'objet, gérer le stockage et la récupération de l'état, fournir le code à exécuter pour les requêtes, etc…): la portabilité est donc traitée en rendant le comportement de l'objet indépendant de la mécanique de l'ORB donc repousse le problème… * ne requière pas que l'ORB maintienne l'état des objets: c'est de la responsabilité de implantation de l'objet * offre un mécanisme extensible pour associer une politique de contrôle du comportement d'un POA et des objets qu'il gère (contrôle: des exécutions concurrentes, de la durée des vies des objets, de la génération des identifiants d'objet, etc…) *contruire des implantations d'objet qui hérite d'un squelette statique ou qui sont des implanation DSI (avec un contrôle plus fin des durées de vie des servants The seven POA policies are all derived from the CORBA::Policy base interface. Each controls a different aspect of the implementation of an object. We briefly describe the purpose of each policy here and discuss it in more detail as we present the relevant implementation techniques. • LifespanPolicy The life span(durée) policy controls whether a reference is transient or persistent. A transient reference works only for as long as its POA remains in existence and then becomes permanently non-functional. Therefore, transient references do not survive server shut-down. Persistent references continue to denote the same object even if the server is shut down and restarted. • IdAssignmentPolicy The ID assignment policy controls whether the object ID that is part of the object key of every reference is created by the ORB or is provided by the application. Transient references usually use IDs that are created by the ORB, whereas persistent reference usually use IDs that are provided by the application. The POA maintains a lookup table known as the Active Object Map (AOM) that associates each object ID with the address of the corresponding servant in memory.8 This means that each object ID must uniquely identify a servant; otherwise, the POA could end up with a single object ID designating two servants simultaneously and would not know which servant to give the request to. • IdUniquenessPolicy The ID uniqueness policy determines how object references are mapped to C++ servants. You can choose to use one servant for each CORBA object that is provided by a server, or you can choose to incarnate multiple CORBA objects with the same C++ servant. • ImplicitActivationPolicy The implicit activation policy determines whether a newly instantiated servant must be explicitly activated (registered with the ORB) or will be activated automatically when you first create a reference for the servant. Transient references usually use implicitly activated servants, whereas persistent references must use explicitly activated servants. The code examples we have seen so far simply call _this on a newly instantiated servant in order to create a reference for the corresponding CORBA object. This technique works because the Root POA always uses the IMPLICIT_ACTIVATION policy. The first call to _this generates a new unique ID for the servant and adds the servant to the AOM. (The Root POA uses SYSTEM_ID and RETAIN). However, as we will see in Section 12.22, IMPLICIT_ACTIVATION is useful only for transient objects. For persistent objects, you must use NO_IMPLICIT_ACTIVATION (because persistent objects almost always use USER_ID, for which IMPLICIT_ACTIVATION is illegal). • RequestProcessingPolicy The request processing policy controls whether the POA maintains the object ID-to-servant associations for you (either to multiple servants or a single servant). You can also choose to maintain these associations yourself. Doing so is more work, but provides more powerful implementation choices. • ServantRetentionPolicy The servant retention policy controls whether you keep your servants in memory at all times or instantiate them on demand, as requests arrive from clients. • ThreadPolicy The thread policy controls whether requests are dispatched on a single thread or multiple threads. - 43 -

Root POA Policies Life Span Policy TRANSIENT ( PERSISTANT)
III. Corba Adaptateur Root POA Policies Life Span Policy TRANSIENT ( PERSISTANT) ID Assignment Policy SYSTEM_ID ( USER_ID) ID Uniqueness Policy UNIQUE_ID ( MULTIPLE_ID) Servant Retention Policy RETAIN ( PERSISTANT) Request Processing Policy USE_ACTIVE_OBJECT_MAP_ONLY ( USE_SERVANT_MANAGER ) Implicit Activation Policy IMPLICIT_ACTIVATION Thread Policy ORB_CTRL_MODEL Activités: ORB_CTRL_MODEL exécution concurrente (défaut); SINGLE_THREAD_MODEL exécution séquentielle Durée de vie: TRANSIENT lorsque le POA est désactivé l'objet n'existe plus (défaut) ; PERSISTANT les objets vivent plus longtemps que le POA créateur Partage: UNIQUE_ID un seul Object ID par servant (défaut); MULTIPLE_ID plusieurs Object ID par servant Génération des objects ID: USER_ID l'application génére les ID; SYSTEM_ID le POA génére les ID (defaut) Utilisation de la table Active Object Map: RETAIN les activations sont présentes dans la table (defaut) NO_RETAIN les activations ne sont pas dans la table (cf utilisation des ServantLocators qui sont un type de servant managers) Traitement de requête: USE_ACTIVE_OBJECT_MAP si l'Object ID n'est pas dans la table, une exception est levée (default); USE_DEFAULT_SERVANT si l'Object ID n'est pas dans la table, envoyer la requête au servant par défaut; USE_SERVANT_MANAGER si l'Object ID n'est pas dans la table, the servant manager est utilisé pour obtenir le servant Activation: IMPLICIT_ACTIVATION les servants peuvent être activés en les convertissant en référence d'objet ou en invoquant _this() sur le servant NO_IMPLICIT_ACTIVATION pas d'activation implicite (defaut) Localisation (spécifique au service Visibroker): BY_INSTANCE tous les objets sont enregistrés sur l'osagent BY_POA sur les POA sont enregistrés et pas tous les objets individuellement (defaut) NONE aucun enregistrement Note that the implicit activation policy does not have the default value. The Root POA is useful for transient objects only. If you want to create persistent objects or use more sophisticated implementation techniques, you must create your own POAs. The Root POA always has the policies shown above. The policies for the Root POA have the default values, except for the implicit activation policy (which has a default value of NO_IMPLICIT_ACTIVATION). The Root POA uses TRANSIENT and SYSTEM_ID, so it is useful only for creation of transient references. You should therefore restrict use of the Root POA to short-lived temporary objects. Adapter activators Un serveur utilise ce composant lorsqu'il souhaite que les POA soient créés à la demande. Lorsqu'un POA reçoit une requête pour un fils (ou un de ses descendants) qui n'existe pas, l'adap ter activa to r permet sa création. Pendant que l'activateur est en train de créer un POA, les requêtes concernant ce POA sont mises en attente: permet que la création se termine avant que des requêtes soient envoyées au nouveau POA - 44 -

Création de POA III. Corba module PortableServer {
Adaptateur Création de POA module PortableServer { interface POAManager; exception AdapterAlreadyExists {}; exception InvalidPolicy { unsigned short index; }; interface POA { POA create_POA( in string adapter_name, in POAManager manager, in CORBA::PolicyList policies; ) raises(AdapterAlreadyExists, InvalidPolicy); readonly attribute POAManager the_POAManager; // ... }; POA Creation The POA interface provides an operation that creates POAs. (This is an example of the factory pattern, which we will examine in more detail in Section ) Initially, the only POA you have access to is the Root POA, returned by resolve_initial_references. In order to create other POAs, you call the create_POA operation on the Root POA or, once you have created other POAs, on a POA other than the Root POA. The newly created POA becomes a child of the POA on which you invoke create_POA. In other words, if you have multiple POAs in a server, they are arranged into a hierarchy with the Root POA at the top. You control the shape of the hierarchy by choosing the POA on which you call create_POA. Each POA has a name, controlled by setting the adapter_name parameter. You can choose any name you deem suitable, but you must ensure that no other sibling POA has the same name; otherwise, create_POA raises an AdapterAlreadyExists exception. As with a directory tree, the name of a POA must be unique only within the context of its parent, so you can have several POAs with the same name, as long as they have different parent POAs. The manager parameter controls whether the new POA will use a separate POA manager or share a POA manger with other POAs: if you pass a nil reference, a new POA manager will be created for this POA; otherwise, you can pass a reference to an existing POA manager 6 and the new POA will be added to the list of POAs controlled by that manager. The policies parameter sets the policies to be applied to the new POA. The policy list can contain up to seven distinct POA policies. If you supply a value for the same policy more than once, or if one of the policies does not apply to the POA, the create_POA raises InvalidPolicy; the index member of the exception indicates the first policy that was found to be in error. You can create a POA with an empty policy sequence. If you do, each of the seven policies gets a default value. For now, let us look at a simple example. The code that follows creates the following POA hierarchy: - 45 -

Exemple de création de POA (en C++)
III. Corba Adaptateur Exemple de création de POA (en C++) // Initialize ORB and get Root POA CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); CORBA::Object_var obj = orb->resolve_initial_references("RootPOA"); PortableServer::POA_var root_poa=PortableServer::POA::_narrow(obj); assert(!CORBA::is_nil(root_poa)); // Create empty policy list CORBA::PolicyList policy_list; // Create Controller POA PortableServer::POA_var ctrl_poa = root_poa->create_POA( "Controller", PortableServer::POAManager::_nil(), policy_list); // Create Thermometer POA as a child of the Controller POA PortableServer::POA_var thermometer_poa = ctrl_poa->create_POA( "Thermometers", PortableServer::POAManager::_nil(), policy_list); // Get the Root POA manager PortableServer::POAManager_var mgr = root_poa->the_POAManager(); // Create Thermostat POA as a child of the Controller POA PortableServer::POA_var thermostat_poa = ctrl_poa->create_POA( "Thermostats", mgr, policy_list); Root POA Controller Thermometers Thermostats Because the code passes a nil reference as the manager parameter, each POA ends up with its own, separate POA manager; because the code passes an empty policy sequence as the policies parameter, each POA gets created with the default policies. There are many reasons for using more than one POA. For example, it is common to use a separate POA for each interface that is provided by a server. (This technique is common in conjunction with servant managers.) The POA hierarchy also controls the order of destruction when you shut down the ORB: child POAs are destroyed before their parents. (This is useful to, for example, ensure that thermometers and thermostats are destroyed before the controller is destroyed.) Similarly, you may want to use more than one POA manager in order to separately control the processing of requests for different groups of objects. (This is useful if you want to suspend request processing temporarily for one set of objects without affecting the processing of requests for another set of objects.) - 46 -

Etapes de mise en œuvre Définition de l ’interface IDL Pré-compilation du fichier IDL et Projection vers des langages de programmation. Code du serveur : Implantation des interfaces IDL Implantation du serveur Implantation des clients Installation et configuration des serveurs Diffusion et configuration des clients Exécution répartie de l’application. Il n’y a pas de scénario standardisé de conception et développement d’applications distribuées néanmoins la mise en place d’une application Corba suit tjs à peu prés le même scénario. On définit les objets composants l ’application à partir d ’un cahier des charge en suivant une méthodologie Objet UML par ex. Cette modélisation est ensuite traduite sous la forme de contrats IDL composés des interfaces des objets et des types de données utiles aux échanges d ’info entre objets. On les saisie avec n ’importe quel éditeur de texte La première étape est la vérification syntaxique et sémantique des définitions IDL. Il peut aussi charger ces définitions dans le référentiel des interfaces (A regarder) puis projection tant pour le client que le serveur. le serveur contient le code pour se connecter au bus, instancier les objets racines du serveur, rendre publique les références sur ces objets à l ’aide par ex. d ’un service de nommage et se mettre en attente de requêtes pour ces objets. Le client incluse le code des souches…. installation dans le référentiel des implantations des serveurs pour automatiser leur activation lorsque les requêtes arrivent sur les objets diffusions des excutables sur les sites de différentes utilisations du client et configuartion des sites clients pour qu ’ils sachent où trouver les serveurs utilisés. - 47 -

III. Corba Interopérabilité Interopérabilité Avant CORBA 2.0, Problème d'interopérabilité entre ORBs. Interopérabilité Capacité pour un ORB A d'invoquer une opération définie en IDL sur un objet résidant sur un ORB B. L'ORB A et B étant des implémentations de CORBA différentes. Il existe différents produits d’ORB ce qui est sain car il permet aux vendeurs d’adapter leurs produits aux besoins spécifiques de leur environnement opérationnel. Mais cela créé aussi le besoin pour plusieurs ORB d’interopérer. De plus il y a des systèmes client/serveur qui ne sont pas compliant Corba et le besoin de pouvoir interopérer avec ces systèmes est croissant. Non seulement il y a des différences d’implémentation qui sépare les objets mais également des raisons de sécurité ou de protection d’un produit en développement. - 48 -

Interopérabilité d’applications avec CORBA
III. Corba Interopérabilité d’applications avec CORBA Deux problèmes : 1- communication d’applications distribuées au sein d’un même environnement; 2- interopérabilité d’applications distribuées entre environnements hétérogènes. Problème 1 Problème 1 Communication Communication Problème 2 Interopérabilité A1 An B1 Bn ... ... Environnement X Environnement Y - 49 -

Portabilité d’applications avec CORBA1.2
III. Corba Interopérabilité Portabilité d’applications avec CORBA1.2 CORBA 1.2 permet de : résoudre le problème de communication d’applications distribuées au sein d’un même environnement; Problème 1 résolu Problème 1 résolu Communication Problème 2 Communication ?? A1 IDL Binding An IDL Binding B1 IDL Binding Bn IDL Binding ... ... ORB 1.2 vendeur x ORB 1.2 vendeur y cf. p. 33 à 40 Environnement X Environnement Y - 50 -

Portabilité d’applications avec CORBA 1.2
III. Corba Interopérabilité Portabilité d’applications avec CORBA 1.2 CORBA 1.2 permet de : simplifier le portage d’applications entre environnements hétérogènes grâce au langage IDL, aux standardisations des bindings. A1 IDL Binding An IDL Binding B1 IDL Binding Bn IDL Binding ... ... ORB 1.2 vendeur y Environnement Y - 51 -

Interopérabilité d’application avec CORBA 2.0
III. Corba Interopérabilité Interopérabilité d’application avec CORBA 2.0 CORBA 2.0 permet de résoudre le problème d’interopérabilité d’applications distribuées entre des environnements hétérogènes grâce au protocole de communication commun GIOP (General Inter ORB Protocol). A1 IDL Binding An IDL Binding B1 IDL Binding Bn IDL Binding Problème 2 résolu ... ... Interopérabilité GIOP ORB 2.0 vendeur x ORB 2.0 vendeur y Environnement X Environnement Y - 52 -

Solution La spécification CORBA 2.0 comporte 4 nouveaux éléments :
le cadre architectural définissant l’interopérabilité entre différents ORBs; la définition de protocoles communs GIOP et IIOP; la définition de protocoles spécifiques à un environnement ESIOP et DCE/ESIOP; la définition de passerelles inter-ORB, permettant la communication entre différentes implémentations de CORBA Les ponts peuvent être implémentés soit de façon interne à l’ORB ou dans les couches au dessus. Implémenté dans l’ORB ils sont dit en Ligne (in-line) sinon il sont dit request-level bridges. Les in_line soit en ajoutant des services à l’ORBsoit en ajoutant du code dans les stubs et squelettes. request_level : le client ORB prétend que le pont et le serveur ORB sont des parties de l’implémentation d’objet et ément une requette vers cet objet au travers du DSI. Le DSI alors en coopération avec le pont transmet la requete dans un format compréhensible par le serveur ORB et l’invoque au travers de la DII de l’ORB serveur. Le pont a alors besoin d’avoir des infos sur l’objet et a donc soit acces à l’interface repository ou il est specifique et donc l’interface de l’applications est cablée dedans. Pour cela, il est nécessaire de stabdardisé la syntaxe (GIOP) - 53 -

GIOP et IIOP GIOP (General Inter-ORB Protocol) spécifie un ensemble de
III. Corba Interopérabilité GIOP et IIOP GIOP (General Inter-ORB Protocol) spécifie un ensemble de formats pour les messages ainsi qu'une représentation commune des données échangées entre les ORBs. La représentation des données communes est basée sur la spécification CDR (Common Data Representation). IIOP (Internet Inter-ORB Protocol) est l'implémentation du protocole GIOP basé sur TCP/IP. Java RMI lui utilise JRMP : Java remote method protocol … Les ORB communiquent en utilisant IIOP il en existe d’autres mais IIOP est le plus populaire, parce que c’est un standard et à cause de la popularité de TCP/IP.(protocole réseau utilisé par Internet), couche sur laquelle repose IIOP Le protocole GIOP définit une représentation commune des données (CDR = Comon Data Représentation), un format de références d ’objet interopérable (IOR ou Interopérable Object Reference) et un ens. de messages de transport de requêtes aux objets (reply, Request, …). Dans le contexte d ’IIOP les IOR contiennent : le nom complet de l ’interface OMG-IDL, l ’adresse IP de la machine internet ou est localisé l ’objet, un port IP pour se connecter au serveur de l ’objet, une clef pour désigner l ’objet dans le serveur (Format libre et donc différent pour chaque implantation du Bus). - 54 -

IOR IOR (Interoperable Object Reference)
III. Corba IOR IOR (Interoperable Object Reference) interface OMG IDL : repository ID adresse + port IP clé de format libre (identifie le POA et l’objet dans le POA) Spécifique à l’ORB possède une forme externe diffusable chaîne IOR : IOR: …. - 55 -

Services communs CORBA
- 56 -

Les services communs CORBA
III. Corba Services Les services communs CORBA Service de recherche d’objets : pour retrouver un objet Nommage (Naming) : par un nom : service de « pages blanches » Vendeur (Trader) : par des propriétés: service de « pages jaunes Services concernant la vie des objets : Life Cycle, Property, Relationship, Externalization, Persistent Object, Query, Collection, Versionning, Time, Licencing Services de sûreté de fonctionnement : Security, Transactions, Concurrence Services de communications asynchrones: Events, Notification, Messaging Vendeur : les objets peuvent être recherchés en fonction de leurs caractéristiques. - 57 -

Les services communs CORBA : historique
III. Corba Services Les services communs CORBA : historique 1er RFP : Nommage, Cycle de vie, Notification d'événements, Persistance. 2ème RFP : Transactions, Concurrence d ’accès, Externalisation, Relations. 3ème RFP : Sécurité, Serveur de temps. 4ème RFP : Propriétés, License, Serveur de requêtes. 5ème RFP : Annuaire par fonctionnalités, Collection, Gestionnaire de versions. Request For Proposalrequete dont le résulat c’est des réponses des membres basées sur des otils existants ou en développement des preuves de faisabilité sont alors demandées. RFP sont alors merger à 16 mois pour sortir un standard. Actuellement le travail est plus tourné vers les CORBA et JavaBeans, Corba Domains et Business Objects. Et il y a la préparation de Corba 3.0 - 58 -

Les services de recherche d’objets CORBA
III. Corba Services Les services de recherche d’objets CORBA Bus d’objets répartis CORBA sur Internet (IIOP) Serveur C++ Client Java Repertoire Traitement Service de recherche d’objets IOR IOR équivalent des pages blanches : objets désignés par un nom symbolique . annuaire matérialisé par un graphe de répertoire de désignation. Services Nommage et/ou Vendeur - 59 -

III. Corba Services Le service de Nommage Le service de Nommage ou Namming service permet : d’associer un nom à une référence d’objet CORBA, relativement à un contexte de noms; de retrouver la référence d’objet ainsi que l’objet associé; de naviguer à l'intérieur d’un contexte de noms. Opérations principales ajouter une association : bind, rebind, ... résoudre une association : resolve détruire une association : unbind lister le contenu : list détruire le contexte : destroy - 60 -

Le contrat IDL du service Nommage
III. Corba Services Le contrat IDL du service Nommage module CosNaming // Le service Nommage. { typedef string Istring; struct NameComponent { // Un nom d’association. string id; string kind; }; // Un chemin d’accès = une suite de noms. typedef sequence<NameComponent> Name; interface NamingContext { // Un contexte. enum NotFoundReason { missing_node, not_context, not_object }; exception NotFound {NotFoundReason why; Name rest_of_name;}; exception CannotProceed {NamingContext cxt; Name rest_of_name;}; exception InvalidName { }; exception AlreadyBound { }; exception NotEmpty { }; // Associer un nom à une référence. void bind(in Name n, in Object obj) raises(NotFound, CannotProceed, InvalidName, AlreadyBound); // Rechercher une association. Object resolve (in Name n) raises(NotFound, CannotProceed, InvalidName); // Autres opérations : // rebind bind_context rebind_context unbind // new_context bind_new_context // destroy list }; - 61 -

Comment retrouver la référence du service de nommage ?
III. Corba Services Comment retrouver la référence du service de nommage ? C’est un « objet notoire » du bus CORBA de nom NameService Quelque soit le langage, le scénario est a. opération CORBA::ORB::resolve_initial_references b. conversion en CosNaming::NamingContext // En C++, obtenir la référence du service Nommage. CORBA_Object_var contextObj = orb->resolve_initial_references ("NameService"); CosNaming::NamingContext_var context = CosNaming::NamingContext::_narrow(contextObj); // En Java, obtenir la référence du service Nommage. org.omg.CORBA.Object objRef = // (1.a) orb.resolve_initial_references ("NameService"); NamingContext nsRef = // (1.b) NamingContextHelper.narrow(objRef); ?? Faut verifier et eventuellement le mettre dans le transparent. - 62 -

Utilisations du service Nommage
III. Corba Services Utilisations du service Nommage Enregistrer une référence diffusion par un serveur de ses références d’objet création d’un chemin opération bind ou rebind Rechercher une référence (2) création d’un chemin valide (3) opération resolve (4) conversion vers le type nécessaire CosNaming::Name_var nsNom = new CosNaming_Name(); nsNom->length(1); nsNom[0].id = (const char*) "BNP";//nom du serveur nsNom[0].kind = (const char*) "BANKSERVER"; context->bind (nsNom, bnpServeur); CORBA::Object_var objRef = context->resolve (nsNom); bankServer_var bnp = bankServer::_narrow (objRef); - 63 -

Le service Vendeur Le service vendeur ou Trader service permet :
III. Corba Services Le service Vendeur Le service vendeur ou Trader service permet : d ’enregistrer des objets auprès de ce service en les caractérisant par un ensemble de propriétés. de retrouver un service en précisant son type et les critères le caractérisant (différentes politiques de recherche possibles) Opérations principales découvrir et importer des services : Interface LookUp : query (type de service recherché, contraintes, préférences, politique de recherche, ….) parcourir les réponses : Interface OfferIterator mise à jour du service Vendeur : Interface Register export, withdraw …... équivalent des pages jaunes : modes de recherche politique de recherche : un ou des services vendeurs contraintes : le service vendeur définit un langage de contraintes, il est possible d ’en utiliser ou d ’en définir d ’autres SQL par ex. préférences : manières dont les résultats seront rournés : ordre de découverte, aléatoire, etc…. - 64 -

Le service de notification d'événements
III. Corba Services Le service de notification d'événements La plupart des requêtes CORBA se traduisent par l’exécution synchrone d’une opération (le client connaît la référence de l’objet auquel la requête s’adresse et le client ainsi que l’objet doivent être tous deux actifs) et sinon? Le service d'Evénements ou Event service permet de découpler la communication entre objets. Mode de communication découplé : lorsque le client et l’objet ne se connaissent pas; lorsque le client et l’objet ne sont pas actifs simultanément. Je saurais le compléter.par un dessin.. Il permet aux objets de produire des événements asynchrone à destination d’objets consommateurs. Producteurs et consommateurs dialoguent à travers un intermédiaire appelé canal d’événements. Les producteurs n’ont pas besoins de connaître tous les consommateurs intéressés. Etendu avec le Notification service ou les consommateurs sont notifiés uniquement des évènements les interessant ce qui permet de réduire le trafic. Voir l ’exemple de Douglas si je pouvais recuperer le transparent…. dans le mode push le producteur a l ’initiative de la production le consommateur est notifié. Dans le mode pull, le consommateur demande explicitement les événements, le producteur est alors sollicité. .. - 65 -

Communication événementielle principes de fonctionnement
• concepts de base : événements, réactions (traitements associés à l’occurrence d’un événement) • principe d’attachement : association dynamique entre un nom d’événement et une réaction • communication anonyme : indépendance entre l’émetteur et les “consommateurs” d’un événement - 66 -

Un canal d’évènements Flot des évènements Consommateur Producteur
III. Corba Services Un canal d’évènements Flot des évènements Consommateur Producteur Consommateur Producteur Canal Consommateur Consommateur - 67 -

Un canal d’évènements : notification
III. Corba Services Un canal d’évènements : notification PushConsumer PushSupplier Consommateur Producteur Push void push(in any data) raises(Disconnected); Consommateur Producteur Canal Push Consommateur Consommateur Producteur actif / Consommateur réactif Le canal diffuse les évènements - 68 -

Un canal d’évènements : demande
III. Corba Services Un canal d’évènements : demande Consommateur Producteur Pull() Consommateur Producteur Canal Pull() Consommateur PullSupplier { //demande de production d’un événement any pull() raises(Disconnected); // présence d’un événement any try_pull(out boolean has_event) raises(Disconnected); demande Consommateur Like consumers, suppliers can also use push or pull behavior. Push suppliers are the more common type, in which the supplier directly forwards data to the event channel and thus plays the client role in the link to the channel. Pull suppliers, on the other hand, are polled by the event channel and supply an event in response, if a new event is available. Polling is done by the try_pull() operation if it is to be non-blocking or by the blocking pull() call: // IDL interface PullSupplier { any pull() raises(Disconnected); any try_pull(out boolean has_event) void disconnect_pull_supplier(); }; Producteur réactif / Consommateur actif Le canal procure les évènements - 69 -

Un canal d’évènements : file d’évènements
III. Corba Services Un canal d’évènements : file d’évènements Consommateur Producteur Pull() Consommateur Producteur Canal Push() Consommateur Consommateur Producteur actif / Consommateur actif Le canal gère des files d’évènements - 70 -

Un canal d’évènements : collecte d’évènements
III. Corba Services Un canal d’évènements : collecte d’évènements Consommateur Producteur Push() Consommateur Producteur Canal Pull() Consommateur Consommateur Producteur réactif / Consommateur réactif Le canal est une entité active voire intelligente - 71 -

Le service de Transaction
III. Corba Services Le service de Transaction Le service de Transaction ou Transaction service permet d’assurer la consistance des traitements en respectant les propriétés ACID (Atomicité, Consistance, Isolation et durabilité) des transactions. Il permet : de commencer et de terminer une transaction; de contrôler la propagation d’une transaction; d’associer plusieurs objets répartis à une seule et même transaction; de coordonner la terminaison d’une transaction (2 phase commit). Propriétés ACID : Atomicité : une transaction n’est pas décomposable, il faut qu’elle aille jusqu’au bout ou que rien n’ait été fait. Consistence : après la transaction l’ensemble des données est dans un état cohérent. Isolement : si exécution simultanée de plusieurs transactions, les mise à jour de chacunes n’interfèrent pas avec les autres. Durabilité : après une transaction terminée normalement par un COMMIT, le système conservera les valeurs des données (journalisation, sauvegarde, reprise). - 72 -

Le service de Concurrence
III. Corba Services Le service de Concurrence Le service de Concurrence ou Concurrency control service permet de contrôler l’accès à un objet de manière à gérer la cohérence et la consistance des opérations entre cet objet et les objets qu’il accède ou bien qui l’accèdent. Il permet de créer des verrous répartis et de spécifier le type de verrou crée (lecture, écriture, mise-à-jour etc...). concu pour être utilisé avec le service Transaction. - 73 -

Le service d’Externalisation
III. Corba Services Le service d’Externalisation Le service d’Externalisation ou Externalization service permet : l’externalisation d’un objet, c’est à dire la représentation de l’état de l’objet dans une séquence d’octets (en mémoire, sur disque, sur réseau) transportable, de durée de vie illimitée indépendante de l’environnement (ORB) d’origine. l’internalisation des données, impliquant la création d’un nouvel objet dans le même environnement ou dans un environnement différent. le déplacement (migration d’objets), passage par valeur et la sauvegarde des objets doivent reposer sur ce service. - 74 -

III. Corba Services Le service Cycle de vie Le service Cycle de vie ou Life cycle service permet : de gérer la création, la destruction, la copie et le déplacement des objets du bus; les objets sont créés par l’intermédiaire d’objets appelés Factories dont la référence est accessible au client; un objet est détruit, copié ou déplacé à l’aide d’opérations définies dans l’interface de base LifeCycleObject; The Factory pattern can be applied in a wide variety of situations, including the following: • Security - A client is required to provide security information before the factory object will allow the client to have access to another object. Load-balancing - The factory object manages a pool of objects, often representing some limited resource, and assigns them to clients based on some utilization algorithm. • Polymorphism - A factory object enables the use of polymorphism by returning object references to different implementations depending on the criteria specified by a client. - 75 -

Le service de Relations
III. Corba Services Le service de Relations Le service de Relations ou Relationships service permet d’établir dynamiquement des relations entre les objets distribués. Une relation est définie par un rôle, un degré, une cardinalité et des attributs. Trois niveaux de services : basique : service de base permettant de créer les relations et les objets et de naviguer à travers la relation, de détruire la relation; graphes d’objet en relation; relations spécifiques : Containment (1-n) et référence (n-m). Ex relation : emploie compangie personne Role de compagnie : employeur Role de personne : employée Degré de la relation emploie : relation binaire (nombre de role requis = 2) Cardinalité de la relation emploie : (nbre max des relations impliquées pour un rôle) Ex => aux nbres max des personnes employés pour une compagnie. Attributs de la relation emploie : titre du job, date de début, etc .... - 76 - Les relations sont encapsulées dans des objets, des contraintes??, et différents types de relations : appartenance, inclusion, référence, l ’auteur et l ’emploi. Manipulation de graphes d ’objets

Affecte le bus, les services, les utiltaires, les applicatifs
III. Corba Services Sécurité et temps Le service de Sécurité (Security) permet de gérer les fonctions suivantes : authentification autorisation sûreté et intégrité des communications encryptage administration de la sécurité Le service de Temps (Time) permet la synchronisation périodique d’horloges dans tous les composants d’un système réparti. autentifier les clients , chiffrer et certifier les communications, contrôler les autorisation d’accès. Ce service utilise les notions de serveurs d’authentifications, de clients/rôle/droits (et délégation de droits), d’IIOP sécurisé permet d’obtenir une horloge globale sur le bus de mesurer le temps et de synchroniser les objets. Affecte le bus, les services, les utiltaires, les applicatifs - 77 -

4ème RFP Le service de Propriétés (Properties) permet d’associer
III. Corba Services 4ème RFP Le service de Propriétés (Properties) permet d’associer dynamiquement une liste de propriétés à un objet. Il est possible d’ajouter, de supprimer, de modifier et de retrouver toute propriété associée à un objet. Le service d’interrogations (Query) permet d’exprimer des requêtes sur des ensembles d’objets CORBA. Le service de License (Licensing) contrôle et gère les rémunérations associées à l’utilisation d’un service objet donné. sans modifier son IDL. Ce sont des attributs spécifiques aux besoins du clients date d’expiration ou annotation par ex. il repose sur SQL et permet d’interroger les attributs des objets Permet de manipuler les requêtes comme des objets Corba, les objets resulat sont mis dans une collection.. briques pour mesurer, contrôler et limiter l’utilisation des objets CORBA. Il produit aussi des info pour facturer les clients et rémunérer les fournisseurs… - 78 -

5ème RFP Le service de Gestion des versions (Change Management) permet
III. Corba Services 5ème RFP Le service de Gestion des versions (Change Management) permet de gérer l’évolution des versions des interfaces des objets ainsi que de l'adéquation avec leurs implémentations. Le service d’Annuaire par fonctionnalités (Trader) permet d’associer des fonctionnalités à des objets CORBA. Le client utilise ce service comme l’annuaire des pages jaunes. Le service de Collection (Collection) permet de créer et de manipuler des collections d’objets. ou vendeur : le fournisseur enregistre ces objets en les caractérisant par des propriétés, ... utilise avec le service interrogations il permet de manipuler et effectuer des traitements itératifs sur des ens. d’objets. - 79 -

Taxonomie des services
III. Corba Services Taxonomie des services Nommage + Annuaire par fonctionnalités Persistance + Externalisation Cycle de vie + Relation Serveur de requêtes + Collections + Properties Transaction + Concurrence Sécurité + License Gestionnaire des versions Time Event - 80 -

CORBA Services en résumé
III. Corba Services CORBA Services en résumé Persistent Object Save objects to databases Concurrency Managing simultaneous access Licensing Managing licensed services Externalization External representation of objects Relationship Manage relationships between objects that don't know about each other Query Query objects on the network Naming How are objects found? Events Standardized mechanism for client notifications. LifeCycle How are objects created, moved, duplicated and deleted? Trader Find objects that have certain properties Transactions Distributed 2-phase commit Interfaced with the XA standard Security Complete distributed security - 81 -

CORBA 3.0 Une suite de spécifications
III. Corba CORBA 3.0 Une suite de spécifications Intégration de Java et l’Internet Passage par valeur (Corba 2.3) Java to IDL : Interopérabilité des objets RMI (2.3) (Firewall specification) Mid-2001 Interopérabilité et service de nommage (2.4) Amélioration de la qualité de service Asynchronous Messaging (2.4 fin 2000) Corba minimum pour les systèmes embarqués Temps réel, Modèle de composants, langage de script Toujours en mouvance, actuellement Corba bouge pour répondre aux prérequis du Web Object. Il doit aussi maintenir son avance sur DCOM génération automatique d ’IDL CORBA à partir de code Java, des stubs en binaire Java portable pour être exécutée sur toute machine virtuelle. Spécification d ’un proxy FireWall Specification de messaging pour intégration de message orienté Middleware et la specification pour travailler avec DCE/DCOM Composants distribués : ?? Objects Passable by Value CORBA's language-independent equivalent of Java's serializable, the valuetype enables many new features including the reverse Java-to-IDL mapping (which we'll mention next) and the XML/Value mapping which allows XML documents to be represented as native CORBA types. Now a well-established part of CORBA, this feature was first included in CORBA 2.3 in June 1999 and still resides in the core CORBA specification where it is included as Chapters 5 and 6. Language-specific aspects are included in each language mapping specification. Java-to-IDL Mapping This mapping allows Java RMI objects to interoperate over the network as CORBA objects. They have CORBA object references, and emit the IIOP protocol. As the CORBA Component Model and Enterprise JavaBeans encourage developers and companies to accumulate libraries of application components, this specification allows libraries of CORBA Components and EJBs to be used together to construct applications. Like the valuetype specification, the Java-to-IDL mapping was part of CORBA 2.3 where it is listed with the language mappings. The CORBA object reference is a cornerstone of the architecture. Because the computer-readable IOR was (until now!) the only way to reach an instance and invoke it, there was no way to reach a remote instance - even if you knew its location and that it was up and running - unless you could get access to its object reference. The easiest way to do that was to get a reference to its Naming Service, but what if you didn't have a reference for even that? The Interoperable Name Service defines one URL-format object reference, corbaloc, that can be typed into a program to reach defined services at a remote location, including the Naming Service. A second URL format, corbaname, actually invokes the remote Naming Service using the name that the user appends to the URL, and retrieves the IOR of the named object. For example, the corbaloc identifier corbaloc:: would resolve to the CORBA Naming Service running on the machine whose IP address corresponded to the domain name (if we had a Name Server running here at OMG). In late 2000 this service was added to CORBA in the 2.4 release, where object URLs are section , and configuration of initial service references are section The definition of a standard syntax for object compound names appears in the Naming CORBAservice, where it is Chapter 2.4. C:\Mes documents\Mireille\Cours\CORBA\CORBA 3 Release Info.htm The new Messaging Specification defines a number of asynchronous and time-independent invocation modes for CORBA, and allows both static and dynamic invocations to use every mode. Asynchronous invocations' results may be retrieved by either polling or callback, with the choice made by the form used by the client in the original invocation. Policies allow control of Quality of Service of invocations. Clients and objects may control ordering (by time, priority, or deadline); set priority, deadlines, and time-to-live; set a start time and end time for time-sensitive invocations, and control routing policy and network routing hop count. The messaging specification became a part of CORBA with Release 2.4 in late 2000, where it appears as Chapter 22. Minimum, Fault-Tolerant, and Real-Time CORBA minimumCORBA is primarily intended for embedded and card-format systems. These systems, once they are finalized and burned into chips for production, are fixed, and their interactions with the outside network are predictable - they have no need for the dynamic aspects of CORBA, such as the Dynamic Invocation Interface or the Interface Repository that supports it, which are therefore not included in minimumCORBA. minimumCORBA became a part of CORBA with Release 2.4 in late 2000, where it appears as Chapter 23. Real-time CORBA standardizes resource control - threads, protocols, connections, and so on - using priority models to achieve predictable behavior for both hard and statistical realtime environments. Dynamic scheduling, not a part of the current specification, is being added via a separate RFP and had completed work and started into a final series of adoption votes when we updated this page in July Real-Time CORBA became a part of CORBA with Release 2.4 in late 2000, where it appears (mostly) as Chapter 24. Fault Tolerant CORBA standardizes redundant software configurations and systems that, when run on redundant hardware, give CORBA the reliable and robust performance that Enterprise applications rely on. More recent than Real-Time and minimumCORBA, this specification has not yet been issued as a numbered release. The specification has been officially adopted, and is now completing its first maintenance cycle. You can find the specification here. - 82 -

Integration de Java RMI avec CORBA : RMI-IIOP
RMI est une solution tout-java Un modèle simple de programmation “An immature middleware infrastructure” CORBA est un standard pour les objets distribués Un modèle de programmation pas si simple et non dédié spécifiquement à Java “A mature middleware infrastructure” RMI s’exécute via IIOP Utilisation des spécifications sur le passage par valeur de l’OMG Java-to-IDL Mais pas de chargement dynamique des stubs La spec va plus loin que du mappings syntaxique elle precise en particulier quel sous ens de JAVA RMI peut etre utilise pour faire du CORBA, ill y a enn effet des grosses differences semantiques commme l’heritage, GC, …pas de cast implicite - 83 -

RMI/CORBA via IIOP RMI implementation client d’un Objet CORBA RMI
stub CORBA Squelette RMI stub contacte un ORB local qui utilise le protocole IIOP pour la communcation avec le serevur au lieu de JRMP De meme l’ORB Java en retour devra transformer la reponse …Donc une grosse part du boulot repose sur le bus… ORB ORB Réseau via IIOP - 84 -

Pourquoi CORBA? Infrastructure largement adoptée pour la distribution d’objets Plate-forme indépendant, il permet l’intégration de systèmes propriétaires Langage indépendant : Clients et serveurs peuvent être implémentés dans des langages différents CORBA est indépendant d’une compagnie (donc d’Un produit ou d’une architecture) De nombreux services Fournit un accès multi-langages pour les EJBs. CORBA offers quite a few advantages. Among them is the fact that CORBA is not proprietary technology, so you get implementations from a large number of vendors for almost every imaginable combination of hardware, operating system, and programming language. Quite fierce competition among vendors ensures that you have a choice, while the specifications ensure interoperability and portability. You can even get Open Source implementations free of charge. CORBA makes distributed programming easier than any other platform in existence. Most of the low-level and difficult work required for distribution is taken care of for you, so you can concentrate on your application instead of distributed programming. (However, that doesn’t mean that you can forget that a network is somewhere between the client and server, only that you don’t have to deal with that network directly.) On the down side, CORBA suffers from a few problems too. Because the OMG publishes specifications, not source code, there is no reference implementation that would definitively state what CORBA is. This means that specifications are sometimes too loose or ambiguous and permit implementation behavior to diverge until the OMG catches up with the problem and fixes the specification. Consensus decision making is also not necessarily the best way to establish a specification. While the specifications usually do what most parties want, they are typically not as elegant or tight as they could be, due to the need to accommodate everyone’s needs. And, as with any powerful and complex tool, it is easy to build something that doesn’t work very well. You still need to know what you are doing and CORBA cannot do your thinking for you. Still, CORBA is by far the most successful and widely-used distributed client/server technology in existence. Once you know it, you will enjoy it! « CORBA is the only middleware platform that is both vendor- and language-independent. » « You still need to know what you are doing and CORBA cannot do your thinking for you ». - 85 -

CORBA … Pas d’approche standard du déploiement
(connexion entre IMR et serveurs non standardisé) Quels services sont disponibles sur le site de déploiement Pas de support des idioms de développement des serveurs CORBA Comment « bootstrapper » les références? (naming, trader, …) Mise en place de factories gérant le cycle de vie… Difficulté pour l’extension des fonctionnalités des objets. Nécessité d’une construction par composition plutôt que par héritage Pas de gestion automatique du cycle de vie des objets. Qui gère l’activation des objets? Pas de standard IMR… - 86 -

COMPOSANTS, besoins Des unités interchangeables
Spécification de ce qui est offert Spécification de ce qui est nécessaire Déploiement standardisé semi-automatique Génération de code pour la mise en œuvre de certains « services » (D.P.) (Factory, persistance, sécurité, …) ATTENTION SERVEURS! typedef sequence<octet> SoundBytes; typedef int Speed; interface AudioStreamIterator { void getStream(out SoundBytes nextSound, out boolean hasMore); }; interface AudioPlayer { attribute string name; AudioStreamIterator getSoundStream(in String strSound); int play(in AudioStreamIterator as); int fastForward(in Speed spd); int rewind(in Speed spd); }; component CassettePlayer supports AudioPlayer{ // The facet for Client components. provides AudioPlayer audioPort; }; component CDPlayer supports AudioPlayer{ // The facet for Client components. provides AudioPlayer audioPort; }; component Stereo { attribute string name; // The receptacles for Cassettes or CDPlayers uses AudioPlayer Cassette; uses AudioPlayer CD; }; The interface for AudioPlayer has four basic methods for dealing with an ambiguously defined type. SoundByte is a sequence of octet. This means that it will be a byte stream of unknown length and, because it is an octet, it will not be marshaled. The getSoundStream() will return an AudioStreamIterator object that will have the SoundByte loaded into it. Since sound files can be exceptionally large, this is a way for us to get portions of the sequence and hopefully keep our RMI (Remote Method Invocation) from getting bogged down. The play() method will take the AudioStreamIterator as an "in" parameter. fastForward() will allow you to move more quickly through the stream and rewind() will push you back in the stream. That's our interface. The component keyword is one of the additions to CIDL. It allows IDL designers to include in its body any attribute declarations - 87 -

CORBA Component Model (CCM)
Modèle de composants côté serveur, il étend le modèle Objet CORBA Proche des EJB et COM : standardisation de Services offerts au client : Évènements, Transactions, Sécurité, persistance Déploiement Interfaces multiples d’un même composant Non limité à Java ou Windows : langage indépendant Utilisation de DP largement acceptés et génération de code Ce n’est plus le developper de l’application qui integre les service mais le developpeur de container Langage indepedant une grosse part des specs des CCM est la specification des container CORBA pour abriter des EJBs. Ceci permet l’interoperabilité bi-dirctionnelle entre EJB et CCM quelque soit de langage de programmation de ces derniers Intégré à CORBA 3.0 spec - 88 -

CCM: extensions à CORBA
Modèle de composants Extensions IDLs (CIDL) , I.R. et ORB Modèle de containeur Component Implementation Framework (CIF) Modèle de « packaging » et déploiement Support aux EJBs et interworking - 89 -

En cours, … MDA Over the past decade or more, companies have endured a succession of middleware platforms. Jon Siegel, OMG Director of Technology Transfer Today OMG has ten Domain Task Forces with several more “in the chute;” more are added from time to time. Rather than show them all in a static diagram, we’ve only included a representative sample in Figure 1 where they appear as rays emanating from the center. The Domain Task Forces (DTFs) produce standard frameworks for standard functions in their application space. For example, a Finance DTF standard for an accounts receivable facility might include a platform-independent UML model, a CORBA-specific UML model, IDL interfaces, a Java-specific UML model, and Java interfaces. XML DTDs or schema generated via XMI-based mapping rules could be included as well. All of these artifacts would be normative. Such a standard would have broad impact, in that the platform-independent model would be useful even in middleware environments other than those targeted by the platform-specific parts of the specification. Since accounts receivable is an Enterprise Computing application, the normative, platform-specific artifacts would be derived at least partially via standard mappings of the Enterprise Computing core model to the platforms. I think the requirements for business software will continue to evolve faster than the technology solutions and that business developers will continue to have "programming" jobs for the rest of my career. Carol Burt, 2AB, Inc., and OMG Architecture Board Member - 90 -

Références Client/Server Programming with Java and CORBA - R. Orfali, D. Harkey John Wiley Sons 1997. CORBA, ActiveX et Java Beans - J. M. Chauvet Eyrolles 1997. Architecture J2EE, Khin Chhoung LAO, Cnam. Éléments fondamentaux des systèmes distribués, Karim Khelifi Distributed Computing and Client-Server Systems, Prentice Hall - Amjad Umar . Client/Server Computing - Byte Special Report, avril 95. Systèmes d ’exploitation - Systèmes centralisés - Systèmes distribués, Prentice Hall - Andrew Tanenbaum, 1994 Enterprise JavaBeans Specifications JavaSoft ( CORBA Specifications: Object Management Group ( - 91 -

Références Composants CORBA : CORBA Junction: IDL for CORBA 3.0, Extending the relationship between interfaces, Client-Serveur, Etude de cas: CORBA – OMG Portable Object Adapter; C. Toinard, ENSERB-3 ième année Informatique Intégration des Systèmes Clients/Serveurs, André Freyssinet, Cours Technologie Internet: Modèles de programmation Jarle HULAAS rs/TechInternet.html Model Driven Architecture by Richard Soley and the OMG Staff Strategy Group Object Management Group, White Paper Draft 3.2 – November 27, 2000 - 92 -

CORBA Common Object Request Broker Architecture

Présentations similaires

Présentation au sujet: "CORBA Common Object Request Broker Architecture"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

CORBA Common Object Request Broker Architecture

Présentations similaires

Présentation au sujet: "CORBA Common Object Request Broker Architecture"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back