Architecture de courtier de demandes d'objets communs - Common Object Request Broker Architecture

Architecture de courtier de demandes d'objets communs
Statut Publié
Année commencée 1991 ; il y a 30 ans ( 1991 )
Dernière version 3.3
octobre 2012 ; il y a 8 ans ( 2012-10 )
Organisation Groupe de gestion des objets
Abréviation CORBA
Site Internet CORBA .org

La Common Object Request Broker Architecture ( CORBA ) est une norme définie par l' Object Management Group (OMG) conçue pour faciliter la communication des systèmes déployés sur diverses plates-formes. CORBA permet la collaboration entre des systèmes sur différents systèmes d'exploitation, langages de programmation et matériel informatique. CORBA utilise un modèle orienté objet bien que les systèmes qui utilisent CORBA ne doivent pas nécessairement être orientés objet. CORBA est un exemple du paradigme de l' objet distribué .

Aperçu

CORBA permet la communication entre des logiciels écrits dans différentes langues et exécutés sur différents ordinateurs. Les détails de mise en œuvre de systèmes d'exploitation, de langages de programmation et de plates-formes matérielles spécifiques sont tous soustraits à la responsabilité des développeurs qui utilisent CORBA. CORBA normalise la sémantique des appels de méthode entre les objets d'application résidant soit dans le même espace d'adressage (application) soit dans des espaces d'adressage distants (même hôte ou hôte distant sur un réseau). La version 1.0 est sortie en octobre 1991.

CORBA utilise un langage de définition d'interface (IDL) pour spécifier les interfaces que les objets présentent au monde extérieur. CORBA spécifie ensuite un mappage d'IDL vers un langage d'implémentation spécifique comme C++ ou Java . Des mappages standard existent pour Ada , C , C++ , C++11 , COBOL , Java , Lisp , PL/I , Object Pascal , Python , Ruby et Smalltalk . Des mappages non standard existent pour C# , Erlang , Perl , Tcl et Visual Basic implémentés par des courtiers de requêtes d'objets (ORB) écrits pour ces langages.

La spécification CORBA dicte qu'il doit y avoir un ORB à travers lequel une application interagirait avec d'autres objets. Voici comment il est mis en œuvre dans la pratique :

  1. L'application initialise l'ORB et accède à un adaptateur d'objet interne , qui gère des éléments tels que le comptage de références , les stratégies d'instanciation d'objet (et de référence) et les stratégies de durée de vie des objets.
  2. L' adaptateur d' objets est utilisé pour enregistrer les instances des classes de code générées . Les classes de code générées sont le résultat de la compilation du code IDL utilisateur, qui traduit la définition de l'interface de haut niveau en une base de classe spécifique au système d'exploitation et au langage à utiliser par l'application utilisateur. Cette étape est nécessaire pour appliquer la sémantique CORBA et fournir un processus utilisateur propre pour l'interfaçage avec l'infrastructure CORBA.

Certains mappages IDL sont plus difficiles à utiliser que d'autres. Par exemple, en raison de la nature de Java, le mappage IDL-Java est assez simple et rend l'utilisation de CORBA très simple dans une application Java. Ceci est également vrai pour le mappage IDL vers Python. Le mappage C++ nécessite que le programmeur apprenne les types de données antérieurs à la bibliothèque de modèles standard (STL) C++ . En revanche, le mappage C++11 est plus facile à utiliser, mais nécessite une utilisation intensive de la STL. Étant donné que le langage C n'est pas orienté objet, le mappage IDL vers C nécessite un programmeur C pour émuler manuellement les fonctionnalités orientées objet.

Afin de construire un système qui utilise ou implémente une interface objet distribuée basée sur CORBA, un développeur doit obtenir ou écrire le code IDL qui définit l'interface orientée objet avec la logique que le système utilisera ou implémentera. En règle générale, une implémentation ORB comprend un outil appelé compilateur IDL qui traduit l'interface IDL dans la langue cible pour une utilisation dans cette partie du système. Un compilateur traditionnel compile ensuite le code généré pour créer les fichiers d'objets pouvant être liés à utiliser dans l'application. Ce diagramme illustre comment le code généré est utilisé au sein de l'infrastructure CORBA :

