Académique Documents
Professionnel Documents
Culture Documents
Fiche de lecture
Y. Durand-Poudret
Plan
CORBA, COM ?
CORBA
Définition
Introduction
L’ORB : Le bus CORBA et protocole de communication IIOP
ORBIX
COSS I
COM
Définition
Introduction
RPC/DCE
CORBA vs COM
Architecture CORBA vs Architecture COM
Résumé
FAQ
Inconvénients
Futur
Questions
L'OMG a donc défini CORBA (Common Object Request Broker Architecture), une architecture respectant la
standardisation ci-dessus. Les principes de CORBA sont :
Une séparation stricte Interface/Implémentation
La transparence de la localisation des objets
La transparence de l'accès aux objets
Le typage des Object References par les interfaces
L'héritage multiple d'interfaces
IDL est le moyen par lequel une implémentation d'un objet indique à ses clients
potentiels quelles opérations sont disponibles et comment elles doivent être invoquées.
IDL a été conçu pour assurer la correspondance avec des langages de programmation.
Un compilateur IDL génère des stubs client et des skeletons serveur. Ceux-ci
automatisent les actions suivantes (en conjonction avec l'ORB):
Les factories client (un factory est un objet créant un autre)
Le codage/décodage des paramètres
La génération des implémentations des classes d'interfaces
L'enregistrement et l'activation des objets
La localisation et les liens des objets
Pour invoquer une opération sur un objet, un client doit faire appel, et être lié statiquement, au stub
correspondant. Puisque le développeur détermine, à l'écriture du code, les stubs qu'un client contient, l'invocation
statique ne peut pas accéder à de nouveaux objets qui ont été ajoutés au système plus tard. La DII fournit cette
capacité. Cette interface permet à un client, à l'exécution, de :
Découvrir de nouveaux objets
Découvrir leurs interfaces
Retrouver les définitions d'interfaces
Construire et distribuer des invocations
Recevoir les réponses
Et ceci de la part d'objets dont les stubs du client ne sont pas liés dans son module.
La DII est donc une interface de l'ORB qui comprend des routines autorisant le client et l'ORB, travaillant
ensemble, à construire et invoquer des opérations sur tout objet disponible à l'exécution.
En essence, la DII est un stub générique côté client capable de faire suivre toute requête vers tout objet, cela en
interprétant, à l'exécution, les paramètres des requêtes et les identifiants des opérations. Cependant, la flexibilité
à l'exécution fournie par la DII peut se révéler coûteuse. Par exemple, Une requête à distance faite à travers une
paire stub/skeleton générée par un compilateur peut être accomplie en une seule RPC; mais le même appel via la
DII nécessite des appels à :
Object::getinterface: pour obtenir l'objet InterfaceDef
InterfaceDef::describe: pour obtenir l'information sur les opérations supportées par l'objet
Object::createrequest: pour créer la requête
Request::addarg: pour chaque argument de la requête
Request::invoke: pour invoquer effectivement la requête
Pour une opération sans argument et un type de retour void, la DII requiert un minimum de deux appels de
fonctions, dont au moins une sera une RPC. En fait, pour la plupart des applications, particulièrement celles écrites
dans un langage compilé comme C++, il est beaucoup plus efficace de passer les requêtes à travers les stubs
statiques IDL.
L'IR est le composant de l'ORB qui fournit un stockage persistant des définitions d'interfaces, il gère et permet
l'accès à une collection de définitions d'objets spécifiés en IDL.
L'ORB peut utiliser les définitions d'objets contenues dans l'IR pour interpréter/manipuler les valeurs fournies lors
d'une requête :
Pour permettre la vérification du type des signatures des requêtes
Pour aider à fournir l'interopérabilité entre différentes implémentations d'ORB
Comme l'interface vers les définitions d'objets maintenue dans une IR est publique, l'information maintenue dans
l'IR peut aussi être utilisée par des clients et des services. Par exemple, l'IR peut être utilisé :
Pour gérer l'installation et la distribution des définitions d'interfaces
Pour fournir des composants dans un environnement CASE (browser d'interface)
Pour fournir l'information interface aux compilateurs
Pour fournir des composants dans des environnements utilisateurs finaux (un constructeur de menus)
L'IR utilise des modules pour grouper des interfaces et pour naviguer à travers ces groupes au moyen de leurs
noms. Un module peut contenir :
Des constantes
Des définitions de types
Des exceptions
Des définitions d'interfaces
D'autres modules
La spécification de CORBA pour l'IR définit seulement des opérations pour retrouver de l'information dans l'IR. Il
peut y avoir plusieurs manières d'insérer de l'information dans l'IR (compiler des définitions IDL, construire des
objets repository a travers la DII, copier des objets d'une IR à une autre...)
Un Object Adapter est l'interface principale pour une implémentation objet pour accéder aux services
fournis par un ORB. On s'attend à ce qu'il y ait peu d'OA disponibles, avec des interfaces appropriées à
des types spécifiques d'objets.
L'éventail important des granularités, temps de vie, politiques et styles d'implémentations d'un objet
rend difficile pour l'ORB Core la fourniture d'une seule interface pratique et efficace pour tous les
objets. Ainsi, à travers les OA, il est possible pour l'ORB de cibler des groupes particuliers
d'implémentations objet qui ont des besoins similaires.
Le BOA est une interface visant à supporter un large éventail d'implémentations objet. Il fournit les
fonctions suivantes :
Génération et interprétation des ObjRef
Authentification du principal effectuant l'appel
Activation/désactivation des objets individuels
Activation/désactivation de l'implémentation
Invocation des méthodes à travers des skeletons
Le BOA supporte des implémentations objet construites d'un ou plusieurs programmes. Il communique
avec ces programmes en utilisant les facilités du système d'exploitation. Il nécessite donc des
informations qui sont, de façon inhérente, non-portables. Bien qu'il ne définisse pas cette information,
le BOA définit le concept d'une Implementation Repository qui peut détenir cette information,
autorisant chaque système à installer et démarrer des implémentations de manière appropriée à
chaque système.
ORBIX inclus aussi plusieurs programmes qui étendent les capacités de l’ORB
De plus ORBIX est un ORB qui combine les fonctionnalités standard de CORBA et intègre une
suite d’autres services comme OrbixNames, OrbixEvents, OrbixOTS, and OrbixSSL.
Les services standards de CORBA comme le “Naming Service” et “Event Service” (OrbixEvents) sont implémenté
et clairement identifié comme processus avec des exécutables associés. Ils peuvent être éxécutés sur une ou
plusieurs machines
Le schéma nous montre aussi que Orbix est ouvert, il peut être étendu avec d’autres solution basé sur CORBA ou
autres
Wikipedia : Component Object Model (COM) est une interface standard pour
les composants logiciels mis en place par Microsoft en 1993. Il est utilisé
pour permettre la communication interne et la dynamique de création de
l'objet dans un large éventail de langages de programmation. Le terme COM
est souvent utilisé dans les industrie du développement logiciel comme un
terme général qui englobe la OLE, OLE Automation, ActiveX, COM + et
DCOM technologies.
L'essence de COM est l’implémentation d’objets qui peuvent être utilisés
dans des environnements différents de celui sur lequel ils ont été créés.
COM permet de réutiliser ces objets sans connaissance de leur
implémentation, comme il force l’utilisation des composants au travers de
leur interface, celle-ci étant distincte de son implémentation.
COM ? Pour réaliser cet objectif, Microsoft a dû fournir un standard de communication entre les différentes
applications qui voulaient être OLE. Ce standard de communication, définit la méthode à employer pour accéder
aux fonctionnalités des objets OLE, ainsi que les principaux services qui peuvent être nécessaires lors de
l'intégration d'objets. Les programmeurs désirant réaliser une application OLE devaient se conformer au protocole
d'appel du standard et fournir un certain nombre des services définis dans OLE. Ce standard a été conçu de
manière ouverte, c'est à dire qu'il n'est pas nécessaire de fournir tous les services définis dans OLE pour être
fonctionnel. Cependant, plus un objet OLE offre de services, meilleure son intégration est. De même, plus une
application est capable d'utiliser des services, plus elle est fonctionnelle avec les objets qui fournissent ces
services. Par ailleurs, il est possible de définir des services différents de ceux définis dans OLE, le système est donc
également extensible. Le standard de communication qui a été défini se nomme COM, ce qui signifie Component
Object Model, ou Modèle Objet de Composants. La plupart des services sont définis dans OLE, cependant, COM lui-
même utilise un certain nombre de services. La limite entre ce qui est défini par COM et ce qui est défini par OLE
est donc floue, mais en principe, les services COM sont tous des services systèmes. Comme on l'a dit, initialement,
OLE devait permettre l'intégration des objets entre applications. En fait, il s'est avéré qu'OLE faisait beaucoup plus
que cela : grâce à COM, il permettait l'écriture de composants logiciels réutilisables par différentes applications. Il
s'agit donc bien d'une technologie à composants.
DCOM ? Microsoft a ensuite complété la technologie COM afin de permettre la répartition des composants sur un
réseau. L'aspect distribué des composants COM ainsi répartis a donné le nom à cette extension de COM, que l'on
appelle simplement DCOM (pour Distributed COM). Dans la suite du document, on considérera que COM est
distribué, on utilisera donc systématiquement le terme DCOM.
Result
Reçoit le résultat de l’exécution de la procédure du RPCRuntime (Dans l’architecture COM c’est le runtime de COM
qui est utilisé),
Décode le message (unpack),
Transmet les données au client
Result
Reçoit le résultat de l’exécution de la procédure du serveur,
Forme un message (pack) avec les résultats,
Transmet les données au RPCRuntime (Dans l’architecture COM c’est le runtime de COM qui est utilisé),
DCOM supporte les objets avec des interfaces multiples alors que CORBA
permet à une interface d’hériter de plusieurs interfaces.
J’utilise les produits Microsoft ; Pourquoi devrais-je choisir CORBA plutôt que DCOM ?
DCOM est une solution spécifique de distribution Microsoft.
Les produits CORBA sont disponibles auprès de plus de 20 fournisseurs différents.
Les produits CORBA supportent Microsoft mais pas l’OS Windows.
CORBA est un excellent mécanisme de ponts entre les « Windows Desktops » et les serveurs Unix.
Compliant prog. Any (with XML java Any (with IDL Many (C+
Langs. parser, SOAP mapping +, Java,
composition) standards) VB, etc.)
COM
http://www.microsoft.com/COM/
http://windows.developpez.com/faq/dcom/
CORBA
http://www.omg.org/gettingstarted/corbafaq.htm
http://www.wikipedia.com
http://corba.developpez.com
http://www.sylbarth.com/corba/corba.html
http://www.iona.com/support/docs/orbix/gen3/33/html/orbix33cxx_intro/Chapte
r_01.html