Common Object Request Broker Architecture (corba) Jean-Louis Pazat irisa/insa

Sizin üçün oyun:

Google Play'də əldə edin


Yüklə 445 b.
tarix18.01.2019
ölçüsü445 b.


Common Object Request Broker Architecture (CORBA)

  • Jean-Louis Pazat - IRISA/INSA

  • Jean-Louis.Pazat@irisa.fr


Plan

  • Introduction

  • Architecture de CORBA

  • Communications

  • Service de nommage

  • Langage de description d’interfaces (IDL)

  • Exemple

  • Compléments

    • Services, “Facilities” & Domaines
    • CORBA et le parallélisme
  • Conclusion



Introduction



motivation

  • Calcul réparti

    • le réseau est au cœur du calcul
  • Pratiques du “génie logiciel”

    • modélisation et programmation objet/composant
  • Indépendance

  • Integration de programmes existants

    • nécessaire


Comment passer du centralisé au réparti ?

  • Casser les structures existantes

    • insérer des appels de procédure/de méthode à distance


Le concept de “bus logiciel”

  • ajouter/supprimer des objets sans recompiler l’ensemble de l’application

    • enregistrer/retrouver des références globales sur des objets
    • connaître à priori ou découvrir les méthodes d’un objet
  • réaliser les appels de méthode à distance

    • passage de paramètres (par valeur)
    • indépendance vais à vis de la localisation des objets


What is CORBA ?

    • standard ouvert pour les applications réparties
    • bus logiciel, orienté objet
    • communication par appel de méthode à distance
    • géré par l’ “Object Management Group” (OMG).
    • indépendant
      • du matériel, du système, des langages
      • et surtout des vendeurs


Le modèle objet de CORBA

  • Types (Types) :

    • définis sur des domaines de valeurs
    • indépendants des langages d’implémentation
  • Objets (objects) :

    • entité encapsulée qui offre des services à des clients
    • peut être créé/détruit
  • méthodes (operation)

    • entité qui définit les points d’entrée qu’un client peut invoquer


Le modèle objet de CORBA (suite)

  • Interfaces (Interfaces)

    • signature des méthodes qu’un client peut invoquer sur un objet


Architecture de CORBA





ORB

  • Niveau interstitiel (Middleware)

    • n’est pas partie intégrante du système
    • sépare le reste de l’architecture du système
  • Permet l’ interopérabilité

    • indépendant des plateformes matérielles ou logicielles
    • différents ORB peuvent communiquer
      • à travers un protocole “Inter ORB” (xIOP)


ORB (suite) GIOP / IIOP / ESIOP

  • GIOP = General Inter ORB Protocol

    • spécification qui permet l’interopérabilité entre différents ORBs
    • spécifie le protocole de transmission + format des requêtes
  • IIOP = Internet Inter ORB Protocol

    • protocole d’interopérabilité standard pour Internet
    • construit sur IP
  • ESIOP = Environment Specific IOP

    • spécification qui permet de définir des protocoles spécifiques


ORB (suite) IIOP

  • Livré avec toute implémentation de CORBA

  • Utilise CDR

    • plus efficace que XDR (0/1 codage/décodage max)
  • Certains serveurs WEB peuvent dialoguer via IIOP



Souche et squelette IDL

  • Générés par le compilateur IDL

    • à partir de la description IDL de l’objet serveur (doit être connue lors de l’écriture du client)


Souche IDL

  • Contient les proxies des objets distants auxquels le client accède

  • génère les requêtes à partir de l’invocation de méthode locale

  • encapsule requête et arguments

  • envoie la requête sur le bus (ORB Core)



Squelette IDL

  • Contient un aiguilleur de requêtes compilé (dispatcher)

  • extrait l’invocation de méthode et les paramètres de la requête reçue du bus

  • transmet l’invocation de méthode vers le bon objet



DII / DSI

  • Interfaces dynamique d’invocation de méthodes (Dynamic Invocation/Skeleton Interface)

    • permet de découvrir dynamiquement de nouvelles interfaces ou de les enregistrer
    • pas recommandé aux programmeurs débutants
    • historiquement était la seule interface disponible en CORBA
    • beaucoup moins efficace que les interfaces statiques


DSI

  • Dynamic Skeleton Interface

    • utile lorsqu’une implémentation n’a pas d’IDL
    • peut tenir compte d’objets créés/enregistrés dynamiquement
    • transfère les invocations de méthodes du coté serveur


DII

  • Dynamic invocation interface

    • API prédéfinie pour tout appel de méthode
    • permet de découvrir dynamiquement des interfaces
    • les requêtes doivent être construites “à la main”
    • syntaxiquement différent d’une invocation de méthode
    • utilisée aussi dans des cas particuliers
      • “deferred synchronous call”


Utilisation de DSI+DII si rien n’est connu à la compilation



DII+IDL Skeleton method invocation le serveur possède une IDL mais le client ne la connaît pas …



Basic Object Adapter

  • Pas à l’usage du programmeur

    • sauf pour init/enregistrement


Communication



Appel de méthode à distance

  • paramètres passés par valeur

    • types de base, types construits
    • références aux objets
  • modes de passage de paramètres

    • in : valeur transmise à la méthode
    • out : valeur calculée par la méthode
    • inout : valeur transmise puis renvoyée (modifiée)