Illustration de l'autogénération du code d'infrastructure à partir d'une interface définie à l'aide du CORBA IDL

Cette figure illustre le paradigme de haut niveau pour les communications interprocessus à distance utilisant CORBA. La spécification de CORBA autres adresses typage des données, des exceptions, des protocoles de réseau, les délais d' attente de communication, etc. Par exemple: Normalement , le côté serveur a l' adaptateur objet portable (POA) qui redirige les appels soit aux locaux domestiques ou (pour équilibrer la charge) à la autres serveurs. La spécification CORBA (et donc cette figure) laisse à l'application le soin de définir divers aspects du système distribué, notamment la durée de vie des objets (bien que la sémantique de comptage de références soit disponible pour les applications), la redondance/le basculement, la gestion de la mémoire, l'équilibrage de charge dynamique et l'application. modèles orientés tels que la séparation entre sémantique affichage/données/contrôle (par exemple voir Modèle–vue–contrôleur ), etc.

En plus de fournir aux utilisateurs un langage et une spécification d' appel de procédure à distance (RPC) indépendante de la plate-forme , CORBA définit les services couramment nécessaires tels que les transactions et la sécurité, les événements, l'heure et d'autres modèles d'interface spécifiques au domaine.

Historique des versions

Ce tableau présente l'historique des versions de la norme CORBA.

Version Date de la version Points forts
1,0 octobre 1991 Première version, mappage C
1.1 Février 1992 Interopérabilité, mappage C++
1.2 décembre 1993 -
2.0 août 1996 Première mise à jour majeure de la norme, également baptisée CORBA 2
2.1 août 1997 -
2.2 Février 1998 Cartographie Java
2.3 juin 1999 -
2.4 août 2000 -
2.5 Septembre 2001 -
2.6 décembre 2001 -
3.0 juillet 2002 Deuxième mise à jour majeure de la norme, également appelée CORBA 3
CORBA Component Model (CCM)
3.0.1 novembre 2002 -
3.0.2 décembre 2002 -
3.0.3 Mars 2004 -
3.1 janvier 2008 -
3.1.1 Août 2011 Adopté en tant qu'édition 2012 de la norme ISO/IEC 19500
3.2 novembre 2011 -
3.3 novembre 2012 Ajout de ZIOP

Serviteurs

Un serviteur est la cible d'appel contenant des méthodes pour gérer les appels de méthode distants . Dans les versions plus récentes de CORBA, l'objet distant (côté serveur) est divisé en objet (qui est exposé aux invocations distantes) et serviteur (auquel la première partie transmet les appels de méthode) . Il peut s'agir d'un serviteur par objet distant , ou le même serviteur peut prendre en charge plusieurs (éventuellement tous) objets, associés à l' adaptateur d'objet portable donné . Le serviteur de chaque objet peut être défini ou trouvé "une fois pour toutes" (activation du serviteur) ou choisi dynamiquement à chaque fois que la méthode sur cet objet est invoquée (emplacement du serviteur). Le localisateur de serviteur et l'activateur de serviteur peuvent tous deux transférer les appels vers un autre serveur. Au total, ce système offre un moyen très puissant d'équilibrer la charge, en répartissant les requêtes entre plusieurs machines. Dans les langages orientés objet, l' objet distant et son serviteur sont des objets du point de vue de la programmation orientée objet.

