Invocation de Méthode à des Objets distants Exemple : CORBA Common Object Request Broker Architecture Mise en pratique avec Orbacus en JAVA Il faudrait ajouter quelque chose tôt sur le marshalling et quelque chose sur le protocole d ’application…. Et le déploiement

Consensus pour l’interopérabilité 1.1-histoire Consensus pour l’interopérabilité Le problème : Intégration des applications Pas de consensus sur les langages de programmation Pas de consensus sur les plate-formes de développement Pas de consensus sur les systèmes d’exploitation Pas de consensus sur les protocoles réseau Pas de consensus sur les formats des données manipulées par les applications Recherche d’un Consensus pour l’interopérabilité CORBA est le fruit d’un long travail de consensus effectué par les membres d’un consortium international OMG. C’est la réponse du groupe de l’OMG au besoin d’interopérabilité entre de nombres de plus en plus inmportant de hadware et logiciel . De façon simple Corba permet ux applications dee communiquer avec d’autres sans se préocupper de la localisation des objets ou de qui les a modélisé. En 91 Corba 1.1 définit le langage d’interface et l’interface qui permet aux objets client/serveur de se connecter avec un ORB spécific. En décembre 94 Corba 2.0 est adopté qui définit comment les ORB fournit par différents vendeurs peuvent communiquer. Component Software is making this interoperability possible. Applications are changing; customers are less willing to accept huge, monolithic do-everything applications and are looking for smaller components which they can combine flexibly and dynamically to create tools focused on their particular business needs. And components will only work together if they have been designed and built on standard interfaces. Since interoperability must span the enterprise and even go beyond it to customers’ and suppliers’ systems, these interfaces must be independent of platform, operating system, programming language, even network protocol; anything less will create “islands of interoperability” insulated from each other by arbitrary technological barriers which keep us from realizing the benefits we’re entitled from our investment in computing. 3 3

Plate-forme client/serveur orientée objets 1.2 CORBA? CORBA Common Object Request Broker Architecture : CORBA Plate-forme client/serveur orientée objets Un standard pour l’interopérabilité entre objets Support pour différents langages Support pour différentes plate-formes (interopérabilité) Communications au travers du réseau Des services (Distributed transactions, events, ... ) Guides et modèles de programmation CORBA (Common Object Request Broker Architecture) is a distributed object-oriented client/server platform. It includes: • an object-oriented Remote Procedure Call (RPC) mechanism • object services (such as the Naming or Trading Service) • • interoperability protocols • programming guidelines and patterns CORBA replaces ad-hoc special-purpose mechanisms (such as socket communication) with an open, standardized, scalable, and portable platform. Mission Promouvoir la technologie orientée objet dans les systèmes informatiques distribués Objectif Favoriser l’intéropérabilité et la portabilité d’applications réparties à travers : une terminologie unique dans le domaine de l’objet; un model de référence commun; des interfaces et des protocoles communes. 1.1 What is CORBA? Fundamentally, the Common Object Request Broker Architecture (CORBA) is a distributed client/server platform with an object-oriented spin. The idea is to provide an object-oriented programming model for distributed computing to programmers that is as close as possible to programming with ordinary local objects. The job of CORBA is take all the grunt work out of distributed programming, so you can focus on your business logic instead of having to worry about distribution infrastructure. CORBA consists of a large set of specifications that run to thousands of pages. However, the fundamental services it provides can be summarized as above. Apart from an RPC mechanism, CORBA offers a number of services that take care of common chores, provides language bindings for a number of popular programming languages, defines an interoperability protocol so implementations from different vendors can interoperate, and it defines a number of programming guidelines and patterns (often enshrined in specific APIs) that you use when you develop applications. CORBA enables you to get away from having to worry about infrastructure and ad-hoc and home-grown communication mechanism and replaces them with a an open and standardized platform that is both portable and scalable.

