1. Une vision globale de la construction d’applications réparties L’omg








titre1. Une vision globale de la construction d’applications réparties L’omg
page1/12
date de publication20.03.2018
taille0.5 Mb.
typeDocumentos
ar.21-bal.com > loi > Documentos
  1   2   3   4   5   6   7   8   9   ...   12

CORBA : des concepts à la pratique




L’objectif de ce document est de présenter concrètement les différentes étapes de la construction d’une application répartie au dessus du bus CORBA. Pour cela, ce document fait quelques rappels sur la vision globale de l’OMG sur la construction d’applications réparties et passe en revue les possibilités du langage OMG-IDL. Le cœur de ce document illustre progressivement les composantes du bus CORBA sur la construction d’une application d’annuaires avec les langages de programmation Java, C++ et CorbaScript. La dernière partie est consacrée aux mécanismes dynamiques de CORBA.

1. Une vision globale de la construction d’applications réparties

1.1. L’OMG



L’Object Management Group (OMG) est un consortium international créé en 1989 et regroupant actuellement plus de 850 acteurs du monde informatique : des constructeurs (IBM, Sun), des producteurs de logiciel (Netscape, Inprise ou ex-Borland/Visigenic, IONA Tech.), des utilisateurs (Boeing, Alcatel) et des institutionels et universités (NASA, INRIA, LIFL). L’objectif de ce groupe est de faire émerger des standards pour l’intégration d’applications distribuées hétérogènes à partir des technologies orientées objet. Ainsi les concepts-clés mis en avant sont la réutilisabilité, l’interopérabilité et la portabilité de composants logiciels. L’élément-clé de la vision de l’OMG est CORBA (Common Object Request Broker Architecture) : un « middleware » orienté objet. Ce bus d’objets répartis offre un support d’exécution masquant les couches techniques d’un système réparti (système d’exploitation, processeur et réseau) et il prend en charge les communications entre les composants logiciels formant les applications réparties hétérogènes.

1.2. Le modèle objet client/serveur



Le bus CORBA propose un modèle orienté objet client/serveur d’abstraction et de coopération entre les applications réparties. Chaque application peut exporter certaines de ses fonctionnalités (services) sous la forme d’objets CORBA : c’est la composante d’abstraction (structuration) de ce modèle. Les interactions entre les applications sont alors matérialisées par des invocations à distance des méthodes des objets : c’est la partie coopération. La notion client/serveur intervient uniquement lors de l’utilisation d’un objet : l’application implantant l’objet est le serveur, l’application utilisant l’objet est le client. Bien entendu, une application peut tout à fait être à la fois cliente et serveur.


La figure précédente présente les différentes notions intervenant dans ce modèle objet client/serveur :


  • L’application cliente est un programme qui invoque les méthodes des objets à travers le bus CORBA.

  • La référence d’objet est une structure désignant l’objet CORBA et contenant l’information nécessaire pour le localiser sur le bus.

  • L’interface de l’objet est le type abstrait de l’objet CORBA définissant ses opérations et attributs. Celle-ci se définit par l’intermédiaire du langage OMG-IDL (voir section 2).

  • La requête est le mécanisme d’invocation d’une opération ou d’accès à un attribut de l’objet.

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

  • L’objet CORBA est le composant logiciel cible. C’est une entité virtuelle gérée par le bus CORBA.

  • L’activation est le processus d’association d’un objet d’implantation à un objet CORBA.

  • L’implantation de l’objet est l’entité codant l’objet CORBA à un instant donné et gérant un état de l’objet temporaire. Au cours du temps, un même objet CORBA peut se voir associer des implantations différentes.

  • Le code d’implantation regroupe les traitements associés à l’implantation des opérations de l’objet CORBA. Cela peut être par exemple une classe Java aussi bien qu’un ensemble de fonctions C.

  • L’application serveur est la structure d’accueil des objets d’implantation et des exécutions des opérations. Cela peut être par exemple un processus Unix.


Dans la suite de ce document, nous verrons que ces notions abstraites se traduisent par des composantes technologiques fournies par la norme CORBA.

1.3. L’architecture globale