L'incarnation est l'acte d'associer un serviteur à un objet CORBA afin qu'il puisse servir des requêtes. L'incarnation fournit une forme concrète de serviteur pour l'objet virtuel CORBA. L'activation et la désactivation se réfèrent uniquement aux objets CORBA, tandis que les termes incarnation et éthéréalisation se réfèrent aux serviteurs. Cependant, les durées de vie des objets et des serviteurs sont indépendantes. Vous incarnez toujours un serviteur avant d'appeler activate_object(), mais l'inverse est également possible, create_reference() active un objet sans incarner de serviteur, et l'incarnation de serviteur se fait ensuite à la demande avec un Servant Manager.

le L'adaptateur d'objet portable (POA) est l'objet CORBA responsable de la division du gestionnaire d'appel à distance côté serveur en l'objetdistantet sonserviteur. L'objet est exposé pour les appels distants, tandis que le serviteur contient les méthodes qui traitent réellement les demandes. Le serviteur pour chaque objet peut être choisi soit statiquement (une fois) soit dynamiquement (pour chaque invocation distante), dans les deux cas permettant le renvoi d'appel vers un autre serveur.

Côté serveur, les POA forment une structure arborescente, où chaque POA est responsable d'un ou plusieurs objets servis. Les branches de cet arbre peuvent être activées/désactivées indépendamment, avoir le code différent pour l'emplacement ou l'activation du serviteur et les différentes politiques de traitement des demandes.

Caractéristiques

Ce qui suit décrit certaines des manières les plus significatives d'utiliser CORBA pour faciliter la communication entre les objets distribués.

Objets par référence

Cette référence est soit acquise via une URL ( Uniform Resource Locator ) chaîne, une recherche NameService (similaire au système de noms de domaine (DNS)), ou transmise en tant que paramètre de méthode lors d'un appel.

Les références d'objets sont des objets légers correspondant à l'interface de l'objet réel (distant ou local). Les appels de méthode sur la référence entraînent des appels ultérieurs à l'ORB et un blocage sur le thread en attendant une réponse, un succès ou un échec. Les paramètres, les données de retour (le cas échéant) et les données d'exception sont marshalés en interne par l'ORB en fonction de la langue locale et du mappage du système d'exploitation.

Données par valeur

Le langage de définition d'interface CORBA fournit la définition de la communication inter-objets indépendante du langage et du système d'exploitation. Les objets CORBA sont passés par référence, tandis que les données (entiers, doubles, structs, énumérations, etc.) sont passées par valeur. La combinaison d'objets par référence et de données par valeur fournit les moyens d'appliquer un excellent typage des données lors de la compilation des clients et des serveurs, tout en préservant la flexibilité inhérente à l'espace de problèmes CORBA.

Objets par valeur (OBV)

Outre les objets distants, CORBA et RMI-IIOP définissent le concept d'OBV et de Valuetypes. Le code à l'intérieur des méthodes des objets Valuetype est exécuté localement par défaut. Si l'OBV a été reçu du côté distant, le code nécessaire doit être soit a priori connu des deux côtés, soit téléchargé dynamiquement depuis l'expéditeur. Pour rendre cela possible, l'enregistrement, définissant OBV, contient la base de code qui est une liste d' URL séparées par des espaces d' où ce code doit être téléchargé. L'OBV peut également avoir les méthodes distantes.

Modèle de Composant CORBA (CCM)

Le modèle de composant CORBA (CCM) est un ajout à la famille des définitions CORBA. Il a été introduit avec CORBA 3 et décrit un cadre d'application standard pour les composants CORBA. Bien qu'il ne dépende pas des " Enterprise Java Beans (EJB) dépendants du langage ", il s'agit d'une forme plus générale d'EJB, fournissant quatre types de composants au lieu des deux définis par EJB. Il fournit une abstraction d'entités qui peuvent fournir et accepter des services via des interfaces nommées bien définies appelées ports .

Le CCM a un conteneur de composants, où les composants logiciels peuvent être déployés. Le conteneur offre un ensemble de services que les composants peuvent utiliser. Ces services incluent (mais ne sont pas limités à) la notification , l' authentification , la persistance et le traitement des transactions . Ce sont les services les plus utilisés dont tout système distribué a besoin et, en déplaçant la mise en œuvre de ces services des composants logiciels vers le conteneur de composants, la complexité des composants est considérablement réduite.

