Les services communs Les composantes du bus CORBA : suite Les services communs Les composantes du bus - 1 -

Services communs CORBA - 2 -

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

Le contrat IDL du service Nommage module CosNaming { typedef string Istring; struct NameComponent {. string id; string kind; }; typedef sequence<NameComponent> Name; // Un chemin d’accès = une suite de noms. 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 { }; void bind(in Name n, in Object obj) // Associer un nom à une référence. raises(NotFound, CannotProceed, InvalidName, AlreadyBound); Object resolve (in Name n) raises(NotFound, CannotProceed, InvalidName); // Autres opérations : // rebind bind_context rebind_context unbind }; Le contrat IDL du service Nommage III. Corba Services Le contrat IDL du service Nommage // new_context bind_new_context // destroy list - 4 -

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 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. // 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); - 5 -

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

Obtenir le service de Nommage en Java import org.omg.CosNaming.*; ... //retrouver la référence de l ’objet notoire « NameService » org.omg.CORBA.Object objRef = null; try { objRef = orb.resolve_initial_references ("NameService"); } catch( org.omg.CORBA.ORBPackage.InvalidName e ) { outils.ARRET ("Le service initial NameService est inconnu"); } //la convertir en une référence à un objet //de type CosNaming::NamingContext NamingContext nsRef = NamingContextHelper.narrow(objRef); if ( nsRef == null ) { outils.ARRET ("Le service initial 'NameService' n'est pas un objet CosNaming::NamingContext"); SERVICES INTIAUX : NameService PropertyService EventService - 7 -

Notion de chemin d’accès - 8 -

Créer un nom/chemin en Java import org.omg.CosNaming.*; //créer un chemin simple NameComponent[] nsNom = new NameComponent [1]; nsNom[0] = new NameComponent(  "grilleA ", ""); //créer un chemin composé NameComponent[] nsNom = new NameComponent [2]; nsNom[0] = new NameComponent( "appli", ""); nsNom[1] = new NameComponent(    "grille ", ""); - 9 -

Enregistrer un objet Opération pour publier un Objet en général, opération réalisée par le serveur Scénario Type 1. Créer un objet 2. Construire un chemin d ’accès (Name) 3. Appeler l ’opération « bind » ou « rebind » avec le chemin et la référence de l ’objet void bind (in Name n, in Object obj) raises (NotFound, CannotProceed, InvalidName, AlreadyBound); - 10 -

Enregistrer un objet en Java //créer un chemin NameComponent[] nsNom = new NameComponent [1]; nsNom[0] = new NameComponent("MONOBJET",""); //enregistrer l ’objet try { nsRef.bind (nsNom, uneRefObjet); } catch (org.omg.CosNaming.NamingContextPackage.NotFound enf) { . . . } catch(org.omg.CosNaming.NamingContextPackage.AlreadyBound eab){ } catch(org.omg.CosNaming.NamingContextPackage.CannotProceed ecp){ } catch(org.omg.CosNaming.NamingContextPackage.InvalidName ein) { - 11 -

Retrouver un objet Opération réalisée par un client ou un serveur Scénario type : construire un chemin d’accès (Name) appeler l’opération « resolve » avec le chemin convertir la référence obtenue dans le bon type Object resolve (in Name n) raises (NotFound, CannotProceed, InvalidName) - 12 -

Retrouver un objet en Java //créer un chemin NameComponent[] nsNom = new NameComponent [1]; nsNom[0] = new NameComponent("MONOBJET",""); //retrouver l ’objet org.omg.CORBA.Object objRef = null; try { objRef = nsRef.resolve (nsNom); } catch (org.omg.CosNaming.NamingContextPackage.NotFound enf) { . . . } catch(org.omg.CosNaming.NamingContextPackage.CannotProceed ecp){ } catch (org.omg.CosNaming.NamingContextPackage.InvalidName ein) { } //convertir la référence Grille uneRefObjet = GrilleHelper.narrow (objRef); - 13 -

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

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

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

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

Un canal d’évènements : demande III. Corba Services Un canal d’évènements : demande Consommateur Producteur Pull() Consommateur Producteur Canal 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(); }; 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 Producteur réactif / Consommateur actif Le canal procure les évènements - 18 -

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

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

Le service de Transaction III. Corba Services Le service de Transaction Le service de Transaction 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). - 21 -

Composantes du bus - 22 -

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 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 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ère transparente. A chaque IDL est associé une interface d ’invocation statique ou souche IDL. Ces souches servent à emballer les invocations, déballer les résultats, 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ée dans un ensemble d ’objets CORBA accessible par des mécanismes d ’invocation statiques et/ou dynamiques. (IFR???) Cf. Suite transparent suivant Application cliente SSI DSI SII DII ORB OA Noyau de communication IR Référentiel des interfaces ImplR Référentiel des implantations - 23 -

