Corba FR

Le modle Objet de CORBA
Systmes et Applications Rpartis
Le modle Objet de OMG-CORBA
UV B : Systme et Applications Rparties Anne 95/96 Laurence Duchien CNAM-CEDRIC, 292, rue st Martin 75141 Paris Cedex 03 tel : 40 27 25 83 e_mail : duchien@cnam.fr http://cedric.cnam.fr/personne/duchien/poly.html
CNAM-CEDRIC
-1-
L.Duchien
Plan
L'OMG- Object Management Group................................................................ 4 Les objets distribus de CORBA............................................................ 5 Tout est dans l'IDL........................................................................... 6 L'objectif de CORBA ........................................................................ 7 L'OMA : Object Manangement Architecture............................................... 8 L'ORB (Object Request Broker)............................................................ 9 ORB Versus RPC............................................................................. 11 Les services objets............................................................................ 12 Les facilits communes....................................................................... 14 Le Modle Objet pour CORBA ...................................................................... 15 La smantique de l'objet ..................................................................... 16 L'implantation de l'objet..................................................................... 18 L'architecture de CORBA ............................................................................ 19 Structure de l'interface de l'ORB ........................................................... 20 Le client........................................................................................ 21 L'implantation objet ct client.............................................................. 22 L'implantation objet .......................................................................... 23 La rfrence d'objet........................................................................... 23 Le talon IDL ct client....................................................................... 24 L'interface d'invocation dynamique (DII) ................................................. 25 L'API du rfrentiel d'interface............................................................. 25 L'interface ORB............................................................................... 26 Le bus ORB (Object Request Brocker core)(1) ........................................... 27 Le bus ORB (Object Request Brocker core)(2) ........................................... 28 Les talons IDL du serveur (skeleton)....................................................... 29 L'interface dynamique (squelette dynamique) (DSI) ..................................... 30 L'adaptateur d'objet .......................................................................... 31 Diffrents adaptateurs d'objets..................................................... 33 Rfrentiels des interfaces et des implantations ........................................... 37 L'interface d'ORB cot serveur.................................................... 38 Le serveur...................................................................................... 39 L'implantation ct serveur.................................................................. 40 L'invocation de mthodes ............................................................................ 41 Quelques exemples d'ORBs.......................................................................... 44 L'interoprabilit....................................................................................... 45 Les ponts entre ORBs................................................................................. 47 L'IDL (langage de dfinition d'interface)........................................................... 48 La structure de l'IDL CORBA............................................................... 49 Un exemple d'IDL............................................................................ 50 Le langage de dfinition de l'interface(IDL) de CORBA................................. 51 L'IDL et l'hritage............................................................................ 52 Exemples IDL et DII (Dynamic Invocation Interface).................................... 53 Le rfrentiel d'interface Corba 2.0......................................................... 54 Les classes du rfrentiel d'interface .............................................. 55 Les services CORBA : le nommage................................................................. 56 L'interface du service de nommage................................................ 58 Le service de courtier (trader)........................................................................ 59 Les services CORBA : le cycle de vie............................................................... 60 Les interfaces du cycle de vie................................................................ 61 Les services CORBA : les vnements.............................................................. 62 Les services CORBA : les transactions ............................................................. 63 Les lments du service transactionnel..................................................... 64 Les services CORBA : la concurrence .............................................................. 65 Les services CORBA : la persistance................................................................ 67 Sauvegarde un niveau contre la sauvegarde deux niveaux........................... 68 CNAM-CEDRIC -2L.Duchien
Systmes et Applications Rpartis 69 69 70 72 73
POS : La vue du client........................................................................ POS : La vue de l'objet persistant........................................................... Les lments du POS................................................................ Des implantations CORBA........................................................................... Bibliographie...........................................................................................
CNAM-CEDRIC
-3-
L.Duchien
L'OMG- Object Management Group

Un consortium compos de vendeurs de systmes, de dveloppeurs de logiciels, d'utilisateurs dveloppant et promouvant la thorie et la pratique des objets distribus. 400 membres (Sunsoft, HP, DEC, IBM, Iona, Hyperdesk, Object Design,...) Produit des standards / documents qui dfinissent les mcanismes de distribution et de communication dans un rseau. - OMA ( Object Management Architecture) - CORBA (Common Object Request Broker Architecture)
1989 1990 1991 1992 1993 1994 1995 1996
Cration de l'OMG 11 Membres
Publication de CORBA 1.1 200 membres Premire publication du guide OMA
390 Membres Publication de Dfinition des services CORBA 2.0 communs
ftp et http : omg.org
CNAM-CEDRIC
-4-
L.Duchien
Les objets distribus de CORBA

Les objets CORBA sont des lments que l'on trouve n'importe o dans le rseau. Ils correspondent des composants qui peuvent tre accds par n'importe quel client distant via des invocations de mthodes. Le client n'a pas besoin de connatre : - la localisation des objets distribus, - le systme qui les excute, - la faon dont le serveur implmente les objets Exemple : un serveur peut tre implment sous forme de classes C++ ou avec des millions de lignes COBOL, le client ne voit pas la diffrence. Il doit seulement connatre l'interface publi par le serveur L'interface : le contrat qui va lier client et serveur
CNAM-CEDRIC
-5-
L.Duchien
Tout est dans l'IDL

IDL : Interface Definition Language L'IDL est un langage de notation standard. Il fournit une notation universel pour spcifier des APIs. Il est purement dclaratif Son objectif : dfinir les limites des composants et les interfaces contractuelles avec les clients potentiels L'IDL fournit des interfaces indpendants des systmes et des langages de programmation pour tous les services et les composants rsidants sur le Bus CORBA. => Permet des clients et des serveurs crits dans des langages diffrents de cooprer travers le rseau et les systmes d'exploitation. La grammaire IDL est un sous-ensemble du C++ avec des mots-cls supplmentaires pour supporter la distribution
C++ADA SmalltalkCobol
Java
C++ADA SmalltalkCobol
Java
IDL IDL IDL IDL IDL IDL Client ORB
IDL IDL IDL IDL IDL IDL Serveur
CNAM-CEDRIC
-6-
L.Duchien
L'objectif de CORBA
Toute objet est quip d'un clou....Tout individu est quip d'un marteau => le clou est l'IDL CORBA. Il permet aux fournisseurs de composants de spcifier dans le langage standard de dfinition l'interface et la structure des objets qu'ils fournissent. => Le marteau correspond l'ensemble des services distribus de CORBA. Ils dterminent quels sont les objets dans le rseau, quelles mthodes ils fournissent et quels adaptateurs d'interface ils supportent. => Le rfrentiel des interfaces (Interface Repository) CORBA contient toutes les dfinitions de ces interfaces et des donnes mta qui permettent aux composants de se dcouvrir mutuellement au moment de l'appel. => Ce qui fait de CORBA un systme se dcrivant luimme.
CNAM-CEDRIC
-7-
L.Duchien
L'OMA : Object Management Architecture

Objets d'application Facilits communes
Object Request Broker
Services objet
Services Objet Les fonctions de base pour mettre en oeuvre les objets:
- cycle de vie - nommage - Gestion des vnements - Persistance - Contrle de concurrence
Normes appeles COSS(Common Object Services Specifications) Object request Broker (ORB) Bus logiciel qui assure la communication entre les objets du rseau Les facilits communes Collection de services orients vers l'utilisateur:
- Messagerie lectronique, - Mise en oeuvre de documents - Accs des bases de donnes
Objets d'application Les objets de l'application de l'utilisateur

CNAM-CEDRIC -8L.Duchien
L'ORB (Object Request Broker)

Bus objet Permet aux objets de faire des requtes vers des objets locaux ou distants et de recevoir les rponses. Quelques avantages de l'ORB : - Les invocations statiques et dynamiques de mthodes - Les liaisons avec des langages de haut niveau. Le client utilise le langage de son choix sans se proccuper du langage utilis par le serveur. - Un systme se dcrivant lui-mme. CORBA fournit des donnes de niveau mta permettant de dcrire chaque interface de serveur connu du systme. Ces donnes sont gnres automatiquement partir des pr-compilateur d'IDL. (exemple metaware C++) - La transparence locale ou distante : un ORB peut fonctionner seul ou en interconnexion avec d'autres ORB (2.0). - Les transactions et la scurit intgres : L'ORB inclut des informations de contexte dans ses messages pour grer la scurit et les transactions entre machines. - Les messages polymorphes : un ORB invoque une opration distante sur un objet cible. Ce qui veut dire que la mme opration peut avoir des comportements diffrents selon l'objet rcepteur.
CNAM-CEDRIC
-9-
L.Duchien
Quelques nuances sur ces avantages : - Les premiers ORBs commerciaux sont lents et inefficaces... ils n'implantent pas toutes les fonctionnalits (ramasse-miettes, rpartition de charge, gestion du contrle, tolrance aux fautes..) - Le code des serveurs n'est pas trs portable : La spcification de Corba ne dcrit pas suffisamment toutes les interfaces pour crire un code de serveur portable. Par contre pour les clients, elle est complte. - l'IDL a besoin d'extensions de niveau smantique : une forme de description flexible des messages est ncessaire
CNAM-CEDRIC
-10-
L.Duchien
ORB Versus RPC
Client Call toto
Serveur code donnes excuter toto
Mcanismes de RPC
Client invoquer toto sur l'objet X invoquer toto sur l'objet Y
Serveur Objet X Objet Y donnes donnes toto toto
Object Request Broker
CNAM-CEDRIC
-11-
L.Duchien
Les services objets

Ensemble de services de niveau systme format comme des objets avec une interface spcifie en IDL. augmente et complte les fonctionnalits de l'ORB 11 objets de services : - service de cycle de vie : Oprations pour crer, copier, dplacer et effacer des objets sur le bus - service de persistance : Fournit une interface simple pour stocker des composants de manire persistante sur un ensemble de serveurs de stockage (bases de donnes objet, bases de donnes relationnelles, simples fichiers). - service de nommage : Permet aux composants sur le bus de s'enregistrer et de se retirer dynamiquement dans des vnements spcifiques. - service vnement: Le service dfinit un objet bien connu "event channel" qui collecte et distribue les vnements travers le rseau. - service de contrle de concurrence : Fournit un gestionnaire de verrous qui peut obtenir des verrous pour des transactions ou des processus classiques. - service de transaction : Fournit le protocole de validation deux phases pour des transactions plates ou imbriques
CNAM-CEDRIC
-12-
L.Duchien
- service de relation : permet de crer des associations dynamiques (ou liens) entre des objets qui ne connaissent rien les uns des autres. - service d'externalisation : fournit un moyen standard pour prendre ou mettre des donnes d'un objet en utilisant un mcanisme de flot. - service de requte : fournit des oprations de requtes pour objets. C'est un sur-ensemble de SQL avec une partie SQL3 et une partie OQL (Object Query Language). - service de licence : fournit des oprations pour mesurer l'utilisation des composants afin d'assurer une utilisation quitable. - service de proprits : fournit des oprations pour associer des valeurs ou des proprits un objet (titre, date,..). - service de scurit ... en cours de dfinition - service de temps .... en cours de dfinition - service d'administration... - service de courtier ... Ces services sont dcrits (ou en cours de descriptions dans des RFP (Request For Proposal) ou encore COSS (Common Object Service Specification) L'utilisation des services permet de construire des objets en mixant ses propres objets et les services offerts par CORBA en fonction des besoins. Exemple : Cration d'un objet "voiture" avec une version persistante, transactionnelle et concurrente en multihritant des services correspondants.
CNAM-CEDRIC
-13-
L.Duchien
Les facilits communes

Collection d'objets dfinis avec une interface IDL pouvant tre utiliss directement par les applications objets Deux catgories : - Horizontale : - Interface utilisateur pour des services d'ditions similaire ceux trouvs dans OpenDoc ou OLE - services de gestion d'information : stockage de document, change de donnes - services de gestion systme : pour grer, instrumenter, configurer, installer des objets - services de gestion de tches : incluant des transactions longues, des agents, des scripts et la messagerie. - Verticale : Fournira des services pour des segments de march comme la sant, la finance, les tlcommunications...
CNAM-CEDRIC
-14-
L.Duchien
Le Modle Objet pour CORBA

Le modle objet de l'OMG est un modle abstrait. Le modle utilis pour CORBA est un modle objet concret qui diffre du modle abstrait sur plusieurs points : - laboration : exemple : dfinition de la forme de paramtres des requtes, du langage utilis pour spcifier les types - Prcision : exemple : dfinition d'instances spcifiques d'entits (objets, oprations, types) - Restriction : exemple : limination d'entits, ajout de restrictions sur l'utilisation. Le principe du modle objets de CORBA : => Isolation des demandeurs de service (client) et des fournisseurs (serveur) => Ct client - cration et identit d'un objet - requte et oprations - type et signature => Ct serveur - implmentation (mthodes, activation) => + des lments dpendants de la machine (modle d'excution et de contrle)
CNAM-CEDRIC
-15-
L.Duchien
La smantique de l'objet
Un client d'un service est une entit quelconque capable de demander un service Un objet est une entit - identifiable - encapsule - qui fournit 1 ou + services des clients Les requtes Il s'agit d'un vnement auquel on associe une opration, un objet, 1 ou + paramtres, et un ventuel contexte de la demande. La forme de la requte correspond une description qui peut tre value plusieurs fois. On les dfinit soit dans un langage de "liaison" particulier (langage de liaison C pour IDL) ou avec des appels sur des interfaces d'invocation dynamique. Une valeur est quelque chose qui peut tre un paramtre dans une requte. Une valeur peut identifier un objet. Plus particulirement, une valeur est une instance d'un type de donne de l'IDL. Une rfrence d'objet est un nom d'objet qui dsigne un objet. Une requte correspond la demande de service d'un client. Un rsultat d'excution est retourn au client. Il peut s'agir d'une valeur de paramtre ou d'une exception. Les paramtres sont des paramtres d'entre, de sortie, ou d'entre-sortie.
CNAM-CEDRIC
-16-
L.Duchien
La cration et la destruction des objets Du point de vue du client, il n'a pas de mcanisme spcial pour crer ou dtruire un objet. Le rsultat de la requte de cration fournit la rfrence du nouvel objet. Les types Un type est une entit identifiable avec un prdicat associ dfini sur des valeurs Les types sont utiliss dans les signatures pour restreindre un paramtre ou un rsultat. Le type d'un objet est un type dont les membres sont des objets. On a les types de base (entier, boolen, caractres,...) et les types construits (structures, squence, union, ...) Les interfaces Une interface est la description des oprations possibles que le client peut demander sur un objet. Les interfaces sont spcifis en IDL. L'hritage d'interface fournit les mcanismes de composition permettant un objet de supporter plusieurs interfaces. Les oprations Une opration est une entit identifiable qui dfinit un service qui peut tre demand. On identifie une opration par un identificateur d'opration. Un opration a une signature qui dcrit les paramtres, les rsultats, les exceptions, le contexte, et une indication sur la smantique d'excution.
L'implantation de l'objet
=> correspond au comportement de l'objet sur un systme => les activits ncessaires la ralisation du comportement de l'objet incluent le calcul du rsultat de la requte et la mise jour de l'tat du serveur. Le modle d'excution - Les donnes reprsentent un composant de l'tat du systme - le code des services demands qui permet de modifier l'tat du systme - un moteur d'excution est une machine abstraite qui peut interprter les mthodes. Il dfinit un contexte dynamique pour l'excution d'une mthode. le modle de construction Le systme objet doit fournir des mcanismes pour raliser les comportements des requtes. Ces mcanismes incluent les dfinitions des objets, des mthodes et aussi l'infrastructure des objets slectionne les mthodes excuter et la visibilit des donnes pour les mthodes. Il dcrit galement les oprations de cration et de destruction des objets.
CNAM-CEDRIC
-18-
L.Duchien
L'architecture de CORBA
a t structure pour permettre l'intgration et l'interoprabilit d'un grand nombre de systmes objets. permet l'change de messages via l'ORB et l'activation de mthodes d'objets
Client
Implmentation objet
requte
Object Resquest Brocker
l'ORB : localise l'objet serveur, gre le formatage des messages portant les requtes, leurs paramtres et les rsultats, gre le retour du rsultat au client. Contrle aussi l'intgrit du systme
CNAM-CEDRIC
-19-
L.Duchien
Structure de l'interface de l'ORB
Client
Implmentation objet
Rfrentiels Invocation d'interface dynamique
Talons IDL
Interface ORB
Squelettes Rfrentiels Adaptateur d'implentations IDL d'objet
Object Resquest Brocker Noyau ORB

Interface indentique pour toutes les implantation d'ORB Il peut y avoir de multiples adaptateurs d'objets Il y a des talons et un squelette pour chaque type d'objet Interface dependant de l'ORB Interface normal d'appel Interface d'appel "montant" (call-up)
Pour raliser une requte, le client utilise l'interface d'invocation dynamique (la mme que pour l'objet cible) ou un talon IDL. Le client peut aussi agir directement avec l'ORB pour quelques fonctions (retrouver la rfrence d'un objet par exemple). L'implmentation de l'objet reoit une requte comme un appel travers l'IDL gnr par le squelette. L'implmentation peut aussi utiliser l'adaptateur d'objet et l'ORB.
CNAM-CEDRIC
-20-
L.Duchien
Le client
Le client est client par rapport un objet spcifique. L'implantation d'un objet peut tre client d'autres objets Le client demande l'excution d'une requte en ayant la rfrence de l'objet et l'opration souhaite Le client initialise la requte en appelant les primitives des talons spcifique un objet (Interface IDL) ou en construisant la requte de manire dynamique. Le client voit la mme interface sans savoir o est l'objet et sans connatre le langage de programmation utilis pour l'implantation de l'objet. Les clients sont portables autant que possible. Le client n'a aucune connaissance sur l'implantation de l'objet, sur l'ORB utilis, sur l'adaptateur d'objet utilis.
CNAM-CEDRIC
-21-
L.Duchien
L'implantation objet ct client

L'interface d'un objet peut tre dfini de deux manires : - statiquement Par l'utilisation d'un Langage de Dfinition d'Interface (IDL) qui dfinit : - les types d'objets, - les paramtres des oprations Proche du langage C++. Aprs l'tape de compilation, les programmes sont figs. - dynamiquement Les requtes sont spcifies l'excution sans faire appel aux interfaces pr-dfinies. Le client prcise dans sa requte : - l'objet auquel il doit accder - l'opration raliser - les paramtres de l'opration Le client est responsable de la spcification des paramtres et des rsultats attendus. Ces informations sont communiques par le rfrentiel d'interface (Interface Repository service) qui contient : - Les descriptions des classes enregistres - Les mthodes et paramtres des classes Les deux manires sont smantiquement quivalentes.
CNAM-CEDRIC
-22-
L.Duchien
L'implantation objet
L'implantation objet fournit la smantique de l'objet dfinie par l'instance de l'objet et le code des mthodes de l'objet. Plusieurs implantations d'objets peuvent tre supportes, en incluant des serveurs spars, des librairies, un programme par mthode, une application encapsule, une base de donnes oriente-objet,... Gnralement les implantations d'objets ne dpendent pas de l'ORB ou de la manire dont le client invoque l'objet. L'implantation peut slectionner les interfaces de services dpendant des ORB par le choix de l'adaptateur de l'objet. Les implantations d'objet sont portables travers tout ORB qui supporte le langage souhait et qui implante l'adaptateur d'objet.
La rfrence d'objet
La rfrence d'un objet est l'information ncessaire pour spcifier et dsigner un objet avec un ORB. Client et implantations d'objet ont une vision de cette rfrence travers le langage de liaison. Deux implantations d'ORB peuvent diffrer par leur choix de la reprsentation des rfrences des objets. La reprsentation d'une rfrence d'un objet utilis par un client n'est valide que pendant la "vie" de ce client. Tous les ORBs doivent fournir le mme langage de liaison pour une rfrence d'objet pour un langage particulier de programmation.
CNAM-CEDRIC
-23-
L.Duchien
Le talon IDL ct client

Fournit les interfaces statiques des services d'objets. Ces talons pr-compils dfinissent comment les clients invoquent les services correspondants sur les serveurs. Du point de vue du client, le talon se comporte comme s'il s'agissait d'un appel local = > C'est un mandataire pour un serveur d'objet distant. Les services sont dfinis en utilisant l'IDL, et les talons du client et du serveur sont gnrs par le compilateur IDL Le client doit avoir un talon IDL pour chaque interface qu'il utilise sur le serveur. Le talon contient le code pour excuter l'opration "d'empaquetage" (codage et dcodage du nom de l'opration, des paramtres et des valeurs) Les talons prsentent un accs des oprations dans un IDL dfini pour un objet de manire unifie de faon ce que ce soit facile pour un programmeur familiaris avec l'IDL et le langage de prdire la smantique Si il a plusieurs ORBs disponibles, il peut y avoir diffrents talons correspondant ces diffrents ORBs.
CNAM-CEDRIC
-24-
L.Duchien
L'interface d'invocation dynamique (DII)

Permet de faire la construction d'invocations dynamiques au moment de l'excution Corba dfinit des APIs standards pour regarder les donnes mta qui dfinissent l'interface du serveur, gnrant les paramtres, faisant l'appel de mthodes et traitant le rsultat Le client spcifie l'objet qui est invoqu, l'opration excuter, l'ensemble des paramtres pour l'opration par un appel ou une squence d'appel; L'interface de l'invocation dynamique peut beaucoup varier d'un langage l'autre
L'API du rfrentiel d'interface

Permet l'obtention et la modification des descriptions de toutes les interfaces des objets enregistrs, les mthodes supportes et les paramtres. Corba appelle ces descriptions : signature de mthode Le rfrentiel d'interface est une base de donnes qui contient des versions d'interface en IDL dfinies des machines accessibles, Les APIs permettent aux objets d'accder, de stocker, et de mettre jour ces informations de manire dynamique.
CNAM-CEDRIC
-25-
L.Duchien
L'interface ORB
Consiste en quelques APIs de services locaux qui peuvent intresss une application. Par exemple, CORBA fournit le moyen de convertir une rfrence d'objet en une chane de caractres. C'est la mme pour tous les ORB et ne dpend pas de l'interface de l'objet ou de l'adaptateur de l'objet Parce que la plupart des fonctionnalits de l'ORB sont fournies par l'intermdiaire de l'adaptateur de l'objet, des talons, des squelettes, de l'invocation dynamique, il y a trs peu d'oprations Ces oprations sont utiles la fois aux client et aux implantations d'objets.
CNAM-CEDRIC
-26-
L.Duchien
Le bus ORB (Object Request Broker core)(1)

L'ORB est responsable de : - des mcanismes pour trouver l'implantation de l'objet pour la requte demande - de prparer l'implantation de l'objet pour recevoir la requte - de communiquer les donnes de la requte Il s'agit d'un mcanisme par lequel un applicatif client accde des classes serveurs. Les actions de l'ORB : - Localisation de l'objet invoqu par le client, - Transmission des paramtres de la requte - Transfert du contrle l'implmentation de l'interface travers le squelette d'IDL. - Une fois la requte termine, retour des rsultats au client.
CNAM-CEDRIC
-27-
L.Duchien
Le bus ORB (Object Request Broker core)(2)

L'ORB n'est pas implment par un seul composant, mais est dfini par rapport ces interfaces. Toute implantation ORB qui fournit une interface approprie est acceptable. Les interfaces sont organises en trois catgories : - les oprations qui sont les mmes pour toutes les implmentations d'ORB. - les oprations qui sont spcifiques pour des types particuliers d'objets, - les oprations qui sont spcifiques pour des styles particuliers d'implmentations d'objets Diffrents ORBs peuvent avoir des choix d'implantations diffrents et fournir un ensemble de services aux clients et d'implantations d'objets qui ont des proprits et des qualits diffrentes. =>Corba est conu pour supporter une reprsentation de base des objets et des requtes de communication qui peut tre diffrente selon les implantations d'ORBs. => Ce sont les interfaces qui sont censes masquer les diffrences
CNAM-CEDRIC
-28-
L.Duchien
Les talons IDL du serveur (skeleton)

Fournit les interfaces statiques de chaque service export par le serveur. Ces talons, comme ceux du client, sont crs en utilisant un compilateur d'IDL. L'interface est en gnral une interface "up-call" L'ORB les appelle travers le squelette L'existence d'un squelette n'implique pas l'existence du talon client correspondant (utilisation de l'interface dynamique pour le client)
CNAM-CEDRIC
-29-
L.Duchien
L'interface dynamique (squelette dynamique) (DSI)

Introduit dans CORBA 2.0 Fournit un mcanisme de liaison dynamique pour les serveurs ayant besoin de grer des appels de mthodes entrant pour des objets n'ayant pas de squelettes compils(ou talons) Le squelette dynamique regarde la valeurs des paramtres dans le message entrant pour voir qui est destin le message : dtermination de l'objet et de la mthode cible Ces squelettes dynamiques sont trs utiles dans le cadre d'implantation de ponts gnriques entre des ORBs. Peuvent aussi tre utiliss par des interprteurs et des langages de script pour gnrer dynamiquement des implmentations d'objets le DSI est l'quivalent au DII
CNAM-CEDRIC
-30-
L.Duchien
L'adaptateur d'objet
Un adaptateur d'objet est un moyen permettant l'implantation d'objet d'accder aux services fournis par l'ORB. On espre qu'il y aura peu d'adaptateurs d'objet, largement diffuss, avec des interfaces qui sont appropris pour des types spcifiques d'objets.
Implmentation objet
ID 6: appel de mthode Talon interface A Talon interfaceB ID 1 : Enregistrement de nouvelles classes ID 3:Rfrences d'objets Rfrentiel d'implementation Adaptateur d'objet 2: Instantiation de nouveaux objets
5: Gestion des requtes clientes entrantes
4: Services de diffusion
Ses fonctions : gnre et interprte les rfrences d'objets gre les invocation de mthodes gre la scurit des interactions active et dsactive l'implantation des objets gre la correspondance entre les rfrences d'objet et leur implantations enregistre les implantations
Souvent l'ORB fournira l'ensemble de ces services. Si ce n'est pas le cas, l'adaptateur d'objet fournit une interface vers lui. Dans le cas contraire, l'OA doit l'implanter. La spcification de CORBA dfinit l'adaptateur de base. D'autres adaptateurs devraient apparatre bientt. La grande varit de granularit des objets, de la politique de gestion des objets, du style d'implantation rend difficile la fourniture d'une simple interface qui soit pratique et efficace pour tous les objets
CNAM-CEDRIC
-32-
L.Duchien
Diffrents adaptateurs d'objets
- Un BOA pour serveur partag : Des objets multiples peuvent rsider sur le mme processus. Le BOA active le processus serveur la premire fois qu'une requte est excute sur un objet. Toutes les requtes suivantes de l'objet sont alors dlivres ce processus serveur. Un serveur gre alors une requte la fois
Processus
Le premier appel est trait les autres attendent Talon interface A Talon interfaceB
Application
Adaptateur d'objet de base (BAO)
CNAM-CEDRIC
-33-
L.Duchien
- Un BOA pour serveur non partag : - Chaque objet rside dans un processus serveur diffrent. - Un nouveau serveur est activ la premire requte sur l'objet - Un nouveau serveur est dmarr quand une requte est effectue pour un objet qui n'est pas encore actif, mme si un serveur d'un autre objet avec la mme implmentation est actif. Processus Processus
Application
Processus Processus
Talon interface A Talon interfaceB
CNAM-CEDRIC
-34-
L.Duchien
- Un BOA avec un serveur par mthode : - Un nouveau serveur est dmarr chaque fois qu'une requte est appele - Le serveur est actif pendant seulement la dure de la mthode - Plusieurs serveurs par objet et mme plusieurs serveurs par mthode Processus Processus
Application
Talon interface A
Talon interfaceB
CNAM-CEDRIC
-35-
L.Duchien
- Un BOA avec serveur persistant : - Les serveurs sont activs en dehors de l'adaptateur, - Un BOA peut dmarrer l'application serveur qui notifie le BOA qu'elle est prte accepter le travail - Le BOA envoie les activations un seul processus : l'ordonnanceur
Processus Processus Processus

Application
Ordonnanceur
Talon interface A Talon interfaceB
CNAM-CEDRIC
-36-
L.Duchien
Rfrentiels des interfaces et des implantations

Fournit un rfrentiel d'information propos des classes qu'un serveur supporte, les objets qui sont instancis et leurs IDs. Sert aussi de place commune pour sauvegarder des informations additionnelles avec l'implmentation des ORBs (information de trace, scurit, informations administratives Il permet pour un programme l'utilisation d'un objet, dont l'interface n'tait pas connue au moment de la compilation, d'tre capable de dterminer quelles sont les oprations valides sur l'objet et de raliser une invocation sur elles. Il fournit galement des informations stockes pour raliser le contrle de type des signatures des requtes, des librairies de talons ou de squelettes, des primitives qui peuvent traiter un type particulier d'objets, des infos pour du debug,.... Le rfrentiel d'implantation contient des informations qui permettent l'ORB de localiser et d'activer l'implantation des objets. Bien que ce soit trs souvent spcifique un ORB ou aux environnements d'exploitation accueillant les objets, il s'agit du lieu o sont stockes les informations d'implantation, de politique d'utilisation, d'activation,.... On y stocke aussi les infos pour du debug, du contrle d'administration, d'allocation de ressource, de scurit,...
CNAM-CEDRIC
-37-
L.Duchien
L'interface d'ORB cot serveur

Correspond un ensemble d'APIs pour des services locaux qui sont identique au ct client.
CNAM-CEDRIC
-38-
L.Duchien
Le serveur
Doit fournir la smantique de l'objet Dfinir les donnes pour l'implantation Dfinir le code pour les mthodes de l'objet Peut utiliser d'autres objets ( et ventuellement retourner des rfrences vers d'autres objets) Ou peut manipuler d'autres logiciels qui ne sont pas euxmmes des objets.
CNAM-CEDRIC
-39-
L.Duchien
L'implantation ct serveur
Squelette IDL (IDL Skeleton) ou Souche serveur Dfinition des mthodes de l'implantation L'adaptateur d'objet Mcanisme de mise en oeuvre de l'application serveur - gnration et interprtation des rfrences d'objets - prise en compte des appels clients et routage vers les mthodes appropries - diffusion des services disponibles sur l'ORB Utilisation d'une base de donnes de mise en oeuvre (rfrentiel d'implmentation) qui contient des informations sur les classes serveurs et les objets instancis.
Dfinitions d'IDL Intallation d'implantation
Rfrentiel d'interface
Talons
Squelette
Rfrentiel d'implantation
Client
Implantation d'objet
CNAM-CEDRIC
-40-
L.Duchien
L'invocation de mthodes
Solution 1 : l'accs statique
Phase 1 Ecriture du fichier IDL
Phase 2 Prcompilation
Gnration des squelettes Phase 3 Adjonction du code de mise en oeuvre
Phase 4 Compilation instanciaton Souche Client Phase 5 Rfrenciel d'interface Souche serveur Implantation objet
Phase 6 Adapteur d'objets
Phase 7 Rfrenciel d'implantation
CNAM-CEDRIC
-41-
L.Duchien
Phase 1:
Description IDL de l'interface du type programmer
. types d'objet . Attributs . Mthodes . Paramtres fournir
Phase 2 : Phase 3 : Phase 4 :
Prcompilation du fichier IDL
Cration des squelettes C d'implantation des classes serveurs Ajout par le dveloppeur du code de mise en oeuvre des mthodes dans les squelettes. Cration des classes serveurs. Compilation du code source rsultant et gnration de 4 fichiers: . fichier d'importation qui dcrit les objets pour une interface de rfrentiel . talon Client pour les mthodes dfinies en IDL. Ces talons sont invoqus par un programme client . talon Serveur qui appelle les mthodes sur le serveur . Code d'implantation des classes serveurs
Phase 5 :
liaison des dfinitions de classes avec le rfrentiel d'interfaces : utilisation d'un utilitaire pour lier les informations de l'IDL dans un rfrentiel d'interface.
Phase 6 : Phase 7 :
Instantiation des objets sur le serveurs (par l'intermdiaire de l'adaptateur d'objets) Enregistrement des objets excutables dans le rfrentiel d'implantation
- facile programmer - fournit un contrle de type
CNAM-CEDRIC
-42-
L.Duchien
Solution 2 : l'accs dynamique Phase 1 :

Obtention d'une mthode dans le rfrentiel d'interface
->lookup_name() -- appel de mthodes d'objets de localisation et description -> describe() -- permet l'obtention d'une description complte de l'IDL
Phase 2 :
Cration d'une liste d'arguments avec les paramtres passer
Cration d'une structure de donnes pour le passage de paramtres appele NameValuelist et avec autant d'appels add_args que ncessaire. -> create_list() -> add_arg()...add_arg()...add_arg()...
Phase 3 :
Cration de la requte avec :
- la rfrence de l'objet - le nom de la mthode invoquer - la liste d'arguments create_request(ObjectReference, Method,ArgumentList)
Phase 4 : Appel de la requte :

3 moyens pour effectuer l'invocation distance - en utilisant un RPC : invoke() - en utilisant le mode asynchrone : send() et get_response() - en appel asynchrone simple : send()
- plus flexible - permet d'ajouter des nouvelles classes au systme sans changement dans le code du client - criture de code gnrique avec des API dynamiques
CNAM-CEDRIC
-43-
L.Duchien
Quelques exemples d'ORBs

Il existe un grand nombre d'implantations d'ORB possible avec la spcification de CORBA: - ORB avec un client et une implantation rsidents S'il existe un mcanisme de communication qui convient, un ORB peut tre implanter avec les primitives rsidentes dans le client et l'implantation On utilise les IPC locaux ou les accs directs un service pour tablie les communications avec les implantations. - ORB bas sur un ou + serveurs Pour centraliser la gestion de l'ORB, tous les clients et les implantations peuvent communiquer avec un ou plusieurs serveurs dont le travail est de router les demandes venant des clients vers les implantations. - ORB bas sur le systme Pour assurer la scurit, la performance ou une certaine robustesse, l'ORB peut tre fourni comme un simple service de base du systme d'exploitation. - ORB bas sur les librairies Pour des objets dont les implantations peuvent tre partages, l'implantation peuvent tre dans une librairie. Dans ce cas les talons pourront tre les mthodes relles. Il faut assumer le fait qu'il est possible pour un programme client d'accder aux donnes des objets et que l'implantation demande aux client de ne pas endommager les donnes...
CNAM-CEDRIC
-44-
L.Duchien
L'interoprabilit
L'apport de Corba 2.0 est la spcification d'un protocole obligatoire : Internet Inter-ORB Protocol (IIOP) L'IIOP est bas sur TCP/IP et correspond un protocole d'change qui sert de "backbone". Tout ORB qui dit respect les normes CORBA doit soit implment de manire native l'IIOP ou une passerelle vers un IIOP Corba IDL
Protocole Inter-Orb gnral (GIOP) protocole Autres Inter_ORB exemples Internet OSI et (IIOP) IPX/SPX TCP/IP Protocoles Inter-ORB pour des environnements spcifiques (ESIOP) DCE/ESIOP DCE RPC DCE RPC au dessus au dessus de TCP/IP de l'OSI Smantique des requtes d'objets Syntaxe de transfert et messages
Transports
CNAM-CEDRIC
-45-
L.Duchien
- GIOP : correspond un ensemble de formats de messages et de reprsentation de donnes pour la communication entre ORBs. - a t construit pour les interactions entre ORBs - il doit travailler directement au-dessus de n'importe quel protocole de transport en mode connect - 7 formats de message pour couvrir les diffrentes smantiques des appels et des rponses - La mode de reprsentation est CDR (Common Data Reprsentation. Il permet de coder les types dfinis dans les IDL en une reprsentation de message plat transportable travers le rseau - IIOP : spcifie comment les messages GIOP sont changs au-dessus de TCP/IP - ESIOPs (Protocoles Inter_ORB pour des environnements spcifiques) : sont utiliss pour des interoprabilit avec des rseaux spcifiques. - DCE est le premier des ESIOP tre oprationnel
CNAM-CEDRIC
-46-
L.Duchien
Les ponts entre ORBs

- Ponts complets Client Serveur
Pont complet DSI ORB A - ORB fdrs :
DII ORB B
- on utilise des ponts inter-ORB et des IIOPs pour crer des topologies trs flexibles
ORB Backbone (DCE/ESIOP) ORB A ORB B
ORB Backbone (IIOP) ORB C ORB D
CNAM-CEDRIC
-47-
L.Duchien
L'IDL (langage de dfinition d'interface)

dfinit les types d'objet par spcification des interfaces; Une interface consiste en un ensemble d'oprations nommes et des paramtres sur ces oprations. l'IDL est le moyen par lequel un objet particulier indique ses clients potentiels les oprations disponibles et comment les invoquer. C'est un langage neutre et totalement dclaratif A partir des dfinitions d'IDL, il est possible de mettre en correspondance les objets CORBA dans un langage de programmation particulier ou avec des objets systmes.
CNAM-CEDRIC
-48-
L.Duchien
La structure de l'IDL CORBA
module <identifier> /*dfinition d'un contexte nomm*/ { <type declarations>; <constant declarations>; <exception declarations>; interface <identitifier> [:<inheritance>] /* definition d'une classe CORBA*/ { <type declarations>; <constant declarations> <attribute declarations> <exception declarations> [<op_type>] <identifier>(<parameters>) [raises exception][context]; /*dfinition d'une mthode*/ .... [<op_type>] <identifier>(<parameters>) [raises exception][context]; } interface <identifier>[<:inheritance>] ... }
CNAM-CEDRIC
-49-
L.Duchien
Un exemple d'IDL
module Mes_Animaux; { /* dfinition de la classe Chien */ interface Chien : animal_de_compagnie, animal; { attribute integer age; exception Non_Interesse {string explication); void aboie (in short combien_de_temps) raises (Non_Interesse ); void assis (in string ou) raises (Non_Interesse ); void grogne (in string apres_qui) raises (Non_Interesse ); } /* Dfinition de la classe chat */ interface Cat : animal; { void Eat(); void Viens(); } } /* fin de Mes_animaux */
CNAM-CEDRIC
-50-
L.Duchien
Le langage de dfinition de l'interface(IDL) de CORBA

C++ Types des IDL
. Entier : long (32 bits), short (16 bits), unsigned long, unsigned short . Rel : float (32 bits), double (64 bits) . Caractres : char (8 bits) . Boolen : boolean . Octet : octet (8 bits, sans conversion) . n'importe quoi : any (permet n'importe quel type d'IDL) . Structures : struct . Unions: union . Enumeration : enum . Sequence : sequence . Strings : string (chaine de caractres) . Typedefs
L'interface objet dfini en accord avec les types de base

. Attributes . Methodes
Le prprocesseur C++ des IDL

. La substitution de macro . La compilation conditionnelle . Inclusion de fichiers sources
Les commentaires, les dclarations diffres, les constantes de C++ Les exceptions
. Les exceptions systmes . Les exceptions dfinies dans l'implantation objet
Les types de mthodes

. normal . en cas de panne : smantique au plus une fois . sans panne : smantique exactement une fois . un seul sens . le mieux possible
CNAM-CEDRIC
-51-
L.Duchien
L'IDL et l'hritage
L'hritage d'une interface par une autre interface Possibilit d'hritage multiple Il est illgal d'hriter de deux interfaces avec le mme nom d'opration ou d'attribut. Il est aussi illgal de redfinir un nom d'opration ou d'attribut dans l'interface driv Il est lgal de redfinir un type, une constante, une exception dans une interface drive. Lgal
Interface A {...} Interface B : A {...} Interface C : A {...} Interface D : B , C {...}
A B D C
CNAM-CEDRIC
-52-
L.Duchien
Exemples IDL et DII (Dynamic Invocation Interface)

//IDL interface foo { string op1(in long x, inout float y, out string x); }; // Client C++/IDL (Orbix/INS bindings) char *result; long x; float y; char *z; foo *myFoo; myFoo=foo::_bind();// Bind to any "foo" on the network result = myFoo->op1(x, y, z); // Client C++/DII (Orbix bindings) CORBA::ObjectRef target = CORBA::Object::_bind("foo"); CORBA::Request r(target, "op1"); r << x << CORBA::inOUtMode << y << CORBA::outMode << z; r.invoke(); r >> result; // C++ Object Implementation (Orbix) class foo_impl : public fooBOAImpl { public: virtual char *op1(long x, float &y, char &*z, CORBA::Environment &env); } char * foo_impl::op1(long x,float &y,char &*z,CORBA::Environment &) { y = (x+y) * .5; z = new char[30]; strcpy(z, "hello"); return(z); } main() { foo_impl obj; CORBA::Orbix.impl_is_ready("foo"); }
Le rfrentiel d'interface Corba 2.0

fdration possible de rfrentiels d'interface qui cooprent travers les ORBs en maintenant l'autonomie des administrateurs locaux Deux caractristiques supplmentaires : - un ensemble de nouvelles mthodes pour mettre jour de manire incrmentale les contenus des rfrentiels l'excution - des identificateurs de rfrentiels uniques et globaux utiliser dans l'espace de noms rparti Dfinition : C'est une base de donnes en ligne de dfinitions d'objets. Les dfinitions d'objets sont fournis par les compilateurs d'IDL ou travers les fonctions d'criture des rfrentiels d'interface. La spcification CORBA ne dcrit pas l'organisation et la recherche d'information dans le rfrentiel, mais dfinit un ensemble de classes dont les instances reprsentent l'information qui sont dans le rfrentiel.
A quoi sert le rfrentiel d'interface : - permet l'ORB de comprendre la dfinition des objets sur lequel il travail par accs dynamique aux dfinitions : - fournit un contrle de type des signatures de mthodes - aide les ORB se connecter entre eux - fournit des informations meta aux client et aux outils - fournit la propre description des objets.
CNAM-CEDRIC
-54-
L.Duchien
Les classes du rfrentiel d'interface

Le rfrentiel d'interface est implment sous forme d'un ensemble d'objets persistants CORBA groupe ses mta-donnes dans des modules qui reprsentent des espaces de noms CORBA dfinit une interface pour chacune de ses 8 structures IDL :
Repository
ConstantDef TypeDef ModuleDef ExceptionDef InterfaceDef
ConstantDef
TypeDef
ExceptionDef
ModuleDef
InterfaceDef OperationDef
ConstantDef TypeDef ExceptionDef AttributeDef
ParametreDef
ExceptionDef
CNAM-CEDRIC
-55-
L.Duchien
Les services CORBA : le nommage

le service de noms : les pages blanches de l'annuaire => permet de localiser un objet partir de son nom Nom : forme facilement reconnaissable par un humain. Le service de nommage fait l'association entre le nom et la rfrence de l'objet. Cette opration est appele la liaisons de noms (namebinding) Un contexte de nommage est un espace de noms dans lequel les noms des objets sont uniques. Chaque objet a une rfrence unique (un ID). Mais on peut associer optionnellement un ou plusieurs noms une rfrence d'objet. Le service encapsule de manire transparente les services d'annuaires existants comme X500, DNS, NIS+, CDS. Utilisation d'une hirarchie o le client navigue travers diffrents arbres de contexte de nommage
CNAM-CEDRIC
-56-
L.Duchien
Annuaire Global Vacances
Mexique
Grce
Hawaii
Hyatt
Rpertoire Club Med Club Med Ixtapa Cancun Playa Blanca
- Un nom simple : Playa Blanca - Un nom compos : un nom simple + des contextes Playa Blanca + Club Med, Mexico, Vacances - Chaque objet a une structure avec deux attributs : - l'identifieur : la chane de caractres - type : une chane dans laquelle on a un attribut de description pour le nom (exemple type fichier)
CNAM-CEDRIC
-57-
L.Duchien
L'interface du service de nommage

Interface NamingContext /* liaison de nom objet avec nom unique*/ resolve() /* trouve un objet li un nom dans un contexte donn */ list() /* permet d'itrer la demande sur un ensemble de noms*/ destroy() /* efface le contexte nomm*/ new_context() /* retourne le nom du contexte*/ bind() /* associe un nom d'objet un contexte de liaison */ rebind() bind_context() rebind_context() bind_new_context() Interface BindingIterator next_one() /* permet d'itrer sur un objet BindingIterator */ next_n() /* mme chose */ destroy() /* permet de librer l'itration*/
CNAM-CEDRIC
-58-
L.Duchien
Le service de courtier (trader)

=> correspond aux pages jaunes de l'annuaire Le standard n'est pas encore stabilis (fin de l'anne 96 ?) Permet un nouveau service de s'enregistrer par l'intermdiaire du courtier. Le fournisseur de service donnera entre autres les informations suivantes : - Une rfrence d'objet : C'est la rfrence que les clients utilisent pour se connecter au service voulu et pour invoquer les oprations - Une description du type de service offert Le courtier stocke ces informations de manire permanente. Le client utilise le courtier pour retrouver la liste des services ou pour demander un service par type Le courtier doit retrouver la meilleure rponse pour le client en fonction du contexte et des offres des fournisseurs Les courtiers de diffrents domaines peuvent crer des fdrations avec des politiques de gestion et de scurit.
CNAM-CEDRIC
-59-
L.Duchien
Les services CORBA : le cycle de vie

Fournit les oprations de cration, de destruction, de dplacement, de copie des objets Ces services ont t tendus la notion de groupe d'objets Un exemple de cycle de vie
In Objet dossier Rfrence
Objet page Objet texte Objet multimedia Objet document
Objet catalogue
Le cycle de vie maintient un graphe de l'ensemble de ces associations Un dplacement du document vers un autre dossier fera en sorte que tous les objets dpendants (les pages et leur contenu, les rfrences) soient galement dplacs vers le dossier cible
CNAM-CEDRIC
-60-
L.Duchien
Les interfaces du cycle de vie

Les services du cycle de vie travaillent la fois sur les objets eux-mmes et leurs relations entre-eux. Pour crer un nouvel objet, un client doit trouver un objet "factory" (c'est un objet qui sait comment instancier un objet de cette classe). Par cet objet factory, la demande cration est effectue et il y retour d'une rfrence d'objet. On peut aussi crer des clones d'objet par copie L'objet "factory" doit allouer des ressources, obtenir les rfrences et enregistrer les nouveaux objets auprs de l'adaptateur d'objet et des rfrentiels d'implantation. Les interfaces :
FactoryFinder { find_factories(); } GenericFactory { create_objetc() } LiveCycleObjext { copy(); move(); remove() }
Il existe des addendum rcents pour supporter les gestion de structures avec des accs sur des noeuds, des rle ou des relations
Les services CORBA : les vnements

Permet des objets d'enregistrer ou de retirer dynamiquement leur intrt pour des vnements Un vnement est une occurrence spcifie pour avoir un intrt quelconque pour un ou plusieurs objets Une notification est un message qu'un objet envoie vers les parties intresses pour les informer qu'un vnement spcifique est arriv. L'objet qui gnre l'vnement ne connat pas les objets intresss par cet vnement => C'est le rle de ce service de trouver les objets qui faire part de l'vnement. Le service vnement cre un canal de communication faiblement coupl entre les objets. Deux rles - les fournisseurs : produisent des vnements - les consommateurs : reoivent et traitent les vnements Deux modles de communication - Un modle "push" : le fournisseur prend l'initiative et initialise le transfert des donnes de l'vnement vers le consommateur - Un modle "pull" : le consommateur prend l'initiative et demande le transfert des donnes de l'vnement au fournisseur. Un canal vnement est un objet intervenant entre du consommateur et du fournisseur d'vnement
CNAM-CEDRIC
-62-
L.Duchien
Les services CORBA : les transactions

L'un des services les plus important de CORBA et le plus difficile mettre en oeuvre... L'ORB deviendra la prochaine gnration de moniteur TP... Les caractristiques des services de transactions objet : - supportent les transactions plates et embotes - permettent aux applications ORB et non ORB de participer une mme transaction ( condition d'adopter le standard X/OPEN DTP) - supportent des transactions qui recouvrent des ORBs htrognes. Des objets sur de multiples ORBs peuvent participer une seule transaction. - supportent des interfaces IDL existants: une simple interface supportent des implmentations transactionnelles et non transactionnelles. => Pour faire un objet transactionnel, on utilise une interface ordinaire qui hrite de la classe abstraite OTS
CNAM-CEDRIC
-63-
L.Duchien
Les lments du service transactionnel

le client transactionnel - correspond un ensemble d'invocations de mthodes qui sont dlimites par des marques de dbut et fin de transactions, - l'ORB intercepte le dbut de transaction et le dirige vers le service transactionnel. - l'ORB fait galement suivre vers le service transactionnel lorsque le client valide ou abandonne la transaction. - le client ne gre que le strict ncessaire : il dmarre la transaction, fait des invocations de mthodes, valide ou abandonne la transaction Le serveur transactionnel : - c'est un ensemble d'objets concerns par la transaction mais n'ayant pas d'tats rcuprables - l'ORB propage les contextes des transactions de manire implicite quand les objets appellent des ressources rcuprables. - le serveur transactionnel ne participe pas la terminaison de la transaction, mais il peut forcer une transaction abandonner Un serveur de recouvrement - c'est une collection d'objets dont les donnes sont affectes par la validation ou l'abandon d'une transaction - on utilise des objets qui permettent d'avoir un coordinateur pour orchestrer la transaction et un protocole de validation deux phases
Les services CORBA : la concurrence

Fournit des interfaces pour acqurir et relcher des verrous afin de permettre des clients multiples d'accder en concurrence des donnes partages, Supporte la fois le mode transactionnel et un mode non transactionnel a t conu pour tre utilis avec OTS pour coordonner les transactions Le service de contrle de concurrence et les transactions : un client pour acqurir des verrous doit choisir l'un des moyens suivants : - au nom d'un transaction : dans ce cas c'est le service de transaction qui gre le relchement des verrous lors de la validation ou de l'abandon de la transaction - au nom d'un client non transactionnel : la responsabilit du relchement des verrous est la charge du client. Les verrous : - un verrou est un jeton qu'un client dtient dans le but d'accder une ressource. - le rle est le partage de ressource et la gestion de conflits ventuels entre plusieurs clients. - il existe plusieurs modes de gestion selon diffrentes catgories d'accs: lire, crire, intention de lire, intention d'crire, lecture avec conflit sur soi-mme (pour prvenir les interblocages)
CNAM-CEDRIC
-65-
L.Duchien
ensemble de verrous - Le service de contrle ne dfinit pas la granularit des ressources qui sont verrouills. - il dfinit un "lockset" qui est une collection de verrous associs une seule ressource exemple : si un objet est une ressource, il doit crer de manire interne un lockset et le maintenir. - le service de contrle de concurrence dfinit un coordinateur de verrous qui gre le relchement de verrous.
CNAM-CEDRIC
-66-
L.Duchien
Les services CORBA : la persistance
Mmoire Objet vivant Objet vivant Sauve Restaure
Objet gel
Objet gel
Le temps de vie d'un objet peut tre infini Le service de persistance des objets (POS) permet de sauvegarder l'tat d'un objet sur une mmoire permanente. Le POS peut grer des objets spcialiss tels que des fichiers, des bases de donnes relationnelles, les bases de donnes objet, des documents composs,.... Le POS fournit une interface aux clients pour sauvegarder des objets sans qu'ils aient connatre les mcanismes de stockage.
CNAM-CEDRIC
-67-
L.Duchien
Sauvegarde un niveau contre la sauvegarde deux niveaux

- un seul niveau POS gre pour les bases de donnes objets un seul niveau de stockage. Dans ce cas, le client n'est pas conscient du fait que les donnes soient en mmoire ou sur disque. On a une un gros systme de stockage virtuel : mmoire et stockage persistant sont la mme chose. - deux niveaux POS gre pour les fichiers et les bases de donnes relationnelles un systme deux niveaux. La mmoire est alors spare du systme de stockage : l'objet doit passer explicitement de la mmoire au systme de sauvegarde.
CNAM-CEDRIC
-68-
L.Duchien
POS : La vue du client

POS offre aux clients le moyen de contrler la persistance des objets (s'ils le souhaitent) Il existe plusieurs niveaux de services : - systme de persistance compltement invisible pour l'usager - Utilisation de protocoles spcifiques de sauvegarde neuf oprations sur trois interfaces pour que le client puisse contrler la persistance
POS : La vue de l'objet persistant

L'objet persistant a en charge sa persistance. Il dcide quel protocole utiliser et quelle visibilit accorder aux clients. L'objet persistant peut aussi dlguer la gestion de sa persistance aux services sous-jacents de persistance. Le grain de contrle de persistance peut tre trs fin. L'objet persistant hrite, si besoin, des fonctions ncessaires la gestion de la persistance Au minimum il collabore avec les systmes de sauvegarde pour traduire son tat en lments que les services sousjacents peuvent grer.
CNAM-CEDRIC
-69-
L.Duchien
Les lments du POS
Application Cliente PO PO PO PO Objets persitants Gestionnaire d'objets persistants Services de donnes persistantes systmes de sauvegarde Bases de donnes SQL Bases de donnes objet Sauvegarde d'objets simples
Protocole
POM
Protocole
DDO
ODMG-93
DA
CNAM-CEDRIC
-70-
L.Duchien
Les objets persistants (POs) : - un objet peut-tre persistant par hritage de la classe PO. - il peut aussi tre persistant par hritage d'un mcanisme pour rendre externe son tat (via un protocole) Tout objet persistant a un identificateur persistant (PID) qui dcrit la localisation de l'objet (sur le systme de sauvegarde) Le gestionnaire d'objets persistants (POM) - C'est une interface indpendante de l'implmentation pour la persistance d'objets - le POM peut diriger les appels des PO vers le service appropri de persistance en examinant le PID de l'objet. - Il fournit une vue uniforme de la persistance au systme travers de multiples services de donnes Les services de persistance de donnes (PDSs) - Ce sont les interfaces des implmentations particulires des systmes de sauvegarde. - Ils effectuent le travail de dplacement des objets entre l'objet et le systme de sauvegarde - Tous ont une interface spcifie en IDL. - certains utilisent un protocole dpendant de l'implmentation Systme de sauvegarde ce sont les implmentations qui sauvent les objets persistants indpendamment de l'espace d'adressage contenu dans l'objet. Da : Attributs directs ODMG : Groupe de gestion des bases de donnes objet DDO : Objet de donnes dynamiques (bases de donnes relationnelles)
Des implantations CORBA

DEC ACA (AIX, VMS, Ultrix, MS Windows, Mac, Unix, HP-UX) HP ORB Plus &HP Distributed Smalltalk HyperDesk HD-DOMS (Sun, HP-UX, AIX,...) IBM SOM IONA Orbix (SunOS, Solaris, DOS, Windows, SGI) SuiteSoftware SuiteDome (VMS, Unix, PC) ExperSoft Xshell Sun DOE Tivoli Others (pas compltement Corba) : Electra, Isis, Cool, Oode,.... Il en sort 2 3 par mois.... Une source : http:// cui_www.unige.ch/Chloe.FAQ/OO-FAQ/oo-faq-toc.html#TOC
CNAM-CEDRIC
-72-
L.Duchien
Bibliographie
Corba 1.2 Specification http://www.acl.lanl.gov/sunrise/Objects/OMG/93-12-43.ps INS bindings : http://www.acl.lanl.gov/sunrise/Objects/OMG/93-11-6.ps CORBA 2.0 http://www.acl.lanl.gov/sunrise/Objects/OMG/93-11-6.ps
Livre : T. Mowbray, R.Zahavi, " The Essential Corba" OMG , Wiley, 1995 R. Orfali, D. Harkey, J. Edwards, "The essential Distributed Objects, Survival Guide", Wiley, 1996.
CNAM-CEDRIC
-73-
L.Duchien

Corba FR

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Corba FR

Transféré par

Droits d'auteur :

Formats disponibles

Le modle Objet de CORBA

Systmes et Applications Rpartis

Le modle Objet de OMG-CORBA

Le modle Objet de CORBA

Systmes et Applications Rpartis

Le modle Objet de CORBA

Systmes et Applications Rpartis 69 69 70 72 73

Le modle Objet de CORBA

Systmes et Applications Rpartis

L'OMG- Object Management Group

Cration de l'OMG 11 Membres

Publication de CORBA 1.1 200 membres Premire publication du guide OMA

390 Membres Publication de Dfinition des services CORBA 2.0 communs

ftp et http : omg.org

Le modle Objet de CORBA

Systmes et Applications Rpartis

Les objets distribus de CORBA

Le modle Objet de CORBA

Systmes et Applications Rpartis

Tout est dans l'IDL

IDL IDL IDL IDL IDL IDL Client ORB

IDL IDL IDL IDL IDL IDL Serveur

Le modle Objet de CORBA

Systmes et Applications Rpartis

Le modle Objet de CORBA

Systmes et Applications Rpartis

L'OMA : Object Management Architecture

Object Request Broker

Objets d'application Les objets de l'application de l'utilisateur

Le modle Objet de CORBA

Systmes et Applications Rpartis

L'ORB (Object Request Broker)

Le modle Objet de CORBA

Systmes et Applications Rpartis

Le modle Objet de CORBA

Systmes et Applications Rpartis

ORB Versus RPC

Client Call toto

Serveur code donnes excuter toto

Client invoquer toto sur l'objet X invoquer toto sur l'objet Y

Serveur Objet X Objet Y donnes donnes toto toto

Object Request Broker

Le modle Objet de CORBA

Systmes et Applications Rpartis

Les services objets

Le modle Objet de CORBA

Systmes et Applications Rpartis

Le modle Objet de CORBA

Systmes et Applications Rpartis

Les facilits communes

Le modle Objet de CORBA

Systmes et Applications Rpartis

Le Modle Objet pour CORBA

Le modle Objet de CORBA

Systmes et Applications Rpartis

Le modle Objet de CORBA

Systmes et Applications Rpartis

Le modle Objet de CORBA

Systmes et Applications Rpartis

Le modle Objet de CORBA

Systmes et Applications Rpartis

Object Resquest Brocker

Le modle Objet de CORBA