L’OMG définit aussi une vision globale de la construction d’applications réparties : l’Object Management Architecture Guide [OMAG 95]. Cette architecture globale, appelée aussi l’OMA, vise à classifier les différents objets qui interviennent dans une application en fonction de leurs rôles :



  • Le bus d’objets répartis est la clé de voûte de l’architecture globale de l’OMG. Il assure le transport des requêtes entre tous les objets CORBA. Il offre un environnement d’exécution aux objets masquant l’hétérogénéité liée aux langages de programmation, aux systèmes d’exploitation, aux processeurs et aux réseaux. Ce bus est plus amplement détaillé dans la suite.

  • Les services objet communs (CORBAservices) fournissent sous forme d’objets CORBA, spécifiés grâce au langage OMG-IDL, les fonctions systèmes nécessaires à la plupart des applications réparties. Actuellement, l’OMG a défini des services pour les annuaires (Nommage et Vendeur), le cycle de vie des objets, les relations entre objets, les événements, les transactions, la sécurité, la persistance, etc. Au fur et à mesure des besoins, l’OMG ajoute de nouveaux services communs.

  • Les utilitaires communs (CORBAfacilities) sont des canevas d’objets (« Frameworks ») qui répondent plus particulièrement aux besoins des utilisateurs. Ils standardisent l’interface utilisateur (e.g. Fresco, OpenDoc), la gestion de l’information, l’administration, le Workflow, etc.

  • Les interfaces de domaine (Domain Interfaces) définissent des objets de métiers spécifiques à des secteurs d’activités comme la finance (e.g. monnaie électronique), la santé (e.g. dossier médical) et les télécoms (e.g. transport multimédia). Leur objectif est de pouvoir assurer l’interopérabilité sémantique entre les systèmes d’informations d’entreprises d’un même métier : les « Business Object Frameworks » (BOFs).

  • Les objets applicatifs (Application Objects) sont ceux qui sont spécifiques à une application répartie et ne sont donc pas standardisés. Toutefois, dès que le rôle de ces objets apparaît dans plus d’une application ils peuvent alors rentrer dans une des catégories précédentes et donc être standardisés par l’OMG.

1.4. Le bus d’objets répartis CORBA




1.4.1. Les caractéristiques



Le bus CORBA est donc l’intermédiaire/négociateur à travers lequel les objets vont pouvoir dialoguer. Il fournit les caractéristiques suivantes :


  • La liaison avec « tous » les langages de programmation : cependant, actuellement l’OMG a seulement défini officiellement cette liaison pour les langages C, C++, SmallTalk, Ada, COBOL et Java.

  • La transparence des invocations : les requêtes aux objets semblent toujours être locales, le bus CORBA se chargeant de les acheminer en utilisant le canal de communication le plus approprié.

  • L’invocation statique et dynamique : ces deux mécanismes complémentaires permettent de 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.

  • Un système auto-descriptif : les interfaces des objets sont connues du bus et sont aussi accessibles par les programmes par l’intermédiaire du référentiel des interfaces. Nous reviendrons plus en détail sur cet aspect dans la section 4.

  • L’activation automatique et transparente des objets : les objets sont en mémoire uniquement s’ils sont utilisés par des applications clientes.

  • L’interopérabilité entre bus : à partir de la norme CORBA 2.0, un protocole générique de transport des requêtes (GIOP pour General Inter-ORB Protocol) a été défini permettant l’interconnexion de bus CORBA provenant de fournisseurs distincts, une de ses instanciations est l’Internet Inter-ORB Protocol (IIOP) fonctionnant au dessus de TCP/IP.



1.4.2. Les composantes



Le bus CORBA fournit les composantes suivantes :



  • ORB (Object Request Broker) est le noyau de transport des requêtes aux objets. Il intègre au minimum les protocoles GIOP et IIOP. L’interface au bus fournit les primitives de base comme l’initialisation de l’ORB.

  • SII (Static Invocation Interface) est l’interface d’invocations statiques permettant de soumettre des requêtes contrôlées à la compilation des programmes. Cette interface est générée à partir de définitions OMG-IDL.

  • DII (Dynamic Invocation Interface) est l’interface d’invocations dynamiques permettant de construire dynamiquement des requêtes vers n’importe quel objet CORBA sans générer/utiliser une interface SII.

  • IFR (Interface Repository) est le référentiel des interfaces contenant une représentation des interfaces OMG-IDL accessible par les applications durant l’exécution.

  • SSI (Skeleton Static Interface) est l’interface de squelettes statiques qui permet à l’implantation des objets de recevoir les requêtes leur étant destinées. Cette interface est générée comme l’interface SII.

  • DSI (Dynamic Skeleton Interface) est l’interface de squelettes dynamiques qui permet d’intercepter dynamiquement toute requête sans générer une interface SSI. C’est le pendant de DII pour un serveur.

  • OA (Object Adapter) est l’adaptateur d’objets qui s’occupe de créer les objets CORBA, de maintenir les associations entre objets CORBA et implantations et de réaliser l’activation automatique si nécessaire.

  • ImplR (Implementation Repository) est le référentiel des implantations qui contient l’information nécessaire à l’activation. Ce référentiel est spécifique à chaque produit CORBA.


