CORBA vs COM

1
CORBA vs COM

• Urbanisation des SI NFE107
• Fiche de lecture
• Y. Durand-Poudret

2
Plan

• CORBA, COM ?
• CORBA
• Définition
• Introduction
• LORB 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

3
CORBA COM ? Intergiciels (Middleware)

• Wikipedia En informatique, un intergiciel (en
  anglais middleware) est un logiciel servant
  d'intermédiaire de communication entre plusieurs
  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.

4
CORBA Définition

• OMG (92) CORBA est lacronyme 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 protocol standard
  IIOP qui permet linteropérabilité de composants
  pouvant provenir de serveurs, de systèmes
  dexploitation, 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.

5
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 sappui 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...)
• 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

6
CORBA LORB 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.
• 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

7
CORBA LORB 2 IDL

• IDL (Interface Definition Language)
• Développer des applications distribuées flexibles
  sur des plateformes hétérogènes nécessite une
  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

8
CORBA LORB 3 IDL Exemple

• IDL d'un service minimal de gestion du compte
  d'un client
• // CompteClient.idl
• interface CompteClient
• void credit ( in unsigned long montantFRF )
• void debit ( in unsigned long montantFRF )
• long solde ( )

9
CORBA LORB 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.
• 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 à
• Objectgetinterface pour obtenir l'objet
  InterfaceDef
• InterfaceDefdescribe pour obtenir
  l'information sur les opérations supportées par
  l'objet
• Objectcreaterequest pour créer la requête
• Requestaddarg pour chaque argument de la
  requête
• Requestinvoke pour invoquer effectivement la
  requête

10
CORBA LORB 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.
• 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

11
CORBA LORB 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
  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.

12
CORBA LORB 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)

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

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

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

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

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

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

17
CORBA ORBIX 1

• ORBIX est un produit commercial phare produit par
  la société IONA basé sur larchitecture CORBA 2
• Comment ORBIX implémente CORBA ?
• Orbix est un ORB basé sur les spécifications de
  larchitecture logicielle CORBA 2, tous les
  composants Orbix et les applications communique
  en utilisation le protocole standard CORBA basé
  sur IIOP
• Les composants de lORBIX 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 lORB, incluant le DII, le DSI et
  lORB 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 lORB
• De plus ORBIX est un ORB qui combine les
  fonctionnalités standard de CORBA et intègre une
  suite dautres services comme OrbixNames,
  OrbixEvents, OrbixOTS, and OrbixSSL.

18
CORBA ORBIX 2

• ORBIX Architecture
• Larchitecture Orbix nous montre dans la partie
  basse, un nombre de serveurs et clients CORBA
  étant relié à lintranet et un serveur seul
  rattaché au système via Internet. Nous avons
  cette représentation parce quOrbix est
  intrinsèquement un système distribué.
  Larchitecture Orbix est basé sur une collection
  de composants coopérant ensemble au travers du
  réseau.
• 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 dautres solution basé
  sur CORBA ou autres

19
CORBA ORBIX 3
20
COM Définition

• Microsoft La technologie COM (Component Object
  Model) dans la famille Microsoft Windows des
  systèmes dexploitation permet à des composants
  logiciels de communiquer. COM est utilisé, par
  les développeurs, pour créer des composants
  logiciels ré-utilisables, 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 limplémentation dobjets
  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 lutilisation des composants au travers de
  leur interface, celle-ci étant distincte de son
  implémentation.

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

22
COM DCE/RPC 1

• DCE (Distributed Computing Environment, de lOSF
  (Open Software Foundation) consortium de
  fabricants dordinateur (IBM, DEC, HP, ).
• DCE est un ensemble doutils, qui tournent sur un
  OS, servant à la création et au déroulement
  dapplications distribuées.
• Lun 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

23
COM DCE/RPC 2 Coté Client

• Le  Stub  client
• Call request
• Reçoit un  call request  du client,
• Forme un message (pack) avec les spécifications
  de la procédure distante et les paramètres,
• Demande au RPCRuntime de les transmettre au stub
  serveur (Dans larchitecture COM cest le runtime
  de COM qui est utilisé).
• Result
• Reçoit le résultat de lexécution de la procédure
  du RPCRuntime (Dans larchitecture COM cest le
  runtime de COM qui est utilisé),
• Décode le message (unpack),
• Transmet les données au client

24
COM DCE/RPC 3 Coté Serveur

• Le  Stub  serveur
• Call request
• Reçoit un  call request  du RPCRuntime (Dans
  larchitecture COM cest le runtime de COM qui
  est utilisé),
• Décode le message (unpack),
• Exécute lappel de procédure locale (normalement)
  dans le serveur.
• Result
• Reçoit le résultat de lexécution de la procédure
  du serveur,
• Forme un message (pack) avec les résultats,
• Transmet les données au RPCRuntime (Dans
  larchitecture COM cest le runtime de COM qui
  est utilisé),

25
CORBA vs COMArchitecture CORBA
26
CORBA vs COMArchitecture DCOM
27
CORBA vs COMDifférences darchitecture

• On note des différences au niveau de
• La couche  basic programming architecture ,
  cest en fait ce qui est visible par les
  programmeurs.
• 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 linterface
  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

28
CORBA vs COMRésumé

• CORBA et DCOM sont fondamentalement similaires
  puisquils fournissent tous une infrastructure
  objet distribué qui par transparence permet
  dinvoquer et daccéder à des objets distants.
• 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
  dhériter de plusieurs interfaces.
• Toutes interfaces CORBA héritent de CORBAObject
  étant le constructeur qui effectue les taches
  denregistrements, de génération de référence
  dobjet, dintanciation 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

29
CORBA vs COMFAQ

• Que Choisir entre CORBA et DCOM ?
• Jutilise 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
  lOS 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 dexécution sur un serveur
  Unix. LOMG 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 lensemble cest 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
  dapplication de type  front-end .
• Si toutes les applications distribuées
  fonctionnent sous les plateformes Microsoft, DCOM
  peut être le bon choix.

30
CORBA vs COMInconvénients

• Difficultés pour les faire marcher à travers des
  firewalls et sur des machines inconnues et non
  sécurisées.
• Plus difficile à mettre en œuvre que dautres
  solutions comme les web services par exemple.

31
CORBA vs COMFutur 1
Web Service RMI CORBA DCOM
Transport Protocol Http JRMP IIOP ORPC
Data Binding XML schema (allow customized data type) Primitive, Serialized objects IDL (primitive and structure) MS IDL
Compliant prog. Langs. Any (with XML parser, SOAP composition) java Any (with IDL mapping standards) Many (C, Java, VB, etc.)
32
CORBA vs COMFutur 2
Web Services RMI CORBA DCOM
Interface Description WSDL Interface of server objects IDL MS IDL
Remote Call By SOAP message Get references of server objects Get reference of server object Get Pointer of server objects
Routine Stub Proxy DII Client stub or proxy Server skeleton Client stub or proxy Server skeleton Client proxy Server stub
33
Bibliographie

• CORBA, COM et les autres
• Middleware et Internet de Daniel Serain
• http//research.microsoft.com/en-us/um/people/ymwa
  ng/papers/html/dcomncorba/s.html
• 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/htm
  l/orbix33cxx_intro/Chapter_01.html

34
Questions

• ?