La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

© ²2004, Mireille Fornarino, E.S.S.I. - 1 - Common Object Request Broker Architecture Architecture permettant de développer des applications distribuées.

Présentations similaires


Présentation au sujet: "© ²2004, Mireille Fornarino, E.S.S.I. - 1 - Common Object Request Broker Architecture Architecture permettant de développer des applications distribuées."— Transcription de la présentation:

1 © ²2004, Mireille Fornarino, E.S.S.I Common Object Request Broker Architecture Architecture permettant de développer des applications distribuées : standardisées dans des environnements hétérogènes indépendants des langages de programmation et des systèmes dexploitation; basées sur la technologie objet. CORBA III. Corba

2 © ²2004, Mireille Fornarino, E.S.S.I 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 dobjets (en Français). Ensemble des logiciels nécessaires pour permettre et organiser la communication et léchange de messages entre client et serveur. I.5. OMA ORB

3 © ²2004, Mireille Fornarino, E.S.S.I ORB (2/2) Composant central du standard CORBA qui gère : +la localisation dobjet +la désignation des objets +lempaquetage des paramètres (marshalling) +le dépaquetage des paramètres (unmarshalling) +linvocation 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 I.5. OMA ORB

4 © ²2004, Mireille Fornarino, E.S.S.I Proxies Make Remote Objects Look Local Un proxy est un objet local qui représente un objet distant –Le proxy est automatiquement créé par lORB Le proxy a linterface de lobjet distant –Si lobjet distant est en C++, et le client est en Java, le proxy sera en Java CORBA Software Bus Client Process Server Process proxy implementation I.5. OMA ORB

5 © ²2004, Mireille Fornarino, E.S.S.I Object reference semantics I.5. OMA ORB

6 © ²2004, Mireille Fornarino, E.S.S.I 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. Process AProcess B Machine 1Machine 2 Direct Call Inter-Process Call Network Call (IIOP) I.5. OMA ORB

7 © ²2004, Mireille Fornarino, E.S.S.I Bus Corba : fonctions... ORB Client serveur Référence -> faire(param1,param2,...) réseau Marshaling Unmarshaling faire(param1,param2,...) Return Marshaling Return Unmarshaling I.5. OMA ORB

8 © ²2004, Mireille Fornarino, E.S.S.I Bus Corba C++ Souche Java Souche Smalltalk Souche Ada Souche ORB : Liaison avec « tous » les langages de programmation I.5. OMA ORB

9 © ²2004, Mireille Fornarino, E.S.S.I Les Services Objet (CORBA Services) : Fonctionnalités système de bas niveau communes à la majorité des applications distribuées. objectif : étendre les fonctions de l ORB interfaces indépendantes des domaines dapplication; spécification par des interfaces IDL; leurs fonctionnalités peuvent être étendues ou spécialisées par héritage; Services objet communs I.5. OMA Services

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

11 © ²2004, Mireille Fornarino, E.S.S.I 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 dapplication; Exemples : interface utilisateur, gestion de l information, administration du système et gestion de la tâche. Utilitaires communs I.5. OMA Services

12 © ²2004, Mireille Fornarino, E.S.S.I 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 dapplications distinctes (OPenDoc). support de l utilisateur : aide en ligne, vérificateur de texte, tableur, …. gestion du bureau scripts Utilitaires communs : L interface Utilisateur I.5. OMA Services

13 © ²2004, Mireille Fornarino, E.S.S.I Les interfaces ou objets des domaines (CORBA Domains) (aussi dits canevas verticaux, objets métiers): spécifiques à un domaine dapplication (médical, financier, télécommunications, commerce électronique,...); spécification dinterfaces IDL; standardisées par lOMG; leurs fonctionnalités peuvent être étendues ou spécialisées par héritage; Interfaces des domaines I.5. OMA Services

14 © ²2004, Mireille Fornarino, E.S.S.I Les Objets applicatifs (CORBA Applications) : spécification par des interfaces IDL; définis par une application de lutilisateur; hors du champ de standardisation de lOMG; possibilité de standardisation pour des objets émergents. Objets applicatifs I.5. OMA Services

15 © ²2004, Mireille Fornarino, E.S.S.I Services objet communs (SO) Utilitaires communs (UC) Interfaces de domaine (ID) Objets applicatifs (0A) OA SO UC ID SOUC SO Bus dobjets répartis (O.R.B.) Vers une industrie du composant logiciel I.5. OMA Services

