CORBA vs COM

Plan
• CORBA, COM ?

• CORBA

NFE107
• 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 2
CORBA COM ? : Intergiciels
(Middleware)
• Wikipedia : En informatique, un intergiciel (en anglais middleware) est
un logiciel servant d'intermédiaire de communication entre plusieurs

NFE107
applications, généralement complexes ou distribuées sur un réseau
informatique.

• Middleware et Internet de Daniel Serain : Le middleware est une

Couche de logiciels située entre le système d'exploitation et les
applications, permettant l'échange d'informations entre celles-ci.

3
CORBA : Définition
• OMG (92): CORBA est l’acronyme de Common Object Request Broker Architecture, ce
fournisseur indépendant offre une architecture et une infrastructure permettant aux
applications informatiques de travailler ensemble au travers du réseau. CORBA utilise le

NFE107
protocol standard IIOP qui permet l’interopérabilité de composants pouvant provenir de
serveurs, de systèmes d’exploitation, de réseaux ou de langages de programmation
similaires ou différents.
L’ interopérabilité est la capacité que possède un produit ou un système, dont les interfaces sont intégralement connues, à fonctionner avec d'autres produits ou systèmes existants ou futurs et ce sans restriction d'accès ou de mise
en œuvre. Il convient de distinguer « interopérabilité » et « compatibilité ». Pour être simple, on peut dire qu'il y a compatibilité quand deux produits ou systèmes peuvent fonctionner ensemble et interopérabilité quand on sait
pourquoi et comment ils peuvent fonctionner ensemble. Autrement dit, on ne peut parler d'interopérabilité d'un produit ou d'un système que si on en connaît intégralement toutes ses interfaces.

• Wikipedia : CORBA, acronyme de Common Object Request Broker Architecture, est une
architecture logicielle, pour le développement de composants et d'Object Request Broker
ou ORB. Ces composants, qui sont assemblés afin de construire des applications complètes,
peuvent être écrits dans des langages de programmation distincts, être exécutés dans des
processus séparés, voire être déployés sur des machines distinctes. Corba est un standard
maintenu par l'Object Management Group.