Intercepteurs portables

Les intercepteurs portables sont les « crochets » utilisés par CORBA et RMI-IIOP pour assurer la médiation des fonctions les plus importantes du système CORBA. La norme CORBA définit les types d'intercepteurs suivants :

  1. Les intercepteurs IOR assurent la médiation de la création des nouvelles références aux objets distants, présentées par le serveur courant.
  2. Les intercepteurs clients assurent généralement la médiation des appels de méthode distante du côté client (appelant). Si l'objet Servant existe sur le même serveur où la méthode est invoquée, ils assurent également la médiation des appels locaux.
  3. Les intercepteurs de serveur assurent la médiation du traitement des appels de méthode distante côté serveur (gestionnaire).

Les intercepteurs peuvent joindre les informations spécifiques aux messages envoyés et aux IOR créés. Ces informations peuvent être lues ultérieurement par l'intercepteur correspondant du côté distant. Les intercepteurs peuvent également lancer des exceptions de transfert, redirigeant la demande vers une autre cible.

Protocole général InterORB (GIOP)

Article détaillé : Protocole général inter-ORB

Le GIOP est un protocole abstrait par lequel les courtiers de requêtes d'objets (ORB) communiquent. Les normes associées au protocole sont maintenues par l' Object Management Group (OMG). L'architecture GIOP fournit plusieurs protocoles concrets, notamment :

  1. Protocole Internet InterORB (IIOP) – Le protocole Internet Inter-Orb est une implémentation du GIOP pour une utilisation sur Internet et fournit un mappage entre les messages GIOP et la couche TCP/IP .
  2. SSL InterORB Protocol (SSLIOP) - SSLIOP est IIOP sur SSL , fournissant le cryptage et l' authentification .
  3. HyperText InterORB Protocol (HTIOP) – HTIOP est IIOP sur HTTP , fournissant un contournement de proxy transparent.
  4. IOP zippé (ZIOP) – Une version zippée de GIOP qui réduit l'utilisation de la bande passante.

VMCID (ID du jeu de codes mineur du fournisseur)

Chaque exception CORBA standard comprend un code mineur pour désigner la sous-catégorie de l'exception. Les codes d'exception mineurs sont de type long non signé et consistent en un "ID de jeu de codes mineur de fournisseur" (VMCID) de 20 bits, qui occupe les 20 bits de poids fort, et le code mineur proprement dit qui occupe les 12 bits de poids faible.

Les codes mineurs pour les exceptions standard sont préfacés par le VMCID attribué à OMG, défini comme la constante longue non signée CORBA::OMGVMCID, qui a le VMCID attribué à OMG occupant les 20 bits de poids fort. Les codes d'exception mineurs associés aux exceptions standard qui se trouvent dans le Tableau 3–13 à la page 3-58 sont combinés avec OMGVMCID pour obtenir la valeur de code mineur qui est renvoyée dans la structure ex_body (voir Section 3.17.1, « Standard Définitions des exceptions", à la page 3-52 et Section 3.17.2, "Codes d'exception mineure standard", à la page 3-58).

Dans un espace attribué au fournisseur, l'attribution des valeurs aux codes secondaires est laissée au fournisseur. Les fournisseurs peuvent demander l'attribution de VMCID en envoyant un courrier électronique à tagrequest@omg.org. Une liste des VMCID actuellement attribués est disponible sur le site Web de l'OMG à l' adresse : http://www.omg.org/cgi-bin/doc?vendor-tags

Les VMCID 0 et 0xfffff sont réservés à un usage expérimental. Le VMCID OMGVMCID (Section 3.17.1, « Définitions des exceptions standard », page 3-52) et 1 à 0xf sont réservés à l'utilisation de l'OMG.

Le courtier de requêtes d'objets communs : architecture et spécification (CORBA 2.3)

