RMI, IIOP et EJB. Avril Dave Curtis Inprise Corporation. 100 Enterprise Way Scotts Valley CA

Transcription

1 RMI, IIOP et EJB Avril 1999 Dave Curtis Inprise Corporation 100 Enterprise Way Scotts Valley CA

2 INTRODUCTION...3 COEXISTENCE OU COOPÉRATION?...4 MODÈLES ET PROTOCOLES DE PROGRAMMATION...5 MODÈLE DE PROGRAMMATION RMI...5 MODÈLE DE PROGRAMMATION CORBA...5 SÉMANTIQUE DU MODÈLE DE PROGRAMMATION ET DU PROTOCOLE...6 DIFFÉRENCES ENTRE LA SÉMANTIQUE DE RMI ET DE CORBA...6 TYPES DE VALEUR DE L IDL...7 RMI AU-DESSUS DE IIOP : UNIFICATION DE RMI & CORBA...8 IIOP DONNE LE E DE EJB...9 INVESTISSEMENT INDUSTRIEL...9 INTÉGRATION AVEC LES SYSTÈMES HÉTÉROGÈNES...10 ELIMINATION DU RISQUE...10 IMPLÉMENTER LES CONTENEURS EJB QUI SUPPORTENT IIOP...11 QUE RECHERCHER EN PRIORITÉ DANS UN CONTENEUR D'EJB?...11 RÉSUMÉ

3 Introduction Lorsque Java a rencontré CORBA pour la première fois, sous la forme de VisiBroker pour Java (le premier ORB Java), les résultats ont été avantageux pour les deux communautés. La communauté OMG/CORBA a trouvé en Java une méthode beaucoup plus propre, plus docile et plus économique que la seule option disponible jusqu'alors pour créer des applications CORBA, le C++. Les programmeurs Java, eux, ont découvert une infrastructure objet distribuée robuste qui tirait parti des investissements éprouvés en technologie CORBA, ainsi qu'une façon propre d'exploiter des ressources d'ancienne génération (donc non Java). Simultanément, RMI (invocation distante de méthode) émergeait comme moyen d'établir les systèmes répartis d'objets Java pur et natif. RMI est très similaire à CORBA en terme d'architecture. Il fait des invocations distantes sur les objets via des interfaces établies et utilise des proxies et des skeletons générés automatiquement pour gérer le marshaling et les communications de façon transparente. Dans bien des aspects, cependant, RMI est très différent. Il utilise le système de types natif de Java pour décrire les interfaces distantes et leurs paramètres, alors que CORBA utilise un IDL (Interface Definition Language) indépendant des langages de programmation. Un programmeur Java/RMI identifie une interface qui est destinée à l'accès distant en définissant l'interface comme extension de l'interface de base distante appropriée. Les méthodes distantes acceptent des paramètres de virtuellement toutes les classes Java (les classes doivent être sérialisables). Par opposition, CORBA n'acceptait à cette époque qu'un nombre limité de types de données. Puisque il s agissait d un système intrinsèquement indépendant du langage, n'importe quel type de données défini en CORBA devait avoir une représentation équivalente dans une variété de langages de programmation (y compris, C++ et COBOL). Bien qu'un certain niveau de concurrence ait été inévitable, Sun et la communauté OMG (Sun étant un des fondateurs et l'un des membres les plus actifs de l'omg) ont compris implicitement qu'une bataille à trois entre DCOM, RMI et CORBA mènerait certainement à un blocage (ou au mieux, une victoire à la Phyrrus). La vraie question était ceci: comment ces deux technologies doivent-elles coexister et coopérer, et quel rôle chacune d entre elles doit avoir dans une solution combinée? 3