Architecture générale fichier IDL Client Implémentation d’objet pré-compilateur 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. il utilise le référentiel des implantations. Differents adaptateurs ont été définis…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 SSI DSI Stub client Interface ORB DII SII Interface de l ’adaptateur Adaptateur d’Objet noyau de l ’Object Request Broker (ORB) Référentiel des interfaces Rint Référentiel des implémentations Rimp - 24 -

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 » - 25 -

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

Architecture CORBA réseau Objet Corba Application Serveur Application Cliente ORB serveur POA Référence d’objet (IOR) ORB client Requête réseau Requête POA Objet Corba Interface d’objet id Objet d’implantation Activation - 27 -

Fichiers générés Interfaces : Classes utilitaires : Gestionnaire GestionnaireOperations Classes utilitaires : GestionnaireHelper : conversion de type, insertion dans un Any, extraction, obtenir le TypeCode GestionnaireHolder : gestion du passage des paramètres en mode inout/out Stub : _GestionnaireStub envoie de requêtes invisible par le programmeur instancié automatiquement par GestionnaireHelper (narrow) Skeleton : GestionnairePOA reçoit et décode des requêtes doit être héritée par l’implantation - 28 -

Hiérarchie en Java org.omg.PortableServer.Servant <<Abstraite>> org.omg.CORBA.portableObjectImpl org.omg.PortableServer.Servant <<Interface>> GestionnaireOperations étend étend étend Implémente <<Interface>> Gestionnaire <<abstract>> GestionnairePOA étend étend _GestionnaireStub <<Interface>> Org.omg.CORBA.Object Gestionnaire_Impl Standard Généré À implémenter - 29 -

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 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. Cl_a Cl_b Cl_c stubs - 30 -

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

Extrait d’un stub public String say_hello(String _ob_a0) { … if(!this._is_local()) org.omg.CORBA.portable.OutputStream out = null; org.omg.CORBA.portable.InputStream in = null; try out = _request(“say_hello", true); out.write_string(_ob_a0); in = _invoke(out); String _ob_r = in.read_string(); return _ob_r; } Pour objetImpl public org.omg.CORBA.portable.InputStream _invoke(org.omg.CORBA.portable.OutputStream out) throws ApplicationException, RemarshalException { return _get_delegate().invoke(this, out); } - 32 -

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 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. Cl_a Cl_b Cl_c Obj Requête du bus - 33 -

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

Extrait d’un squelette (HelloServicePOA)(I) public org.omg.CORBA.portable.OutputStream invoke( String opName, org.omg.CORBA.portable.InputStream in, org.omg.CORBA.portable.ResponseHandler handler) { final String[] _ob_names ={ "getClone", "hello"}; … switch(_ob_index) case 0: // getClone return _OB_op_getClone(in, handler); case 1: // hello return _OB_op_hello(in, handler); } throw new org.omg.CORBA.BAD_OPERATION(); - 35 -

Extrait d’un squelette (HelloServicePOA)(II) private org.omg.CORBA.portable.OutputStream _OB_op_getClone(org.omg.CORBA.portable.InputStream in, org.omg.CORBA.portable.ResponseHandler handler) { org.omg.CORBA.portable.OutputStream out = null; String _ob_a0 = in.read_string(); HelloService _ob_r = getClone(_ob_a0); out = handler.createReply(); HelloServiceHelper.write(out, _ob_r); return out; } - 36 -

CORBA : les composantes du bus - Invocations Dynamiques- Adaptateur d’objet Interface du bus Interface de Squelettes Statiques Interface d’Invocation Statique Interface de Squelettes Dynamiques Interface d’Invocation Dynamique Application serveur 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 Application cliente SSI DSI SII DII ORB OA Noyau de communication IR Référentiel des interfaces ImplR Référentiel des implantations - 37 -

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

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 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 invoke send-deferred send_oneWay wait get_response module acme_com { // IDL:acme_com:1.0 module M { // IDL:acme_com/M:1.0 // ... }; - 39 -

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

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 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. lookup_name, describe, ….. create_request, ….. - 41 -

Interface de squelette dynamique 4. Corba Composants Interface de squelette dynamique Analogue au DII mais du côté serveur. 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. 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) - 42 -

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 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 Application cliente SSI DSI SII DII ORB OA Noyau de communication IR Référentiel des interfaces ImplR Référentiel des implantations - 43 -

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

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

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

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

Portable Object Adapter III. Corba Adaptateur 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) Faire un dessin au tableau 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. Requetes traites immédiatement, mise en queues, rejette avec transient (a renvoyer plus tard) inactive requetes rejetees) • 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.) POlicies : Les policies déterminent les caractéristiques de l’implémentation des références des objets créés par le POA Elles sont aussi utilisées pour la qualité 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. 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. - 48 -

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 Requetes traites immédiatement, mise en queues, rejette avec transient (a renvoyer plus tard) inactive requetes rejetees) Les policies déterminent les caractéristiques de l’implémentation des références des objets créés par le POA Destruction d’objet Elles sont aussi utilisées pour la qualité 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 - 49 -

