Cours 7 - CORBA/Partie 1 Claude Duvallet - Welcome...

Plan

La vision globale del’OMG

Le modèleClient/Serveur

L’architecture globale

Le bus à objetsrépartis CORBA

NFP111 — Systèmes et Applications Réparties 1 de 34

NFP111 — Systèmes et Applications RépartiesCours 7 - CORBA/Partie 1

Claude Duvallet

Université du HavreUFR Sciences et Techniques

25 rue Philippe Lebon - BP 54076058 LE HAVRE CEDEX

Courriel : [email protected]://litis.univ-lehavre.fr/∼duvallet/

Plan






Vision globale de la construction d’applicationsréparties (1/2)

L’Object Management Group (OMG) : un consortiuminternational crée en 1989.But : définir les spécifications d’architectures distribuées etouvertes :

Regroupe plus de 850 acteurs du monde informatique :des constructeurs (HP, IBM, Sun, ...)des producteurs logiciels (Netscape, Inprise/Borland, IONA,...)des utilisateurs (Bœing, Alcatel, ...)des institutions et des universités

Standards pour l’intégration d’applications distribuéeshétérogènes à partir des technologies orientées objets.

Plan






Vision globale de la construction d’applicationsréparties (2/2)

Les propriétés fontamentales :la réutilisabilitél’interopérabilitéla portabilité des objets logiciels

L’élément clef est CORBA (Common Object Request BrokerArchitecture) :

Middleware orienté objetPlus précisément, c’est un bus à objets répartis :

offre un support d’exécution masquant les couches bases dusystème répartis (système d’exploitation, processeur etréseau).prends en charge les communications entre les logicielsformant les applications réparties hétérogènes.

Plan






Le modèle objet Client/Serveur (1/5)

CORBA propose un modèle de coopération :Client/Serveur, Abstrait, Orienté objet.

Chaque application peut exporter :certaines de ses fonctionalités (services),sous la forme d’objets CORBA : c’est la composanted’abstraction (structuration) du modèle.

Les interactions entre applications :au moyen d’invocations à distance des méthodes des objets.

La notion de client/serveur n’intervient qu’uniquement lors del’utilisation d’un objet : l’application implantant l’objet est leserveur, l’application utilisant l’objet est le client.

Plan







Référencede l’objet

Requête

Bus CORBA

Interfacede l’objet

Coded’implantation

Etatde

l’objet

ApplicationServeur

ObjetCORBA

ApplicationCliente

Activation

Plan







Application cliente :programme qui invoque les méthodes des objets à travers lebus CORBA.

Référence de l’objet :structure désignant l’objet CORBA et contenant l’informationnécessaire pour le localiser sur le bus.

Interface de l’objet :type abstrait spécifiant l’objet par ses méthodes et sesattributs, se définit au moyen du langage IDL.

Requête :le mécanisme d’invocation d’une méthode ou d’un accès à unattribut de l’objet.

Plan







Bus CORBA :achemine les requêtes de l’application cliente vers l’objet enmasquant tous les problèmes d’hétérogénéité (langages,systèmes d’exploitation, matériels, réseaux).

Objet CORBA :objet logiciel cible (entité virtuelle gérée par le bus CORBA).

Activation :processus d’association d’un objet d’implantation à un objetCORBA.

Implantation :code de l’objet CORBA à un instant donné, gère un état del’objet temporaire. Au cours du temps, un même objetCORBA peut-être associé à des implantations différentes.

Plan







Code d’implantation :regroupe les traitements associés à l’implantation de l’objetCORBA. Par exemple, une classe Java ou un ensemble defonctions C.

Application serveur :structure d’accueil des objets d’implantation et des exécutionsdes opérations : un processus Unix par exemple.

Plan






L’architecture globale (1/4)

Cyclede vie

Nommage

Objetsapplicatifs

Spécifiques

Interfacesde domaine

Télécoms

Santé Finance

Télécoms

Utilitairescommuns

DataWare

Workflow Administration

IHM

ExternalisationLicence

Changements

TempsCollections

Persistance Concurrence

RelationsSécurité

Transations

Vendeur

Interrogations Propriétés Evénements

Services objet communs

Bus d’objets répartis

Plan







L’OMG propose une vision globale de la constructiond’applications réparties.Classifier les différents objets qui interviennent dans uneapplication en fonction de leurs rôles :