4
CORBA : Introduction
• L'OMG a défini un modèle de référence pour des applications distribuées utilisant des techniques orientées objet. Ce modèle comprend quatre points de
standardisation :
• Object Model: c'est un modèle générique pour assurer la communication avec des systèmes orientés objet conformes au modèle de l'OMG
• Object Request Broker (ORB): c'est l'élément clé de communication, il assure la distribution des messages (Il s’appui sur le protocole IIOP (Internet Inter-ORB Procotol)
• ObjectServices (ou encore CORBAServices): ces services fournissent les principales fonctions de base nécessaires à la gestion des objets (nommage, persistance,gestion
d'évènements...)

NFE107
• CommonFacilities (ou encore CORBAFacilities): ce sont des utilitaires destinés aux applications

 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
5
CORBA : L’ORB #1
• L'ORB fournit les mécanismes par lesquels des objets font des requêtes et reçoivent des
réponses, et ce de manière transparente.

NFE107
• Il fournit également l'interopérabilité entre des applications sur différentes machines dans
des environnements distribués hétérogènes et il interconnecte sans coutures de multiples
systèmes objets.
• L'ORB est défini plutôt par ses interfaces que comme un unique composant.

• Il comprend les composants suivants :

• ORB Core/ORB interface
• Interface Definition Language (IDL)
• Dynamic Invocation Interface (DII)
• Interface Repository (IR)
• Basic Object Adapter (BOA)

• L'ORB est responsable de tous les mécanismes nécessaires pour :

• Trouver l'implémentation de l'objet pour la requête
• Préparer cette implémentation à recevoir la requête
• Communiquer les données constituant la requête
6
CORBA : L’ORB #2 IDL
IDL (Interface Definition Language)

• Développer des applications distribuées flexibles sur des plateformes hétérogènes nécessite une

NFE107
séparation stricte interface/implémentation(s). IDL aide à accomplir cette séparation.
En effet, IDL est un langage de définition d'interface orienté objet. Il définit les types des objets en
spécifiant leurs interfaces. Une interface consiste en un jeu d'opérations et de paramètres pour ces
opérations.

• 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

7
CORBA : L’ORB #3 IDL Exemple

• IDL d'un service minimal de gestion du compte d'un client

// CompteClient.idl

NFE107
interface CompteClient {
void credit ( in unsigned long montantEuros);
void debit ( in unsigned long montantEuros );
long solde ( );
};

8
CORBA : L’ORB #4 DII
DII (Dynamic Invocation Interface)
• L'interface d'invocation dynamique d'un ORB autorise la création et l'invocation dynamique de requêtes. Un client utilisant cette
interface pour envoyer une requête à un objet obtient la même sémantique qu'un client utilisant l'opération stub générée à partir de
la spécification de type IDL.

NFE107
• 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 9
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.
CORBA : L’ORB #5 IR
IR (Interface Repository)

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

NFE107
• 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
10
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...)
CORBA : L’ORB #6 BOA
BOA (Basic Object Adapter)

• 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

NFE107
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.
11
CORBA : L’ORB #7 BOA
BOA (Basic Object Adapter)
Le BOA est donc l'interface qui permet aux implémentations objet de pouvoir communiquer avec l'ORB et d'accéder à ses services (cf. Fig 2: Structure et scénario
d'un BOA)

NFE107
1. Le BOA démarre un programme pour fournir l'implémentation objet
2. L'implémentation objet notifie le BOA que son initialisation est terminée et qu'elle est prête à manipuler des requêtes.
3. Quand la première requête pour un objet particulier arrive, l'implémentation est avertie qu'elle doit activer l'objet.
4. Dans les requêtes suivantes, le BOA appelle la méthode appropriée en utilisant les skeletons.
5. A certains moments, l'implémentation objet peut accéder aux services du BOA tels que création d'un objet, désactivation... 12
CORBA : COSS I #1

• Avant de détailler les services du COSS I (Common Object Service Specification I) à proprement dit, décrivons l'architecture générale d'un
ObjectService. Un service est caractérisé par les interfaces qu'il fournit et par les objets qui fournissent ces interfaces. Un service peut impliquer
un seul objet (par exemple un timer), plusieurs objets qui fournissent le même type d'interface (par exemple des objets threads) ou plusieurs
objets qui fournissent des types d'interfaces distincts qui héritent d'un type d'interface de service (par exemple tout objet fournissant le service
Cycle de Vie).

NFE107
 Chaque ObjectService fournit son service à un jeu d'utilisateurs qui sont typiquement des applications ou des
Common Facilities, mais qui peuvent aussi être d'autres ObjectServices (cf. Fig 3).
13
CORBA : COSS I #2 Naming Service

• Le service de nommage fournit le principal mécanisme à travers lequel la plupart des objets d'un système basé-
ORB situent les objets qu'ils veulent utiliser. Pour cela, il utilise des noms. Un nom est une séquence ordonnée de
composants. Chaque composant sauf le dernier nomme un contexte, le dernier dénote les objets liés par le nom.
Un composant est composé de deux attributs :

NFE107
• Attribut identifier: identifiant
• Attribut kind: type du composant

• Un contexte est un jeu de liens noms-objets dans lequel chaque nom est unique.

• Le service de nommage permet :

• De lier un nom à un objet, ceci dans un contexte de nommage
• De résoudre un nom, i.e., déterminer l'objet associé au nom dans un contexte donné

• Les implémentations de ce service peuvent être spécifiques à une application ou bien basées sur une variété de
systèmes de nommage actuellement disponibles, ceci grâce à la généralité du modèle utilisé et car les noms sont
traités dans leur forme structurelle. Puisque les valeurs des attributs des noms ne sont ni assignées ni interprétée
par ce service, les logiciels de plus haut niveau n'ont pas de contraintes en terme de politique sur l'utilisation ou la
gestion de ces valeurs.