4 Coexistence ou coopération? La réponse simpliste qui a d'abord émergé était quelque chose du type : utilisez RMI quand vous développez de nouvelles applications réparties Java, utilisez CORBA quand vous devez accéder à des applications existantes non-java. Il faut préciser que la taille du budget informatique destiné à mettre à jour et intégrer des systèmes de production non-java était, et demeure pour un avenir proche, beaucoup plus grande que celle de du budget destiné aux nouveaux développements, quelque soit le langage. Quoiqu'il en soit, cette réponse n'était pas satisfaisante pour un grand nombre des clients qui avaient déjà fait un investissement significatif en technologie CORBA, mais qui voulaient également faire de nouveaux développements en Java. A cette époque, RMI avait sa propre infrastructure, ne partageant pratiquement rien avec l'infrastructure CORBA. Il avait son propre protocole de communication de messages (JRMP), son propre mécanisme d enregistrement, et développait son propre ensemble de services, semblables (mais non compatibles) aux services CORBA existants. Les entreprises ne sont pas particulièrement enthousiastes à l idée de maintenir et supporter deux infrastructures différentes. Un message limpide fut envoyé aux deux communautés : nous voulons programmer en Java, utiliser les modèles CORBA et RMI si nécessaire, mais nous n'avons pas besoin de deux infrastructures. Débrouillez-vous! Le résultat fut RMI au-dessus de IIOP. Comprendre vraiment ce que ceci signifie nécessite de comprendre le rapport entre les modèles de programmation distribués et leurs protocoles fondamentaux. Plus spécifiquement, la façon dont les modèles de programmation et les protocoles sont simultanément indépendants, et interdépendant en même temps. 4

5 Modèles et protocoles de programmation Modèle de programmation RMI RMI est un modèle de programmation. Quand un programmeur Java écrit une application qui utilise RMI, il a un certain nombre de techniques disponibles, des décisions de conception à faire, et des contraintes à observer. Comme cité précédemment, une interface accessible à distance doit être spécifiquement conçue et établie en tant que telle, étendant une interface de base particulière, et observant certaines contraintes sur les signatures de méthode. Par exemple, toutes les méthodes doivent envoyer certaines exceptions, tous les paramètres doivent être serializables, et ainsi de suite. La majeure partie du travail mécanique est effectuée par le compilateur Java et le postprocesseur de RMI, produisant les proxies et les squelettes qui automatisent le lien aux logiciels serveurs, le marshalling des requêtes, et la gestion des communications. Mettre en application et utiliser un objet distant prend légèrement plus de travail que la simple construction d'un objet local et l'appel de ses méthodes. Un client doit obtenir une référence sur l'objet à partir du registre RMI ou du répertoire JNDI. La classe d implémentation doit exécuter quelques rituels de comptabilité, y compris l enregistrement des références d instances ou leur publication dans le répertoire. Le client et le logiciel serveur doivent également être conçus pour prendre en compte les problèmes fondamentaux de l informatique distribuée : les requêtes prennent typiquement des milli-secondes au lieu de micro-secondes, beaucoup de choses nouvelles peuvent tourner mal lors de la communication, il y a beaucoup plus d'incertitude au sujet de ce qui peut s'être produit ou non à l'autre extrémité du fil. Modèle de programmation CORBA CORBA présente également aux utilisateurs un modèle de programmation stylisé (ou peut-être, des modèles, étant donné les variations qui existent à travers les projections vers différents langages). Le concepteur/programmeur définit les interfaces distribuées dans un IDL séparé. Un compilateur d'idl produit des proxies et des squelettes (tout comme ceux produits par le postprocesseur de RMI) dans un langage de programmation particulier, selon des règles normalisées définies par l'omg. Jusqu à récemment, les types de données disponibles pouvant être utilisés comme paramètres d'exécution étaient limités aux types de base habituels, plus un petit ensemble de types construits tels que des structures, des enregistrements, des tableaux et des séquences. Les détails du modèle de programmation CORBA sont en grande partie déterminés par le langage de programmation utilisé pour l'application spécifique et la projection IDL définie pour ce langage. 5