Le bus à objet répartis est l’élément fondamental :assure le transport des requêtes entre tous les objets CORBA,offre un environnement d’exécution masquant l’hétérogénéitéliée aux langages de programmation, aux systèmesd’exploitation, aux processeurs et aux protocoles réseaux.

Plan







Les services objets communs (CORBAservices)Fournissent sous formes d’objets CORBA, spécifiés grâce aulangage IDL, les fonctions systèmes nécessaires à la plupartdes applications réparties.L’OMG a défini des services pour les annuaires, le cycle devie des objets, les relations entre les objets, les événements,les transactions, la sécurité, la persistance, etc.Au fur et à mesure des besoins, l’OMG ajoute des nouveauxservices communs.

Les utilitaires communs (CORBAfacilities) :Ils sont des canevas d’objets ou frameworks qui répondentplus particulièrement aux besoins des utilisateurs.Ils standardisent l’interface utilisateur, la gestion del’information, l’administration, le workflow, ...

Plan







Les interfaces de domaines (Domain Interfaces) :Définissent des objets métiers spécifiques à des domainesd’activité : par exemple la finance, la santé (dossier médical)ou les télécoms.Leur objectif est d’assurer l’interopérabilité sémantique entreles systèmes d’informations d’entreprises d’un même métier(« Business Object Framework » = BOFs).

Les objets applicatifs (Application Objects) :Spécifiques à une application, ils ne sont donc passtandardisés.Toutefois, dès que le rôle de ces objets apparaît dans plusd’une application, ils peuvent alors rentrer dans une descatégories précédentes et donc être standardisés par l’OMG.

Plan






Caractéristiques du bus à objets répartis CORBA(1/2)

Le bus CORBA est un intermédiaire à travers lesquels lesobjets vont pouvoir dialoguer :

Liaison avec les langages de programmation : C, C++, JAVA,SmallTalk, Ada, COBOL, etc.Transparences des invocations :

les requêtes aux objets semblent toujours être locales,le bus CORBA se charge de les acheminer.

Invocation statique et dynamique : 2 mécanismes permettentde soumettre les requêtes aux objets

en statique, les invocations sont contrôlées à la compilation,en dynamique, les invocations doivent être contrôlées àl’exécution.

Plan






Caractéristiques du bus à objets répartis CORBA(2/2)

Système auto-descriptif :les interfaces des objets sont connues du bus et sont aussiaccessibles par les programmes par l’intermédiaires d’unréférentiel d’interfaces.

Activation automatique et transparente des objets :les objets sont en mémoire uniquement s’ils sont utilisés pardes applications clientes.

L’interopérabilité entre bus :à partir de la norme CORBA 2.0, définition d’un protocolegénérique de transport des requêtes (GIOP = GeneralInter-ORB Protocol) permettant l’interconnexion de busCORBA provenant de fournisseurs différents,une de ses instanciations est l’Internet Inter-ORB Protocol(IIOP) fonctionnant au dessus de TCP/IP.

Plan






Les composantes du BUS (1/3)

Object Request Broker

SII DII

Client Fournisseur

SSI DSI

RéférentielInterfaces IFR

InterfaceBUS Adaptateur d’Objets OA

RéférentielImplantations ImpIR

Plan






Les composantes du BUS (2/3)

ORB (Object Request Broker) : noyau de transport desrequêtes

Intègre au minimum les protocoles de transport GIOP et IIOP.L’interface du BUS fournit les primitives de base commel’initialisation de l’ORB.

SII (Static Interface Invocation) : interface d’invocationstatique

permet de soumettre des requêtes contrôlées à la compilationdes programmes.

DII (Dynamic Interface Invocation) : interface d’invocationsdynamiques

permet de construire dynamiquement des requêtes versn’importe quel objet CORBA sans générer ou utiliser uneinterface SSI.

IR (Interface Repository) : référentiel des interfacescontient une représentation des interfaces OMG-IDLaccessibles par les applications durant l’exécution.

Plan






Les composantes du BUS (3/3)SSI (Skeleton Static Interface) : interface de squelettesstatiques

permettant à l’implantation des objets de recevoir lesrequêtes qui leur sont destinées.générée comme l’interface SII.

DSI (Dynamic Skeleton Interface) : interface de squelettesdynamiques

permet d’intercepter dynamiquement toute requête sansgénérer une interface SSI.équivalent à DII mais coté serveur.

