Rapport d'étude sur la comparaison d'ORBSPierre Bittner Dominique Debruyne Loïc Grulois Thierry Jilibert Olivier Roland Etudiants en DESS Génie Informatique Promotion 1999 - 2000 SOMMAIRE
Les ORBs sont nés pour répondre aux soucis de faire communiquer entre eux des objets répartis. L'ORB se définit ainsi :
Les fonctions demandées à un ORB sont simples à comprendre :
Hormis certains produits hétéroclites, trois grandes familles de bus à objets répartis, qui répondent à ses critères, se démarquent. Il s'agit de :
CORBA est la spécification d’une architecture standard pour les ORBs développée par l'OMG. CORBA est un mécanisme Middleware. Pour vulgariser, on pourrait dire qu'il s'agit d'une généralisation du Remote Procedure Call. Toutefois, CORBA ne s'arrête pas là et défini en plus nombre de services qui sont autant de facilités pour le développeur. CORBA a été conçu pour permettre a des composants intelligents (des objets) de se trouver sur le réseau et d'interopérer via un bus. La norme définie par l'OMG permet plus que la simple interoperabilité en définissant de nombreux services associés au bus qui permettent de créer et supprimer des objets, leur assigner un nom, les rendre persistants, externaliser leur état, définir des relations entre eux, traiter des transactions, etc.. CORBA fournit donc, en plus du RPC simpliste, un IDL, un Langage de Description d'Interfaces. Il permet de spécifier de manière standardisée le comportement des objets présents sur le bus.
L'architecture CORBA 2.0 permet une interopérabilité entre objets quels que soient le langage de programmation, l'environnement d'exécution, le réseau de communication. Ainsi il est permis de faire communiquer entre eux des objets écrits dans des langages différents, pour des systèmes différents, d'une manière extrêmement simplifiée. Bien qu'elle spécifie beaucoup de points au niveau de l'IDL, de l'inter-opérabilité, la norme Corba est cependant suffisamment souple pour permettre de multiples implémentations différentes de bus répondants tous à cette norme.
Les ORBs génériques : Ils implémentent plus ou moins rigoureusement la norme CORBA 2.X ou 3.0.
Cette norme permet donc à des objets de communiquer de manière transparente pour le développeur, et elle définit le langage de définition d'interface supporté,
les services qui doivent être implémentés, et une certaine inter-opérabilité entre les ORBs existants.
On peut citer les produits Orbacus, ou encore VisiBroker qui correspondent à cette définition. Les ORBs Temps Réels : Les ORBS temps réels fournissent en plus des ORBs classiques une interface standard qui permet aux applications de spécifier leurs besoins en ressources.
TAO est un exemple d’ORB temps réel. Ces ORB ne sont pas très fréquents. Les ORBs embarqués : Les ORBs embarqués sont eux soumis à des contraintes fortes. Ils sont obligés de tenir compte des contraintes liées aux systèmes embarqués qui sont : Ces contraintes n’ont donc pas été prises en compte dans les premières versions de la norme CORBA. L'OMG se penche sur ce problème et travaille actuellement sur une norme Systèmes Embarqués. Les principaux besoins sont d'épurer l'implémentation et de définir le strict minimum nécessaire pour garder les fonctionnalités des bus CORBA mais peut être en supprimant certains services ( service de nommage, etc...… ). On retrouve ici un produit d’Orbacus, et il existe par exemple une version de MICO pour les Palm Pilot. Les ORBs pur Java : Tout en répondant à la norme CORBA, ils sont écrits comme leur nom l'indique tout en Java. Ceci leur permet de fonctionner sur toute station supportant une machine virtuelle Java. Ils peuvent donc répondre à des besoins spécifiques en palliant à une forte disparité matérielle au sein de l’entreprise par exemple. On peut choisir d'utiliser un tel ORB pour ne pas imposer d'Operating System au client (navigateur). Quelques produits existants : DAIS, JacOrb, JavaOrb. Nous remarquons donc qu'il existe une réelle diversité de l'offre. Une fois que l'on a choisi le ou les type ( s ) d'ORB que l’on va utiliser, il reste donc à savoir quel sera le meilleur des ORBs pour vos besoins spécifiques. Les ORBs proposent des services qui sont normalisés ( spécifiés par la norme Corba ).
Par contre, les ORBs proposent aussi des services qui ne sont pas normalisés, ceci afin de les différencier des concurrents. Il en résulte que ces services spécifiques ne sont soit : Si une entreprise a besoin d'un ORB proposant des services qui ne sont pas normalisés par l'OMG, le choix des ORBs candidats se retrouve restreint et on choisira donc non pas le meilleur des ORBs mais l'ORB qui propose les services requis. Une dernière remarque concerne le fait qu'avant de pouvoir comparer les ORBs, il est nécessaire de pouvoir faire fonctionner le même programme de tests sur les ORBs à comparer. Attachons nous maintenant à l’étude de la portabilité des applications entre les différents ORBs existants. Le nombre d'ORBs sur le marché est gigantesque, Corba est en effet une des clés de l'évolution de l'informatique. Pour ne pas rater ce secteur critique du traitement de l'information, toutes les grandes sociétés, qu'elles soient du secteur informatique ou des télécommunications, ont un d'ORB qu'elles tentent d'imposer.
Sur ce marché en constantes évolutions, on remarque également une présence importante de produits développés par des communauté de l'Internet.
Ces offres ne sont malheureusement pas toujours proposé sous une licence reconnue par la Free Software Fondation.
Pour effectuer la comparaison d'ORBs nous avons tout d'abord du faire un tri et sélectionner des critères auxquels devaient répondre les candidats. Ces critères sont établies à partir de raisons techniques et matériels. Sur le type des ORBs sélectionnés, nous avons porté notre choix sur les versions non-spécialisés (génériques dans le chapitre précédent). Ceci pour une simple et bonne raison, nous ne disposions pas des capacités techniques pour évalués des ORBs temps-réels ou embarqués. Ensuite pour des raisons matériels nous n'avons pu tester que les ORBs fonctionnant sur plate-forme Intel. Par contre nous ne nous sommes pas limités aux systèmes d'exploitation de Microsoft, Windows. Une grande partie des tests c'est déroulée sous Linux, un système ayant des capacités reconnues dans les applications communicantes. Nous avons également décidés d'évalués les ORBs qui ont pour langage cibles C++ incontournable mais également JAVA qui fait une percée remarquable dans les applications N-tiers. Le langage cible est le langage dans lequel est développé notre application. Il existe de nombreux autres langages comme le C, ADA ou smalltalk. Mais ceux-ci sont traités par des ORBs spécifiques. Le C++ et Java représente de toute manière la plus grande partie des langages utilisés dans la programmation objet. Notre sélection comporte des ORBs commerciaux mais aussi développé par des communautés.
Voici la liste des ORBs qui ont été sélectionnés à partir des critères précédemment évoqués : Sur quels points avons nous testé ces ORBs. Premier critère et non des moindres, l'installation. Pour diverses raisons, certains ORBs n'ont pu s'installer sur notre machine de test. Il ne s'agit pas uniquement des produits non-commerciaux tournant sous linux comme on pourrait se l'imaginer.
On réussit souvent par diverses manouvres a obtenir un logiciel qui fonctionne grâce a la disponibilité des sources et des shells scripts d'installation.
Voici la liste des ORBs qui ont passé la phase d'installation.
Tous ces ORBs ont été installés avec les options par défaut. Voila donc 9 ORBs sur lesquels nous avons pu tester la portabilité du code et dans le chapitre suivant la performance. Ceux sont des critères relativement importants lorsque l'on souhaite utiliser de manière intensive un ORB. C'est le point le plus satisfaisant sur l'ensemble de l'offre. Chaque ORB permet une configuration suffisante pour la plupart des utilisations.
Pas de critique particulière sur ce point.
Notre but premier été de vérifier qu'un programme utilisant CORBA pouvait être porté sur ces ORBs. Nous avons décidé de porter une application minimaliste de type Hello Word sur ces ORBs. Un client fait l'appel d'une fonction d'un objet géré par un serveur.
L'adaptateurs d'objets et le CosNaming sont les outils minimums que doivent fournir les ORBs. On remarqua rapidement que même une application aussi simple ne pouvait se recompiler et s'exécuter rapidement sur n'importe quel ORB. Nous avons donc tenté de fournir un programme le plus facilement adaptable.
Dans les 2 parties qui suivent, nous allons voir la mise en oeuvre effectue pour notre applications sur les ORBs C++ puis JAVA.
Edité par Inprise, VisiBroker se veut orienté vers le e-commerce. Ce produit existe en 3 déclinaisons : Visibroker pour java, Visibroker pour C++ et Visibroker pour Delphi, et existe pour différentes plateformes (Windows, Solaris, HP-UX, AIX, IRIX, Digital Unix, Linux, OS390). La version 4 supporte la norme CORBA 2.3 et inclu désormais les fonctionnalités suivantes : Visibroker n'est chez Inprise qu'un élément d'une vaste gamme, ou les produits phares sont J/C++Builder et Delphi. Plusieurs versions sont téléchargeables sur Internet, dont des versions pour Linux et Windows. L'installation est aisée sur ces deux plateformes. Sous linux, elle requiert un shell compatible Korn Shell, et est guidée par un script interactif. Sous Windows, Visibroker est fourni sous la forme d'une archive compressée. L'installation se passe sans problèmes sous Windows 95, mais a planté Windows 2000. Contrairement à l'installation, l'utilisation de Visibroker ne nous est pas apparu simple. Le produit Orbix 3 est édité par la société Iona et est disponible sur une vaste gamme de plateformes : Orbix s'intègre dans une gamme de produit restreinte et orienté Middleware avec notamment OrbixCOMet (intégration CORBA-COM) et Wonderwall (firewall IIOP). Produit par la société Object Oriented Concept., Orbacus bénéficie d'une approche ouverte : Exemples et documentation en font un produit simple à utiliser. L'installation à partir du code source s'est déroulé sans problème. MICO = Mico is Corba Mico est un projet OpenSource de l'université de Francfort, placé sous licence GNU, dont l'intention est de produire une implantation de CORBA respectant au plus près la norme de l'OMG et disponible gratuitement. Le projet est guidé par 5 principes : La version 2.3.1 de Mico supporte les BOA, POA, DII, DSI, ainsi que de nombreux services CORBA : Mico est utilisable sur la plupart des systèmes UNIX (Linux, Solaris, AIX ...) ainsi que sur Windows NT. Il inclu un navigateur graphique d' « interface repository » écrit en Java. Un projet visant à produire un ORB complètement multi-threadé est poursuivi parallèlement à Mico sous le nom de Mico-mt. Ce projet devrait être intégré à Mico lorsque un seuil de stabilité aura été atteint. Mico-mt est disponible en version alpha, mais de larges parties boguées le rendent difficilement utilisable. TAO est une implantation temps-réel de CORBA utilisant ACE, conçu à l'université de Washington par Douglas Schmidt. ILU est le projet Inter Language Unification de Xerox. Orbit est un ORB écrit en C, destiné au projet Gnome. Orbit inclu un service de nommage et un début de service événement. Notre but ici est d'experimenter un portage d'une application simple d'un ORB vers un autre afin d'entrevoir les différents problèmes que cela pose.
Soit l'IDL suivant :
L'implantation de cet IDL a la structure suivante :
La fonction hello ne fait rien d'intéressant : elle retourne une chaîne de caractères :
Nous disposons pour cet IDL d'une implantation réalisée avec Mico.
Notre implantation de Hello est donc la suivante. Il reste à définir un client et un serveur pour notre objet Hello_i.
Avec Mico, cela donne le code suivant. Le serveur, quant à lui, initialise l'ORB et le BOA avant d'instancier un servant pour l'interface Hello. Nous remarquons que dans l'implantation de Hello_i et dans le client nous incluons le fichier hello.h. Ce fichier est généré par le compilateur IDL de Mico. C'est là notre première modification de portage : les compilateurs IDL des différents produits ne produisent pas les mêmes fichiers, ni les mêmes classes d'ailleurs. Afin de faire tourner notre application avec omniORB, il faut inclure le fichier hello.hh et faire hériter Hello_i de la classe _sk_Hello.
Le deuxième lot de différences est constitué par les signatures différentes des fonctions d'initialisation.
Nous avons du apporter une autre modification à notre code source pour pouvoir le compiler avec omniORB.
La troisième catégorie de différences est celle liée à la compilation.
Voici deux exemples de Makefile pour notre petite application Hello, le premier pour Mico et le second pour OmniORB. Pour OmniORB, on change les chemins, les binaires et les options de compilation. En examinant ces scripts, on remarque plusieurs détails différenciant Mico et OmniORB, comme par exemple le fait que Mico utilise des wrappers à la place des compilateurs et linkers du système, ou que OmniORB définisse des variables particulières. Comme ORBs Java, nous avons évalué Visibroker, Orbacus, JavaORB et JacORB.
JacORB est un ORB écrit en JAVA - is an object request broker written in Java - il implémente la version standard CORBA 2.0. JacORB est un logiciel OpenSource, facile à installer et à utiliser. La version la plus récente date du 11 Février 2000 (Version 1.0 Béta 15). Caractéristiques de JacORB JavaORB est concu par le Distributed Object Group Nous utilisons pour ce test le JDK 1.2. Celui de Blackdown sous Linux et celui de SUN sous Windows. Le JDK 1.2 fournit les paquetages CORBA de l'OMG.
Pour minimiser les différences d'utilisations des ORBs, nous avons développé un Makefile générique. Ce Makefile inclu un fichier Makefile.bench dans lequel on redéfini
les exécutables en fonctions de L'ORB.
Maintenant regardons de plus prés le fichier Makefile.bench. En fonction de l'ORB, nous générons les outils de compilations et d'exécution.
Par exemple pour JacORB dans trois console différentes :
Seul Visibroker échappe à cette règle car la mise en oeuvre du NameService est plus compliqué. Nous verrons cela un peu plus tard. Que la compilation et la mise en oeuvre diffère selon les ORBs cela peut paraître normale. Il n'en va pas de même pour le code. Malheureusement en Java, nous n'avons pas à notre disposition de pré-processeurs comme en C++ qui nous permettent de définir des macros.
On peut donc voir à partir du fichier les différences d'utilisations. Remarquez à quelle point les interfaces sont proches. Cela ne varie qu'en fonction des paramètres ou des paquetages utilisés.
A part pour VisiBroker et les propriétés de Orbacus peut de différence. Evidemment le code est très simple et met en oeuvre peut de fonctionnalité. Voila pour le code de l'applications, maintenant nous allons parler des processus a utilisé pour faire fonctionner le NameService sur les ORBs. Pour utiliser le NameService de chaque ORB, il est nécessaire de lancer des programmes.
Visibroker Pour utiliser Visibroker, il faut lancer le programme osagent.
Le NameService même :
Puis l'objet bench :
Les autres ORBs utilisent tous la même méthodes Orbacus Java :
JavaORB :
JacORB :
Les fichiers en paramètres sont tous des fichiers de log. Nous en avons terminé avec les ORBs Java. Tous ont pu être utilisés avec le CosNaming. En conclusion, le portage d'une application d'un ORB vers un autre necessite des modifications que nous répartissons en trois catégories :
Les imprévus.
Notons cependant que ces problèmes ne se posent lors de l'utilisation des services de CORBA. Le critère de la rapidité ne peut pas être le principal critère de choix d’un ORB. Ce critère n’intervient que quand tous les autres critères ont été satisfaits. Que faire d’un ORB très rapide mais qui ne serait pas stable ? Il revient donc a chacun, en fonction de ces besoins, de sélectionner parmi les ORBs sur le marché ceux qui conviennent le mieux en terme de stabilité, de respect des spécifications de l’OMG, de service, de licence et de prix. Ce n'est qu'en dernier lieu, et pour départager les ORBs ainsi sélectionnés que l’on envisagera de les comparer en terme de vitesse. Aussi, le critère de la rapidité aussi important soit il ne peut être que le dernier critère à prendre en compte. Comme toutes les technologie qui utilise les réseaux informatiques, les ORBs sont assez difficiles à évaluer en terme de performance. Le résultat d’un test ne sera jamais qu’un résultat obtenu sur une machine particulière, sur un réseau particulier et surtout à un instant donné. De surcroît les résultats obtenus n’auront de valeur que pour le test qui a été fait, rien ne dit à priori que les ORBs se comporteraient de la même manière sur un tout autre test. L’un des principal problème auquel nous avons à faire face et la charge du réseau. Si cette dernière et constante dans le temps, nous pouvons considérer que les ORBs sont testés dans des conditions équitables. Si toutefois le réseau par sa lenteur constitue un goulot d’étranglement, les résultats risquent d’être nivelés par la performance du réseau lui même ! Plus pénible encore est le cas du réseau à charge hautement variable, or c’est précisément le cas de notre réseau en salle de TP. Pour une raison encore mal définie (le HUB est probablement le principal responsable) la charge de notre réseau est très variable d’un ¼ heure sur l’autre avec une tendance certaine à la saturation. La solution à moins d’avoir à disposition un réseau libre dédié aux tests est bien entendu de travailler en local sur une machine via localhost. Un autre problème auquel nous sommes confrontés est un problème qui se pose pour tout bench, à savoir que les autres processus qui tournent sur la machine de test ont tendance à faire varier (certes faiblement) les résultats. Ainsi, comme on le verra ci après, il est difficile de mettre en évidence certains phénomènes dont on parle notamment dans le CORBA comparaison project et qu’on évoquera ci-après. N’oublions pas et ce sera la conclusion de ce chapitre, que la solution qui consiste à passer par localhost pour éviter les interférences dues au réseau et quand même un peu réductrice et masque un certains nombres de mécanismes complexes. Ainsi par exemple, il se peut que le temps d’invocation d’une méthode via localhost soit supérieur au temps d’invocation en passant par le réseau. C’est le cas notamment quand on passe un tableau d’anys (Cf CORBA comparaison project). Après un certains nombre d’essais, nous avons finalement réduit notre procédure de test à sa plus simple expression. Le contrat IDL suivant est suffisant pour mettre en évidence un certain nombre de phénomènes.
Les tests en C++ ont été effectué avec: Les tests en JAVA ont été effectué avec La machine de test est un celeron 400 avec 64 Mo de RAM. Les résultats en C++.(les temps sont donnés en ms)
 Interprétation des résultats.Le premier call null est aussi la première invocation de méthode. Le délai un peu plus long s’explique par le mécanisme de localisation de la machine serveur. Remarquons qu’une fois que la machine est localisée, les appels suivants sont beaucoup plus courts. Ce mécanisme n’a donc lieu qu’au premier appel. Remarquons que le temps constant de l’invocation rend négligeable les différences dues aux types passés en paramètre. Il est donc plus rentable de faire moins d’appel, quitte à passer plus d’arguments. Remarquons également la différence selon que l’on utilise pour l’adaptateur d‘objets le type BOA ou le type POA. Il est intéressant de constater une fois de plus que portabilité et performance ne font pas bon ménage. Remarquons pour finir, sans toutefois tirer des conclusion hâtives à quel point OmniORB se montre particulièrement à son avantage dans ce test. Les résultats en JAVA(les temps sont donnés en ms)
 Interprétation des résultats.Ce que nous pouvons remarquer ici, cest que tous les ORB sont à peu prés équivalents en terme de performances. Visibroker (Linux) se montre le plus rapide sur tous les points mais il ny a pas un facteur de 2 en comparaison avec JavaORB qui est le plus lent. Les autres remarques sont les mêmes que celles plus haut pour les ORBs c++. Comparaison C++/JAVAIl est intéressant de comparer les ORBs c++ et les ORBs java en termes de performances. Ainsi en prenant OmniORB ( le plus rapide en c++) et visibroker ( le plus rapide en java), on saperçoit quOmniORB est 10 fois plus rapide. Lécart avec lORB le plus lent peut aller jusquà un facteur de 20. Nous avons vu que la vitesse nest pas le facteur premier cependant un facteur de 10 à 20 est non négligeable dans le cas dapplications réclamant une bonne disponibilité. Conclusion sur les tests effectuésNous tirons ici une conclusion générale des tests que nous avons effectués sur les différents ORBs. le plus performantOmniORB le plus simple d'installationVisibroker (version Windows) Le meilleurOrbacus Cette conclusion ne va pas revenir sur les produits testés mais va rester générale à l'ensemble de l'offre d'ORBs en soulevant les points essentiels qu'il faut avoir en tête au moment du choix d'un ORB. Différences d’évolutions normes/produits De nouvelles normes de corba définies par l'OMG apparaissent régulièrement. Ces spécifications proviennent principalement de la demande d'utilisateurs pour obtenir de nouvelles fonctionnalités ou/et des éditeurs d'ORBs pour standardiser une technologie qu'ils sont les seuls à maîtriser. Ainsi avec toutes ces évolutions, il y a toujours un décalage de plusieurs mois entre l'annonce d'une nouvelle norme et son implémentation dans les principaux ORB Un produit peut très bien implémenter une nouvelle norme immédiatement car cette nouvelle norme provient d'une technologie propriétaire mais n'implémentera pas forcément des normes définies quelques mois plus tôt. Choix en fonction des caractéristiques Nous l'avons vu, la rapidité d'un ORB n'est pas le facteur principal du choix de ce dernier. Plus que tout, il faut d'abord analyser les besoins que l'on a pour ensuite déterminer le produit le plus apte à remplir ces besoins. C'est à dire la conformité du produits aux différentes spécifications et normes définies par l'OMG. Les ORBs les plus performants sont souvent ceux qui implémentent le moins de spécifications. Alors à quoi cela sert d'avoir l'ORB le plus rapide si il n'implémente pas les normes dont nous avons besoin. Il faut regarder à la disponibilité du produits sous plusieurs systèmes d'exploitation et langages différents. Rares sont les entreprises dont tous les ordinateurs fonctionnent sous le même OS et dont tous les programmeurs utilisent le même langage. Une fois les points ci dessus rempli, il convient de regarder: Si l'on veut utiliser efficacement l'ORB en question, ces différents se doivent d'être bons. Ils peuvent aisément conduire au choix d'un ORB plutôt qu'un autre qui aurait les mêmes spécifications. Le dernier critère est la rapidité de l'ORB. Difficulté de portabilité Nous l'avons vu, porter une application, écrite pour un ORB spécifique, sous un autre ORB ne se fait pas immédiatement. Il y a toujours des petits problèmes d'incompatibilité même en utilisant les normes spécifiques comme le bus POA. Fonctionnalités propriétaires Chaque éditeur ajoute des fonctionnalités propriétaires et redéfini souvent les fonctions des interfaces standards ( par exemple l'ajout d'un argument lors de l'appel à une fonction ). ORBs open source Les ORBS open source ne sont pas à négliger. Nous le remarquons avec OmniORB. Ce sont souvent des ORB qui évoluent très rapidement du fait de l'enthousiasme de la communauté de développeurs open source. Ils sont donc fournis avec les sources et ils sont gratuits. Ce dernier critère peut se révéler capital pour une utilisation restreinte ( une entreprise qui n'a pas les moyens, les particuliers ) et aussi pour une première approche de CORBA. En effet au lieu d'investir de l'argent dans un ORB payant, pourquoi ne pas tester un ORB open source ? Interopérabilité Au vu de tout cela, aucun produit ne réunit toutes ces caractéristiques. Par conséquent on peut essayer l'interopérabilité, c'est à dire prendre un ORB/c++/windows qui va privilégier la rapidité et un orb/java/linux qui sera facile à programmer et maintenir et qui apportera les services ne nécessitant pas une grande vitesse. Bien que minimal, ce test nous a cependant permis de mettre en évidence quelques points forts intéressants. Les différences de vitesse entre ORBs pouvant comme nous l’avons constaté être sensibles, c’est donc un point qu’il ne faut pas négliger. Vous pouvez télécharger les programmes que nous avons utilisé pour évaluer les ORBs : S'il ne devait en rester qu'un ce serait ce site : Merci à Philippe Merle pour son cours sur CORBA et ses remarques sur l'interpretation des résultats. |