OMM01
Introduction
L’Object Management Group (OMG) est un consortium international créé en 1989 et regroupant actuellement plus de 850 acteurs du monde informatique : des constructeurs, desproducteurs de logiciel des utilisateurs et des institutionnels et universités. 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 visé sont la l’interopérabilité, réutilisabilité, et la portabilité de composants logiciels, programmés dans différents langages.
Le cœur de la vision de l’OMG est CORBA (Common Object Request Broker Architecture) : qui est un middleware orienté objet et repose sur le protocole TCP / IP.
L’idée consiste à créer des objets qui seront accessibles par le client et le serveur. CORBA propose un support d’exécution masquant les couches techniques d’un système réparti et il prend en charge les communications entre les composants logiciels formant les applications réparties et hétérogènes.
Modèle client/serveur de CORBA
Architecture client/serveur traditionnelle
L’application cliente est située sur le poste client. Le lien entre le serveur et le client est direct.
L’application cliente accède aux données de la base via des requêtes SQL. Peu de traitements sont localisés au niveau du serveur.
Architecture client/serveur à trois tiers
Le client n’accède pas directement au serveur. Il émet des requêtes au serveur d’application qui exécute les traitements et à son tour faire transmettre les requêtes au serveur de données.
Cette architecture ne repose pas sur le concept d’objet.
Architecture distribuée
Dans cette architecture l’ensemble des dialogues entre machines est pris en charge par le middleware (dans notre cas c’est CORBA). Il prend en charge tous les problèmes de communication liés à l’intégration des différentes plates-formes utilisées (langages distincts, machines distantes, environnements hétérogènes) CORBA propose donc un modèle client/serveur de coopération entre des objets répartis, chaque application peut exporter certains services sous forme d’objet CORBA, cette notion de client serveur intervient uniquement lors de l’utilisation de l’objet.
Les interactions entre applications sont faites à travers les invocations de procédures distantes.
L’application utilisant un objet est un client, et celle en attente des requêtes est le Serveur tandis que la partie du serveur implantant l’objet est appelée le servant.
L’architecture globale de CORBA
L’OMG a défini une architecture globale pour classifier les différents objets qui participent dans la construction d’applications réparties. Cette architecture comprend un bus d’objets répartis : l’ORB (voir ci-dessous) qui est l’intermédiaire à travers lequel les objets vont pouvoir dialoguer. Des services de base (CorbaServices) qui fournissent les fonctions nécessaires à la plupart des applications réparties. Ces services sont spécifiés grâce au langage OMG-IDL (voir ci-dessous). Des utilitaires communs (Common Facilities) qui répondent plus particulièrement aux besoins des utilisateurs. Des interfaces d’objets applicatifs (Application Interfaces) qui définissent les objets créés par les utilisateurs. Des interfaces de domaines(Domain Interfaces) qui définissent des interfaces spécialisées répondant aux besoins spécifiques de tel ou tel marché comme la finance ou la santé.
La figure 2 illustre cette architecture.
L’ORB (Object Request Broker)
L’ORB (Object Request Broker) est une entité (en réalité en ensemble des interfaces) qui fournit des mécanismes d’interrogations permettant de récupérer des objets, des procédures qui constituent une application répartie. Donc c’est l’intermédiaire/négociateur à travers lequel les objets vont pouvoir dialoguer et ce de manière transparent.
Le noyau de communication (ORB Core) transporte les requêtes du client vers l’implantation de l’objet cible, selon diverses techniques dépendantes de la localisation. Si les objets sont situés sur des machines différentes, L’ORB Core utilise le protocole IIOP (Internet Inter-ORB Protocol) et si les objets sont sur le même site il utilise des outils de communication interprocessus. Ainsi l’ORB est responsable de trouver l’implantation de l’objet, de l’activer, de délivrer la requête à l’objet et de retourner la réponse à l’appelant. Ce noyau n’est pas directement accessible par les programmeurs.
L’IDL (Interface Definition Language)
IDL est un langage de définition d’interface orienté objet. Il a été créé pour fournir l’interopérabilité entre plusieurs applications répartir, flexibles écrites dans différents langage de programmation, Il cherche à masquer l’hétérogénéité de ces applications et il définit les types des objets en spécifiant leurs interfaces. Cette spécification des applications répartie flexibles sur des plateformes hétérogènes nécessite une séparation stricte entre l’interface de l’objet et de son implémentation.
D’où l’idée de créer un langage objet : OMG-IDL qui ne décrit que les interfaces des objets, et ceci de manière indépendante du langage d’implantation. L’interface d’un objet contient les éléments suivent :
) Les opérations,
) Les paramètres,
) Les noms des méthodes,
) Le type de retour,
) Les attributs,
) Les types et les exceptions.
Du côté client, on a uniquement l’interface de l’objet.
Du côté serveur, on a l’interface des objets et on a aussi l’implantation dans des langages de programmation tels que (C, C++, Smalltalk, Java, Cobol) L’interface et l’implantation sont liées par l’intermédiaire du bus CORBA.
Un compilateur IDL génère des stubs (les souches) client et des skeletons (squelettes) serveurs. Le client invoque localement les stubs pour accéder aux objets. Les stubs IDL créent des requêtes, qui vont être transportées par le bus CORBA, puis délivrées par celui-ci aux skeletons IDL qui les délégueront aux objets.
La projection vers un langage de programmation
Une projection est la traduction d’une spécification OMG-IDL dans un langage d’implantation. Pour permettre la portabilité des applications d’un bus vers un autre, les règles de projection sont normalisées et fixent précisément la traduction de chaque construction IDL en une ou des constructions du langage cible et les règles d’utilisation correcte de ces traductions. Actuellement, ces règles exLa projection est réalisée par un pré compilateur IDL dépendant du langage cible et de l’implantation du bus CORBA cible. Ainsi, chaque produit CORBA fournit un pré compilateur IDL pour chacun des langages supportés. Le code des applications est alors portable d’un bus à un autre car les souches/squelettes générés s’utilisent toujours de la même manière quel que soit le produit CORBA. Par contre, le code des souches et des squelettes IDL n’est pas forcément portable car il dépend de l’implantation du bus pour lequel ils ont été générés.
La figure suivante illustre la pré compilation d’un contrat IDL vers les langages cibles C++ et Java. Comme les deux applications vont dialoguer à travers IIOP, on peut très bien d’un côté utiliser un pré compilateur IDL/C++ fourni par un bus A et de l’autre côté utiliser un pré compilateur IDL/Java fourni par un bus B. istent pour les langages C, C++, SmallTalk, Ada, Java et Cobol orienté objet. Nous ne détaillons pas ici ces règles. Toutefois, voici quelques exemples de règles de projection :
Les services objet communs
Les services objet communs sont ensemble de services de niveau système formaté comme des objets avec une interface spécifiée en IDL et ont pour objectif de standardiser les interfaces des fonctions système nécessaires à la construction et l’exécution de la plupart des applications réparties. Un service est caractérisé par les interfaces qu’il fournit et par les objets qui fournissent ces interfaces.
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 de Nommage pour Naming Service : les objets sont désignés par des noms symboliques.ce service est l’équivalent des “pages blanches”, ) Le service Vendeur pour Trader Service : en utilisant ce service les objets peuvent être recherchés en fonction de leurs caractéristiques.
Ce servie est l’équivalent des “pages jaunes”.
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 pour 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 et utilise la notion de fabriques d’objets Object Factory pour faire cala, ) Le service Propriétés pour Property Service permet aux utilisateurs d’associer dynamiquement des valeurs nommées à des objets. Ces propriétés ne modifient pas l’interface de l’IDL, mais représentent des besoins caractéristiques du client, ) Le service Relations pour Relationship Service sert à gérer des associations dynamiques (appartenance, inclusion, référence, emploi,…) reliant des objets sur le bus CORBA. Il permet aussi de manipuler des graphes d’objets, ) Le service Externalisation pour 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 pour 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 PersistentObject et d’un mécanisme d’externalisation, ) Le Service Interrogations pour 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.
Télécharger le document complet