• Par l'utilisation de bibliothèques de noms, la manipulation des noms est simplifiée, et les noms peuvent être
indépendants de la représentation, permettant ainsi à cette représentation d'évoluer sans requérir de
changements du côté client.

• La localisation d'applications est facilitée par l'indépendance des noms au niveau syntaxique et par la présence de
l'attribut kind. 14
CORBA : COSS I #3 Event Service

• Dans CORBA, l'invocation standard d'une méthode consiste en une exécution synchrone d'une opération fournie par un objet. Or, pour la plupart des applications,
un modèle de communication plus découplé entre objets est nécessaire. L'OMG a donc défini un jeu d'interfaces event service qui permet la communication
asynchrone entre objets. Le modèle de l'OMG est basé sur le paradigme publish/subscribe.

NFE107
• Le service évènement définit deux rôles pour les objets: producteur et consommateur. Les producteurs fournissent les données évènement, les consommateurs
consomment ces données. La communication de ces données entre producteurs et consommateurs se fait par les requêtes CORBA standards. Les producteurs
peuvent générer des évènements sans connaitre les identités des consommateurs. De même, les consommateurs peuvent recevoir des évènements sans
connaitre les identités des producteurs.

• Il existe deux approches pour initier la communication d'évènements :

• Le modèle push: il permet à un producteur d'initier le transfert des données évènements vers le consommateur. Le producteur a donc l'initiative.
• Le modèle pull: il permet à un consommateur de solliciter des données évènements d'un producteur. Le consommateur a donc l'initiative.

• La communication elle-même peut être soit générique soit typée:

• Communication générique : toute communication se fait au moyen d'opérations push et pull génériques qui prennent un seul paramètre englobant toutes les
données évènements.
• Communication typée : toute communication se fait via des opérations définies en IDL.

• Ce service définit également des objets event channel. Un event channel est un objet qui permet à de multiples producteurs de communiquer avec de multiples
consommateurs, et ce de manière asynchrone. Un event channel est à la fois un producteur et un consommateur d'évènements ; c'est un objet CORBA standard et
donc la communication avec un event channel se fait par les requêtes CORBA standards. De plus, l'interface event channel peut être sous-typée pour supporter des
facultés étendues. Les interfaces producteur et consommateur étant symétriques, on peut chainer des event channel (pour supporter par exemple divers modèles
de filtrage des évènements).

• Ce service fournit des capacités basiques qui peuvent être configurées ensemble de façon flexible et puissante, il supporte :
• Evènements asynchrones (découplés en producteurs et consommateurs)
• Evènements fan-in
• Evènements fan-out
• Acheminement fiable d'évènements (par des implémentations appropriées d'event channel).