16 © ²2004, Mireille Fornarino, E.S.S.I (O.R.B.) composant TCP/IP network (O.R.B.) composant IIOP (O.R.B.) composant BD IIOP (O.R.B.) Bridge (O.R.B.) IIOP DCE-CIOP (O.R.B.) BD composant DCE network DCE-CIOP I.5.OMA Interopérabilité Communication inter-ORB RMI/IIOP IIOP

17 © ²2004, Mireille Fornarino, E.S.S.I 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 TCP/ IP DCE RPC Above OSI... CORBA IDL Object Request Semantics Message Format Transport I.5.OMA Interopérabilité

18 © ²2004, Mireille Fornarino, E.S.S.I Noyau de communication Interface dInvocation Statique Interface dInvocation Dynamique Interface du bus SIIDII ORB SSIDSI OA Interface de Squelettes Statiques Interface de Squelettes Dynamiques Adaptateur dobjet IR Référentiel des interfaces ImplR Référentiel des implantations CORBA : les composantes du bus

19 © ²2004, Mireille Fornarino, E.S.S.I pré-compilateur fichier IDL Client Implémentation dobjet DII Stub client Interface ORB Référentiel des interfaces Rint Référentiel des implémentations Rimp noyau de l Object Request Broker (ORB) SSI DSI SII Adaptateur dObjet Architecture générale Interface de l adaptateur

20 © ²2004, Mireille Fornarino, E.S.S.I Projection des descriptions OMG-IDL vers les langages dimplantation des clients et serveurs. –mode « statique » Instanciation sous forme dobjets CORBA des descriptions OMG-IDL dans un référentiel des interfaces commun. –mode « dynamique » OMG-IDL : compilation

21 © ²2004, Mireille Fornarino, E.S.S.I Les clients et serveurs implantent des descriptions OMG-IDL communes, statiquement précisées dans la phase de compilation/projection du source IDL. III. Corba mode statique CORBA : le mode statique Contrat IDL Bus CORBA Squelette IDL Stub IDL Fournisseur d objets Client d objets Les souches générées encapsulent lutilisation du bus, lactivation et la distribution des composants et lhétérogénéité de larchitecture.

22 © ²2004, Mireille Fornarino, E.S.S.I La projection client Fichier OMG-IDL Cl_aCl_bCl_c stubs Compilation vers client ex : IDL/C++ Référence dobjet Requête vers le bus III. Corba mode statique

23 © ²2004, Mireille Fornarino, E.S.S.I 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 lORB. 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". III. Corba mode statique

24 © ²2004, Mireille Fornarino, E.S.S.I La projection serveur Fichier OMG-IDL Impl_aImpl_bImpl_c squelettes Compilation vers serveur ex : IDL/Java Cl_aCl_bCl_c Obj Requête du bus III. Corba mode statique

25 © ²2004, Mireille Fornarino, E.S.S.I 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 lORB 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 ». III. Corba mode statique

26 © ²2004, Mireille Fornarino, E.S.S.I Invocation statique Client Implémentation dobjet Stub client Adaptateur dObjet ORB noyau squelette statique requête réponse squelette dynamique III. Corba mode statique

27 © ²2004, Mireille Fornarino, E.S.S.I Exemple ORBACUS

28 © ²2004, Mireille Fornarino, E.S.S.I Un « référentiel des interfaces » stocke sous forme dobjets les descriptions dinterfaces OMG-IDL. Une API (DII: Dynamic Invocation Interface) permet de construire des requêtes à lexécution. Une API (DSI : Dynamic Skeleton Interface) permet de comprendre des requêtes à lexécution. III. Corba mode dynamique CORBA : le mode dynamique

29 © ²2004, Mireille Fornarino, E.S.S.I 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 dopération, une liste de couples valeur - type (au sens de lIR) et une structure pour le résultat invoke send_deferred + get_response, poll_response send_oneway wait invoke get_response send-deferred send_oneWay Interface d'invocation dynamique (1) III. Corba mode dynamique

30 © ²2004, Mireille Fornarino, E.S.S.I 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;. III. Corba mode dynamique

31 © ²2004, Mireille Fornarino, E.S.S.I 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, ….. create_request, ….. invocation dynamique (3) III. Corba mode dynamique

32 © ²2004, Mireille Fornarino, E.S.S.I 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. 4. Corba Composants