6 Sémantique du modèle de programmation et du protocole En général, les programmeurs utilisant RMI ou CORBA ne se rendent pas directement compte du protocole fondamental utilisé pour faire des appels distants. Le point principal d'un modèle abstrait d'objets distribués est de rendre les problématiques de bas-niveau (telles que les communications) transparentes au programmeur. C'est particulièrement vrai en ce qui concerne le protocole fondamental de transport utilisé ; il est assez évident qu'une application utilisant une abstraction de haut niveau comme un ORB ne sait pas ou ne s'inquiète pas de savoir si les messages sont audessus de TCP/IP ou de SPX, puisque le travail du protocole de transport est simplement de déplacer des octets. Mais RMI et CORBA définissent tous les deux des protocoles de communication de messages, appelés respectivement JRMP et IIOP. En général, de tels protocoles de communication ne sont pas aussi indépendants du modèle de programmation que la couche transport. Un protocole de communication incarne nécessairement la sémantique du modèle de programmation qu il implémente. Par exemple, les protocoles de communication pour les systèmes d'objet répartis indiquent comment des références d'objet sont employées pour localiser et identifier des instances spécifiques, reflétant directement (ou dans certains cas, définissant) le concept de l'identité d'objet pour le modèle d'objet. Ces protocoles doivent également supporter le modèle d'information inhérent aux demandes et réponses, y compris le types de données des paramètres qui peuvent être échangés et la façon dont ils sont encodés, quels genres d'exceptions peuvent être retournés, si n'importe quel contexte implicite est transmis par la demande et comment, et ainsi de suite. JRMP a été conçu pour supporter la sémantique de RMI. De même, IIOP a été conçu pour supporter la sémantique de CORBA. C'est un problème non trivial de supporter la sémantique d'un modèle de programmation avec un protocole de communication conçu pour un modèle de programmation différent, et de le faire efficacement. En plus des erreurs d'assortiment dans les systèmes de types de données (qui sont les problèmes les plus évidents), il peut y avoir quelques différences de base dans la sémantique de demande. Par exemple, un protocole particulier peut (ou peut ne pas) supporter certaines capacités qui apparaissent indirectement dans le modèle de programmation comme, par exemple, des dispositifs de qualité de service, ou la capacité de participer aux transactions distribuées. Différences entre la sémantique de RMI et de CORBA La plus grande différence entre RMI et CORBA qui se manifeste dans les différences entre JRMP et IIOP se trouve dans les types qui peuvent être utilisés en tant que paramètres lors des appels distants. CORBA s'est restreint aux types relativement simples afin de rester conforme aux différents langages et garantir aucune perte d'information quand des demandes sont faites entre différents langages. 6

7 RMI, cependant, n avait pas une telle contrainte de conception. Il supporte la capacité de passer des instances de classes Java comme paramètres, par valeur. Ceci signifie que la requête passe l'état complet de l'objet paramètre à la cible, où une nouvelle instance de la classe est créée avec le même état dans l'espace d adressage local de la cible. La différence importante est que le paramètre incarne l'état et le comportement (parce que le paramètre objet a des méthodes que vous pouvez appeler). Les appels CORBA ne pouvaient seulement passer l'état par valeur, sous forme de structures, de séquences par exemple. Les appels CORBA (aussi bien que des appels RMI) peuvent passer des paramètres d'objet par référence, signifiant que l'objet n'est pas dupliqué dans l'espace adresse de la cible; la destination reçoit une référence sur l'objet par lequel il peut faire des invocations distantes. Cette limitation dans CORBA reflète son caractère de conception indépendant du langage. Il n'est pas particulièrement significatif d essayer de passer un objet Java vers une application C++ ou COBOL. Types de valeur de l IDL Afin de permettre l utilisation de IIOP comme protocole de communication pour des programmes RMI, IIOP avait besoin d être étendu pour supporter la sémantique de RMI qui à ce moment-là n existait pas dans CORBA, principalement la capacité de passer des objets par valeur. L'OMG a fait ceci, non pas en étendant IIOP directement, mais en étendant le système de typage CORBA de base pour inclure la capacité de définir des types de valeur (c.-à-d., des objets de programmation locaux) en IDL et de les passer par valeur comme paramètres dans les appels. Les types de valeur ont été conçus pour pouvoir exprimer des objets Java, mais ne sont pas limités à ce langage. Les types de valeur sont indépendants du langage. Actuellement, les projections de type de valeur existent pour les langages Java et C++, et sont développés pour d'autres langages. Utiliser des types valeur pose quelques problèmes difficiles avec des langages autres que Java. Les types de valeur (comme les types classe des langages de programmation OO) supportent l héritage et le polymorphisme. Ceci signifie que l on peut passer un objet paramètre dont le type réel est dérivé du type formel déclaré dans la signature de l opération. Il n'y a aucune garantie que la cible de la demande (ou de la réponse) connaisse ce type, ou ait le code qui instrumente ce type disponible localement. Dans des programmes Java, la destination peut télécharger l implémentation correcte à la volée. C'est, en pratique, a peu près impossible dans les langages de programmation qui exécutent du code binaire natif. Les types de valeur CORBA résolvent partiellement ce problème en permettant aux types dérivés de valeur d'être tronqués (c.-à-d., l'information qui a constitué le type plus dérivé est perdue) à un type de base, à la discrétion du programmeur. Dans les cas où aucune implémentation n'est disponible et le type ne peut pas être tronqué, la demande envoie une exception. 7

8 RMI au-dessus de IIOP : unification de RMI & CORBA Dans le cadre de la définition d un nouveau type IDL, le reste de la spécification CORBA qui a été affecté a été mise à jour pour s adapter aux types de valeur, y compris la spécification IIOP. En conséquence, la version 1.2 de IIOP (la version IIOP de CORBA 2.3) supporte la sémantique requise pour être utilisée comme protocole de communication pour RMI. Dans la théorie, il aurait été possible de définir une projection (càd un ensemble de règles de marshalling) du modèle de programmation de RMI vers un nouvel IIOP étendu en s'arrêtant là. C'est une bonne chose que l'omg ne se soit pas contenté de cela, parce que le sous-produit le plus intéressant de cet exercice entier aurait été détruit. Au lieu de projeter RMI sur IIOP, l'omg a défini une projection de Java RMI sur IDL. Ceci signifie qu'une description d'interface de RMI peut être convertie en interface équivalente IDL. Ceci a des implications profondes pour des utilisateurs de ces deux technologies. Il est maintenant possible de prendre une application écrite au Java, en utilisant RMI, et d ajouter les nouveaux clients qui sont écrits en un autre langage, sans changer aucune des interfaces RMI existantes. Réciproquement, il est possible de prendre la même application et de remplacer des implémentation d'objet dans l'environnement logiciel serveur par des implémentations écrites en d'autres langages. Pour y parvenir, vous avez besoin d'un produit de l ORB qui supporte la projection Java-IDL. Le produit (habituellement sous forme de postprocesseur de byte-code) lit les fichiers de classes qui incluent les interfaces RMI distantes, et produit l'idl équivalent. Vous pouvez alors traiter cet IDL avec votre compilateur IDL normal (dans l hypothèse où il supporte des types de valeur et d'autres extensions CORBA 2.3), produisant des stubs et des squelettes pour le langage de votre choix. A l'exécution, les stubs RMI marshallent les requêtes en messages IIOP à un bout, et le squelette généré par l IDL (par exemple en C++) marshalle la requête, instanciant les types de valeur des paramètres qui ont été rassemblés comme objets Java. Le programme non-java doit avoir été construit pour inclure des implémentations des types de valeur qui correspondent aux classes Java correspondantes utilisées comme paramètres. Globalement, l'omg n'a pas simplement défini un moyen d'utiliser IIOP comme protocole pour des demandes RMI. L'OMG a plutôt défini une solution d'interopérabilité pour RMI et CORBA, permettant aux programmes écrits avec ces deux technologies de communiquer directement, sans erreur d'impédance. 8

