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

© 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis - 1 - CORBA : suite - Les services communs - Les composantes du bus.

Présentations similaires


Présentation au sujet: "© 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis - 1 - CORBA : suite - Les services communs - Les composantes du bus."— Transcription de la présentation:

1 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis CORBA : suite - Les services communs - Les composantes du bus

2 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis Services communs CORBA

3 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

4 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis Le contrat IDL du service Nommage module CosNaming { typedef string Istring; struct NameComponent {. string id; string kind; }; typedef sequence Name; // Un chemin daccè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 }; III. Corba Services // new_context bind_new_context // destroy list Le contrat IDL du service Nommage

5 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

6 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

7 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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");

8 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis Notion de chemin daccès

9 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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 ", "");

10 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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);

11 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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) {...

12 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis Retrouver un objet Opération réalisée par un client ou un serveur Scénario type : –construire un chemin daccès (Name) –appeler lopération « resolve » avec le chemin –convertir la référence obtenue dans le bon type Object resolve (in Name n) raises (NotFound, CannotProceed, InvalidName)

13 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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);

14 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

15 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

16 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis Un canal dévènements Producteur Consommateur Canal Flot des évènements III. Corba Services

17 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

18 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

19 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

20 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

21 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis Le service de Transaction Le service de Transaction 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

22 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis Composantes du bus

23 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

24 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

25 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

26 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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.

27 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis ORB serveur POA Architecture CORBA ORB client Objet dimplantation Référence dobjet (IOR) Interface dobjet Requête Activation Objet Corba réseau POA id Requête

28 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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 limplantation

29 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis Hiérarchie en Java org.omg.CORBA.portableObjectImpl > _GestionnaireStub étend > GestionnairePOA org.omg.PortableServer.Servant > GestionnaireOperations Implémente > Gestionnaire étend Gestionnaire_Impl > Org.omg.CORBA.Object étend Standard À implémenter Généré étend

30 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

31 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

32 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis Extrait dun 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; }

33 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

34 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

35 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis Extrait dun 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(); }

36 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis Extrait dun 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; }

37 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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 - Invocations Dynamiques-

38 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

39 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

40 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

41 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

42 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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. 4. Corba Composants

43 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

44 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

45 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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. III. Corba Référentiels

46 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

47 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

48 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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) III. Corba Adaptateur

49 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

50 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis POA « Pont entre les requêtes arrivant 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

51 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

52 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis Diagramme détat du POA Manager III. Corba Adaptateur

53 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

54 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis POA Policies The seven POA policies are all derived from the CORBA::Policy base interface. Each controls a different aspect of the implementation of an object. We briefly describe the purpose of each policy here LifespanPolicy : The life span policy controls whether a reference is transient or persistent. A transient reference works only for as long as its POA remains in existence and then become permanently non- functional. Therefore, transient references do not survive server shut-down. Persistent references continue to denote the same object even if the server is shut down and restarted. IdAssignmentPolicy : The ID assignment policy controls whether the object ID that is part of the object key of every reference is created by the ORB or is provided by the application. Transient references usually use IDs that are created by the ORB, whereas persistent reference usually use IDs that are provided by the application. The POA maintains a lookup table known as the Active Object Map (AOM) that associates each object ID with the address of the corresponding servant in memory. This means that each object ID must uniquely identify a servant; otherwise, the POA could end up with a single object ID designating two servants simultaneously and would not know which servant to give the request to. IdUniquenessPolicy: The ID uniqueness policy determines how object references are mapped to C++ servants. You can choose to use one servant for each CORBA object that is provided by a server, or you can choose to incarnate multiple CORBA objects with the same C++ servant. ImplicitActivationPolicy : The implicit activation policy determines whether a newly instantiated servant must be explicitly activated (registered with the ORB) or will be activated automatically when you first create a reference for the servant. Transient references usually use implicitly activated servants, whereas persistent references must use explicitly activated servants. RequestProcessingPolicy : The request processing policy controls whether the POA maintains the object ID-to-servant associations for you (either to multiple servants or a single servant). You can also choose to maintain these associations yourself. Doing so is more work, but provides more powerful implementation choices. ServantRetentionPolicy : The servant retention policy controls whether you keep your servants in memory at all times or instantiate them on demand, as requests arrive from clients. ThreadPolicy : The thread policy controls whether requests are dispatched on a single thread or multiple threads.

55 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

56 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

57 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

58 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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. III. Corba Interopérabilité

59 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

60 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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é

61 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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é

62 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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é

63 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

64 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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) (RMI-IIOP) –(Firewall specification) Mid-2001 –Interopérabilité et service de nommage (2.4) Amélioration de la qualité de service –Asynchronous Messaging (2.4 fin 2000) –Corba minimum pour les systèmes embarqués –Temps réel, Modèle de composants, langage de script CORBA 3.0 III. Corba

65 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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…

66 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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é, …) COTS, Tests, Fichier dassemblage, ADL, …

67 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis CORBA Component Model (CCM) Modèle de composants côté serveur, il étend le modèle Objet CORBA – Extensions IDLs (CIDL), I.R. et ORB –Modèles : Services offerts, requis, puits, sources –Interfaces multiples dun même composant Modèle de containeur –Proche des EJB et COM –Services offerts au client : Évènements, Transactions, Sécurité, persistance Modèle de « packaging » et déploiement Non limité à Java ou Windows : langage indépendant

68 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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

69 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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)

70 © 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis 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 "© 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis - 1 - CORBA : suite - Les services communs - Les composantes du bus."

Présentations similaires


Annonces Google