OA (Object Adapter) : adaptateur d’objetscrée les objets CORBA.maintient les associations entre les objets CORBA et lesimplantations.réalise l’activation automatique si nécessaire

ImpIR (Implementation Repository) : référentiel desimplantations

contient l’information nécessaire à l’implantation.ce référentiel est spécifique à chaque application CORBA.

Plan






Construction d’un bus CORBA

Différentes approches peuvent être utilisées pour construireun bus :

1 bus = 1 processus : les objets sont dans le même espacemémoire que les clients. C’est le cas typique des applicationsembarquées.1 bus = 1 OS : les clients et les fournisseurs sont desprocessus différents sur la même machine.1 bus = 1 réseau : les processus sont sur des sites différentset les requêtes sont véhiculées à travers le réseau (Internetavec IIOP).

Fédération de bus CORBA :Plusieurs bus distincts peuvent être mis ensemble pourformer une fédération.Les communications entre ces bus peuvent se faire :

soit par le protocole commun IIOP,soit à travers des passerelles spécifiques ou génériques(Exemple : DII←→ DSI).

Plan






Les protocoles réseaux (1/2)

Tout bus à la norme CORBA 2.0 doit fournir les protocolesGIOP et IIOP.Le protocole GIOP définit :

une représentation commune des données (CDR ouCommon Data Representation).un format de références d’objet interopérable (IOR ouInteroperable Object Reference).un ensemble de messages de transport des requêtes auxobjets (Request Reply, ...).

GIOP est seulement un protocole générique, IIOP fournitalors une implantation de GIOP au dessus de TCP/IP.

Plan






Les protocoles réseaux (2/2)

Les IORs utilisés avec IIOP doivent contenir :Le nom complet de l’interface IDL de l’objet.L’adresse IP de la machine où est localisé l’objet.Le port IP pour se connecter au serveur de l’objet.Une clé pour désigner l’objet dans le serveur : son format estlibre et il est différent pour chaque implantation du busCORBA.

Un bus CORBA peut utiliser d’autres protocoles de transportdes requêtes aux objets :

bus multi-protocoles permettant d’avoir simultanément descommunications en IIOP, en UDP-IIOP et en multicast-IIOP.

Plan






Les services communs

Objectif : standardiser les interfaces desfonctions systèmes indispensables à laconstruction et à l’exécution de la majoritédes applications réparties.

Plan






La recherche d’objets

Offrir des mécanismes pour rechercher dynamiquement desobjets sur le BUS (équivalents à des annuairestéléphoniques)Nommage (Naming Service) est l’équivalent des « pagesblanches » :

les objets sont désignés par des noms symboliques. Cetannuaire est matérialisé par un graphe de répertoires dedésignation.

Vendeur (Trader Service) est l’équivalent des « pagesjaunes » :

les objets peuvent être recherchés en fonction de leurscaractéristiques/fonctionnalités.

Plan






Le cycle de vie des objets (1/4)

Cycle de Vie (Life Cycle Service) :Décrit des interfaces pour la création, la copie, ledéplacement et la destruction des objets sur le bus.Définit pour cela la notion unique de fabrique d’objets« Object Factory ».

Propriétés (Property Service) :Permet aux utilisateurs d’associer dynamiquement desvaleurs nommées à des objets.Ces propriétés ne modifient pas l’interface IDL maisreprésentent des besoins spécifiques aux clients (annotationsou méta-données par exemple).

Relations (Relationship Service) :Sert à gérer des associations dynamiques (appartenance,inclusion, références, auteur, etc.) reliant des objets sur leBUS.

Plan







Externalisation (Externalization Service) :Mécanisme standard pour fixer ou extraire des objets du bus.

Persistance (Persistent Object Service) :Stocker des objets sur un support persistant.Quel que soit le support utilisé ce service s’utilise de la mêmemanière via un « Persistent Object Manager ».Un objet persistant doit hériter de l’interface « PersistentObject » et d’un mécanisme d’externalisation.

Plan







Interrogation (Query Service) :Permet d’interroger les attributs d’un objet.Repose sur les langages standards d’interrogation (SQL 3 ouOQL).L’interface QUERY permet de manipuler les requêtes commedes objets CORBA.Les objets résultats sont enregistrés dans une collection.

Collections (Collection Service) :Permet de manipuler d’une manière uniforme des objets sousla forme de collections et d’itérateurs.

Plan