Ces différentes composantes sont toutes décrites dans le langage OMG-IDL, ce qui les rend accessibles au travers du bus (e.g. le référentiel des interfaces). Cela permet aussi d’homogénéiser les différentes implantations possibles de la norme car différentes approches peuvent être envisagées pour construire un bus :


  • 1 bus = 1 processus : les objets sont dans le même espace mémoire que les clients. C’est le cas typique des applications embarquées. Ici, le langage OMG-IDL sert à spécifier les objets.

  • 1 bus = 1 OS : les clients et les fournisseurs sont des processus différents sur la même machine. Le bus CORBA peut alors être tout ou partie du système d’exploitation, e.g. Spring l’OS orienté objet de SUN [Spring 95].

  • 1 bus réseau : les processus sont sur des sites différents et les requêtes sont véhiculées à travers le réseau, c’est le cas sur Internet avec IIOP.

  • Fédération de bus CORBA : plusieurs bus distincts peuvent être mis ensemble pour former 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 (DII-DSI).



1.4.3. Les protocoles réseaux



Tout bus à la norme CORBA 2.0 doit fournir les protocoles GIOP et IIOP. Le protocole GIOP définit une représentation commune des données (CDR ou Common Data Representation), un format de références d’objet interopérable (IOR ou Interoperable Object Reference) et un ensemble de messages de transport des requêtes aux objets (Request, Reply, …). Cependant, GIOP est seulement un protocole générique, IIOP fournit alors une implantation de GIOP au dessus de TCP/IP et donc d’Internet. Les IORs dans le contexte d’IIOP doivent contenir :


  • le nom complet de l’interface OMG-IDL de l’objet ;

  • l’adresse IP de la machine Internet où est localisé l’objet ;

  • un port IP pour se connecter au serveur de l’objet ;

  • une clé pour désigner l’objet dans le serveur. Son format est libre et il est donc différent pour chaque implantation du bus CORBA.


Toutefois, un bus CORBA peut contenir d’autres protocoles de transport des requêtes aux objets. Par exemple, nous travaillons actuellement sur un bus multi-protocoles permettant d’avoir simultanément des communications en IIOP, UDP-IOP et Multicast-IOP.

1.5. Les services objet communs



Les services objet communs ont pour objectif de standardiser les interfaces des fonctions système indispensables à la construction et l’exécution de la plupart des applications réparties. Cette section décrit sommairement ces services selon leur rôle dans une application répartie. Elle se base sur l’actuelle spécification CORBAservices [COS 98] et les travaux en cours à l’OMG.

1.5.1. La recherche d’objets



Cette catégorie de services offre les mécanismes pour rechercher/retrouver dynamiquement sur le bus les objets nécessaires aux applications. Ce sont les équivalents des annuaires téléphoniques :


  • Le service Nommage (Naming Service) est l’équivalent des « pages blanches » : les objets sont désignés par des noms symboliques. Cet annuaire est matérialisé par un graphe de répertoires de désignation.

  • Le service Vendeur (Trader Service) est l’équivalent des « pages jaunes » : les objets peuvent être recherchés en fonction de leurs caractéristiques.

1.5.2. La vie des objets



Cette catégorie regroupe les services prenant en charge les différentes étapes de la vie des objets CORBA.


  • Le service Cycle de Vie (Life Cycle Service) décrit des interfaces pour la création, la copie, le déplacement et la destruction des objets sur le bus. Il définit pour cela la notion de fabriques d’objets («Object Factory»).

  • Le service Propriétés (Property Service) permet aux utilisateurs d’associer dynamiquement des valeurs nommées à des objets. Ces propriétés ne modifient pas l’interface IDL, mais représentent des besoins spécifiques du client comme par exemple des annotations.

  • Le service Relations (Relationship Service) sert à gérer des associations dynamiques (appartenance, inclusion, référence, auteur, emploi,...) reliant des objets sur le bus. Il permet aussi de manipuler des graphes d’objets.

  • Le service Externalisation (Externalization Service) apporte un mécanisme standard pour fixer ou extraire des objets du bus. La migration, le passage par valeur, et la sauvegarde des objets doivent reposer sur ce service.

  • Le service Persistance (Persistent Object Service) offre des interfaces communes à un mécanisme permettant de stocker des objets sur un support persistant. Quel que soit le support utilisé, ce service s’utilise de la même manière via un «Persistent Object Manager». Un objet persistant doit hériter de l’interface «Persistent Object» et d’un mécanisme d’externalisation.

  • Le service Interrogations (Query Service) permet d’interroger les attributs des objets. Il repose sur les langages standards d’interrogation comme SQL3 ou OQL. L’interface Query permet de manipuler les requêtes comme des objets CORBA. Les objets résultats sont mis dans une collection. Le service peut fédérer des espaces d’objets hétérogènes.

  • Le service Collections (Collection Service) permet de manipuler d’une manière uniforme des objets sous la forme de collections et d’itérateurs. Les structures de données classiques (listes, piles, tas,..) sont construites par sous-classement. Ce service est aussi conçu pour être utilisé avec le service d’interrogations pour stocker les résultats de requêtes.

  • Le service Changements (Versionning Service) permet de gérer et de suivre l’évolution des différentes versions des objets. Ce service maintient des informations sur les évolutions des interfaces et des implantations. Cependant, il n’est pas encore spécifié officiellement.



