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

Introduction au bus CORBA

Chapitre2 du livre

Corba : des concepts à la pratique

Boucif Amar Bensaber

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é à :

1. Définir une architecture globale d’intégration de services orientés objets

2. La rédaction des spécifications de CORBA


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)


Le modèle objet de CORBA

C’est un modèle objet de type client/serveur.

Référencede l’objet

Implantation de l’objet

Interfacede l’objet

Applicationcliente

Code d’implantation

Application serveur

ObjetCORBA

Bus CORBA

Activation

Référence+ opération+arguments

Exception ourésultats+arguments


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



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.



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.



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...



L’application serveur Habituellement un processus exécuté par le

système d’exploitation; Permet de stocker le contexte d’objets.

L’architecture globale de l’OMG


Architecture globale de l’OMG

Bus d’objets répartis (ORB)

Gestion des tâches

Administrationdu système

Gestion del’information

Interfaceutilisateur

Télécom

Finance

Santé

Concurrenced’accès

TransactionsÉvénements Licences

Vendeur

Changements

Sécurité

TempsRelationsInterrogations

Cyclede vie

Externalisation

Nommage Persistance Propriétés Collections

Objets Applicatifs Interfaces de Domaines Utilitaires Communs

Services objet communs

Spécifiques


Les 4 catégories de composants

1. Le bus d’objets répartis

2. Les services objets communs

3. Les utilitaires communs

4. Les interfaces de domaines


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.


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


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.

Le bus d’objets répartis CORBA


Le bus d’objets répartis (ORB)

C’est le cœur de l’architecture OMAIl est appelé négociateur ou transitaire de requête objetLes 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


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).


Noyau de l’Object Request Broker

Adaptateur d’Objets

Composants du bus CORBA

Interface d’Invocations

StatiquesSII

Interfaced’InvocationsDynamiques

DII

InterfaceORB

Interface deSquelettesStatiques

SSI

Interface deSquelettes

DynamiqueDSI

Interface del’Adaptateur

d’Objets

Référentieldes interfaces

Référentieldes

implantations

Clients Serveur (Objets)


L’architecture du 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


Le dialogue CORBA : Client, ORB et serveur

Application cliente

Stub

Implémentation de l’objet

Skeleton

ORB

Client Serveur


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.


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’activationLes droits d’accès aux serveurs et à leurs

objets


Identification des objets : IOR

Application cliente

Stub IOR


Skeleton

ORB

Client Serveur


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


Positionnement du BOA dans l’architecture CORBA

Application cliente

Stub


Skeleton

ORB

Client Serveur

BOA


Implantations possibles du bus d’objets répartis (ORB)

Bus processusLes 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’exploitationFournit des mécanismes pour transporter les requêtes

entre les processusComposantes intégrées dans le noyau du système

d’exploitation ou processus serveur dédié.


Implantations possibles du bus d’objets répartis (ORB)

Bus réseauLe 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.


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.



Ponts spécifiquesUtilisation 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.



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.



Protocoles standardisésUtilisation 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.


Les protocoles GIOP et IIOP

Protocole générique réseau à usage général: GIOP

Indépendant des couches transports sous-jacente Implantation simpleAdéquat aux réseaux à grande échelle (Internet) :

IIOPFaible coût d’utilisation (performant);Spécifications génériques.



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.



Références d’objets interopérables (IOR)Plusieurs références existentUne 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.



Format des messagesEntête précisant le type de message et son

corps

Valeur Type Émetteur0 Request Client

1 Reply Serveur

2 CancelRequest Client

3 LocateRequest Client

4 LocateReply Serveur

5 CloseConnection Serveur

6 MessageError Tous


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.

ReplyMessage envoyé par le serveur comme réponse à un

message request.Contient le résultat de l’opération et les paramètres en

sortie.


Format des messages

CancelRequestLe client informe le serveur qu’il ne désire plus

de réponse pour la dernière requête qu’il avait émise.

LocateRequestDé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


Format des messages

LocateReplyRé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.

MessageErrorRéponse à n’importe quelle requête lors d’une erreur.


Transport des messages

Les canaux de communication ou connexionsConnexions 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.


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.

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.


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:


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


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.


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:


Les utilitaires communs

L’interface utilisateurComposante 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’informationModé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.



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.



Gestion des tâchesUne 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.



Les interfaces de domaines Composantes de haut niveau basés sur les services de base

comme les transactions, la sécurité, l’événement,… Objets spécifiques à différents marchés/métiers.

Santé, finance, télécommunications, e-commerce



Les objets applicatifs Propre à une entreprise donc ne peuvent être

standardisés; Décrit à l’aide du langage IDL; Ils utilisent les autres services de CORBA ainsi

que leur logique propre.

Documents

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