Common Object Request Broker Architecture – Standard de l’OMG définissant l’architecture logicielle nécessaire pour permettre à des parties de programmes (objets) de communiquer avec d’autres, issues d’environnements différents. Modèle d’architecture Client/Serveur distribué orienté objet. Ce modèle a été spécifié pour la première fois par l’OMG (Object Managment Group) en 1989, la première version de CORBA étant apparue en 1992.
CORBA repose sur un modèle orienté objet Client/Serveur d’abstraction et de coopération entre applications réparties. Chaque application peut exporter certaines fonctionnalités, appelées aussi Services, sous la forme d’objet CORBA : c’est la composante d’abstraction (structuration) du modèle. Les interactions entre les applications sont alors matérialisées par des invocations à distance des méthodes des objets : c’est la partie coopération du système.
CORBA est une spécification normative basée sur les cinq grands domaines constituant les systèmes objets distribués :
- Un langage de description des objets, appelé IDL (Interface Definition Language) et une infrastructure de distribution d’objet, appelé ORB (Object Request Broker).
- Une description des services communs nécessaires à tous les objets applicatifs. Ces spécifications, appelées CORBA Services, couvrent entre autres des services de nommages, de persistance, d’annuaire, de cycles de vie des objets… Ces services, tous décrits dans l’IDL, sont nécessaires dans les systèmes distribués, car ils permettent d’isoler les clients et les serveurs des détails d’implémentation dus à leur localisation et à leur état d’activation.
- Une description des services nécessaires aux applications et non plus seulement aux objets. Ces spécifications sont appelées CORBAFacilities et permettent d’offrir des services de plus haut niveau comme l’interface utilisateur, l’administration des systèmes et réseaux… Le but des CORBA Facilities est de définir des objets préfabriqués pour les applications récurrentes de l’entreprise, comme la conception de documents, l’administration des systèmes informatiques…
- Un ensemble de descriptions de services spécialisés par domaines d’activité, tels que les télécommunications, la santé, la finance… Sous le nom de Domain Services, ces spécifications visent à offrir une description standard des objets et des services communs à une activité donnée.
- Une spécification normative d’interopérabilité entre ORB. Cette spécification, permettant la communication entre différents ORB, est devenu nécessaire devant le nombre d’implémentations, souvent incompatibles entre elles, de CORBA. Le Bus CORBA est l’entité qui permet l’acheminement des requêtes de l’application cliente vers l’objet invoqué. Ainsi, par son intermédiaire, les objets vont pouvoir dialoguer entre eux, sans se soucier des problèmes d’hétérogénéité.
Le bus CORBA présente les caractéristiques suivantes :
- Une liaison avec « tous « les langages de programmation grâce à l’IDL.
- La transparence des invocations : les requêtes aux objets semblent toujours être locales, le bus CORBA se chargeant de les acheminer en utilisant le canal de communication le plus approprié.
- L’invocation statique et dynamique : ces deux mécanismes complémentaires permettent de soumettre les requêtes aux objets. En statiques, les invocations sont contrôlées à la compilation. En dynamique, les
invocations doivent être contrôlées à l’exécution. - Un système auto-descriptif : les interfaces sont connues du bus et sont aussi accessibles par les programmes par l’intermédiaire du référentiel d’interface.
- L’activation automatique et transparente des objets : les objets sont en mémoire uniquement s’ils sont utilisés par des applications clientes.
- L’interopérabilité entre bus : à partir de la norme CORBA 2.0, un protocole générique de transport des requêtes (GIOP pour General Inter-ORB Protocol) a été défini, permettant l’interconnexion de bus CORBA
provenant de fournisseurs distincts. L’une des implémentations de GIOP est IIOP (Internet Inter-ORB Protocol) ; elle fonctionne au-dessus de TCP/IP.