1.5.3. La sûreté de fonctionnement



Cette catégorie de services fournit les fonctions système assurant la sûreté de fonctionnement nécessaire à des applications réparties.


  • Le service Sécurité (Security Service) permet d’identifier et d’authentifier les clients, de chiffrer et de certifier les communications et de contrôler les autorisations d’accès. Ce service utilise les notions de serveurs d’authentification, de clients/rôles/droits (et délégation de droits), d’IIOP sécurisé (utilisant Kerberos ou SSL).

  • Le service Transactions (Object Transaction Service) assure l’exécution de traitements transactionnels impliquant des objets distribués et des bases de données en fournissant les propriétés ACID.

  • Le service Concurrence (Concurrency Service) fournit les mécanismes pour contrôler et ordonnancer les invocations concurrentes sur les objets. Le mécanisme proposé est le verrou. Ce service est conçu pour être utilisé conjointement avec le service Transactions.



1.5.4. Les communications asynchrones



Par défaut, la coopération des objets CORBA est réalisée selon un mode de communication client/serveur synchrone. Toutefois, il existe un ensemble de services assurant des communications asynchrones.


  • Le service Evénements (Event Service) permet aux objets de produire des événements asynchrones à destination d’objets consommateurs à travers des canaux d’événements. Les canaux fournissent deux modes de fonctionnement. Dans le mode « push », le producteur a l’initiative de la production, le consommateur est notifié des événements. Dans le mode « pull », le consommateur demande explicitement les événements, le producteur est alors sollicité.

  • Le service Notification (Notification Service) est une extension du service précédent. Les consommateurs sont uniquement notifiés des événements les intéressant. Pour cela, ils posent des filtres sur le canal réduisant ainsi le trafic réseau engendré par la propagation des événements inintéressants.

  • Le service Messagerie (CORBA Messaging [OMG-CM])  définit un nouveau modèle de communication asynchrone permettant de gérer des requêtes persistantes lorsque l’objet appelant et l’objet appelé ne sont pas présents simultanément sur le bus. Cela permet d’avoir des fonctionnalités proches des MOMs (« Message Oriented Middleware »).



1.5.5. Autres fonctions





  • Le service Temps (Time Service) fournit des interfaces permettant d’obtenir une horloge globale sur le bus (Universal Time Object), de mesurer le temps et de synchroniser les objets.

  • Le service Licences (Licensing Service) permet de mesurer et de contrôler l’utilisation des objets, et cela en vue de facturer les clients et de rémunérer les fournisseurs.

1.6. Les interfaces de domaine