33 © ²2004, Mireille Fornarino, E.S.S.I Composants du bus

34 © ²2004, Mireille Fornarino, E.S.S.I Référentiel dinterfaces 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 dune référence dobjet, on peut retrouver le contenu dune interface, la signature dune 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 III. Corba Référentiels

35 © ²2004, Mireille Fornarino, E.S.S.I Référentiel dimplémentations. Responsable de lenregistrement 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.)) III. Corba Référentiels

36 © ²2004, Mireille Fornarino, E.S.S.I Interfaces de base du Bus Object module CORBA { exception COMM_FAILURE { … }; // Autres exceptions systèmes. interface Object { // Duplique une référence dobjet CORBA. Object _duplicate(); // Libère une référence dobjet. void _release(); // Teste si une référence ne dénote aucun objet. boolean _is_nil(); // Teste si un objet référencé nexiste plus. boolean _non_existent(); ………………………………………... III. Corba

37 © ²2004, Mireille Fornarino, E.S.S.I Object Adapter : fonctions Fonctions des Adaptateurs dobjets: 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é Intermédiaire entre le bus et les implantations possibles des objets Proxy Servant POA III. Corba Adaptateur

38 © ²2004, Mireille Fornarino, E.S.S.I 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 dadaptateurs) III. Corba Adaptateur

39 © ²2004, Mireille Fornarino, E.S.S.I POA « Pont entre les requêtes arrivants et les objets dimplémentation leur correspondant » Un POA gère les relations entre les références dobjets, 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. III. Corba Adaptateur

40 © ²2004, Mireille Fornarino, E.S.S.I 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 Architecture du POA et terminologie

41 © ²2004, Mireille Fornarino, E.S.S.I POA manager Associé à un POA lors de la création de ce dernier (il ne peut pas être changé) Les états possibles dun 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. ORB POA Manager Requête Servants Application serveur dispatch III. Corba Adaptateur

42 © ²2004, Mireille Fornarino, E.S.S.I Diagramme détat du POA Manager III. Corba Adaptateur

43 © ²2004, Mireille Fornarino, E.S.S.I 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 dimplémentation) ImplicitActivationPolicy (activation automatique ou non des servants) RequestProcessingPolicy (gestion ID-to-servant) ServantRetentionPolicy (gestion mémoire des servants) ThreadPolicy III. Corba Adaptateur

44 © ²2004, Mireille Fornarino, E.S.S.I 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 III. Corba Adaptateur

45 © ²2004, Mireille Fornarino, E.S.S.I 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; //... }; //... }; III. Corba Adaptateur

46 © ²2004, Mireille Fornarino, E.S.S.I Exemple de création de POA (en C++) // Initialize ORB and get Root POA CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); CORBA::Object_var obj = orb->resolve_initial_references("RootPOA"); PortableServer::POA_var root_poa=PortableServer::POA::_narrow(obj); assert(!CORBA::is_nil(root_poa)); // Create empty policy list CORBA::PolicyList policy_list; // Create Controller POA PortableServer::POA_var ctrl_poa = root_poa->create_POA( "Controller", PortableServer::POAManager::_nil(), policy_list); // Create Thermometer POA as a child of the Controller POA PortableServer::POA_var thermometer_poa = ctrl_poa->create_POA( "Thermometers", PortableServer::POAManager::_nil(), policy_list); // Get the Root POA manager PortableServer::POAManager_var mgr = root_poa->the_POAManager(); // Create Thermostat POA as a child of the Controller POA PortableServer::POA_var thermostat_poa = ctrl_poa->create_POA( "Thermostats", mgr, policy_list); Root POA Controller Thermometers Thermostats III. Corba Adaptateur

47 © ²2004, Mireille Fornarino, E.S.S.I 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 lapplication. Etapes de mise en œuvre

48 © ²2004, Mireille Fornarino, E.S.S.I 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. Avant CORBA 2.0, Problème d'interopérabilité entre ORBs. III. Corba Interopérabilité

49 © ²2004, Mireille Fornarino, E.S.S.I Interopérabilité dapplications avec CORBA Environnement X Interopérabilité An A1... Environnement Y Bn B1... Deux problèmes : 1- communication dapplications distribuées au sein dun même environnement; 2- interopérabilité dapplications distribuées entre environnements hétérogènes. Problème 1 Problème 2 Communication Problème 1 Communication III. Corba

