Common Object Request Broker Architecture
Pour l’article ayant un titre homophone, voir Korba.
Cet article ne cite pas suffisamment ses sources ().
Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?
| CORBA | ||
 | ||
| Éditeur | Object Management Group (OMG) | |
|---|---|---|
| Genre | Spécification formelle | |
| État | Version 3.3 | |
| Première publication | ||
| Dernière publication | ||
| Standard | omg.org/spec/CORBA | |
| Site web | www.corba.org | |
| modifier |
||
CORBA, acronyme de Common Object Request Broker Architecture, est une architecture logicielle pour le développement de composants et d’object request broker (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.
À la mode dans les années 1990, CORBA n'est plus qu'une technologie de niche depuis la moitié des années 2000.
Le standard CORBA est maintenu par l’Object Management Group.
Historique
[modifier | modifier le code]CORBA a été à la mode dans les années 1990. Dans les années 2000, des technologies telles que SOAP et Distributed Component Object Model de Microsoft ont éclipsé CORBA, qui est devenu une technologie de niche[1].
CORBA est une norme définie en 1992 par des constructeurs de matériel informatique et des éditeurs de logiciels (dont Sun, Oracle, IBM…) regroupés au sein d’un consortium nommé Object Management Group (OMG).
C'est avec la version 2 de CORBA (fin 1995) qu'est apparu le protocole standard IIOP et l’interface description language (IDL).
La version 2.3 rend interopérables CORBA et RMI.
La version 3 de CORBA spécifie seize types de services (nommage et annuaire des objets, cycle de vie, notification d'événements, transaction, relations et parallélisme entre objets, stockage, archivage, sécurité, authentification et administration des objets, gestion des licences et versions…) mais tous ne sont pas mis en œuvre dans les ORB du marché.
Choix de conception de CORBA
[modifier | modifier le code]La technologie CORBA adopte une approche essentiellement orientée objet : du point de vue d'un langage de programmation, toutes les méthodes sont virtuelles ; il n'y a ni polymorphisme paramétrique, ni méthode protégée ou privée, ni surcharge d'opérateur, ni fonction de première classe. Chaque composant est décrit sous la forme d'une interface écrite en langage IDL.
Une correspondance a été spécifiée entre le langage IDL et différents langages de programmation. Des précompilateurs dédiés permettent de générer automatiquement le squelette de l'interface IDL dans un langage donné, en produisant aussi le code qui assure l'appel de fonctions distantes et le traitement des résultats. Ce code porte le nom de stub du côté client et de skeleton du côté serveur. Un module dont l'interface est spécifiée en IDL pourra ainsi être programmé en C , tandis que des modules Java qui l'utiliseraient effectueraient en fait des appels sur une interface Java générée à partir du même IDL, l'architecture CORBA assurant l'acheminement des appels entre les processus.
Applications et composants CORBA mélangent typages statique et dynamique. Ainsi, chaque composant est décrit statiquement par une interface mais les composants qui utilisent celui-ci doivent vérifier dynamiquement que l'interface est effectivement implémentée.
Développement CORBA
[modifier | modifier le code]
Interfaces
[modifier | modifier le code]Object Request Broker (ORB)
[modifier | modifier le code]L'Object Request Broker (ORB), est un composant fondamental de l'architecture CORBA ; sa mission est de faciliter la communication entre objets : il est chargé d'envoyer les requêtes aux objets et de retourner les réponses au client qui les a invoqués par un processus de sérialisation.
Interface Definition Language (IDL)
[modifier | modifier le code]Le langage de définition des interfaces ou IDL (Interface Definition Language), est utilisé pour définir les interfaces entre les composants d'une application et permettre l'interopérabilité entre différentes technologies.
IDL ne peut définir que des interfaces, pas d'implémentations. En spécifiant les interfaces entre objets en CORBA, IDL se charge d'assurer l'indépendance avec les langages de programmation utilisés : un module dont l'interface est spécifiée en IDL pourra ainsi être programmé en C , tandis que des modules Java qui l'utiliseraient effectueraient en fait des appels sur une interface Java générée à partir du même IDL, l'architecture CORBA assurant l'acheminement des appels entre les processus.
Implantations
[modifier | modifier le code]Composition
[modifier | modifier le code]Durant l'exécution, les communications entre composants sont gérées par un ORB.
Exemples d'applications
[modifier | modifier le code]La technologie Bonobo du projet GNOME utilise CORBA.
C'est également le cas du framework SCADA 'TANGO' de l'ESRF.
Bibliographie
[modifier | modifier le code]- Annick Fron 2007, Architectures réparties en Java, (ISBN 978-2-10-051141-9).
- J. M. Geib, C. Gransart, P. Merle, 'CORBA : des concepts à la pratique', Masson, 1997.
Voir aussi
[modifier | modifier le code]Articles connexes
[modifier | modifier le code]- RPC et MoM
- .NET
- XPCOM
- D-Bus
- COM : Component Object Model
- OLE : Object Linking and Embedding
- RMI
- Middleware
Références
[modifier | modifier le code]- (en) Michi Henning, « The Rise and Fall of CORBA », ACM Queue, (lire en ligne)
Liens externes
[modifier | modifier le code]- Site officiel de l'OMG concernant le bus à objets répartis CORBA : On y trouve les spécifications du bus, des protocoles de communication, des services objet communs…