Emplacement de Corba (CorbaLoc)

L'emplacement Corba (CorbaLoc) fait référence à une référence d'objet sous forme de chaîne pour un objet CORBA qui ressemble à une URL.

Tous les produits CORBA doivent prendre en charge deux URL définies par OMG : « corbaloc : » et « corbaname : ». Le but de ceux-ci est de fournir un moyen lisible et modifiable par l'homme de spécifier un emplacement où un IOR peut être obtenu.

Un exemple de corbaloc est montré ci-dessous :

corbaloc::160.45.110.41:38693/StandardNS/NameServer-POA/_root

Un produit CORBA peut éventuellement prendre en charge les formats " http: ", " ftp: " et " file: ". La sémantique de ceux-ci est qu'ils fournissent des détails sur la façon de télécharger un IOR stringifié (ou, de manière récursive, télécharger une autre URL qui finira par fournir un IOR stringified). Certains ORB fournissent des formats supplémentaires qui sont propriétaires pour cet ORB.

Avantages

Les avantages de CORBA incluent l'indépendance du langage et du système d'exploitation, l'absence d'implémentations liées à la technologie, un typage des données solide, un haut niveau de réglage et l'absence des détails des transferts de données distribués.

Indépendance linguistique
CORBA a été conçu pour libérer les ingénieurs des limitations du couplage de leurs conceptions à un langage logiciel particulier. Actuellement, il existe de nombreux langages pris en charge par divers fournisseurs CORBA, les plus populaires étant Java et C++. Il existe également des implémentations C++11, C uniquement, Smalltalk, Perl, Ada, Ruby et Python, pour n'en citer que quelques-unes.
Indépendance du système d'exploitation
La conception de CORBA est censée être indépendante du système d'exploitation. CORBA est disponible en Java (indépendant du système d'exploitation), ainsi qu'en natif pour Linux/Unix, Windows, Solaris, OS X, OpenVMS, HPUX, Android, LynxOS, VxWorks, ThreadX, INTEGRITY et autres.
Libération des technologies
L'un des principaux avantages implicites est que CORBA offre un terrain de jeu neutre aux ingénieurs pour pouvoir normaliser les interfaces entre divers systèmes nouveaux et anciens. Lors de l'intégration de C, C++, Object Pascal, Java, Fortran, Python et de tout autre langage ou système d'exploitation dans un seul modèle de conception de système cohérent, CORBA fournit les moyens de niveler le terrain et de permettre à des équipes disparates de développer des systèmes et des tests unitaires qui peuvent plus tard être réunis en un système complet. Cela n'exclut pas la nécessité de prendre des décisions d'ingénierie système de base, telles que le threading, la synchronisation, la durée de vie des objets, etc. Ces problèmes font partie de tout système, quelle que soit la technologie. CORBA permet de normaliser les éléments du système en un seul modèle de système cohérent.
Par exemple, la conception d'une architecture multiniveau est simplifiée à l'aide de servlets Java dans le serveur Web et de divers serveurs CORBA contenant la logique métier et encapsulant les accès à la base de données. Cela permet aux implémentations de la logique métier de changer, tandis que les changements d'interface devraient être traités comme dans toute autre technologie. Par exemple, une base de données encapsulée par un serveur peut voir son schéma de base de données changer pour une utilisation ou des performances améliorées du disque (ou même un changement de fournisseur de base de données à grande échelle), sans affecter les interfaces externes. Dans le même temps, le code hérité C++ peut communiquer avec le code hérité C/Fortran et le code de base de données Java, et peut fournir des données à une interface Web.
Saisie des données
CORBA fournit un typage de données flexible, par exemple un type de données « ANY ». CORBA applique également un typage de données étroitement couplé, ce qui réduit les erreurs humaines. Dans une situation où des paires Nom-Valeur sont transmises, il est concevable qu'un serveur fournisse un nombre là où une chaîne était attendue. Le langage de définition d'interface CORBA fournit le mécanisme permettant de s'assurer que le code utilisateur est conforme aux noms de méthode, aux types de retour, aux types de paramètres et aux exceptions.
Haute accordabilité
De nombreuses implémentations (par exemple ORBexpress (implémentation Ada, C++ et Java) et OmniORB (implémentation open source C++ et Python)) ont des options pour régler les fonctionnalités de gestion des threads et des connexions. Toutes les implémentations ORB ne fournissent pas les mêmes fonctionnalités.
Absence de détails de transfert de données
Lors de la gestion des connexions et des threads de bas niveau, CORBA fournit un niveau de détail élevé dans les conditions d'erreur. Ceci est défini dans le jeu d'exceptions standard défini par CORBA et dans le jeu d'exceptions étendu spécifique à l'implémentation. Grâce aux exceptions, l'application peut déterminer si un appel a échoué pour des raisons telles que "Petit problème, alors réessayez", "Le serveur est mort" ou "La référence n'a pas de sens". La règle générale est la suivante : ne pas recevoir d'exception signifie que l'appel de méthode s'est terminé avec succès. Il s'agit d'une caractéristique de conception très puissante.
Compression
CORBA rassemble ses données sous forme binaire et prend en charge la compression. IONA, Remedy IT et Telefónica ont travaillé sur une extension de la norme CORBA qui fournit une compression. Cette extension s'appelle ZIOP et c'est maintenant une norme OMG formelle.