Historique Minimum Corba RealTime Corba Corba Component Model 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 2000 2002 CORBA 2.1 CORBA 3.0 Fondation de l’OMG Publication de l’OMA Publication CORBA 1.1 Publication CORBA 1.2 Mapping IDL/C++ Adoption CORBA 2.0 CORBA 2.3 Publication CORBA 1.0 Minimum Corba RealTime Corba Corba Component Model l’OMG établi en 89, avec 8 membres à l’origine, a aujourd’hui plus de 760 membres. Le but de l’OMG est la définition de l’OMA dont CORBA fait partie. Corba dans l’OMA implémente l’ORB.On se concentrera surtout sur CORBA accessoirement sur les services et facilities. décembre 90 : CORBA 1.0 puis début 91 1.1 qui définit IDLet l ’API pour communiquer avec l ’ORB. Dans toutes les versions 1. x on ne disait pas comment les ORBs pouvaient communiquer entre eux. Fevrier 92 CORBA 1.1 = première version largement publiée des spécifications CORBA. interface du BOA et de la gestion mémoire Décembre 93 : on élimine plusieurs ambiguïtés surtout en ce qui concerne la gestion mémoire et les comparaisons de référence d’objets : Août 96 : Corba 2.0 : DSI, extension de IR, GIOP, IIOP¨, …. Transactions services …travail avec OLE2/COM Corba 2.0 introduit un protocole qui permet la communication entre ORB définit par des vendeurs différents. IIOP (EyeOP prononcé) nécessaire pour que les ORB soient considérés conformes à la 2.0. Août 97 : CORBA 2.1 : ajout de caractéristiques liées à la sécurité (IIOP secure), ajout de 2 langages cibles Ada et Cobol, extensions des types IDL, Février 98 : Corba 2.2 : POA, IDL/JAVA spec. Fin septembre : IDL JAVA Language mapping, … Relase Commercial en 99 : 6 6

Object Management Group (OMG) http://www.omg.org consortium international créé en 1989 but non lucratif regroupement de plus de 460 organismes constructeurs (SUN, HP, DEC, IBM, ...) environnements systèmes (Microsoft, OSF, Novell, ...) outils et langages (Iona, Object Design, Borland, ...) produits et BD (Lotus, Oracle, Informix, O2, ...) industriels (Boeing, Alcatel, Thomson, ...) institutions et universités (INRIA, NASA, LIFL, W3C) Au début des années 80, les technologies objets prennet une place de plus en plus importante dans la réalisation des projets informatiques de grandes sociétés comme Data General Corportaion, Hewlett-Packard ou Sun MicroSystems, les ingénieurs de ces sociétés se réunissent pour échanger idées et expériences et donneront naissance à l ’OMG. En 89, le consortium fut créé et de nouvelles sociétés se joignirent HyperDesk et IONA technologie. Des gens de tous horizons : fournisseurs de matériels (SUN, HP, DEC ou IBM) de grands utilisateurs Boeing, Motorola, Alcatel Aujourd ’hui on y trouve aussi des producteurs de logiciels Netscape, Iona tech, Visigenic,… des intituts et universités NASA, INRIA, LIFL L ’objectif est la définition de standard pour l ’intégration d ’appli distribuées et hétérogènes fondées Les trois concepts clefs suivants : la réutilisation des composants, l ’interopérabilité et la portabilité. l ’élément clé de la vision de l ’OMG c ’est CORBA (Common Object Request Architecture) : un middleware orienté Objet. Objectif: faire émerger des standards pour l’intégration d’applications distribuées hétérogènes et la réutilisation de composants logiciels Ils ne produisent pas de logiciels. sa force c ’est la présence de la plupart des compagnies intéressées par les développement OO Basée aux Etats Unis avec des représentations au Royaume Uni, au Japon en Australie et en Allemagne. 4 4

OMG en résumé OMA : pour l ’architecture logicielle  MDA (Model Driven Architecture) CORBA : pour le  « middleware » technique UML pour la modélisation UML = Unified Modeling language MOF pour la méta-modélisation MOF = Meta-Object Facility

Processus de développement