• Un serveur centralisé n'est pas nécessaire, ce service ne dépend d'aucun service global. De plus, les interfaces de ce service autorisent différentes qualités de
15
service, pour différents niveaux de fiabilité et permettent des extensions futures pour des fonctionnalités additionnelles. Elles peuvent être implémentées et
utilisées dans différents environnements (qu'ils supportent le multithreading ou pas). Les producteurs,consommateurs et event channel étant des objets, on peut
tirer des avantages des optimisations de performance fournies par les implémentations des ORB pour les objets locaux ou éloignés.
CORBA : COSS I #4 LifeCycle Service

• Le service cycle de vie définit les services et les conventions nécessaires à la création, la
destruction, la copie et au déplacement des objets. Puisque les environnements basés sur CORBA
supportent des objets distribués, ce service autorise les clients à exécuter ces opérations sur des
objets situés dans différents endroits.

NFE107
• Le modèle client pour la création d'objets est défini en termes d'objets factory. Un factory est un
objet qui crée un autre objet. Ce n'est pas un objet spécial, il a des interfaces IDL bien définies et
des implémentations dans un langage de programmation. Il n'y a pas d'interface standard pour un
factory, cependant ce service définit également une interface pour un factory générique, ceci
permet la définition de services de création standard. Les opérations remove, copy et move sont
définies dans une interface LifeCycleObject.
• Creation: La plupart des paramètres fournis à un opérateur create seront dépendants de l'implémentation, une
signature IDL standardisée et universelle pour la création n'est donc pas possible. Les signatures IDL pour la création
seront définies pour différentes sortes d'objets factory mais elles seront spécifiques au type, à l'implémentation et au
mécanisme de stockage persistant de l'objet devant être crée.
• Deletion: Un opérateur remove est défini pour tout objet supportant l'interface LifeCycleObject. Ce modèle pour la
suppression supporte tout paradigme pour garantir l'intégrité référentielle. Le service décrit un support pour les deux
paradigmes les plus communs, basés sur les relations de référence et de contenu. Un seul type de suppression est
autorisé, une opération différente devra être utilisée pour archiver un objet.

16
CORBA : ORBIX #1
ORBIX est un produit commercial phare produit par la société IONA basé sur l’architecture CORBA 2

Comment ORBIX implémente CORBA ?

NFE107
• Orbix est un ORB basé sur les spécifications de l’architecture logicielle CORBA 2, tous les composants Orbix et les
applications communique en utilisation le protocole standard CORBA basé sur IIOP

• Les composants de l’ORBIX sont les suivants :

• Le compilateur IDL compile les « IDL definitions » et produit du code C++ qui permet de développer les « clients stub » et les « server
skeleton »
• La library ORBIX met en œuvre plusieurs composants of l’ORB, incluant le DII, le DSI et l’ORB core
• Le démon ORBIX est un processus exécuté sur chaque serveur et implémente plusieurs ORB components, incluant l’« Implementation
Repository »
• L’ « ORBIX Interface Repository server » étant le processus qui implémente l’« Interface Repository »

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

17
COM : Définition
• Microsoft : La technologie COM (Component Object Model) dans la famille Microsoft
Windows des systèmes d’exploitation permet à des composants logiciels de communiquer.
COM est utilisé, par les développeurs, pour créer des composants logiciels ré-utilisables,

NFE107
pour créer des applications réparties à partir de composants liés entre eux, et de tirer profit
des services Windows. La famille des technologies COM comprend COM, COM+,
Distributed COM (DCOM) et des contrôles ActiveX.

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

19
COM : Introduction
• OLE ? OLE est l'abréviation de Object Linking and Embedding, ce qui signifie Intégration d'objets et Lien sur des objets. OLE est une
technologie qui a été développée par Microsoft, initialement dans le but de permettre la programmation d'objets capables d'être insérés
dans des applications réceptacles soit par intégration complète, soit par référence (ce que l'on appelle une liaison). Ce but a été atteint
pour la plupart des applications et apparaît à présent dans le menu Coller | Collage spécial. Les objets intégrés ou liés sont capables de
s'afficher dans l'application qui les contient. Ils sont également capables de fournir un certain nombre de services standards permettant

NFE107
leur manipulation (ces services peuvent être la sauvegarde de leur état, la capacité à être édité, etc...). OLE est donc un remplacement
efficace des liaisons DDE.

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

20
COM : DCE/RPC #1
• DCE (Distributed Computing Environment, de l’OSF (Open Software
Foundation) consortium de fabricants d’ordinateur (IBM, DEC, HP, …).

NFE107
• DCE est un ensemble d’outils, qui tournent sur un OS, servant à la
création et au déroulement d’applications distribuées.

• L’un de ces composants est RPC (Remote Procedure Call) basé sur le
protocole ORPC (Object RPC). RPC est la base de toute
communication dans DCE.

• RPC-DCE utilisent la génération automatique de stubs

21
CORBA vs COM
Architecture CORBA

NFE107 24
CORBA vs COM
Architecture DCOM

NFE107 25
CORBA vs COM
Différences d’architecture
• On note des différences au niveau de :
• La couche « basic programming architecture », c’est en fait ce qui est visible par
les programmeurs.

NFE107
• DCOM : La Class factory permet de créer de façon standard des objets

• La couche intermédiaire est la « remoting architecture » qui rend transparente

l’interface des pointeurs ou des références significatives objet.
• DCOM : On parle parfois de proxy pour le « client stub »
• CORBA : Le serveur stub est appelé le skeleton

• La couche inférieure représente le protocole de communication utilisé, qui étend

la « remoting architecture ».
• DCOM : protocole ORPC
• CORBA : protocole IIOP

26
CORBA vs COM
Résumé
• CORBA et DCOM sont fondamentalement similaires puisqu’ils fournissent tous une
infrastructure objet distribué qui par transparence permet d’invoquer et d’accéder à des objets
distants.

NFE107
• Architecte permettant la réutilisation de code et de services sur Internet

• DCOM supporte les objets avec des interfaces multiples alors que CORBA permet à une interface
d’hériter de plusieurs interfaces.

• Toutes interfaces CORBA héritent de CORBA::Object étant le constructeur qui effectue les taches
d’enregistrements, de génération de référence d’objet, d’intanciation de « skeleton », etc… Dans
DCOM ces taches sont effectuées soit explicitement par le serveur soit dynamiquement par le
run-time DCOM

• Les spécifications DCOM contiennent de nombreux détails qui traitent des problèmes de mise en
oeuvre que ne spécifie pas CORBA

27
CORBA vs COM
FAQ
Que Choisir entre CORBA et DCOM ?

• J’utilise les produits Microsoft ; Pourquoi devrais-je choisir CORBA plutôt que DCOM ?
• DCOM est une solution spécifique de distribution Microsoft.

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

• Dois-je chosir entre DCOM et CORBA ?

• Non. Les applications distribuées peuvent être développées en utilisant CORBA ou DCOM. Par exemple des objets COM peuvent accéder à
des objets CORBA en cours d’exécution sur un serveur Unix. L’OMG a défini une sorte de « passerelle » qui standardise les échanges entre
COM et CORBA.

• Est-ce que CORBA est plus mature que DCOM ?

• CORBA existe depuis 1990. Des solutions commerciales sont disponibles depuis 1992.
• DCOM était disponible en beta version en 1996.
• CORBA a eu plus de temps pour mûrir et il y a un grande nombre de compagnies qui ont développé en CORBA ORB. Dans l’ensemble c’est
cette concurrence qui a certainement contribué à rendre CORBA plus robuste.

• Quels avantages a DCOM de plus que CORBA ?

• DCOM est bien adapté à des développements d’application de type « front-end ».
• Si toutes les applications distribuées fonctionnent sous les plateformes Microsoft, DCOM peut être le bon choix.
• DCOM peut également être utilisé avec CORBA. La question n’est pas toujours devrais-je utiliser CORBA ou DCOM ?

28
CORBA vs COM
Inconvénients
• Difficultés pour les faire marcher à travers des firewalls et sur des
machines inconnues et non sécurisées.

NFE107
• Plus difficile à mettre en œuvre que d’autres solutions comme les
web services par exemple.

29
CORBA vs COM
Futur #1
Web Service RMI CORBA DCOM

Transport Http JRMP IIOP ORPC

Protocol

Data Binding XML schema Primitive, IDL MS IDL

(allow Serialized objects (primitive
customized and
data type) structure)

Compliant prog. Any (with XML java Any (with IDL Many (C+
Langs. parser, SOAP mapping +, Java,
composition) standards) VB, etc.)

NFE107 30
CORBA vs COM
Futur #2
Web Services RMI CORBA DCOM

Interface WSDL Interface of IDL MS IDL

Description server
objects

Remote Call By SOAP message Get Get Get Pointer of

references reference of server objects
of server server
objects object
Routine Stub Client: Client: stub Client: proxy
Proxy stub or or proxy Server: stub
proxy Server:
DII
Server: skeleton
skeleton

NFE107 31
Bibliographie
CORBA, COM et les autres
• Middleware et Internet de Daniel Serain
• http://research.microsoft.com/en-us/um/people/ymwang/papers/html/dcomncorba/s.html

NFE107
• http://www.flydragontech.com/ebcourseWinter2008/9_comparison.ppt

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/Chapter_01.html

32
Questions

NFE107
33