1 / 52

Introduction au bus CORBA

Introduction au bus CORBA. Chapitre2 du livre Corba : des concepts à la pratique. Historique de CORBA. Objectif : définir des standards pour l’intégration d’applications distribuées fondés sur trois concepts : La réutilisation des composants; L’interopérabilité; La portabilité.

fran
Download Presentation

Introduction au bus CORBA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction au bus CORBA Chapitre2 du livre Corba : des concepts à la pratique

  2. Historique de CORBA • Objectif: définir des standards pour l’intégration d’applications distribuées fondés sur trois concepts: • La réutilisation des composants; • L’interopérabilité; • La portabilité. • C’est l’OMG (Object Management Group) qui a décidé de se baser sur le modèle objet et ses mécanismes. • Le travail de l’OMG a consisté à : • Définir une architecture globale d’intégration de services orientés objets • La rédaction des spécifications de CORBA Boucif Amar Bensaber

  3. Le bus CORBA • Les objets du serveurs communiquent avec les clients (interface) par le bus CORBA. • Permet entre autre l’hétérogénéité des langages de programmation, des systèmes d’exploitation et du matériel informatique. • Les interfaces sont conçues à l’aide du langage IDL (Interface Definition Language) • Repose sur l’architecture OMA (Object Management Architecture) Boucif Amar Bensaber

  4. Le modèle objet de CORBA • C’est un modèle objet de type client/serveur. Application cliente Bus CORBA Code d’implantation Référence+ opération +arguments Activation Référence de l’objet Objet CORBA Implantation de l’objet Exception ou résultats+arguments Interface de l’objet Application serveur Boucif Amar Bensaber

  5. Concepts de ce modèle objet • L’application cliente • Écrite avec un langage de notre choix; • C’est elle qui utilise les objets distribués par le/les serveur(s). • La référence de l’objet • C’est une structure de données; • Contient l’information nécessaire à la désignation de/des objet(s) (local ou distant)par le bus CORBA. • Pointeur ou adresse réseau de la machine Boucif Amar Bensaber

  6. Concepts de ce modèle objet • L’interface de l’objet • C’est la déclaration des méthodes et des propriétés d’une instance de l’objet CORBA (Signature) • Elle est développée à l’aide du langage IDL. • La requête • Mécanisme d’appel à distance sur l’objet CORBA; • Les informations nécessaires (nom de la méthode, paramètres, etc.) sont transportées sur le bus CORBA jusqu’à l’objet. Boucif Amar Bensaber

  7. Concepts de ce modèle objet • L’objet CORBA • Composant logiciel qui reçoit les requêtes; • N’accepte que celles décrites dans son interface. • Le processus d’activation • Associe un objet d’implantation à l’objet CORBA; • Charger en mémoire un exécutable binaire charger de traiter les requêtes • Permet de disposer de millions d’objets alors que quelques uns seulement sont actifs. Boucif Amar Bensaber

  8. Concepts de ce modèle objet • L’implantation de l’objet • C’est une entité qui code un objet CORBA; • Stocke le statut/état de l’objet CORBA et fournit une réalisation pour chaque opération de l’objet; • C’est une instance d’une classe en C++, JAVA ou SmallTalk. Peut aussi être un objet d’une base de données. • Le code d’implantation • Classe habituelle codée en C++, JAVA ou Eiffel; • Regroupé dans des exécutables binaires, des bibliothèques... Boucif Amar Bensaber

  9. Concepts de ce modèle objet • L’application serveur • Habituellement un processus exécuté par le système d’exploitation; • Permet de stocker le contexte d’objets. Boucif Amar Bensaber

  10. L’architecture globale de l’OMG

  11. Architecture globale de l’OMG Objets Applicatifs Interfaces de Domaines Utilitaires Communs Santé Spécifiques Télécom Gestion de l’information Gestion des tâches Finance Administration du système Interface utilisateur Bus d’objets répartis (ORB) Services objet communs Nommage Persistance Cycle de vie Propriétés Concurrence d’accès Collections Sécurité Vendeur Interrogations Externalisation Événements Transactions Relations Temps Changements Licences Boucif Amar Bensaber

  12. Les 4 catégories de composants • Le bus d’objets répartis • Les services objets communs • Les utilitaires communs • Les interfaces de domaines Boucif Amar Bensaber

  13. L’architecture de l’OMG • Le bus d’objets répartis (ORB) • Assure le transport des requêtes entre les objets distribués; • C’est lui qui masque les problèmes d’hétérogénéité (langages, systèmes, format interne des données). • Les services objets communs • Fonctions de bases du système CORBA; • Cycle de vie, transaction, sécurité, etc. Boucif Amar Bensaber

  14. L’architecture de l’OMG • Les utilitaires communs • Les fonctions communes à plusieurs applications; • L’interface, la gestion, l’administration du système, etc. • Les interfaces de domaine • Objets adaptés à plusieurs domaines précis; • Objets de métier adaptés aux spécificités d’un métier • La santé, la finance, les télécommunications, etc. • L’OMG standardise ces objets réutilisables via les interfaces de domaine Boucif Amar Bensaber

  15. L’architecture OMG • Les objets applicatifs • Non standardisé par l’OMG; • Objets personnalisés par et pour un organisme; • Décrit par le langage IDL • Si ces objets répondent aux besoins de plusieurs entreprises d’un même marché ou d’un même secteur économique, ils sont standardisés par des interfaces de domaines. Boucif Amar Bensaber

  16. Le bus d’objets répartis CORBA

  17. Le bus d’objets répartis (ORB) • C’est le cœur de l’architecture OMA • Il est appelé négociateur ou transitaire de requête objet • Les caractéristiques • Peut être utilisé par n’importe quel langage de haut niveau (C, C++, Java ou SmallTalk); • Choisi le meilleur mode de transport selon la localisation (locale,distante) des objets • transparence des invocations : localisation, formats interne • Permet des invocations statiques (vérification pendant la compilation) et dynamiques (durant l’exécution); • Propose plusieurs stratégies d’activations des objets afin d’optimiser l’utilisation de la mémoire; • Un seul serveur est activé quelque soit le nombre de clients • Un serveur est activé par client et est désactivé à la déconnexion • Un serveur est activé à chaque appel de méthode et est désactivé à la fin de la méthode Boucif Amar Bensaber

  18. Le bus d’objets répartis (ORB) • Les caractéristiques (suite) • Assure la communication entre les différents bus de deux façons: • Convertisseur de requêtes • Utilisation de protocoles standardisés: • General Inter-ORB Protocol (GIOP); • Environment specific Inter-ORB Protocol (ESIOP); • Internet Inter-ORB Protocol (IIOP). Boucif Amar Bensaber

  19. Composants du bus CORBA Clients Serveur (Objets) Interface de l’Adaptateur d’Objets Interface de Squelettes Statiques SSI Interface de Squelettes Dynamique DSI Interface d’Invocations Statiques SII Interface d’Invocations Dynamiques DII Interface ORB Adaptateur d’Objets Noyau de l’Object Request Broker Référentiel des interfaces Référentiel des implantations Boucif Amar Bensaber

  20. L’architecturedu bus d’objets répartis (ORB) • Contient neufs blocs fonctionnels: • 1 - Le noyau de communication; • 2 - L’interface d’invocations statiques; • 3 - L’interface d’invocations dynamiques; • 4 - Le référentiel des interfaces; • 5 - L’interface du bus; • 6 - L’interface de squelettes statiques • 7 - L’interface de squelettes dynamiques • 8 - L’adaptateur d’objets • 9 - Le référentiel des implantations Boucif Amar Bensaber

  21. Le dialogue CORBA : Client, ORB et serveur Client Serveur Application cliente Implémentation de l’objet Stub Skeleton ORB Boucif Amar Bensaber

  22. Le référentiel des interfaces • Il forme une base de données stockant toutes les définitions IDL des objets du bus : les modules, les interfaces, les opérations, les attributs, les exceptions, les constantes et les types de données • Il fournit à une application cliente les méthodes nécessaires à la découverte des informations sur les les éléments qu’il contient. Boucif Amar Bensaber

  23. Le référentiel des implantations • Il contient l’ensemble des informations décrivant l’implantation des objets : • le nom des exécutables contenant le code des objets, • les politiques d’activation • Les droits d’accès aux serveurs et à leurs objets Boucif Amar Bensaber

  24. Identification des objets : IOR Client Serveur Application cliente Implémentation de l’objet Skeleton Stub IOR ORB Boucif Amar Bensaber

  25. L’adaptateur d’objets • C’est l’outil qui permet l’interaction entre les objets et les ORB. En réponse aux demandes de l’ORB, il permet : • D’appeler des méthodes standards pour créer et détruire vos objets • De déterminer l’état d’un objet • De transmettre à l’objet les demandes émises par les différents clients • D’activer un objet lorsque la demande lui est faite Boucif Amar Bensaber

  26. Positionnement du BOA dans l’architecture CORBA Client Serveur Application cliente Implémentation de l’objet Skeleton BOA Stub ORB Boucif Amar Bensaber

  27. Implantations possiblesdu bus d’objets répartis (ORB) • Bus processus • Les composants du bus sont dans le même espace mémoire afin d’offrir des performances optimales d’exécution des invocations. • Système embarqué (temps réel) • Bus système d’exploitation • Fournit des mécanismes pour transporter les requêtes entre les processus • Composantes intégrées dans le noyau du système d’exploitation ou processus serveur dédié. Boucif Amar Bensaber

  28. Implantations possiblesdu bus d’objets répartis (ORB) • Bus réseau • Le noyau de communication utilise une couche transport réseau pour échanger les invocations entre processus; • Le protocole IIOP permet même de déployer des objets sur n’importe quel site de l’Internet. Boucif Amar Bensaber

  29. L’interopérabilité entre bus • CORBA 2.0 impose un ensemble de règles et de protocoles permettant à différente implantation du bus de communiquer • Deux façons de communiquer entre les différentes implantations du bus: • Passerelles de conversion (ou ponts); • Utilisation de protocoles communs à CORBA. Boucif Amar Bensaber

  30. L’interopérabilité entre bus • Ponts spécifiques • Utilisation d’un pont qui intercepte les requêtes d’un bus et les converties pour un autre bus; • Se comporte comme un serveur d’objets du premier bus et comme un client du dernier bus (et inversement); • Offre des contrôles de sécurité permettant de réaliser un coupe-feu par exemple; • Permet aussi la conversion de requêtes entre un bus CORBA et non-CORBA (DCOM de Microsoft par exemple); • Multitudes de passerelles à administrer. Boucif Amar Bensaber

  31. L’interopérabilité entre bus • Demi-ponts génériques • Implantation indépendante des protocoles utilisés par les différents bus; • La communication entre bus peut se faire par le partage d’espace mémoire (processus) ou par un des protocoles communs; • Les mécanismes d’invocations dynamiques effectues les conversions d’un bus vers un autre. Boucif Amar Bensaber

  32. L’interopérabilité entre bus • Protocoles standardisés • Utilisation d’une gamme de protocoles instanciés à partir du protocole GIOP. IIOP est le protocole GIOP instancié sur la couche transport TCP/IP par exemple; • Utilisation de protocoles spécifiques aux applications distribuées comme ESIOP ou DCE-CIOP qui permettent l’appel de procédures à distance. Boucif Amar Bensaber

  33. Les protocoles GIOP et IIOP • Protocole générique réseau à usage général: GIOP • Indépendant des couches transports sous-jacente • Implantation simple • Adéquat aux réseaux à grande échelle (Internet) : IIOP • Faible coût d’utilisation (performant); • Spécifications génériques. Boucif Amar Bensaber

  34. Les protocoles GIOP et IIOP • Représentation commune des donnée (CDR) • Représenté sous la forme d’une suite d’octets; • Le récepteur effectue un décodage seulement si sa représentation interne des données est différente de celle de l’émetteur; • Le format de codage de l’émetteur est stocké en tête du flux d’octets. Boucif Amar Bensaber

  35. Les protocoles GIOP et IIOP • Références d’objets interopérables (IOR) • Plusieurs références existent • Une référence doit au moins contenir • Le numéro de version de la couche transport acceptée par le serveur de l’objet; • L’adresse de la machine destinatrice; • La clé qui permet d’identifier/localiser l’objet sur le serveur. Boucif Amar Bensaber

  36. Les protocoles GIOP et IIOP • Format des messages • Entête précisant le type de message et son corps Boucif Amar Bensaber

  37. Format des messages • Request • Invocations d’opérations et accès aux attributs d’un objet CORBA; • Son corps contient la référence de l’objet invoqué, le nom de l’opération ou attribut ainsi que la valeur des paramètres en entrée. • Reply • Message envoyé par le serveur comme réponse à un message request. • Contient le résultat de l’opération et les paramètres en sortie. Boucif Amar Bensaber

  38. Format des messages • CancelRequest • Le client informe le serveur qu’il ne désire plus de réponse pour la dernière requête qu’il avait émise. • LocateRequest • Détermine si la référence de l’objet (IOR) est valide; • Si la référence n’est pas valide, il tente de déterminer la nouvelle référence. • Pour l’activation automatique d’un objet Boucif Amar Bensaber

  39. Format des messages • LocateReply • Réponse du serveur au LocateRequest; • Contient un booléen qui détermine s’il s’agit d’un objet local (vrai). Si faux, il contient aussi la référence de l’objet. • CloseConnection • Indique que le serveur veut fermer la connexion; • Aucune réponse ne sera envoyé aux requête en cours. • MessageError • Réponse à n’importe quelle requête lors d’une erreur. Boucif Amar Bensaber

  40. Transport des messages • Les canaux de communication ou connexions • Connexions asymétriques: • Le client émet des messages et attends des réponses • Le serveur attends des messages et envoie des réponses • GIOP impose que la couche transport soit orientée connexion, fiable et ordonnée; • La couche transport doit informer les clients lors d’un problème réseau. Boucif Amar Bensaber

  41. Le protocole IIOP • GIOP repose sur le protocole TCP/IP • Permet aux applications de dialoguer sur le réseau Internet; • Les référence IOR doivent contenir: • Le numéro de version du protocole IIOP (act. 1.0); • L’adresse de la machine Internet (IP); • Le port du canal de communication; • La clé permettant de localiser l’objet sur le serveur. Boucif Amar Bensaber

  42. Les objets de l’architecture OMA

  43. Les objets de l’architecture OMA • Propose une classification des objets CORBA selon leurs fonctions dans les applications distribuées; • Les catégories sont: • Services objet communs; • Utilitaires communs; • Interfaces de domaines; • Objets applicatifs. Boucif Amar Bensaber

  44. Les services objet communs • Ce sont des ensembles d’objets CORBA spécifiés par des interfaces IDL • Fonctionnalités systèmes de bas niveau • Consiste de 16 fonctionnalités: Boucif Amar Bensaber

  45. Les services • Noms: permet de retrouver les objets à partir de noms symboliques. Il est organisé en graphe de répertoires contenant les références sur les objets. • Cycle de vie: ensemble d’outils pour la gestion d’un objet, décrit les interfaces et les opérations IDL pour créer, détruire, copier,..un objet • Événements : produit des évènements asynchrones au niveau du serveur. Le client les reçoit par le canal d’événements. • Transactions :gère l’aspect transactionnel en garantissant l’intégrité des # objets du système • Persistance : prend en charge le stockage et la restauration d’objets de manière stable sur tout type de support • Concurrence d’accès : fournit les mécanismes de verrous pour contrôler les invocations concurrentes d’opérations sur les objets • Sécurité :garantir la sécurité d’une application : authentification des clients, cryptage, certificats,… • Heure : les clients se règlent sur l’horloge du serveur pour se synchroniser Boucif Amar Bensaber

  46. Les services objet communs… • Un service peut être centralisé, réparti ou dupliqué selon le besoins de l’application; • Ces services ne sont pas encore tous disponible pour certains produit CORBA; • Il faut choisir un ORB en fonction des services qu’il offre en relation avec nos besoins; • Les 16 services communs seront expliqués en détail dans un chapitre ultérieur. Boucif Amar Bensaber

  47. Les utilitaires communs • Fonctionnalités de plus haut niveau • Les services assemblés sous forme de canevas de composants logiciels réutilisables • 4 canevas d’utilitaires communs: Boucif Amar Bensaber

  48. Les utilitaires communs • L’interface utilisateur • Composante pour créer des interfaces homme/machine graphique; • Concept multi-fenêtres. • L’aide en ligne ou vérification de texte entre plusieurs applications • Gestion de l’information • Modélise l’information pour • Son stockage structuré (XML peut être?) • L’échange de données, d’objets, de documents entre applications • Son codage et représentation. Boucif Amar Bensaber

  49. Les utilitaires communs • Administration du système • Essentiel au bon fonctionnement d’un système distribué; • Contient les mécanismes pour • Administrer les objets répartis; • Configurer les objets répartis; • Tester les objets répartis; • Exécuter les objets répartis; • Réparer les objets répartis; Des fonctionnalités qui existent dans le protocole SNMP et CMIP • Mets en œuvre la majorité des services objet communs. Boucif Amar Bensaber

  50. Les utilitaires communs • Gestion des tâches • Une tâche est composé d’une seule opération ou consultation d’un attribut; • Outils nécessaire à la gestion: • D’agents; • Des flux d’activités; • Des règles. Boucif Amar Bensaber

More Related