Problèmes et critiques

Bien que CORBA ait fourni une grande partie de la manière dont le code a été écrit et le logiciel construit, il a fait l'objet de critiques.

Une grande partie des critiques de CORBA découle de la mauvaise mise en œuvre de la norme et non des lacunes de la norme elle-même. Certains des échecs de la norme elle-même étaient dus au processus par lequel la spécification CORBA a été créée et aux compromis inhérents à la politique et aux affaires d'écriture d'une norme commune provenant de nombreux implémenteurs concurrents.

Incompatibilités de mise en œuvre initiale
Les spécifications initiales de CORBA ne définissaient que l'IDL, pas le format on-the-wire. Cela signifiait que la compatibilité du code source était la meilleure disponible depuis plusieurs années. Avec CORBA 2 et versions ultérieures, ce problème a été résolu.
Transparence de l'emplacement
La notion de transparence de localisation de CORBA a été critiquée ; c'est-à-dire que les objets résidant dans le même espace d'adressage et accessibles avec un simple appel de fonction sont traités de la même manière que les objets résidant ailleurs (processus différents sur la même machine, ou machines différentes). Il s'agit d'un défaut de conception fondamental, car il rend tous les accès aux objets aussi complexes que le cas le plus complexe (c'est-à-dire un appel réseau distant avec une large classe d'échecs qui ne sont pas possibles dans les appels locaux). Il masque également les différences inévitables entre les deux classes, empêchant les applications de sélectionner une stratégie d'utilisation appropriée (c'est-à-dire qu'un appel avec une latence de 1 µs et un retour garanti sera utilisé de manière très différente d'un appel avec une latence de 1 s avec un éventuel échec de transport. , dans laquelle l'état de la livraison est potentiellement inconnu et peut prendre 30 s pour expirer).
Défauts de conception et de processus
La création de la norme CORBA est aussi souvent citée pour son processus de conception par comité . Il n'y avait pas de processus pour arbitrer entre des propositions contradictoires ou pour décider de la hiérarchie des problèmes à résoudre. Ainsi, la norme a été créée en prenant une union des caractéristiques dans toutes les propositions sans tenir compte de leur cohérence. Cela a rendu la spécification complexe, coûteuse à mettre en œuvre entièrement et souvent ambiguë.
Un comité de conception composé d'un mélange de fournisseurs de mise en œuvre et de clients a créé un ensemble diversifié d'intérêts. Cette diversité a rendu difficile une norme cohérente. Les normes et l'interopérabilité ont accru la concurrence et facilité les déplacements des clients entre les implémentations alternatives. Cela a conduit à de nombreuses luttes politiques au sein du comité et à de fréquentes versions de révisions de la norme CORBA que certains implémenteurs d'ORB ont assuré qu'elles étaient difficiles à utiliser sans extensions propriétaires. Les fournisseurs CORBA moins éthiques ont encouragé le verrouillage du client et obtenu de solides résultats à court terme. Au fil du temps, les fournisseurs d'ORB qui encouragent la portabilité ont pris des parts de marché.
Problèmes avec les implémentations
Tout au long de son histoire, CORBA a été en proie à des lacunes dans les mauvaises implémentations ORB. Malheureusement, de nombreux articles critiquant CORBA en tant que norme sont simplement des critiques d'une implémentation particulièrement mauvaise de CORBA ORB.
CORBA est une norme complète avec de nombreuses fonctionnalités. Peu de mises en œuvre tentent de mettre en œuvre toutes les spécifications, et les mises en œuvre initiales étaient incomplètes ou inadéquates. Comme il n'y avait aucune obligation de fournir une implémentation de référence, les membres étaient libres de proposer des fonctionnalités qui n'ont jamais été testées pour leur utilité ou leur implémentation. Les implémentations ont été en outre entravées par la tendance générale de la norme à être verbeuse et la pratique courante de compromis en adoptant la somme de toutes les propositions soumises, ce qui a souvent créé des API incohérentes et difficiles à utiliser, même si les propositions individuelles étaient parfaitement raisonnables. .
Des implémentations robustes de CORBA ont été très difficiles à acquérir dans le passé, mais sont maintenant beaucoup plus faciles à trouver. Le SDK Java SUN est fourni avec CORBA intégré. Certaines implémentations mal conçues se sont avérées complexes, lentes, incompatibles et incomplètes. Des versions commerciales robustes ont commencé à apparaître mais pour un coût important. À mesure que des implémentations gratuites de bonne qualité sont devenues disponibles, les mauvaises implémentations commerciales sont mortes rapidement.
Pare-feu
CORBA (plus précisément GIOP ) n'est lié à aucun transport de communication particulier. Une spécialisation de GIOP est le protocole Internet Inter-ORB ou IIOP. IIOP utilise des connexions TCP/IP brutes pour transmettre des données.
Si le client se trouve derrière un pare-feu très restrictif ou un environnement de serveur proxy transparent qui n'autorise que les connexions HTTP vers l'extérieur via le port 80, la communication peut être impossible, à moins que le serveur proxy en question n'autorise également la méthode HTTP CONNECT ou les connexions SOCKS . À une certaine époque, il était même difficile de forcer les implémentations à utiliser un seul port standard – elles avaient plutôt tendance à choisir plusieurs ports aléatoires. À ce jour, les ORB actuels présentent ces lacunes. En raison de ces difficultés, certains utilisateurs ont utilisé de plus en plus les services Web au lieu de CORBA. Ceux-ci communiquent en utilisant XML / SOAP via le port 80, qui est normalement laissé ouvert ou filtré via un proxy HTTP à l'intérieur de l'organisation, pour la navigation Web via HTTP. Les implémentations récentes de CORBA, cependant, prennent en charge SSL et peuvent être facilement configurées pour fonctionner sur un seul port. Certains ORBS, tels que TAO , omniORB et JacORB prennent également en charge le GIOP bidirectionnel, ce qui donne à CORBA l'avantage de pouvoir utiliser la communication de rappel plutôt que l'approche d'interrogation caractéristique des implémentations de services Web. De plus, la plupart des pare-feu modernes prennent en charge GIOP et IIOP et sont donc des pare-feu compatibles CORBA.

Voir également

Génie logiciel

Technologies logicielles basées sur des composants

Liaisons de langue

Les références

Lectures complémentaires

Liens externes