POA Un POA gère les relations entre III. Corba Adaptateur POA « Pont entre les requêtes arrivant 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 - 50 -

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 Il peut y avoir plusieurs POA dans un manager 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 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. - 51 -

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

• 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 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. • 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. * 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 policies supported include all of the default policy values from CORBA. The minimumCORBA RootPOA is a subset of the CORBA RootPOA. The only policy in which it differs is more restrictive than its CORBA RootPOA counterpart. Hence an application built on the minimumCORBA RootPOA will run on the CORBA RootPOA. 23.9.2.1 ThreadPolicy The only minimumCORBA ThreadPolicy is ORB_CTRL_MODEL. The SINGLE_THREAD_MODEL policy is omitted because it is not required for basic ORB operation. 23-8 Common Object Request Broker Architecture (CORBA), v2.6 December 2001 23 23.9.2.2 LifespanPolicy MinimumCORBA supports both values of LifespanPolicy - TRANSIENT and PERSISTENT. The PERSISTENT policy is retained because it allows the creation of ‘well known’ object references, which allow a service to still be contacted using the same reference after it has been reinitialized. This is useful in a constrained resource environment, as it allows applications to dispense with code to reobtain references for servers. Note that minimumCORBA takes the PERSISTENT policy to imply nothing more than the converse of the TRANSIENT policy. That is, using the PERSISTENT policy, object references generated using one instantiation of a POA may be successfully used after the POA is deactivated and reinstantiated in another process. No further action to restore the state of the POA or the objects managed by it is assumed. As minimumCORBA does not support Adapter Activators or Servant Managers, minimumCORBA applications implementing a POA with the PERSISTENT policy are responsible for recreating the POA and reactivating the relevant objects before these objects can be successfully invoked upon from clients still holding references to them from previous instantiations of the POA. 23.9.2.3 ObjectIdUniquenessPolicy MinimumCORBA supports both values of ObjectIdUniquenessPolicy - 1) UNIQUE_ID, and 2) MULTIPLE_ID. The cost of the latter is negligible and it offers the ability to save resources by multiplexing multiple objects onto one servant. 23.9.2.4 IdAssignmentPolicy MinimumCORBA supports both values of IdAssignmentPolicy - 1) SYSTEM_ID, and 2) USER_ID. The cost of having both is negligible and is useful in a constrained resource environment, as it allows the reuse in ObjectIds of values that have a meaning in another context within an application. 23.9.2.5 ServantRetentionPolicy MinimumCORBA only supports the RETAIN ServantRetentionPolicy. The NON_RETAIN policy is omitted in accordance with the design policy of removing dynamic behaviors that are unnecessary to basic operation. The dynamic model it supports has non-negligible cost and implications for system predictability. 23.9.2.6 RequestProcessingPolicy MinimumCORBA only supports the USE_ACTIVE_OBJECT_MAP_ONLY RequestProcessingPolicy. The USE_DEFAULT_SERVANT and USE_SERVANT_MANAGER policies are omitted for the same reasons as the NON_RETAIN option. December 2001 CORBA, v2.6: Interoperability 23-9 23.9.2.7 ImplicitActivationPolicy MinimumCORBA supports only the NO_IMPLICIT_ACTIVATION policy. IMPLICIT_ACTIVATION is omitted as it is not required for basic ORB operation, and the dynamic programming model it supports has non-negligible cost. For this policy, minimumCORBA is aligned with the default policy value in CORBA. The CORBA RootPOA has an ImplicitActivationPolicy of IMPLICIT_ACTIVATION. However, the minimumCORBA RootPOA is still a subset of the CORBA RootPOA because the IMPLICIT_ACTIVATION setting does not prohibit explicit activation and the NO_IMPLICIT_ACTIVATION setting permits only explicit activation. That is, the one permitted activation mode in minimumCORBA is one of the two permitted activation modes of CORBA. 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). - 53 -

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 • LifespanPolicy : The life span 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 become 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. 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. • 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. POA Policies - 54 -

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

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 12.24.) 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: - 56 -

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 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.) Thermometers Thermostats - 57 -

