1 / 37

Interopérabilité JOnAS - CORBA

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

ronna
Download Presentation

Interopérabilité JOnAS - CORBA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related