Le langage IDL: Un « esperanto » pour les objets contrat Client d ’objets Fournisseur d ’objets Stub IDL Bus CORBA Squelette IDL Après ce tour d ’horizon de l ’env. Corba, interessons nous à présent au langage de définition d ’interface définit par l ’OMG, OMG IDL Une interface OMG IDL correspond à l ’abtraction d ’un type d ’objet, API que l'ont veut rendre publique elle contient donc les opérations exportées et utilisées par les autres objets mais pas forcément toutes les méthodes implantés par la classe d'objet. Java d ’un côté, C++ de l ’autre. Ce contrat isole le client des détails d ’implantation des objets I;E; de l ’ens. des logiciels et du matériel choisi pour leur implantation. Le fournisseur peut lui implanter plusieurs versions des objets en fonction de la qualité de service demandée. Il permet également l ’indépendance vis à vis du bus. Objets Corba 17 17

Spécification interface IDL (1/2) Un objet grid est un tableau contenant des valeurs. Les valeurs sont accessibles grâce aux opérateurs get et set qui peuvent être invoqués à distance. objets grid Appel de get et set sur l'objet grid distant Processus client Processus serveur

Spécification interface IDL (2/2) interface Grid { readonly attribute short height; readonly attribute short width; void set (in short n, in short m, in long value); long get(in short n, in short m); void copyIn(inout Grid g); };

Le langage IDL: Interface Definition Language langage de spécification d’interfaces, supportant l’héritage multiple; indépendant de tout langage de programmation ou compilateur (langage pivot entre applications); langage utilisé pour générer les stubs, les squelettes et pour définir les interfaces du Référentiel d’interface; la correspondance IDL-langage de programmation est fournie pour les langages C, C++, Java, Smalltalk, Ada, Cobol. Après ce tour d ’horizon de l ’env. Corba, interessons nous à présent au langage de définition d ’interface définit par l ’OMG, OMG IDL Langage de description La norme internationale ODP à adopté IDL comme standard pour la description de ses propres objets. Langage indépendant d ’un langage. Mais quand même très proche de C++! interface (avec héritage multiple sans surcharge) Sa gammaire est relativement simple et décrite en moins de 36 pages dans la norme Corba 2.0. 17 17