III. Corba Interopérabilité 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. - 58 -

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

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 cf. p. 33 à 40 ?? A1 IDL Binding An IDL Binding B1 IDL Binding Bn IDL Binding ... ... ORB 1.2 vendeur x ORB 1.2 vendeur y Environnement X Environnement Y - 60 -

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

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). SOAP et IIOP = même objectif - 62 -

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: …. IOR/URL For a server to correctly dispatch incoming requests to the correct servant, and for a client to correctly connect to the a server, an object reference must contain a minimum amount of information. In particular, it must contain an address (such as a host–port pair) that the client can use to contact the server, and it must contain information that, once a request is passed to the server, identifies the particular target object for an invocation. As shown above, an object reference contains exactly that. The transport information, which (at least for IIOP) is standardized, enables the client to connect to the correct server. When a client sends an invocation to a particular server, it sends the object key with the request. The object key,internally, contains both a POA name and an object ID. The POA name enables the receiving ORB to identify the correct POA to pass the request to. In turn, the POA uses the object ID part of the object key to identify the specific servant that must handle the request. Note that the object key is in a proprietary format, specific to each ORB vendor, and is never looked at except by the server that created it. Other clients and servers in a CORBA system treat the object key as an opaque blob of data. Adresse de transport est standardisée poir IIOP La clef contient le nom du POA et l’ID de l’object. Le nom du POA permet à l’ORB d’identifier le POA qui a son tour identifie le servant qui doit répondre à la requête. La clef est un format propriétaire specifique à chaque vendeur de l’ORB All of the strategies described in this chapter involve the publication of an object reference in some form. A common source of problems for newcomers to CORBA is the lifetime and validity of object references. Using IIOP, an object reference can be thought of as encapsulating several pieces of information: •hostname •port n umber • object key If any of these items were to change, any published object references containing the old information would likely become invalid and its use might result in a TRANSIENT or OBJECT_NOT_EXIST exception. The sections that follow discuss each of these compo-nents and describe the steps you can take to ensure that a published object reference remains valid. 6.2.1 Hostname By default, the hostname in an object reference is the canonical hostname of the host on which the server is running. Therefore, running the server on a new host invalidates any previously published object references for the old host. ORBACUS provides the -OAhost option to allow you to override the hostname in any object references published by the server. This option can be especially helpful when used in conjunction with the Domain Name System (DNS), in which the -OAhost option spec-ifies a hostname alias that is mapped by DNS to the canonical hostname. See “Command-line Options” on page 58 for more information on the -OAhost option. 6.2.2 Port Number Each time a server is executed, the Root POA manager selects a new port number on which to listen for incoming requests. Since the port number is included in published object references, subsequent executions of the server could invalidate existing object ref-erences. To overcome this problem, ORBACUS provides the -OAport option that causes the Root POA manager to use the specified port number. You will need to select an unused port number on your host, and use that port number every time the server is started. Object Key Each object created by a server is assigned a unique key that is included in object refer-ences published for the object. Furthermore, the order in which your server creates its objects may affect the keys assigned to those objects. To ensure that your objects always have the same keys, activate your objects using POAs with the PERSISTENT life span policy and the USER_ID object identification policy. - 63 -

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) (RMI-IIOP) (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::www.omg.org/NameService would resolve to the CORBA Naming Service running on the machine whose IP address corresponded to the domain name www.omg.org (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 13.6.10, and configuration of initial service references are section 4.5.3. 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 2001. 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.   - 64 -

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… - 65 -

COTS, Tests, Fichier d’assemblage, ADL, … 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 COTS, Tests, Fichier d’assemblage, ADL, … - 66 -

CORBA Component Model (CCM) Modèle de composants côté serveur, il étend le modèle Objet CORBA Extensions IDLs (CIDL) , I.R. et ORB Modèles : Services offerts, requis, puits, sources Interfaces multiples d’un même composant Modèle de containeur Proche des EJB et COM Services offerts au client : Évènements, Transactions, Sécurité, persistance Modèle de « packaging » et déploiement 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 - 67 -

En cours, … MDA 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. Over the past decade or more, companies have endured a succession of middleware platforms. Jon Siegel, OMG Director of Technology Transfer 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 - 68 -

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 (http://www.javasoft.com/ejb) CORBA Specifications: Object Management Group (http://www.omg.org) http://www.ooc.com/ob/training_download.html - 69 -

Références Composants CORBA : http://umeet.uninet.edu/conferencias/acsdsevilla/ccm CORBA Junction: IDL for CORBA 3.0, Extending the relationship between interfaces, http://www-106.ibm.com/developerworks/components/ 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, HTTP://dyade.inrialpes.fr/~freyssin Cours Technologie Internet: Modèles de programmation Jarle HULAAS http://cui.unige.ch/tios/co 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 - 70 -