50 © ²2004, Mireille Fornarino, E.S.S.I Environnement X ??... ORB 1.2 vendeur x Environnement Y ORB 1.2 vendeur y CORBA 1.2 permet de : résoudre le problème de communication dapplications distribuées au sein dun même environnement; A1 IDL Binding An IDL Binding... B1 IDL Binding Bn IDL Binding Problème 1 résolu Communication Problème 1 résolu Communication Problème 2 Portabilité dapplications avec CORBA1.2 III. Corba Interopérabilité

51 © ²2004, Mireille Fornarino, E.S.S.I CORBA 1.2 permet de : simplifier le portage dapplications entre environnements hétérogènes grâce au langage IDL, aux standardisations des bindings.... Environnement Y ORB 1.2 vendeur y A1 IDL Binding An IDL Binding... B1 IDL Binding Bn IDL Binding Portabilité dapplications avec CORBA 1.2 III. Corba Interopérabilité

52 © ²2004, Mireille Fornarino, E.S.S.I CORBA 2.0 permet de résoudre le problème dinteropérabilité dapplications distribuées entre des environnements hétérogènes grâce au protocole de communication commun GIOP (General Inter ORB Protocol). Environnement X... ORB 2.0 vendeur x Environnement Y ORB 2.0 vendeur y A1 IDL Binding An IDL Binding... B1 IDL Binding Bn IDL Binding GIOP Interopérabilité Problème 2 résolu Interopérabilité dapplication avec CORBA 2.0 III. Corba Interopérabilité

53 © ²2004, Mireille Fornarino, E.S.S.I Solution La spécification CORBA 2.0 comporte 4 nouveaux éléments : + le cadre architectural définissant linteropérabilité entre différents ORBs; + la définition de protocoles communs GIOP et IIOP; + la définition de protocoles spécifiques à un environnement ESIOP et DCE/ESIOP; + la définition de passerelles inter-ORB, permettant la communication entre différentes implémentations de CORBA

54 © ²2004, Mireille Fornarino, E.S.S.I 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. III. Corba Interopérabilité

55 © ²2004, Mireille Fornarino, E.S.S.I IOR + IOR (Interoperable Object Reference) u interface OMG IDL : repository ID uadresse + port IP uclé de format libre (identifie le POA et lobjet dans le POA) Spécifique à lORB upossède une forme externe diffusable chaîne IOR : IOR: …. III. Corba

56 © ²2004, Mireille Fornarino, E.S.S.I Services communs CORBA

57 © ²2004, Mireille Fornarino, E.S.S.I Les services communs CORBA z Service de recherche dobjets : 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 zServices de sûreté de fonctionnement : Security, Transactions, Concurrence z Services de communications asynchrones: Events, Notification, Messaging III. Corba Services

58 © ²2004, Mireille Fornarino, E.S.S.I Les services communs CORBA : historique + 1er RFP : Nommage, Cycle de vie, Notification d'événements, Persistance. + 2ème RFP : Transactions, Concurrence d accès, Externalisation, Relations. + 3ème RFP : Sécurité, Serveur de temps. + 4ème RFP : Propriétés, License, Serveur de requêtes. + 5ème RFP : Annuaire par fonctionnalités, Collection, Gestionnaire de versions. III. Corba Services

59 © ²2004, Mireille Fornarino, E.S.S.I Services Nommage et/ou Vendeur Bus dobjets répartis CORBA sur Internet (IIOP) Serveur C++Client Java Repertoire Traitement IOR Service de recherche dobjets IOR Les services de recherche dobjets CORBA III. Corba Services

60 © ²2004, Mireille Fornarino, E.S.S.I Le service de Nommage Le service de Nommage ou Namming service permet : * dassocier un nom à une référence dobjet CORBA, relativement à un contexte de noms; * de retrouver la référence dobjet ainsi que lobjet associé; * de naviguer à l'intérieur dun 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 III. Corba Services

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

62 © ²2004, Mireille Fornarino, E.S.S.I Comment retrouver la référence du service de nommage ? Cest un « objet notoire » du bus CORBA de nom NameService Quelque soit le langage, le scénario est a. opération CORBA::ORB::resolve_initial_references b. conversion en CosNaming::NamingContext // En C++, obtenir la référence du service Nommage. CORBA_Object_var contextObj = orb->resolve_initial_references ("NameService"); CosNaming::NamingContext_var context = CosNaming::NamingContext::_narrow(contextObj); III. Corba Services