9 IIOP donne le E de EJB L'interopérabilité entre RMI et CORBA est intéressante et utile, mais elle est secondaire par rapport à certaines des autres possibilités que l'unification de RMI/IIOP ouvre. L'impact le plus significatif de l'intégration de RMI/IIOP est sur les Entreprise JavaBeans. EJB a adopté IIOP comme protocole standard d interopérabilité. D'autres protocoles sont autorisés, mais IIOP est exigé pour que des implémentations EJB soient interopérables entre elles. Certaines des raisons de ce choix sont : EJB définit l'interopérabilité de produits basés sur un standard industriel qui s'est révélé pertinent pour l'interopérabilité de produits du monde CORBA. EJB peut interopérer avec des applications CORBA déployées, et utilise l interopérabilité avec CORBA pour la connectivité aux systèmes de production non-java et aux sources de données. IIOP s'est révélé capable de monter en charge pour satisfaire les demandes de grands systèmes d'entreprise, réduisant les risques associés au développement d un nouveau protocole pour les systèmes à objet répartis. Investissement industriel CORBA, ainsi qu IIOP, ont été utilisé dans des développements lourds depuis plus longtemps que n'importe quelle autre technologie d'objet distribués. Les implémentations de CORBA sont fournies par un grand nombre de constructeurs. La concurrence parmi ces constructeurs a mené aux améliorations des implémentations de IIOP, qui a entraîné l ajout de nouvelles capacités au cahier des charges de CORBA lui-même, y compris de nouvelles extensions à IIOP. Certaines de ces nouvelles capacités incluent : La définition des normes pour contrôler des connexions de IIOP à travers des firewalls, y compris des normes pour des proxies IIOP, et l'utilisation améliorée de connexions dans des environnements possédant des firewalls. Un modèle puissant de transaction sur des objets distribués, y compris la validation distribuée en 2 phases, des transactions imbriquées, et une intégration avec les ressources transactionnelles standard par des interfaces XA. Le support des requêtes asynchrones, indépendant du temps, avec la capacité de choisir diverses qualités de service. Des mécanismes flexibles et puissants de sécurité pour l'authentification et le chiffrement 9

