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

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

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

Object reference semantics

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

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

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

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

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

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

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

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 »

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.

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

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)

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

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

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

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

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

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

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

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

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