63 © ²2004, Mireille Fornarino, E.S.S.I Utilisations du service Nommage Enregistrer une référence diffusion par un serveur de ses références dobjet création dun chemin opération bind ou rebind Rechercher une référence (2) création dun 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); III. Corba Services

64 © ²2004, Mireille Fornarino, E.S.S.I Le service Vendeur Le service vendeur ou Trader service permet : * d enregistrer des objets auprès de ce service en les caractérisant par un ensemble de propriétés. * de retrouver un service en précisant son type et les critères le caractérisant (différentes politiques de recherche possibles) Opérations principales découvrir et importer des services : Interface LookUp : query (type de service recherché, contraintes, préférences, politique de recherche, ….) parcourir les réponses : Interface OfferIterator mise à jour du service Vendeur : Interface Register export, withdraw …... III. Corba Services

65 © ²2004, Mireille Fornarino, E.S.S.I Le service de notification d'événements La plupart des requêtes CORBA se traduisent par lexécution synchrone dune opération (le client connaît la référence de lobjet auquel la requête sadresse et le client ainsi que lobjet 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 lobjet ne se connaissent pas; lorsque le client et lobjet ne sont pas actifs simultanément. III. Corba Services

66 © ²2004, Mireille Fornarino, E.S.S.I Communication événementielle principes de fonctionnement concepts de base : événements, réactions (traitements associés à loccurrence dun événement) principe dattachement : association dynamique entre un nom dévénement et une réaction communication anonyme : indépendance entre lémetteur et les consommateurs dun événement

67 © ²2004, Mireille Fornarino, E.S.S.I Un canal dévènements Producteur Consommateur Canal Flot des évènements III. Corba Services

68 © ²2004, Mireille Fornarino, E.S.S.I Un canal dévènements : notification Producteur Consommateur Canal Producteur actif / Consommateur réactif Le canal diffuse les évènements Push PushSupplier PushConsumer void push(in any data) raises(Disconnected); III. Corba Services

69 © ²2004, Mireille Fornarino, E.S.S.I Un canal dévènements : demande Producteur Consommateur Canal Producteur réactif / Consommateur actif Le canal procure les évènements Pull() demande PullSupplier { //demande de production dun événement any pull() raises(Disconnected); // présence dun événement any try_pull(out boolean has_event) raises(Disconnected); III. Corba Services

70 © ²2004, Mireille Fornarino, E.S.S.I Un canal dévènements : file dévènements Producteur Consommateur Canal Producteur actif / Consommateur actif Le canal gère des files dévènements Push() Pull() III. Corba Services

71 © ²2004, Mireille Fornarino, E.S.S.I Un canal dévènements : collecte dévènements Producteur Consommateur Canal Producteur réactif / Consommateur réactif Le canal est une entité active voire intelligente Pull() Push() III. Corba Services

72 © ²2004, Mireille Fornarino, E.S.S.I Le service de Transaction Le service de Transaction ou Transaction service permet dassurer 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 dune transaction; dassocier plusieurs objets répartis à une seule et même transaction; de coordonner la terminaison dune transaction (2 phase commit). III. Corba Services

73 © ²2004, Mireille Fornarino, E.S.S.I Le service de Concurrence Le service de Concurrence ou Concurrency control service permet de contrôler laccès à un objet de manière à gérer la cohérence et la consistance des opérations entre cet objet et les objets quil accède ou bien qui laccè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...). III. Corba Services

74 © ²2004, Mireille Fornarino, E.S.S.I Le service dExternalisation Le service dExternalisation ou Externalization service permet : lexternalisation dun objet, cest à dire la représentation de létat de lobjet dans une séquence doctets (en mémoire, sur disque, sur réseau) transportable, de durée de vie illimitée indépendante de lenvironnement (ORB) dorigine. linternalisation des données, impliquant la création dun nouvel objet dans le même environnement ou dans un environnement différent. III. Corba Services

75 © ²2004, Mireille Fornarino, E.S.S.I Le service Cycle de vie Le service Cycle de vie ou Life cycle service permet : + de gérer la création, la destruction, la copie et le déplacement des objets du bus; + les objets sont créés par lintermédiaire dobjets appelés Factories dont la référence est accessible au client; + un objet est détruit, copié ou déplacé à laide dopérations définies dans linterface de base LifeCycleObject; III. Corba Services

