Interopérabilité JOnAS - CORBA Projet de fin d’études chez Evidian Patrick Bruneton et Marc Dutoo

Objectifs

Objectifs de l’interopérabilité Intérêts Relier des applications existantes Permettre des clients EJB multi-langages Buts Interopérabilité inter-conteneurs EJB Accès à un serveur JOnAS depuis un client CORBA Accès à des serveurs CORBA depuis un EJB

Objectifs du stage Les cas envisagés Client CORBA Serveur JOnAS Client EJB

Objectifs 4 niveaux d’interopérabilité Protocole: support du protocole de communication de CORBA par JOnAS Nommage: support du service de nommage CORBA par JOnAS Transactions mixant des ressources CORBA et JOnAS Sécurité

Choix d’un protocole RMI/IIOP

Nécessité d’un protocole RMI/IIOP JOnAS utilise des protocoles RMI inconnus du monde CORBA. IIOP (Internet Inter Orb Protocol) est le protocole de communication de CORBA. EJB impose le modèle de programmation répartie Java RMI, mais pas le protocole sous jacent. EJB s’adapte à CORBA avec RMI/IIOP: modèle de programmation RMI au dessus d’un ORB IIOP.

Protocoles disponibles Sun RMI/IIOP Implémentation de référence par Sun David RMI Personnalité RMI/IIOP de l’ORB Jonathan (Kelua) David RMI (RMI/IIOP) Jérémie (RMI) David (CORBA) Jonathan (ORB)

Comparaison des protocoles Sun RMI/IIOP et David RMI: performances identiques mais plus lent que RMI/JRMP

Comparaison des protocoles Sun : pas de passage de paramètres implicites David : produit Objectweb, similarités avec Jérémie déjà intégré dans JOnAS Test d’interopérabilité Client \ Serveur Sun RMI/IIOP David RMI/IIOP oui Sun Java IDL Orbacus non David CORBA

Choix d’un protocole David RMI est plus adapté à nos besoins par la présence d’intercepteurs Mais, David non disponible au début du projet À défaut, intégration de RMI/IIOP dans JOnAS Possibilité de patcher les stubs pour passage de paramètres implicites

Intégration d’un protocole RMI/IIOP dans JOnAS

JOnAS actuel Deux protocoles, deux distributions: Version RMI/JRMP Version Jérémie Compilation conditionnelle Sources JOnAS Compilation 1 Compilation 2 Version RMI Version Jérémie

2 possibilités d’intégration (1/2) Dans la continuité Sources JOnAS Compilation 1 Compilation 3 Compilation 2 Version RMI Version Jérémie Version RMI/IIOP

2 possibilités d’intégration (2/2) Une seule distribution mais support simultané de plusieurs protocoles Des clients RMI/JRMP et RMI/IIOP peuvent contacter un même serveur. Nécessite un export des beans sur tous les ORB ou un export au cas par cas (plus problématique). Mais difficultés d’unification des sources, notamment au niveau des transactions. Solution étudiée mais non retenue: intégration simple privilégiée

Principe d’intégration (1/2) La classe RemoteObject est la classe de base de tous les objets distants JOnAS. La changer, revient à modifier le protocole de JOnAS. La compilation condition conditionnelle de JOnAS sélectionne une implémentation. Ajout d’un protocole RMI/IIOP: Modification de RemoteObject.jpp Modification des scripts de compilation

Principe d’intégration (2/2) La compilation de JOnAS doit générer les stubs et tie iiop des objets distants : Pour Sun RMI/IIOP : rmic -iiop ne fonctionne pas: compilation de JOnAS impossible (correction dans JDK 1.4) Pour David RMI : nouveau compilateur jrmic

Interopérabilité CORBA Ecriture d’un client CORBA pour JOnAS : Client CORBA (Java, C++, …) Serveur JOnAS (Java) stub tie RMI/IIOP RMI rmic –idl puis idl2java, idl2c++, … rmic -iiop IIOP

Service de nommage

Nécessité d’un CosNaming Le service de nommage de CORBA et de RMI/IIOP est le CosNaming. JOnAS sur David RMI doit l’utiliser (David en a un). En EJB, accès au nommage via JNDI (Java Naming and Directory Interface). Ajout d’une couche JNDI au dessus du CosNaming. Client RMI/IIOP Serveur JOnAS Couche JNDI SUN Client CORBA CosNaming David