10 distribuée. Des capacités encore plus novatrices sont à l étude, incluant : Les normes pour l'usage du même format de message que IIOP (appelé GIOP) avec les nouveaux transports à grande vitesse, tels que ATM, RUDP et FireWire. Des normes pour les systèmes fiables et tolérants aux pannes en utilisant IIOP. L'utilisation des transports multi-cast avec IIOP. Avec le choix de IIOP comme protocole standard pour EJB, les EJB peuvent exploiter les investissements faits dans IIOP par de nombreux constructeurs en concurrence, et les caractéristiques naissantes à l'omg. Intégration avec les systèmes hétérogènes Les systèmes d'entreprise sont intrinsèquement hétérogènes. Même si des organisations font des efforts de normalisation sur des technologies, ils ne peuvent faire cela que sur des périodes limitées. Par la suite, même les plus disciplinées des organisations accumulent une variété de technologies (systèmes d'exploitation, langages de programmation, technologies de gestion de réseau, etc ) qui doivent fonctionner ensemble. En raison de sa nature multi-plateforme et multilangage, CORBA s'est avéré être un mécanisme de choix pour l'intégration de technologies disparates. Etant interopérable par l'intermédiaire de IIOP, les EJB obtiennent la capacité d accéder directement aux systèmes de production existants en étant encapsulés dans des interfaces CORBA. Elimination du risque Des systèmes CORBA utilisant IIOP ont été déployés depuis un certain temps dans de vrais systèmes d'entreprise. IIOP a subi des révisions et évolutions considérables depuis son invention, basée sur une expérience obtenue en vrais développement et déploiement de système. Il est, pour ainsi dire, endurci par la bataille. Par la normalisation de IIOP, EJB élimine les risques et le coût de développer un autre nouveau protocole distribué objet. En fait, IIOP fournit le E dans EJB. 10

11 Implémenter les conteneurs EJB qui supportent IIOP Il est possible de constituer un conteneur d'ejb à partir de zéro, y compris une implémentation sur mesure de RMI au-dessus de IIOP. C est possible, mais pas très recommandé. Ce n est peut pas être évident pour l'observateur occasionnel, mais le moyen le plus pertinent d'établir un système d'exécution sérieux d'ejb est de commencer par un ORB Java récent et de bonne qualité. Les interfaces de conteneur d'ejb peuvent être implémentées comme une couche très mince d'api sur CORBA. Le POA (Portable Object Adapter) de CORBA, par exemple, fournit toute la capacité requise pour mettre en application les politiques exigées de cycle de vie des Beans et des politiques transactionnelles. Si l'orb sous-jacent supporte le service de transaction d'objet CORBA (OTS), alors les besoins transactionnels des EJB sont déjà couverts. EJB prévoit l'utilisation de JTS pour le support de transactions distribuées. Bien que l'on ne s en doute généralement pas, JTS est simplement la projection Java pour les interfaces IDL de CORBA OTS. Que rechercher en priorité dans un conteneur d'ejb? Il y a maintenant un grand nombre de conteneurs EJB de première génération sur le marché, mais aucun d eux ne supporte (à ma connaissance) toutes les conditions pour une implémentation conforme et robuste d'ejb. On devrait noter que les implémentations de RMI au-dessus de IIOP deviennent disponibles seulement maintenant, et que mettre en application simplement RMI audessus de IIOP ne vous fournit pas nécessairement tous les avantages potentiels. Voici quelques capacités à rechercher dans des conteneurs robustes et conformes aux EJB : Une implémentation prouvée de IIOP, y compris des révisions récentes pour IIOP et la projection Java-IDL. Support intégré de la distribution dans une implémentation robuste de JTS/OTS. Interopérabilité démontrable avec des produits ORB connus. Capacité à montée en charge et fiabilité démontrables de l'infrastructure de support. Support des spécifications firewalls de CORBA. Mécanismes de sécurité utilisables basés sur des caractéristiques CORBA. 11

12 Résumé L'intégration des technologies Java et CORBA est une réponse à une demande forte de la communauté d'utilisateur. L'approche adoptée pour intégrer RMI et IIOP a des avantages qui vont au delà de la simple problématique du modèle de programmation et du protocole. Finalement, la large acceptation de Java et des EJB est rendue plus prometteur par le fait qu'ils peuvent exploiter des années d'expérience et d'investissement en technologie CORBA. 12