Exemple interface attribut opérations exception opérations interface account { readonly attribute float balance; attribute string description; void credit (in float f); void debit (in float f); }; interface currentAccount : account { readonly attribute float overdraftLimit; interface bank { exception reject {string reason;}; account newAccount (in string name) raises (reject); currentAccount newCurrentAccount (in string name, in float limit) void deleteAccount (in account a); }; interface attribut opérations exception 3 types d’objets sont ici décrit Account, …. Chacun définit des opérations Overdraft : decouvert opérations 19 19

Eléments IDL Une spécification IDL définit un ou plusieurs types, constantes, exceptions, interfaces, modules,... pragma constantes types de base au format binaire normalisé nouveaux types (typedef, enum, struct, union, array, sequence) exceptions types de méta-données (TypeCode, any) pragma: fixer les identifiants. Les pragmas IDL sont des directives permettant au précompilateur IDL de générer et créer des identifiant globaux (Utile pour le référentiel des interfaces) La norme définit les 3 pragmas : prefix : utilisé dans la génération des identifiants le + utilisé (utilisation du nom du domaine Internet. version :permet d ’associer un numéro de version à un identifiant IDL ID : fixer précisément l ’identifiant associé à une def IDL. #pragma prefix « omg.org » module ServiceDate { IDL:omg.org/ServiceDate typedef unsigned short Mois; #pragma version Mois 1.2; IDL:omg.org/ServiceDate/Mois:1.2 typedef unsigned short Annee; #pragma ID Annee « IDL:monde/Annee:2.3 » IDL:monde/Annee:2.3  constantes : nom symbolique à des valeurs particulières : const Ident = expression types de base au format binaire normalisé : élémentaires : entiers, flottants, booleans, caractères, chaînes, types composés composés : énumérations, structures, union, tableaux, séquences des types dynamiques auto-déscriptifs (TypeCode et any). ??? nouveaux types permet de créer un nouveau type de donnée. (typedef (aussi dit alias) , enum, struct, union, array, sequence) par exemple typedef sequence<Positif> Des entiersPositifs; typedef unsigned long EntierPositif; que l ’on retrouve dans intreface Premier plus clair de manipuler des jours qu ’un entier de 16bits exception : chaque exception définir un type de données structuré constitué d ’un ens. de champs typé types de méta-données (TypeCode, any) cf plus loin 18 18

Eléments IDL Un module permet de limiter la validité des identificateurs (namespace/package) Interface : ensemble d’opérations et de types =>(classe C++/Java) Syntaxe : Interface | [<héritage>] { <interface Body>}; opération (synchrone ou asynchrone sans résultat) attribut (possibilité de lecture seule) Surcharge Interdite Réutilisation de spécifications existantes (#include/import) 18 18

Exemple module définitions de type interface opérations module unService { typedef unsigned long EntierPositif; typedef sequence<Positif> desEntiersPositifs; interface Premier { boolean est_premier ( in EntierPositif nombre); desEntiersPositifs nombres_premiers (in EntierPositif nombre); }; module monApplication { interface MonService { unService::EntierPositif prochainPremier(..); module définitions de type interface opérations Nous noterons une syntaxe très proche de C++, avec cependant en plus le mode passage des paramètres et la liste des exceptions d’une opération. Le concept d ’interface est l ’équivalent des interface Java, ou des classes abstraites C++. La sémantique des typedef n ’est pas très claire : sous-type ou alias (en général alias). En général utilisé dans un but de lisibilité des contrats IDL.

Exemple 3. IDL Description Description d’un service pour manipuler des dates. La notion de modules permet de regrouper des définitions communes à un ou plusieurs services. Ici on trouve des définitions de types et 3 définitions d’interfaces. Jour et années sont représentés par des entiers positifs. On remarque la structure date. L’attribut année8courante permet de consulter et de modifier la date courante. 19 19

Ici on trouve des définitions de types et 3 définitions d’interfaces. Description d’un service pour manipuler des dates. La notion de modules permet de regrouper des définitions communes à un ou plusieurs services. Ici on trouve des définitions de types et 3 définitions d’interfaces. Jour et années sont représentés par des entiers positifs. On remarque la structure date. L’attribut année8courante permet de consulter et de modifier la date courante. 19 19

Attribut IDL Définition d’attribut interface account { Equivaut à : readonly attribute float balance; attribute string description; ... }; Equivaut à : float get_balance(); string get_description(); void set_description(in string s); Attention la notion d’attributs IDL ne doit pas être confondue avec les attributs d’instances. Ce n’est qu’une construction syntaxique pour exprimer simplement une paire d’opérations d’accès à une propriété d’un objet. Il faut ensuite implanter ces opérations.Celles-ci peuvent tres bien ne pas utiliser d ’attribut température consulte un capteur externe, ... Ces attributs sont tjs publiques comme tout ce qui est dans les IDLs. 22 22

Operations (1/2) Paramètres nommés et associés à un mode 3. IDL Description Operations (1/2) Paramètres nommés et associés à un mode Opérations bloquantes par défaut void op1 (in long input, out long output, inout long both); interface account; interface bank { account newAccount (in string name); void deleteAccount (in account old); }; Client uneBanque newAccount L’identificateur d’une opération est unique. Liste des paramètres in : transport du client vers l’objet out : transport en retour de l’objet vers le client in out : dans un sens puis dans l’autre. Le type de retour est void quand rien n’est retourné. mode d ’invocation : par défaut synchrone I.E. que le client attend la fin d ’exécution de l ’opération pour reprendre la suite de son activité. exceptions : indique optionnellement les exceptions pouvant être déclenchées par cette opération. contextes : variables d ’environnement du client vers l ’objet. Tres peu utilisée, car on préfère passer des informations telles que le contexte d ’exécution du client via des paramètres. void afficher () context (« DISPLAY »); demande l ’adresse de l ’ecran graphique ou DISPLAY sous X-Windows. IMPORTANCE DE préciser les types de données et leur format binaire pour une gestion automatique de l'hétérogénéité. calcul retours <uneOpération> ::= <modeInvocation> <typeRetour> <identificateur> ‘ (‘ <paramètres> ‘ ) ’ <clausesExceptions><clausesContextes> 23 23

Pourquoi différents modes de passage de paramètres ? in : Données fournies par le client out : Données retournées par l ’objet inout : Données clientes modifiées par l ’objet Répartition Passage par copie

Opérations (2/2) oneway void notify (in string message); 3. IDL Description Opérations (2/2) oneway void notify (in string message); Opération non bloquante Pas de paramètre de type out, inout ou d’exceptions Valeur de retour : void Pas d ’exceptions déclenchées. L’appelant ne sait alors pas si l’opération a été effectivement exécutée 0 ou n fois, + spécifications d ’un service pour les communications asynchrones. Tous les paramètres en in et type de retour void. Corba assure seulement qu’elle sera exécuté avec the best effort et que si l’opération arrive elle ne sera exécutée qu’une seule fois. La plupart des environnements CORBA assure la délivrance et l ’exécution de l ’opération. elle ne peut déclencher aucune exception aussi est-il difficile de déterminer si l ’exécution a réussi ou non. Client uneBanque notify(«ok ») méthode finie 24 24

Exceptions Gestion explicite de la part du client 3. IDL Description Exceptions exception reject {string reason;}; account newAccount (in string name) raises (reject); exception DateErronnee { String raison; }; CORBA::Exception CORBA::UserException CORBA::SystemException Des exceptions CORBA standardisées UNKNOWN NO_PERMISSION BAD_PARAM NO_IMPLEMENT COM_FAILURE OBJECT_NOT_EXIST INV_OBJREF ………. Similaire à la définition d ’une structure elles peuvent avoir plusieurs champs de valeurs typées. Ce qui permet d ’informer le client sur le contexte et les raisons qui ont provoqué l ’exception. Des exception Systeme elles ne doivent pas être précisées parmis les exceptions qui peuvent être déclenchées par une opération: leur déclaration est implicite. cf. en 14 jours P. 56-57 en faire la photocopie?? ou P.97 UNKNOWN = le bus ne la connaît pas. BAD8PARAM: un paramètre invalide a été transmis à une primitive du bus. COMM_FAILURE : problème de communication sur le réseau NO8PERMISSION : non autorisation d ’invoquer une opération (lié au contrôle d ’accès du serveur Sécurité) NO_IMPLEMENT : l ’implantation d ’une opération est non disponible OBJECT… invocation sur un objet déjà détruit les ref sur cet objet doivent être détruites. INV_OBJE.. une référence d ’objet est invalide Gestion explicite de la part du client

Définitions circulaires 3. IDL Description Définitions circulaires module Circulaire { interface B; interface A { void utiliséB(in B unB); } interface B { void utiliséA(in A unA); Les attributs de A sont présents en un seul exemplaire dans D. Aujourd’hui si un objet est l’implanattion de plusieurs interface alors il doit y avoir une interface les combinant qui a été défini. Mais cela devrait changer comme en Java. 25 25

Héritage multiple A B C D 3. IDL interface A { ... } Description Héritage multiple interface A { ... } interface B : A { ... } interface C : A { ... } interface D : B, C { ...} A B C Les attributs de A sont présents en un seul exemplaire dans D. héritage seulement de spécifications mais deux interface ne peuvent pas définir un même nom d’opération. Ce problème doit être résolu en éléminant les conflist de nom (A REVOIR) Aujourd’hui si un objet est l’implanattion de plusieurs interface alors il doit y avoir une interface les combinant qui a été défini (OMG-MI) Mais cela devrait changer comme en Java ou en COM. D 25 25

Types de base et autres types 3. IDL Description Types de base et autres types Types de base short long unsigned short unsigned long float double char boolean octet …... Types construits struct union enum Types génériques array sequence string Langage fortement typé. Type scalaire 15 : void, entier, réel, chaine, octet, boolean, caractère types complexes : énumération, structure, union, tableau, séquence. Type dynamiques typeCode : n ’importe quel type IDL.et any : n ’importe quelle valeur IDL en conservant son typeCode. Ces méta-types permettent de de spécifier des contrats IDL indépendant des types de données manipulées eg une pile d ’any stocke n ’importe quelle valeur. et bien sûr des types objets : ceux de l ’utilisateur Notons l ’absence de pointeurs présents seulement dans certains langages Un caractère par ex. dans la définition de constante est noté ‘ A ’, ‘ \n ’ ’ ¨ ’ « Une Chaîne de caractère » Union permet d’exprimer une structure à discriminant. On l’a gardé par souci de compatibilité mais les pgmeurs lui préfèrent le type Any. Définition de tableaux de taille fixe : nombre de dimensions et taille sont fixés à la déclaration typedef Date[10] TableauDates; const unsigned short Taille = 100; typedef float [Taille] [Taille]MatriceCarreDeFlottants; Les pgmmeurs préfèrent l ’utilisation de tableaux dynamiques ou séquence IDL. séquence : le nombre d ’éléments est fixé à l ’exécution, ce qui permet le transport d ’ens non borné de valeurs. On peut fixer une taille maximale.Toutes les valeurs d ’une séquence doivent être du même type (ou any ou un dérivé). sequence <Television> televisionInventory Ex. pour retourner les jours fériés, sans ce type on aurait du retourner un tableau de 366 éléments, ici l ’allocation se fera à l ’exécution. MétaTypes Types de données dynamiques et auto-descriptifs any TypeCode 21 21

Type Any interface PileDeChaines { readonly attribut string sommet; 3. IDL Description Type Any interface PileDeChaines { readonly attribut string sommet; void poser(in string valeur); string retirer(); }; interface PileGénérique { readonly attribut Any sommet; readonly attribut TypeCode typeDesValeurs; void poser(in Any valeur); Any retirer(); }; MétaType de données : I.E. des types de données contenant une valeur et une info décrivant le type de celle-ci. TypeCode : permet de stocker la description de tout autre type IDL. Par ex. S ’il contient une structure, il en contiendra le nom et la liste de tous ses champs (leur nom et TypeCode associé). Any permet de stocker n ’importe quelle valeur IDL et son TypeCode associé. Utilisé dans tous les contextes où il est nécessaire de transporter des valeurs dont le type n ’est pas encore connu au moment des phases de conception IDL ou pour définir des opérations dont l ’un des paramètres est polymorphe. Ces types sont à la base des mécanismes dynamiques du bus CORBA.

Exemple Compilation interface IDL vers Java 1- Exemple introductif Exemple Compilation interface IDL vers Java Grid.idl jidl … Grid.idl A écrire Compilateur IDL/Java Généré Répertoire grid Répertoire grid Répertoire grid Répertoire grid Client Serveur GridOperations.java _GridStub.java GridPOA.java Ya aussi GridOperations Si j’ai un module j’ai un repertoire. Sinon je crois que l’option package me donne un repertoire… Le code de l’implementation squelette c’est des appels aux fonctions de l’utilisateur… dont on encapsule la reponse dans la requete recu en parametre. On voit tres bien la lecture de la requete… l’execution… la recuperation du resultat ou de l’exception attendue… Le stub … on voit l’identifiant de l’IDL, la creation de la requete, le passage par in out etc… la transformation des parametres en Any, … l’invocation Helper lui définit les fonctions de manipulation de GRID en any, extraction d’un any, la creation du typeCode, … la conversion de type a partir d’une Stream…. In.read_object … x’est de la lecture d’IOR ????? La creation de Stub et son association a l’objet d’implementation … ca m’a l’air tes reflexif ici… et le narrow … _impl genere un exemple avec le suffixe _impl In order to implement this application in Java, the interface specified in IDL is translated to Java classes similar to the way the C++ code was created. The ORBACUS IDL-to-Java translator jidl is used like this: jidl --package hello Hello.idl This command results in several Java source files on which the actual implementation will be based. The generated files are Hello.java, HelloHelper.java, HelloHolder.java, HelloOperations.java, HelloPOA.java and _HelloStub.java, all generated in a directory with the name hello. I Grid.java Client.java Grid_Impl.java GridHelper.java Serveur.java GridHolder.java

Les classes Stubs et Squelettes 1- Exemple introductif Les classes Stubs et Squelettes implantation du stub public class _GridStub ……. Grid envoie de requêtes invisible par le programmeur instanciée automatiquement par GridHelper (narrow) Utilise le DII pour assurer la portabilité du binaire implantation du squelette public abstract class GridPOA ………. GridOperations reçoit et décode des requêtes doit être héritée par l’implantation 1.Extends Org.omg.corba.portable.ObjectImpl 2.dynamicImplementation … marchalling D'autres approches par delegation TIE surtout si on un systeme proprietaire et que l'on ne veut pas en heriter...

Implémentation du serveur (1) 1- Exemple introductif Implémentation du serveur (1) 1. Initialiser le bus CORBA obtenir l’objet ORB 2. Initialiser l’adaptateur d’objets obtenir le POA 3. Créer les implantations d’objets 4. Enregistrer les implantations par l’adaptateur 5. Diffuser leurs références afficher une chaîne codifiant l’IOR 6. Attendre des requêtes venant du bus 7. Destruction du Bus

Implémentation du client 1- Exemple introductif Implémentation du client 1. Initialiser le bus (objet ORB) 2. Créer les souches des objets à utiliser 2.a. obtenir les références d’objet (IOR) 2.b. convertir vers les types nécessaires narrow contrôle le typage à travers le réseau 3. Réaliser les traitements

Le cycle de vie des objets Problème actuellement, 1 grille = 1 serveur pas de création/destruction d’objets à distance seulement invocation d’opérations Solution notion de fabrique d’objets exprimée en OMG-IDL C’est un canevas de conception : Design pattern voir aussi le service LifeCycle Autres usages de la fabrique : - gestion de droits, load-balancing, polymophisme, …

L’implantation de la fabrique creerGrille Grille Grille Fabrique

L’implantation de la fabrique Grille Grille Fabrique detruireGrille

Interface IDL d ’une fabrique de Grilles module grilles { . . . interface Fabrique { Grid newGrid(in short width,in short height); }; }; Here is our Java implementation of the Product interface: 1 // Java 2 public class Product_impl extends ProductPOA 3 { 4 public void destroy() 5 { 6 byte[] id = _default_POA().servant_to_id(this); 7 _default_POA().deactivate_object(id); 8 } 9 } 2 Servant class Product_impl is defined as an implementation of the Product interface. 6,7 The destroy operation deactivates the servant with the POA. As long as no other refer-ences to the servant are held in the server, the object will be eligible for garbage collec-tion. Here’s our implementation of the factory: 2 public class Factory_impl extends FactoryPOA 4 public Product createProduct() 6 Product_impl result = new Product_impl(orb_); 7 org.omg.PortableServer.POA poa = ... // Get servant’s POA 8 byte[] id = ... // Assign an ID 9 poa.activate_object_with_id(id, result); 10 return result._this(orb_); 11 } 12 } 2 Servant class Factory_impl is defined as an implementation of the Factory interface. 4-11 The createProduct operation instantiates a new Product servant, activates it with the POA, and returns an object reference to the client. void destroyGrid (in Grid g);

Scénario d ’obtention de la référence du service de nommage Client ou Serveur ORB resolve_initial_references ("NameService"); CosNaming:: NamingContext conversion ajout,retrait,lecture,...

Notion de chemin d’accès

Que reste-t-il à savoir ? Plus sur la génération de stubs, les possibilités Corba (DII, Activation d’objets…) Plus sur le service de nommage Corba Interopérabilité et JNDI Le service d’événements Corba Du service d’événements aux MOM Un exemple de MOM JMS