Parallèlement aux services, l’OMG porte ses efforts sur la conception de canevas d’objets dédiés à des secteurs d’activité (ou métiers) ou des besoins applicatifs transverses à des métiers. Ces efforts sont effectués au sein de groupes de travail nommés selon les cas : « Working Groups », « Domain Task Forces » ou « Special Interest Groups », etc. Les groupes les plus actifs sont actuellement :


  • Business Objects DTF standardise les méthodogies et les technologies pour la conception d’applications métier au dessus de CORBA.

  • Workflow Workgroup travaille sur les outils CORBA nécessaires au fonctionnement des applications de gestion de flux de travail indispensables aux activités coopératives au sein des entreprises.

  • C4I DSIG fait la promotion de CORBA au sein des organismes et administrations liés à la défense en jouant un rôle pédagogique.

  • End User SIG travaille en relation avec les utilisateurs finaux à fin de déterminer leurs besoins, de connaître leurs expériences pour mieux orienter les futurs technologies CORBA.

  • CORBAmed définit les standards OMG pour le domaine de la médecine. Ces standards permettront l’interopérabilité entre les acteurs de la santé en définissant par exemple la notion d’objets patient.

  • Life Sciences Research DTF est un nouveau groupe dédié à l’utilisation de CORBA par les instituts de recherche dans les sciences de la vie : les universités et les laboratoires pharmaceutiques.

  • Electronic Commerce s’intéresse à la définition de technologies CORBA pour les applications de commerce électronique.

  • Financial Services DTF produit les spécifications OMG liées au domaine de la finance/banque comme, par exemple, la définition d’objets monnaie et d’objets convertisseur de monnaie.

  • Telecom DTF fait la liaison entre le monde CORBA et le monde des télécommunications.

  • Internet Platform SIG travaille sur les rapprochements des technologies CORBA avec les technologies d’Internet. Il étudie principalement les relations avec le World Wide Web.

  • Manufacturing DFT tente de combler le fossé entre les technologies OMG et les besoins des industries.

  • Realtime SIG réfléchit sur la prise en compte des aspects temps réel au sein du bus CORBA.

  • Distributed Simulation SIG adresse les problèmes liés à la simulation distribuée et son exécution au dessus d’un bus CORBA.

  • Test SIG doit définir les méthodologies, les outils, les protocoles pour automatiser les tests d’applications réparties CORBA.

  • Object Model Working Group travaille sur l’unification des modèles orientés objet en vue de créer un standard plus généraliste que celui proposé actuellement par CORBA.

  • UML Revision Task Force travaille sur le futur du langage UML. Ce langage, standardisé par l’OMG, est une notation graphique pour définir des modèles orientés objet.


Cette liste n’est pas exhaustive car les groupes de travail OMG sont lancés ou arrêtés au fur et à mesure du temps, des besoins et de l’activité de leurs participants. De plus, vu le nombre de groupes, il nous est assez difficile de suivre pleinement l’activité de chacun d’eux. Cependant, le point important à retenir est que l’OMG est un consortium de standardisation « de facto » ouvert qui est prêt à accueillir et/ou créer tout nouveau groupe de travail voulant réfléchir aux impacts de l’utilisation du bus CORBA dans un contexte applicatif particulier. Par exemple, le groupe « Sciences de la vie » a été créé tout récemment pour permettre d’étendre la vision globale de l’OMG vers ce nouveau domaine.

  1   2   3   4   5   6   7   8   9   ...   12

similaire:

1. Une vision globale de la construction d’applications réparties L’omg iconAllied Vision offre la performance aux applications de vision dans...
«1» d’Allied Vision. Elle consiste à intégrer dans un design optimisé, mais ouvert, un grand nombre de fonctionnalités de traitement...

1. Une vision globale de la construction d’applications réparties L’omg icon4 travaux apportent nombre d’éléments nouveaux ou une vision globale d’une problématique
«immigrées» : un poids plus important que dans la population active, des créations plus employeurs que les entreprises créées par...

1. Une vision globale de la construction d’applications réparties L’omg iconRésumé : Cette communication propose une vision dynamique de l'attractivité,...

1. Une vision globale de la construction d’applications réparties L’omg iconBlue Coat dévoile sa vision sur l’optimisation et la sécurisation...

1. Une vision globale de la construction d’applications réparties L’omg iconIl me semble nécessaire de les lire dans leur entièreté de telle...

1. Une vision globale de la construction d’applications réparties L’omg iconAteliers environnement et développement durable
Rff a fait valoir à juste titre que ce n’était pas à lui de définir les objectifs en la matière. Les deux acteurs pouvant porter...

1. Une vision globale de la construction d’applications réparties L’omg iconDocumentation HappyNet – So@t
«référence». Le but est de proposer un ensemble de solutions répondant à des besoins fréquents lors de la construction d’applications...

1. Une vision globale de la construction d’applications réparties L’omg iconDocumentation HappyNet – So@t
«référence». Le but est de proposer un ensemble de solutions répondant à des besoins fréquents lors de la construction d’applications...

1. Une vision globale de la construction d’applications réparties L’omg iconCentile Telecom Applications déploie chez Jaguar Network une solution...
«Centile se réjouit d’accompagner Jaguar Network, leader de l’hébergement et du monde de la data, dans son expansion vers des services...

1. Une vision globale de la construction d’applications réparties L’omg iconRésumé Au delà des aspects purement techniques de leur mise en oeuvre,...
«fonctions processus» qu’elle peuvent offrir, leur capacité et leur disponibilité. Ce schéma, qui pousse à l’extrême le principe...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com