1 / 58

CORBA : suite

CORBA : suite. Les services communs Les composantes du bus. Services communs CORBA. III. Corba Services. Les services communs CORBA. Service de recherche d’objets : pour retrouver un objet Nommage (Naming) : par un nom : service de « pages blanches »

margo
Download Presentation

CORBA : suite

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Services communs CORBA - 2 -

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

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

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

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

  7. Notion de chemin d’accès - 8 -

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

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

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

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

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

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

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

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

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

  17. III. Corba Services Un canal d’évènements : demande Consommateur Producteur Pull() Consommateur Producteur Canal Pull() Consommateur PullSupplier { //demande de production d’un événement any pull() raises(Disconnected); // présence d’un événement any try_pull(out boolean has_event) raises(Disconnected); demande Consommateur Producteur réactif / Consommateur actif Le canal procure les évènements - 18 -

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

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

  20. III. Corba Services Le service de Transaction • Le service de Transaction permet d’assurer la consistance • des traitements en respectant les propriétés ACID • (Atomicité, Consistance, Isolation et durabilité) des transactions. • Il permet : • de commencer et de terminer une transaction; • de contrôler la propagation d’une transaction; • d’associer plusieurs objets répartis à une seule et même transaction; • de coordonner la terminaison d’une transaction (2 phase commit). - 21 -

  21. Composantes du bus - 22 -

  22. IR Référentiel des interfaces ImplR Référentiel des implantations CORBA : les composantes du bus Adaptateur d’objet Interface du bus Interface de Squelettes Statiques Interface d’Invocation Statique Interface de Squelettes Dynamiques Interface d’Invocation Dynamique Application serveur Application cliente SSI DSI SII DII ORB OA Noyau de communication - 23 -

  23. Architecture générale fichier IDL Client Implémentation d’objet pré-compilateur SSI DSI Interface ORB Stub client DII SII Interface de l ’adaptateur Adaptateur d’Objet noyau de l ’Object Request Broker (ORB) Référentiel des interfaces Rint Référentiel des implémentations Rimp - 24 -

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

  25. III. Corba mode statique Contrat IDL 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. Client d ’objets Fournisseur d ’objets Stub IDL Bus CORBA Squelette IDL • Les souches générées encapsulent l’utilisation du bus, l’activation et la distribution des composants et l’hétérogénéité de l’architecture. - 26 -

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

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

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

  29. III. Corba mode statique Application cliente Référence d’objet Requête Cl_a Cl_b Cl_c stubs Compilation vers client ex : IDL/C++ vers le bus La projection client Fichier OMG-IDL - 30 -

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

  31. III. Corba mode statique Application serveur Impl_a Impl_b Impl_c squelettes Compilation vers serveur ex : IDL/Java Cl_a Cl_b Cl_c Obj Requête du bus La projection serveur Fichier OMG-IDL - 33 -

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

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

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

  35. III. Corba mode dynamique Interface d'invocation dynamique (1) Permet la création dynamique de requêtes API (DII) sans passer par des souches pré-générées; • Un objet Request = un nom d’opération, une liste de couples valeur - type (au sens de l’IR) et une structure pour le résultat • invoke • send_deferred + get_response, poll_response • send_oneway invoke send-deferred send_oneWay wait get_response - 39 -

  36. III. Corba mode dynamique Interface d'invocation dynamique (2) • Utilisation du référentiel des interfaces pour récupérer les informations relatives aux interfaces IDL; • Avantages : • les interfaces peuvent être découvertes dynamiquement; - code client générique indépendant d'une interface IDL;. - 40 -

  37. 4. Corba Composants Interface de squelette dynamique • Analogue au DII mais du côté serveur. • Permet de délivrer une requête à un objet implémentation • qui est inconnu lors de la phase de compilation • Interprète une requête et ses paramètres. • Utiliser pour créer des ponts entre des ORBs de vendeurs différents. • Utiliser pour intégrer des applications existantes (legacy application). Les applications peuvent ne pas être conformes aux standard CORBA et peuvent également ne pas être OO. - 42 -

  38. IR Référentiel des interfaces ImplR Référentiel des implantations CORBA : les composantes du bus Adaptateur d’objet Interface du bus Interface de Squelettes Statiques Interface d’Invocation Statique Interface de Squelettes Dynamiques Interface d’Invocation Dynamique Application serveur Application cliente SSI DSI SII DII ORB OA Noyau de communication - 43 -

  39. III. Corba Référentiels Référentiel d’interfaces Maintient les informations sur les types, les interfaces etc.....; Un graphe d ’objets « concepts » d ’IDL : ModuleDef, InterfaceDef, OPerationDef, .. Par navigation dans ce graphe ou à partir d’une référence d’objet, • on peut retrouver le contenu d’une interface, la signature d’une opération, … • Informations pour une interface : • son module • son nom • ses attributs • ses opérations (nom, nom et types des paramètres, • exceptions, contexte) • ses héritages - 44 -

  40. III. Corba Adaptateur Object Adapter : fonctions Intermédiaire entre le bus et les implantations possibles des objets Fonctions des Adaptateurs d’objets: 1- Enregistrement des objets implémentation. 2- Génération et interprétation des références d'objets. 3- Activation et désactivation des objets implémentation. 4- Invocation des méthodes à travers les squelettes ou le DSI. 5- Participation à la sécurité Servant Proxy POA - 47 -

  41. III. Corba Adaptateur Portable Object Adapter • Interfaces IDL définies dans le module PortableServer • • POA : Interface principale côté serveur • quels servants sont instanciés? • Activation/désactivation, • destruction des servants • Création de références, … • • POAManager • Contrôle du flot des requêtes vers plusieurs POAs • • Servant • native Servant; • • POA Policies (7 interfaces) - 48 -

  42. III. Corba Adaptateur POA « Pont entre les requêtes arrivant et les objets d’implémentation leur correspondant » Un POA gère les relations entre les références d’objets, les identificateurs et les servants Un serveur peut contenir plusieurs POAs Un POA gère plusieurs servants, tous avec une même politique déterminée par ses « policies » (immuables). Le RootPOA a un ensemble fixé de Policies, il est toujours présent. Un servant est associé à un unique POA. - 50 -

  43. III. Corba Adaptateur Application serveur dispatch Servants ORB POA Manager Requête POA POA manager • Associé à un POA lors de la création de ce dernier (il ne peut pas être changé) Les états possibles d’un POA manager : • Active : routage normale des requêtes • Holding : Requêtes stockées • Discarding : Requêtes rejetées avec TRANSIENT • Inactive : Requêtes rejetées ; les clients peuvent être redirigés vers un serveur différent pour ré-essayer. - 51 -

  44. III. Corba Adaptateur POA Policies Chaque POA a un ensemble de politiques. Lorsqu'un nouveau POA est créé, on peut utiliser les valeurs par défaut ou les fixer selon les besoins. Un POA n'hérite pas des politiques de son père. • LifespanPolicy (références transitoires ou persistantes) • IdAssignmentPolicy (gestion de la clef) • IdUniquenessPolicy (association servant et objets d’implémentation) • ImplicitActivationPolicy (activation automatique ou non des servants) • RequestProcessingPolicy (gestion ID-to-servant) • ServantRetentionPolicy (gestion mémoire des servants) • ThreadPolicy - 53 -

  45. III. Corba Adaptateur Root POA Policies Life Span Policy TRANSIENT ( PERSISTANT) ID Assignment Policy SYSTEM_ID ( USER_ID) ID Uniqueness Policy UNIQUE_ID ( MULTIPLE_ID) Servant Retention Policy RETAIN ( PERSISTANT) Request Processing Policy USE_ACTIVE_OBJECT_MAP_ONLY ( USE_SERVANT_MANAGER ) Implicit Activation Policy IMPLICIT_ACTIVATION Thread Policy ORB_CTRL_MODEL - 55 -

  46. III. Corba Interopérabilité Interopérabilité Capacité pour un ORB A d'invoquer une opération définie en IDL sur un objet résidant sur un ORB B. L'ORB A et B étant des implémentations de CORBA différentes. - 58 -

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

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

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

  50. III. Corba Interopérabilité GIOP et IIOP GIOP (General Inter-ORB Protocol) spécifie un ensemble de formats pour les messages ainsi qu'une représentation commune des données échangées entre les ORBs. La représentation des données communes est basée sur la spécification CDR (Common Data Representation). IIOP (Internet Inter-ORB Protocol) est l'implémentation du protocole GIOP basé sur TCP/IP. - 62 -

More Related