Interopérabilité JOnAS - CORBA

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

2. Objectifs

3. 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

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

5. 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é

6. Choix d’un protocole RMI/IIOP

7. 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.

8. 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)

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

10. Client \ Serveur Sun RMI/IIOP David RMI/IIOP Sun RMI/IIOP oui oui Sun Java IDL oui oui Orbacus oui non David RMI/IIOP oui oui David CORBA oui oui 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é

11. 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

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

13. 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

14. 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

15. 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

16. 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

17. 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

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

19. Service de nommage

20. 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

21. 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

22. Transactions et sécurité

23. 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

24. 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é)

25. 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

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

27. 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

28. 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.

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

30. 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.

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

32. 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

33. 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.

34. 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)

35. Bilan

36. 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)

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