html5-img
1 / 50

CORBA C ommon O bject R equest B roker A rchitecture Mise en pratique avec Orbacus en JAVA

CORBA C ommon O bject R equest B roker A rchitecture Mise en pratique avec Orbacus en JAVA. Mireille Blay-Fornarino blay@essi.fr. Extraits de JM Geib, C. Gransart, P. Merle. http://www.iona.com/products/orbacus_home.htm. 1.1-histoire. Consensus pour l’interopérabilité.

tameka
Download Presentation

CORBA C ommon O bject R equest B roker A rchitecture Mise en pratique avec Orbacus en JAVA

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 Common Object Request Broker Architecture Mise en pratique avec Orbacus en JAVA • Mireille Blay-Fornarino • blay@essi.fr Extraits de JM Geib, C. Gransart, P. Merle http://www.iona.com/products/orbacus_home.htm - 1 -

  2. 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é « The bad news is that there will never be a single operating system, single programming language, or single network architecture that replaces all that has passed; The good news is that you can still manage to build systems economically in this environment. » «  Model Driven Architecture » by Richard Soley and the OMG Staff Strategy Group - 3 -

  3. 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 replaces ad-hoc special-purpose mechanisms (such as socket communication) with an open, standardized, scalable, and portable platform. » - 4 -

  4. I.3. OMG Object Management Group (OMG) • 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) http://www.omg.org The World’s Best Standardization Process « In addition to its technologies, OMG has the world’s best standardization process. Executing our process, building consensus as they converge on technical details, OMG members produce each new specification in nine to seventeen months. Proven in the marketplace with the standardization of CORBA, the CORBAservices, Domain Facilities, UML, the MOF, and OMG’s other modeling standards, the process is one of our group’s major assets. » - 6 -

  5. I.3. OMG Organisation et procédures • Comité technique • détermine la direction de l’architecture et des normes; • émet des RFI (Request For Information) pour vérifier la disponibilité des technologies; • émet des RFP (Request For Proposal) pour obtenir des propositions de spécifications; • évalue les propositions et propose une sélection; • fait des recommandations au comité directeur sur les choix des • technologies. • Comité directeur • prend les décisions finales pour l’adoption des spécifications. - 7 -

  6. I.3. OMG OMG en résumé • L ’OMG prône l ’utilisation d ’une approche basée sur les technologies « objet » (devenu « modèle ») pour offrir une vue unique d ’un système distribué et hétérogène • OMA : pour l ’architecture logicielle • OMA = Object Managment Architecture • MDA (Model Driven Architecture) • CORBA : pour le  « middleware » technique • CORBA = Common Object Request Broker Architecture • UML pour la modélisation • UML = Unified Modeling language • MOF pour la méta-modélisation • MOF = Meta-Object Facility - 8 -

  7. Application Cliente Code d’implantation Référence d’objet Requête Objet Interface d’objet ORB Application Serveur I.4. Client/serveur Le modèle client/serveur orienté objet (1) Objet Corba Activation Servant ORB: Object Request Broker : Bus à Objets répartis - 9 -

  8. I.5. OMA ORB ORB (2/2) • Composant central du standard CORBA qui gère : • la localisation d’objet • la désignation des objets • l’empaquetage des paramètres (marshalling) • le dépaquetage des paramètres (unmarshalling) • l’invocation des méthodes • la gestion des exceptions • l ’activation automatique et transparente des objets De plus, il fournit des caractéristiques telles que : • la liaison avec « tous » les langages de programmation • un système auto-descriptif • l ’interopérabilité entre les bus - 15 -

  9. I.5. OMA ORB Return Return faire(param1,param2,...) Unmarshaling Marshaling Unmarshaling 010010010110110101111 10010110110 Bus Corba : fonctions ... Client serveur Référence -> faire(param1,param2,...) Marshaling ORB réseau - 16 -

  10. I.5. OMA ORB ORB : Liaison avec « tous » les langages de programmation C++ Java Smalltalk Ada Souche Souche Souche Souche Bus Corba - 17 -

  11. OMA Object Management Architecture - 18 -

  12. I.5. OMA Object Management Architecture • Description d’une architecture de Gestion d’Objets • classifiant les objets en fonction de leurs rôles et • définissant les bases des futures spécifications incluant : • une prise en compte des problèmes d’intégration dans des environnements distribués; • un modèle d’objets abstrait; • l’architecture du modèle de référence; • InterOpérabilité entre ORBs • un glossaire des termes utilisés Utiliser des services standardisés à la conception, l’implantation et l’exécution. - 19 -

  13. I.5. OMA Modèle objet s t u b s Concepts (1/2) Vue d’un objet dans une application d'objets distribués Vue d’un objet dans une application monolithique s q e l e t t e s i m p l invocation distante objet objet sur serveur Servant objet sur client Proxy Legende impl = objet implementation - 20 -

  14. I.5. OMA Modèle objet Concepts (2/2) client serveur serveur pur client pur objet serveur objet client invocation distante obj1 Impl c- obj1 s objet serveur objet serveur obj3 Impl s obj2 Impl s invocation distante invocation distante objet client c- obj2 objet client c- obj3 Application 2 Application 3 Application 1 Legende : c-obji : objet client obji obji Impl : objet implementation obji s : squelette - 21 -

  15. I.5. OMA Interfaces de domaine Utilitaires communs Objets applicatifs Workflow Administration Télécom Santé Finance DataWare IHM Spécifiques Licences Nommage Vendeur Sécurité Relations Collections Temps Externalisation Cycle de vie Transactions Propriétés Persistance Events Changements Interrogations Concurrence Services objet communs (CORBA Services) Architecture du modèle de référence CORBA Bus d’objets répartis (O.R.B.) - 22 -

  16. Processus de développement - 23 -

  17. 3. IDL IDL 3- Le langage IDL Un « esperanto » pour les objets Le contrat IDL Client d ’objets Fournisseur d ’objets Stub IDL Bus CORBA Squelette IDL Objets Corba - 24 -

  18. Étapes de mise en oeuvre Spécification interface IDL Compilation interface IDL Implantation des objets Corba Implantation du serveur Implantation du client Enregistrement du serveur Côté client Côté serveur Utilisation du service Nommage - 25 -

  19. 1- Exemple introductif 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 - 26 -

  20. 1- Exemple introductif 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); }; - 27 -

  21. 3. IDL Description 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. - 28 -

  22. 3. IDL Description Exemple 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) raises (reject); void deleteAccount (in account a); }; interface attribut opérations exception opérations - 29 -

  23. 3. IDL Description 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) - 30 -

  24. 3. IDL Description Eléments IDL • Un module permet de limiter la validité des identificateurs • Interface : ensemble d’opérations et de types =>classe C++ • 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) - 31 -

  25. 3. IDL Description Exemple module unService { typedefunsignedlong 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 - 32 -

  26. 3. IDL Description Exemple - 33 -

  27. 3. IDL Description Attribut IDL Définition d’attribut interface account { readonly attribute float balance; attribute string description; ... }; Equivaut à : float get_balance(); string get_description(); void set_description(in string s); - 34 -

  28. 3. IDL Description Operations (1/2) <uneOpération> ::= <modeInvocation> <typeRetour> <identificateur> ‘ (‘ <paramètres> ‘ ) ’ <clausesExceptions><clausesContextes> • 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 calcul retours - 35 -

  29. 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 - 36 -

  30. 3. IDL Description onewayvoid notify (in string message); Opérations (2/2) • 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. Client uneBanque notify(«ok ») méthode finie - 37 -

  31. 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 ………. Gestion explicite de la part du client - 38 -

  32. 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); } - 39 -

  33. 3. IDL Description Héritage multiple interface A { ... } interface B : A { ... } interface C : A { ... } interface D : B, C { ...} A B C D - 40 -

  34. 3. IDL Description Types de base et autres types • Types construits • struct • union • enum • Types génériques • array • sequence • string • Types de base • short • long • unsigned short • unsigned long • float • double • char • boolean • octet • …... MétaTypes Types de données dynamiques et auto-descriptifs • any • TypeCode - 41 -

  35. 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(); }; - 42 -

  36. 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 I Grid.java Client.java Grid_Impl.java GridHelper.java Serveur.java GridHolder.java - 43 -

  37. 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 - 44 -

  38. 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 - 45 -

  39. 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 • Rem. : éviter l’opérateur bind (2.a + 2.b) • spécifique à chaque produit donc non portable - 46 -

  40. Processus B Processus B Objet Objet invocation d ’une méthode résultat Passage d ’un objet par référence ou par valeur Processus A Processus A invocation d ’une méthode invocation d ’une méthode copie d ’objet créée référence Objet serialized Object Processus A Processus A Processus B Processus B référence Objet Objet copie Objet Objet - 48 -

  41. 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, … - 49 -

  42. creerGrille Grille Grille Grille L’implantation de la fabrique Grille Fabrique - 50 -

  43. Grille Grille Grille detruireGrille L’implantation de la fabrique Grille Fabrique - 51 -

  44. Interface IDL d ’une fabrique de Grilles module grilles { . . . interface Fabrique { Grid newGrid(in short width,in short height); }; }; - 52 -

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

  46. 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); - 55 -

  47. 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) - 56 -

  48. Une application d’administration de la fabrique • Création d’une nouvelle grille et mise à disposition par le service Nommage • 1. Initialiser le bus CORBA • 2. Obtenir le service Nommage (NS) • 3. Obtenir la fabrique depuis le NS • 4. Créer un répertoire • 5. Enregistrer le répertoire dans le NS - 57 -

  49. What is ORBacus? http://www.ooc.com/ob/. ORBACUS is an Object Request Broker (ORB) that is compliant with the Common Object Request Broker Architecture (CORBA) specification (2.4 + features 3) • Full CORBA IDL support • C++ and Java language mappings • Simple configuration and bootstrapping • Portable Object Adapter • Objects by Value • Portable Interceptors • Single- and Multi-threaded • Active Connection Management • Fault Tolerant Extensions • Dynamic Invocation and Dynamic Skeleton Interface •Dynamic Any • Interface and Implementation Repository • Pluggable Protocols • IDL-to-HTML and IDL-RTF documentation tools • Includes Naming, Trading, Event, Notify, Property Services,balancing,… - 58 -

  50. Conclusion • CORBA : ça marche et c’est simple • Choisir son langage d’implantation • C++ : complexe et moins portable • Java : portable et plus lent • Choisir son bus • 1 bus = 1 bibliothèque • mixer les bus : c’est possible Expérimentez en TPs ! - 59 -

More Related