Appel blocant

  • “twoway method invocation”

    • l’appelant est bloqué jusqu’à la terminaison de la méthode appelée
    • out, inout et des resultats ou des exceptions peuvent être retournées


Appel non blocant 1

  • “oneway method”

    • l’appelant n’est pas bloqué
    • aucun résultat ou paramètre inout ou out ne peuvent être utilisés


Appel non blocant 2

  • “asynchronous call”

    • uniquement en utilisant le DII
    • permet de récupérer des résultats
  • méthodes du DII :

      • send_deferred()
      • get_response()
      • poll_response()


Communication par passage de messages



Service de nommage

  • Un des serveurs standard livrés avec l’ORB (service)

  • Service de nommage générique

    • Associe des noms et des références CORBA (IOR)
    • nommage uniforme
  • Contexte de nommage

    • organisé en DAG
    • conventions de nommage
  • Opérations

    • bind / unbind / rebind / resolve


Interface Definition Language (IDL)



présentation

  • Est indépendant des langages

  • Peut être “mappé” dans de nombreux langages :

    • C++, C++, C++, C++, C, Java, ...
  • Permet de décrire

  • une interface IDL est similaire à

      • une interface Java
      • une classe abstraite C++


exemple de spécification IDL



éléments du langage IDL

  • Modules

  • Interfaces

    • Opérations (oneway, twoway)
    • Attributs
  • Déclarations de

    • constantes
    • types
    • exceptions


Modules

  • espaces de nommage pour les définitions IDL

    • évite les conflits de noms
  • les modules peuvent être imbriqués

  • les noms sont visibles (préfixer)

    • module simulation { typedef ::MatrixComputation::Matrix constraints; … };
    • module MatrixComputation { typedef double Matrix[N][N]; …};


Interfaces

  • Description de la partie publique d’un objet

  • Héritage entre interfaces possible (restrictions)

    • redéfinitions interdites
    • héritage multiple autorisé
    • interface coffee { // coffee interface definitions }; interface Drinks: coffee { // inherits all coffee definitions // then adds other definitions };


Constantes

  • Seulement pour certains types

    • integer, character, Boolean, Floating point, String, renamed types
    • peuvent être des expressions
    • pas de constantes pour les types construits
    • const char etoileu_des_neigeu = ‘*’
    • typedef Long Entier;
    • Entier 600+60+6


Déclarations de types

  • Renommage ou types def. par le programmeur

  • énumeration, structures, tableaux, unions

    • enum couleurs { rouge, vert, bleu};
    • struct ecole {
    • Interessant tutoriels, exposes;
    • Bon repas;
    • Sympatique station;
    • };
    • typedef Char BadDate[2];
  • sequences (tableaux de taille variable)

    • typedef sequence formation;


types de données



type dynamique IDL Any

  • N’est pas un type générique au sens objet

  • Défini des types “auto-identifiés”

    • contient des informations sur
      • son type dynamique (CORBA type code)
      • sa valeur
    • les types définis par l’utilisateur ont un “type code”
  • utile pour définir des services “génériques”



attributs

  • attributs public des objets

  • peuvent être en “lecture seule” ou en “lecture/écriture” (par défaut)

  • seuls les types nommés sont autorisés

    • interface time {
    • attribute unsigned long nanosecond;
    • readonly attribute date Y2K;
    • attribute long notAllowed[10];
    • }


exceptions

  • Assure qu’un client reçoit toujours une réponse lors d’une invocation distante

  • 2 sortes d’exceptions

    • “CORBA Standard Exceptions”
      • levées par CORBA
      • même si elle peuvent avoir été levées par l’implémentation d’un objet
    • exceptions définies par le programmeur
      • exception EntryNotAllowed{string reason;};


exceptions (suite)

  • Exemple

  • interface Account {

  • exception OverdrawnException {};

  • void deposit( in float amount );

  • void withdraw( in float amount )

  • raises ( OverdrawnException );

  • float balance();

  • };



IDL mappings

  • Existent pour plusieurs langages

    • orientés objet
    • non orienté objet
  • Un nouveau “mapping” ne peut pas être facilement ajouté

    • nécessite la modif du compilateur IDL, du BOA, …
    • son intégration dans la norme
    • connecter 2 ORBs est plus simple ...
  • mapping

    • trivial pour C++, assez simple pour Java


Mon premier programme CORBA



Mon premier programme CORBA



Mon premier programme CORBA











Conclusion



Nombreuses mise en œuvre existantes

    • Nombreuses mise en œuvre existantes
      • Orbix (Iona), Visibroker (Inprise), ... comm
      • MICO (Université de Francfort)
      • ORBit, TAO, JacORB, ...
    • Intérêts
      • Utilisation assez facile
      • Réelle interopérabilité !
    • Défauts
      • Trop bas/haut niveau :-)
      • Architecture complexe
      • Performances limitées sur les réseaux haut débit
    • Et ...



Dostları ilə paylaş:
Orklarla döyüş:

Google Play'də əldə edin


Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2017
rəhbərliyinə müraciət

    Ana səhifə