Changements (Versionning Service) :Permet de gérer et de suivre l’évolution des différentesversions des objets.Maintient des informations sur les évolutions des interfaces etdes implantations.Pas encore complètement spécifié officiellement.

Plan






La sécurité

Sécurité (Security Service) :Permet d’authentifier les clients, de chiffrer et de certifier lescommunications.Minimum = IIOP sur Secure Socket Layer (SSL).

Transactions (Object Transaction Service) :Assure l’exécution des traitements transactionnels impliquantdes objets distribuées et des bases de données enfournissant les propriétés ACID (Atomicité, Consistance,Isolation, Durabilité.

Concurrence (Concurrency Service) :Fournit les mécanismes pour contrôler et ordonnancer lesinvocations concurrentes sur les objets.

Plan






Les communications synchrones et asynchrones(1/2)

La coopération des objets CORBA à un mode decommunication client/serveur synchrone.Il existe des services assurant des communicationsasynchrones.Événements (Event Service) :

Permet aux objets de produire des événements asynchronesà destination d’objets consommateurs au travers de canauxd’événements.Les canaux fournissent deux modes de fonctionnement :

mode push : le producteur a l’initiative de la production, leconsommateur est notifié des événements.mode pull : le consommateur demande explicitement lesévénements, le producteur est alors sollicité.

Plan






Les communications synchrones et asynchrones(2/2)

Notification (Notification Service)Une extension du service précédent :

Les consommateurs sont uniquement notifiés des événementsles intéressant.

Messagerie (CORBA Messaging) :Modèle de communication asynchrone

Permet de gérer des requêtes persistantes.Utiles lorsque l’objet appelant et l’objet appelé ne sont pasprésents simultanément sur le bus (mobilité ?).

Cela permet d’avoir des fonctionnalités proches des MOMs(Message Oriented Middleware).

Plan






Les autres services

Temps (Time Service) :Fournit des interfaces permettant d’obtenir une horlogeglobale sur le bus (Universal Time Object),Mesurer le temps et de synchroniser les objets.

Licences (Licensing Service) :Permet de contrôler l’utilisation des objets.

Plan






Les interfaces de domaines

Parallèlement aux services, l’OMG cherche àdéfinir des canevas d’objets dédiés à des secteursd’activité (ou métiers) ou à des besoins applicatifstransverses à des métiers.

Groupes de travail nommés selon les cas :Working Groups, Domain Task Forces ou SpecialInterest Groups.

Plan






Groupes de travail (1/3)

Business Objects DTF standardise les méthodologies et lestechnologies pour la conception d’applications métiers.Workflow Workgroup travaille sur les outils CORBA pour lesapplications de gestion de flux de travail et les activitéscoopératives au sein des entreprises.C4I DSIG fait la promotion de CORBA au sein desorganismes et administrations liés à la défense en jouant unrôle pédagogique.End User SIG travaille en relation avec les utilisateurs finauxà fin de déterminer leurs besoins, de connaître leursexpériences.CORBAmed pour le domaine de la médecine pour permettrel’interopérabilité entre les acteurs de la santé.

Plan







Life Sciences Research DTF groupe dédié à l’utilisation deCORBA par les instituts de recherche dans les sciences de lavie.

Electronic Financial Commerce pour les applications decommerce électronique.

Financial Services DTF domaine de la finance/banque.

Telecom DTF fait la liaison entre le monde CORBA et lemonde des télécommunication.

Internet Platform SIG travaille sur les rapprochements destechnologies CORBA avec les technologies d’Internet.

Plan







Manufacturing DFT tente de combler le fossé entre lestechnologies OMG et les besoins des industries.Realtime SIG réfléchit sur la prise en compte des aspectstemps réel au sein du bus CORBA.Distributed Simulation SIG adresse les problèmes liés à lasimulation distribuée et à son exécution sur un bus CORBA.Test SIG doit définir les méthodologies, les outils, et lesprotocoles pour automatiser les tests d’applications répartiesCORBA.Object Model Working Group travaille sur l’unification desmodèles orientés objet en vue de créer un standard plusgénéraliste que celui proposé actuellement par CORBA.UML Revision Task Force travaille sur le langage UMLstandardisé par l’OMG (http ://www.omg.org/uml/).

Cours 7 - CORBA/Partie 1 Claude Duvallet - Welcome...

Documents

Transcript of Cours 7 - CORBA/Partie 1 Claude Duvallet - Welcome...