76 © ²2004, Mireille Fornarino, E.S.S.I Le service de Relations Le service de Relations ou Relationships service permet détablir dynamiquement des relations entre les objets distribués. Une relation est définie par un rôle, un degré, une cardinalité et des attributs. Trois niveaux de services : basique : service de base permettant de créer les relations et les objets et de naviguer à travers la relation, de détruire la relation; graphes dobjet en relation; relations spécifiques : Containment (1-n) et référence (n-m). III. Corba Services

77 © ²2004, Mireille Fornarino, E.S.S.I Sécurité et temps Le service de Sécurité (Security) permet de gérer les fonctions suivantes : authentification autorisation sûreté et intégrité des communications encryptage administration de la sécurité Le service de Temps (Time) permet la synchronisation périodique dhorloges dans tous les composants dun système réparti. III. Corba Services

78 © ²2004, Mireille Fornarino, E.S.S.I ème RFP Le service de Propriétés (Properties) permet dassocier dynamiquement une liste de propriétés à un objet. Il est possible dajouter, de supprimer, de modifier et de retrouver toute propriété associée à un objet. Le service dinterrogations (Query) permet dexprimer des requêtes sur des ensembles dobjets CORBA. Le service de License (Licensing) contrôle et gère les rémunérations associées à lutilisation dun service objet donné. III. Corba Services

79 © ²2004, Mireille Fornarino, E.S.S.I ème RFP Le service de Gestion des versions (Change Management) permet de gérer lévolution des versions des interfaces des objets ainsi que de l'adéquation avec leurs implémentations. Le service dAnnuaire par fonctionnalités (Trader) permet dassocier des fonctionnalités à des objets CORBA. Le client utilise ce service comme lannuaire des pages jaunes. Le service de Collection (Collection) permet de créer et de manipuler des collections dobjets. III. Corba Services

80 © ²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 III. Corba Services

81 © ²2004, Mireille Fornarino, E.S.S.I CORBA Services en résumé Naming –How are objects found? Events –Standardized mechanism for client notifications. LifeCycle –How are objects created, moved, duplicated and deleted? Trader –Find objects that have certain properties Transactions –Distributed 2-phase commit –Interfaced with the XA standard Security –Complete distributed security 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 III. Corba Services

82 © ²2004, Mireille Fornarino, E.S.S.I Une suite de spécifications Intégration de Java et lInternet –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 CORBA 3.0 III. Corba

83 © ²2004, Mireille Fornarino, E.S.S.I 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 sexécute via IIOP –Utilisation des spécifications sur le passage par valeur de lOMG – Java-to-IDL –Mais pas de chargement dynamique des stubs

84 © ²2004, Mireille Fornarino, E.S.S.I implementation dun Objet CORBA RMI/CORBA via IIOP RMI client RMI stub ORB CORBA Squelette ORB Réseau via IIOP

85 © ²2004, Mireille Fornarino, E.S.S.I Pourquoi CORBA? Infrastructure largement adoptée pour la distribution dobjets Plate-forme indépendant, il permet linté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 dune compagnie (donc dUn produit ou dune 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 ».

86 © ²2004, Mireille Fornarino, E.S.S.I CORBA … Pas dapproche 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 lextension des fonctionnalités des objets. –Nécessité dune construction par composition plutôt que par héritage Pas de gestion automatique du cycle de vie des objets. –Qui gère lactivation des objets? Pas de standard IMR…

87 © ²2004, Mireille Fornarino, E.S.S.I 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é, …)

88 © ²2004, Mireille Fornarino, E.S.S.I 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 dun même composant Non limité à Java ou Windows : langage indépendant Intégré à CORBA 3.0 spec

89 © ²2004, Mireille Fornarino, E.S.S.I 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

90 © ²2004, Mireille Fornarino, E.S.S.I 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, 2AB, Inc., and OMG Architecture Board Member

91 © ²2004, Mireille Fornarino, E.S.S.I Références Client/Server Programming with Java and CORBA - R. Orfali, D. Harkey John Wiley Sons CORBA, ActiveX et Java Beans - J. M. Chauvet Eyrolles Architecture J2EE, 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)

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


Télécharger ppt "© ²2004, Mireille Fornarino, E.S.S.I. - 1 - Common Object Request Broker Architecture Architecture permettant de développer des applications distribuées."

Présentations similaires


Annonces Google