Nécessité d’un registre RMI Certains objets JOnAS ne peuvent pas être enregistrés dans le CosNaming. Il faut conserver un registre RMI. Deux services de nommage: Client CORBA JOnAS CosNaming Client RMI/IIOP Registre RMI

Transactions et sécurité

Transactions dans les EJBs Principe mise à jour distribuée ACID de plusieurs ressources réparties (BD, JMS, …) Gestion des transactions Bean-managed Container managed Initialisation possible côté client

Transactions et interopérabilité Le service transactionnel CORBA Object Transaction Service spécifié en IDL Contexte transactionnel Identification et contrôle de la transaction en cours imposé par EJB 2.0 Le cas container-managed Mise en oeuvre immédiate Initialisation côté client interactions EJB – CORBA (contexte propagé)

Transactions et interopérabilité 3 solutions envisagées, la dernière retenue Encapsulation du JOnAS TM sous forme d’OTS Implémentation intégrale d’un OTS pour JOnAS Coopération des mécanismes OTS et JOnAS TM

Encapsulation du JOnAS TM sous forme d’OTS (1/3) Client CORBA Serveur JOnAS Client RMI/IIOP JOnAS TM Couche OTS Current (OTS) UserTransaction (JTA) TransactionManager (JTA)

Encapsulation du JOnAS TM sous forme d’OTS (2/3) Traduction de types OTS – JOnAS TM Exceptions Références d’objets distants CORBA - RMI Unification du contexte transactionnel vers CosTransactions::PropagationContext Utilisation spécifique du champ any Côté client de l’OTS à écrire

Encapsulation du JOnAS TM sous forme d’OTS (3/3) Avantages réutilisation et intégration relatives du code Obtention d’un OTS CORBA complet Inconvénients Trop de traductions d’exceptions Problème du double référencement des interfaces OTS et JOnAS TM D’où abandon.

Implémentation intégrale d’un OTS pour JOnAS (1/2) Client CORBA Serveur JOnAS Client RMI/IIOP JOnAS TM Implémentation JTS Current (OTS) UserTransaction (JTA) TransactionManager (JTA)

Implémentation intégrale d’un OTS pour JOnAS (2/2) Unification du contexte transactionnel Vers celui de CORBA Adaptation par correspondances de types Incompatibilité des APIs 70% du code diffère avec la version RMI Intégration du service peu cohérente avec JOnAS RMI D’où abandon.

Coopération des mécanismes OTS et JOnAS TM (1/3) Chaque monde (EJB et CORBA) contrôle ses propres transactions Client CORBA Serveur JOnAS Client RMI/IIOP JOnAS TM UserTransaction (JTA) TransactionManager (JTA) OTS CORBA Coopération Current (OTS)

Coopération des mécanismes OTS et JOnAS TM (2/3) Contexte transactionnel: champ any un client CORBA appelle un EJB Encapsulation du contrôle JOnAS de la transaction sous forme de ressource CORBA et enregistrement par le contrôle OTS un EJB appelle un objet CORBA Il faut signaler la présence de la transaction à l’OTS du monde CORBA pour qu’il la contrôle chez lui

Coopération des mécanismes OTS et JOnAS TM (3/3) Inconvénients Mise en oeuvre moins évidente Cas de l’appel d’un objet CORBA par un EJB Avantages Réutilisation et intégration maximales Le côté client transactionnel est à la charge de l’OTS externe Solution retenue pour JOnAS David RMI Validation non effectuée faute de temps.

Sécurité Actuellement: contexte de sécurité propagé Spécifique à JOnAS Intégration dans JOnAS David RMI Configuration Sérialisation Java faute de temps Interopérabilité CORBA Sécurité JOnAS étendue au monde CORBA Envisagée (sérialisation IIOP)

Bilan

Validation Utilisation des tests standards Tests portés et validation de JOnAS David Transactions, sécurité Non régression de JOnAS RMI / JRMP Non régression de JOnAS Jérémie Passage à Jonathan 3.0 (transactions et sécurité) Interopérabilité CORBA Validation par test simple (sans transactions)

Conclusion Objectifs atteints Perspectives JOnAS version David RMI Interopérabilité CORBA Perspectives Version JOnAS David RMI officielle (il reste des bugs) Validation de l’interopérabilité des transactions