CORBA III Corba Common Object Request Broker Architecture
CORBA III. Corba Common Object Request Broker Architecture permettant de développer des applications distribuées : Ø standardisées Ødans des environnements hétérogènes indépendants des langages de programmation et des systèmes d’exploitation; Øbasées sur la technologie objet. © ² 2004, Mireille Fornarino, E. S. S. I.
ORB (1/2) I. 5. OMA 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. © ² 2004, Mireille Fornarino, E. S. S. I.
ORB (2/2) I. 5. OMA ORB 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 © ² 2004, Mireille Fornarino, E. S. S. I. -3 -
“Proxies Make Remote Objects Look Local” I. 5. OMA ORB • 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 Server Process Client Process implementation proxy CORBA Software Bus © ² 2004, Mireille Fornarino, E. S. S. I. -4 -
Transparence de localisation des objets I. 5. OMA ORB 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 Process A Machine 2 Process B Direct Call Inter-Process Call Network Call (IIOP) © ² 2004, Mireille Fornarino, E. S. S. I. -6 -
I. 5. OMA ORB Bus Corba : fonctions. . . Client Return serveur Référence -> faire(param 1, param 2, . . . ) Return faire(param 1, param 2, . . . ) Unmarshaling Marshaling ORB Unmarshaling Marshaling 010010010110110101111 réseau © ² 2004, Mireille Fornarino, E. S. S. I. 10010110110
ORB : Liaison avec « tous » les langages de programmation C++ Java Smalltalk Ada Souche Bus Corba © ² 2004, Mireille Fornarino, E. S. S. I. 5. OMA ORB
Services objet communs I. 5. OMA Services Les Services Objet (CORBA Services) : Fonctionnalités système de bas niveau communes à la majorité des applications distribuées. ü objectif : étendre les fonctions de l ’ORB ü interfaces indépendantes domaines d’application; ü spécification par des interfaces IDL; ü leurs fonctionnalités peuvent être étendues ou spécialisées par héritage; © ² 2004, Mireille Fornarino, E. S. S. I.
Services CORBA • Naming – How are objects found? • Events – Standardized mechanism for client notifications. • Life. Cycle – How are objects created, moved, duplicated and deleted? • Trader – Find objects that have certain properties • Transactions – Distributed 2 -phase commit • Security – Complete distributed security © ² 2004, Mireille Fornarino, E. S. S. I. 5. OMA Services • Persistent Object – Save objects to databases • Concurrency – Managing simultaneous access • Licensing – Managing licensed services • Externalization – External representation of objects • Relationship – Manage relationships between objects that don't know about each other • Query – Query objects on the network - 10 -
Utilitaires communs I. 5. OMA Services Les utilitaires communs (CORBA Facilities) (aussi dits canevas horizontaux): ensemble de services orientés utilisateur de plus haut niveau fournissant des fonctionnalités utiles dans de nombreuses applications; ü spécification par des interfaces IDL; ü leurs fonctionnalités peuvent être étendues ou spécialisées par héritage; üindépendants des domaines d’application; üExemples : interface utilisateur, gestion de l ’information, administration du système et gestion de la tâche. © ² 2004, Mireille Fornarino, E. S. S. I.
Utilitaires communs : L ’interface Utilisateur I. 5. OMA Services Collection de composants pour standardiser l ’utilisation des IHM sophistiquées. Øgestion du rendu : affichage des fenêtres et des éléments graphiques de dialogue avec l ’utilisateur final. Ø Gestion des documents composites : Coopération visuelle d’applications distinctes (OPen. Doc). Øsupport de l ’utilisateur : aide en ligne, vérificateur de texte, tableur, …. Øgestion du bureau Øscripts © ² 2004, Mireille Fornarino, E. S. S. I.
Interfaces domaines I. 5. OMA Services Les interfaces ou objets des domaines (CORBA Domains) (aussi dits canevas verticaux, objets métiers): spécifiques à un domaine d’application (médical, financier, télécommunications, commerce électronique, . . . ); ü spécification d’interfaces IDL; ü standardisées par l’OMG; ü leurs fonctionnalités peuvent être étendues ou spécialisées par héritage; © ² 2004, Mireille Fornarino, E. S. S. I.
Objets applicatifs Les Objets applicatifs (CORBA Applications) : ü spécification par des interfaces IDL; ü définis par une application de l’utilisateur; ü hors du champ de standardisation de l’OMG; ü possibilité de standardisation pour des objets émergents. © ² 2004, Mireille Fornarino, E. S. S. I. 5. OMA Services
Vers une industrie du composant logiciel Objets applicatifs (0 A) OA SO UC Interfaces de domaine (ID) Utilitaires communs (UC) ID ID I. 5. OMA Services SO UC UC SO Bus d’objets répartis (O. R. B. ) Services objet communs (SO) © ² 2004, Mireille Fornarino, E. S. S. I.
CORBA : les composantes du bus Adaptateur d’objet Interface du bus Interface d’Invocation Statique Interface de Squelettes Statiques Interface de Squelettes Dynamiques Interface d’Invocation Dynamique SSI SII DSI DII ORB OA Noyau de communication IR © ² 2004, Mireille Fornarino, E. S. S. I. Référentiel des interfaces Impl. R Référentiel des implantations
Architecture générale fichier IDL Client Implémentation d’objet pré-compilateur SSI DII Stub client DSI Interface ORB Adaptateur d’Objet Interface de l ’adaptateur noyau de l ’Object Request Broker (ORB) Référentiel des interfaces Rint © ² 2004, Mireille Fornarino, E. S. S. I. Référentiel des implémentations Rimp
OMG-IDL : compilation • Projection descriptions OMG-IDL vers les langages d’implantation des clients et serveurs. – mode « statique » • Instanciation sous forme d’objets CORBA descriptions OMG-IDL dans un référentiel des interfaces commun. – mode « dynamique » © ² 2004, Mireille Fornarino, E. S. S. I. - 20 -
CORBA : le mode statique III. Corba mode statique • Les clients et serveurs implantent descriptions OMG-IDL communes, statiquement précisées dans la phase de compilation/projection du source IDL. Client d ’objets Stub IDL Contrat IDL Bus CORBA Fournisseur d ’objets 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. © ² 2004, Mireille Fornarino, E. S. S. I. - 21 -
III. Corba mode statique La projection client Fichier OMG-IDL Référence d’objet Requête Compilation vers client ex : IDL/C++ © ² 2004, Mireille Fornarino, E. S. S. I. stubs Cl_a Cl_b Cl_c vers le bus - 22 -
III. Corba mode statique La projection serveur Fichier OMG-IDL squelettes Compilation vers serveur ex : IDL/Java Obj Impl_a Cl_a Impl_b Impl_c Cl_b Cl_c Requête du bus © ² 2004, Mireille Fornarino, E. S. S. I. - 24 -
Invocation statique Client Implémentation d’objet requête Stub client réponse squelette statique squelette dynamique Adaptateur d’Objet ORB noyau © ² 2004, Mireille Fornarino, E. S. S. I. III. Corba mode statique
Exemple ORBACUS © ² 2004, Mireille Fornarino, E. S. S. I. - 27 -
CORBA : le mode dynamique III. Corba 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. © ² 2004, Mireille Fornarino, E. S. S. I.
Interface d'invocation dynamique (1) III. Corba mode dynamique Permet la création dynamique de requêtes API (DII) sans passer par des souches pré-générées; Un objet Request = un nom d’opération, une liste de couples valeur - type (au sens de l’IR) et une structure pour le résultat invoke send_deferred + get_response, poll_response send_oneway invoke wait © ² 2004, Mireille Fornarino, E. S. S. I. send-deferred send_one. Way get_response
III. Corba Interface d'invocation dynamique (2) mode dynamique Ø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; . © ² 2004, Mireille Fornarino, E. S. S. I.
III. Corba invocation dynamique (3) mode dynamique ü Etapes 1. trouver la référence d ’un objet (string_to_object) 2. recherche et interprétation de son interface dans le référentiel des interfaces; get_interface -> CORBA: : Interface. Def 3. obtenir la description de l ’opération à invoquer lookup_name, describe, …. . 4. construction d'un objet requête; construire la liste des arguments à transmettre create_request, …. . 5. invocation de la requête 6. traiter les résultats retournés. © ² 2004, Mireille Fornarino, E. S. S. I.
Interface de squelette dynamique 4. Corba Composants • 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. © ² 2004, Mireille Fornarino, E. S. S. I.
Composants du bus © ² 2004, Mireille Fornarino, E. S. S. I. - 33 -
Référentiel d’interfaces III. Corba Référentiels Maintient les informations sur les types, les interfaces etc. . . ; Un graphe d ’objets « concepts » d ’IDL : Module. Def, Interface. Def, OPeration. Def, . . 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 © ² 2004, Mireille Fornarino, E. S. S. I.
Référentiel d’implémentations III. Corba Référentiels . Responsable de l’enregistrement des serveurs dans le système (enregistrement de la commande exécutable). . Spécifié par une interface IDL. (( Avec Orbix • Controlé par la commande putit dans les commandes associées lsit, catit, rmit, chmodit. • Implémenté par un processus démon. )) © ² 2004, Mireille Fornarino, E. S. S. I.
Interfaces de base du Bus Object III. Corba 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(); ……………………. . . © ² 2004, Mireille Fornarino, E. S. S. I.
III. Corba Object Adapter : fonctions Adaptateur 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é Servant Proxy © ² 2004, Mireille Fornarino, E. S. S. I. POA
Interfaces : Portable Object Adapter III. Corba Adaptateur Interfaces IDL définies dans le module Portable. Server : • 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 • Adapter. Activator (Factory d’adaptateurs) © ² 2004, Mireille Fornarino, E. S. S. I. - 38 -
POA III. Corba Adaptateur « 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 Root. POA a un ensemble fixé de Policies, il est toujours présent. Un servant est associé à un unique POA. © ² 2004, Mireille Fornarino, E. S. S. I. - 39 -
Architecture du POA et terminologie Active Object Map: table des objet actifs via leur ID Adapter activator: objet qui peut créer un POA sur demande Object ID: identification de l'objet au sein de l'adaptateur (unique au sein d'un même adaptateur) POA manager: objet qui contrôle l'état du POA Policy: objet qui contrôle le comportement d'un POA et de ses objets root. POA: 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 © ² 2004, Mireille Fornarino, E. S. S. I. - 40 -
III. Corba POA manager Adaptateur • Associé à un POA lors de la création de ce dernier (il ne peut pas être changé) Application serveur dispatch Requête ORB POA Manager Servants POA 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. © ² 2004, Mireille Fornarino, E. S. S. I. - 41 -
POA Policies III. Corba Adaptateur 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. • Lifespan. Policy (références transitoires ou persistantes) • Id. Assignment. Policy (gestion de la clef) • Id. Uniqueness. Policy (association servant et objets d’implémentation) • Implicit. Activation. Policy (activation automatique ou non des servants) • Request. Processing. Policy (gestion ID-to-servant) • Servant. Retention. Policy (gestion mémoire des servants) • Thread. Policy © ² 2004, Mireille Fornarino, E. S. S. I. - 43 -
Root POA Policies III. Corba Life Span Policy TRANSIENT ( PERSISTANT) ID Assignment Policy SYSTEM_ID ( USER_ID) ID Uniqueness Policy UNIQUE_ID ( MULTIPLE_ID) Servant Retention Policy RETAIN ( PERSISTANT) Adaptateur Request Processing Policy USE_ACTIVE_OBJECT_MAP_ONLY ( USE_SERVANT_MANAGER ) Implicit Activation Policy IMPLICIT_ACTIVATION Thread Policy ORB_CTRL_MODEL © ² 2004, Mireille Fornarino, E. S. S. I. - 44 -
Etapes de mise en œuvre • Définition de l ’interface IDL • Pré-compilation du fichier IDL et Projection vers des langages de programmation. • Code du serveur : Implantation des interfaces IDL Implantation du serveur • Implantation des clients • Installation et configuration des serveurs • Diffusion et configuration des clients • Exécution répartie de l’application. © ² 2004, Mireille Fornarino, E. S. S. I.
Interopérabilité III. Corba Interopérabilité Avant CORBA 2. 0, Problème d'interopérabilité entre ORBs. Interopérabilité Capacité pour un ORB A d'invoquer une opération définie en IDL sur un objet résidant sur un ORB B. L'ORB A et B étant des implémentations de CORBA différentes. © ² 2004, Mireille Fornarino, E. S. S. I.
Interopérabilité d’applications avec CORBA III. 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 Communication A 1 . . . An Environnement X © ² 2004, Mireille Fornarino, E. S. S. I. Problème 2 Interopérabilité Communication B 1 . . . Bn Environnement Y
Portabilité d’applications avec CORBA 1. 2 III. Corba Interopérabilité 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 Communication IDL A 1 IDL . . . Binding ? ? Communication IDL An B 1 Binding ORB 1. 2 vendeur x Environnement X © ² 2004, Mireille Fornarino, E. S. S. I. Problème 2 IDL . . . Bn Binding ORB 1. 2 vendeur y Environnement Y
Portabilité d’applications avec CORBA 1. 2 III. Corba Interopérabilité CORBA 1. 2 permet de : • simplifier le portage d’applications entre environnements hétérogènes grâce au langage IDL, aux standardisations des bindings. IDL A 1 Binding . . . IDL An B 1 Binding IDL . . . Bn Binding ORB 1. 2 vendeur y Environnement Y © ² 2004, Mireille Fornarino, E. S. S. I.
Interopérabilité d’application avec CORBA 2. 0 III. Corba Interopérabilité 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). IDL A 1 IDL . . . Binding An Binding ORB 2. 0 vendeur x Environnement X © ² 2004, Mireille Fornarino, E. S. S. I. Problème 2 résolu Interopérabilité GIOP IDL B 1 Binding IDL . . . Bn Binding ORB 2. 0 vendeur y Environnement Y
GIOP et IIOP III. Corba Interopérabilité + 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. © ² 2004, Mireille Fornarino, E. S. S. I.
IOR III. Corba + IOR (Interoperable Object Reference) u interface OMG IDL : repository ID uadresse + port IP uclé de format libre (identifie le POA et l’objet dans le POA) Spécifique à l’ORB upossède une forme externe diffusable chaîne IOR : IOR: …. © ² 2004, Mireille Fornarino, E. S. S. I. - 55 -
Services communs CORBA © ² 2004, Mireille Fornarino, E. S. S. I. - 56 -
Les services communs CORBA III. Corba Services z 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 z Services concernant la vie des objets : Life Cycle, Property, Relationship, Externalization, Persistent Object, Query, Collection, Versionning, Time, Licencing z. Services de sûreté de fonctionnement : Security, Transactions, Concurrence z Services de communications asynchrones: Events, Notification, Messaging © ² 2004, Mireille Fornarino, E. S. S. I.
Les services de recherche d’objets CORBA Client Java Traitement Services Serveur C++ Service de recherche d’objets IOR III. Corba Repertoire IOR Bus d’objets répartis CORBA sur Internet (IIOP) Services Nommage et/ou Vendeur © ² 2004, Mireille Fornarino, E. S. S. I. - 59 -
Le service de Nommage III. Corba Services Le service de Nommage ou Namming service permet : * d’associer un nom à une référence d’objet CORBA, relativement à un contexte de noms; * de retrouver la référence d’objet ainsi que l’objet associé; * de naviguer à l'intérieur d’un contexte de noms. Opérations principales ajouter une association : bind, rebind, . . . résoudre une association : resolve détruire une association : unbind lister le contenu : list détruire le contexte : destroy © ² 2004, Mireille Fornarino, E. S. S. I.
Le contrat IDL du service Nommage III. Corba Services module Cos. Naming // Le service Nommage. { typedef string Istring; struct Name. Component { // Un nom d’association. string id; string kind; }; // Un chemin d’accès = une suite de noms. typedef sequence<Name. Component> Name; interface Naming. Context { // Un contexte. enum Not. Found. Reason { missing_node, not_context, not_object }; exception Not. Found {Not. Found. Reason why; Name rest_of_name; }; exception Cannot. Proceed {Naming. Context cxt; Name rest_of_name; }; exception Invalid. Name { }; exception Already. Bound { }; exception Not. Empty { }; // Associer un nom à une référence. void bind(in Name n, in Object obj) raises(Not. Found, Cannot. Proceed, Invalid. Name, Already. Bound); // Recher une association. Object resolve (in Name n) raises(Not. Found, Cannot. Proceed, Invalid. Name); // Autres opérations : // rebind_context rebind_context unbind // new_context bind_new_context // destroy list }; }; © ² 2004, Mireille Fornarino, E. S. S. I. - 61 -
Comment retrouver la référence du service de nommage ? III. Corba Services C’est un « objet notoire » du bus CORBA de nom Name. Service Quelque soit le langage, le scénario est a. opération CORBA: : ORB: : resolve_initial_references b. conversion en Cos. Naming: : Naming. Context // En C++, obtenir la référence du service Nommage. CORBA_Object_var context. Obj = orb->resolve_initial_references ("Name. Service"); Cos. Naming: : Naming. Context_var context = Cos. Naming: : Naming. Context: : _narrow(context. Obj); © ² 2004, Mireille Fornarino, E. S. S. I. - 62 -
Utilisations du service Nommage III. Corba Services 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 Cos. Naming: : Name_var ns. Nom = new Cos. Naming_Name(); ns. Nom->length(1); ns. Nom[0]. id = (const char*) "BNP"; //nom du serveur ns. Nom[0]. kind = (const char*) "BANKSERVER"; context->bind (ns. Nom, bnp. Serveur); Recher une référence (2) création d’un chemin valide (3) opération resolve (4) conversion vers le type nécessaire CORBA: : Object_var obj. Ref = context->resolve (ns. Nom); bank. Server_var bnp = bank. Server: : _narrow (obj. Ref); © ² 2004, Mireille Fornarino, E. S. S. I. - 63 -
Le service Vendeur III. Corba Services Le service vendeur ou Trader service permet : * d ’enregistrer des objets auprès de ce service en les caractérisant par un ensemble de propriétés. * de retrouver un service en précisant son type et les critères le caractérisant (différentes politiques de recherche possibles) Opérations principales découvrir et importer des services : Interface Look. Up : query (type de service recherché, contraintes, préférences, politique de recherche, …. ) parcourir les réponses : Interface Offer. Iterator mise à jour du service Vendeur : Interface Register export, withdraw …. . . © ² 2004, Mireille Fornarino, E. S. S. I.
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. © ² 2004, Mireille Fornarino, E. S. S. I.
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 © ² 2004, Mireille Fornarino, E. S. S. I. - 66 -
Un canal d’évènements : notification III. Corba Services Push. Consumer Consommateur Push. Supplier Push Producteur void push(in any data) raises(Disconnected); Consommateur Producteur Push Canal Consommateur Producteur actif / Consommateur réactif Le canal diffuse les évènements © ² 2004, Mireille Fornarino, E. S. S. I. - 68 -
Un canal d’évènements : demande III. Corba Services Consommateur Pull() Producteur Consommateur Producteur Pull() Canal Consommateur Pull. Supplier { //demande de production d’un événement demande any pull() raises(Disconnected); Consommateur // présence d’un événement any try_pull(out boolean has_event) raises(Disconnected); Producteur réactif / Consommateur actif Le canal procure les évènements © ² 2004, Mireille Fornarino, E. S. S. I. - 69 -
Un canal d’évènements : file d’évènements III. Corba Services Consommateur Pull() Producteur Consommateur Producteur Push() Canal Consommateur Producteur actif / Consommateur actif Le canal gère des files d’évènements © ² 2004, Mireille Fornarino, E. S. S. I. - 70 -
Un canal d’évènements : collecte d’évènements III. Corba Services Consommateur Push() Producteur Consommateur Producteur Pull() Canal Consommateur Producteur réactif / Consommateur réactif Le canal est une entité active voire intelligente © ² 2004, Mireille Fornarino, E. S. S. I. - 71 -
Le service de Transaction III. Corba Services Le service de Transaction ou Transaction service permet d’assurer la consistance des traitements en respectant les propriétés ACID (Atomicité, Consistance, Isolation et durabilité) des transactions. Il permet : § de commencer et de terminer une transaction; § de contrôler la propagation d’une transaction; § d’associer plusieurs objets répartis à une seule et même transaction; § de coordonner la terminaison d’une transaction (2 phase commit). © ² 2004, Mireille Fornarino, E. S. S. I.
Le service de Concurrence III. Corba Services Le service de Concurrence ou Concurrency control service permet de contrôler l’accès à un objet de manière à gérer la cohérence et la consistance des opérations entre cet objet et les objets qu’il accède ou bien qui l’accèdent. Il permet de créer des verrous répartis et de spécifier le type de verrou crée (lecture, écriture, mise-à-jour etc. . . ). © ² 2004, Mireille Fornarino, E. S. S. I.
Le service d’Externalisation III. Corba Services Le service d’Externalisation ou Externalization service permet : § l’externalisation d’un objet, c’est à dire la représentation de l’état de l’objet dans une séquence d’octets (en mémoire, sur disque, sur réseau) transportable, de durée de vie illimitée indépendante de l’environnement (ORB) d’origine. § l’internalisation des données, impliquant la création d’un nouvel objet dans le même environnement ou dans un environnement différent. © ² 2004, Mireille Fornarino, E. S. S. I.
Le service Cycle de vie III. Corba Services Le service Cycle de vie ou Life cycle service permet : + de gérer la création, la destruction, la copie et le déplacement des objets du bus; + les objets sont créés par l’intermédiaire d’objets appelés Factories dont la référence est accessible au client; + un objet est détruit, copié ou déplacé à l’aide d’opérations définies dans l’interface de base Life. Cycle. Object; © ² 2004, Mireille Fornarino, E. S. S. I.
Sécurité et temps III. Corba Services Le service de Sécurité (Security) permet de gérer les fonctions suivantes : ü authentification ü autorisation ü sûreté et intégrité des communications ü encryptage ü administration de la sécurité Le service de Temps (Time) permet la synchronisation périodique d’horloges dans tous les composants d’un système réparti. © ² 2004, Mireille Fornarino, E. S. S. I.
4ème RFP III. Corba Services Le service de Propriétés (Properties) permet d’associer dynamiquement une liste de propriétés à un objet. Il est possible d’ajouter, de supprimer, de modifier et de retrouver toute propriété associée à un objet. Le service d’interrogations (Query) permet d’exprimer des requêtes sur des ensembles d’objets CORBA. Le service de License (Licensing) contrôle et gère les rémunérations associées à l’utilisation d’un service objet donné. © ² 2004, Mireille Fornarino, E. S. S. I.
5ème RFP III. Corba Services Le service de Gestion des versions (Change Management) permet de gérer l’évolution des versions des interfaces des objets ainsi que de l'adéquation avec leurs implémentations. Le service d’Annuaire par fonctionnalités (Trader) permet d’associer des fonctionnalités à des objets CORBA. Le client utilise ce service comme l’annuaire des pages jaunes. Le service de Collection (Collection) permet de créer et de manipuler des collections d’objets. © ² 2004, Mireille Fornarino, E. S. S. I.
Taxonomie des services üNommage + Annuaire par fonctionnalités üPersistance + Externalisation üCycle de vie + Relation üServeur de requêtes + Collections + Properties üTransaction + Concurrence üSécurité + License üGestionnaire des versions üTime üEvent © ² 2004, Mireille Fornarino, E. S. S. I. III. Corba Services
CORBA 3. 0 III. Corba Une suite de spécifications • Intégration de Java et l’Internet – Passage par valeur (Corba 2. 3) – Java to IDL : Interopérabilité des objets RMI (2. 3) – (Firewall specification) Mid-2001 – Interopérabilité et service de nommage (2. 4) • Amélioration de la qualité de service – Asynchronous Messaging (2. 4 fin 2000) – Corba minimum pour les systèmes embarqués – Temps réel, • Modèle de composants, langage de script © ² 2004, Mireille Fornarino, E. S. S. I. - 82 -
Integration de Java RMI avec CORBA : RMI-IIOP • RMI est une solution tout-java – Un modèle simple de programmation – “An immature middleware infrastructure” • CORBA est un standard pour les objets distribués – Un modèle de programmation pas si simple et non dédié spécifiquement à Java – “A mature middleware infrastructure” • RMI s’exécute via IIOP – Utilisation des spécifications sur le passage par valeur de l’OMG – Java-to-IDL – Mais pas de chargement dynamique des stubs © ² 2004, Mireille Fornarino, E. S. S. I. - 83 -
RMI/CORBA via IIOP RMI client implementation d’un Objet CORBA RMI stub CORBA Squelette ORB Réseau via IIOP © ² 2004, Mireille Fornarino, E. S. S. I. - 84 -
Pourquoi CORBA? • Infrastructure largement adoptée pour la distribution d’objets • Plate-forme indépendant, il permet l’intégration de systèmes propriétaires • Langage indépendant : Clients et serveurs peuvent être implémentés dans des langages différents • CORBA est indépendant d’une compagnie (donc d’Un produit ou d’une architecture) • De nombreux services • Fournit un accès multi-langages pour les EJBs. « CORBA is the only middleware platform that is both vendor- and language-independent. » « You still need to know what you are doing and CORBA cannot do your thinking for you » . © ² 2004, Mireille Fornarino, E. S. S. I. - 85 -
CORBA … • Pas d’approche standard du déploiement – (connexion entre IMR et serveurs non standardisé) – Quels services sont disponibles sur le site de déploiement • Pas de support des idioms de développement des serveurs CORBA – Comment « bootstrapper » les références? (naming, trader, …) – Mise en place de factories gérant le cycle de vie… • Difficulté pour l’extension des fonctionnalités des objets. – Nécessité d’une construction par composition plutôt que par héritage • Pas de gestion automatique du cycle de vie des objets. – Qui gère l’activation des objets? Pas de standard IMR… © ² 2004, Mireille Fornarino, E. S. S. I. - 86 -
COMPOSANTS, besoins • Des unités interchangeables – Spécification de ce qui est offert – Spécification de ce qui est nécessaire • Déploiement standardisé semi-automatique • Génération de code pour la mise en œuvre de certains « services » (D. P. ) (Factory, persistance, sécurité, …) © ² 2004, Mireille Fornarino, E. S. S. I. - 87 -
CORBA Component Model (CCM) • Modèle de composants côté serveur, il étend le modèle Objet CORBA • Proche des EJB et COM : standardisation de – Services offerts au client : Évènements, Transactions, Sécurité, persistance – Déploiement – Interfaces multiples d’un même composant • Non limité à Java ou Windows : langage indépendant Intégré à CORBA 3. 0 spec © ² 2004, Mireille Fornarino, E. S. S. I. - 88 -
CCM: extensions à CORBA • Modèle de composants - Extensions IDLs (CIDL) , I. R. et ORB -Modèle de containeur -Component Implementation Framework (CIF) -Modèle de « packaging » et déploiement -Support aux EJBs et interworking © ² 2004, Mireille Fornarino, E. S. S. I. - 89 -
En cours, … MDA Over the past decade or more, companies have endured a succession of middleware platforms. Jon Siegel, OMG Director of Technology Transfer 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, 2 AB, Inc. , and OMG Architecture Board Member © ² 2004, Mireille Fornarino, E. S. S. I. - 90 -
Références Client/Server Programming with Java and CORBA - R. Orfali, D. Harkey John Wiley Sons 1997. CORBA, Active. X et Java Beans - J. M. Chauvet Eyrolles 1997. Architecture J 2 EE, 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 Java. Beans Specifications Java. Soft (http: //www. javasoft. com/ejb) CORBA Specifications: Object Management Group (http: //www. omg. org) http: //www. ooc. com/ob/training_download. html © ² 2004, Mireille Fornarino, E. S. S. I. - 91 -
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/Tech. Internet. html Model Driven Architecture by Richard Soley and the OMG Staff Strategy Group Object Management Group, White Paper Draft 3. 2 – November 27, 2000 © ² 2004, Mireille Fornarino, E. S. S. I. - 92 -
- Slides: 79