Module SI4 Applications réparties Questions Réponses Extraits de Mireille Blay-Fornarino, Audrey Occello et Didier Donsez . -1- JNDI ? . -2- JNDI en quelques mots • Services de nommages connus : rmiregistry, Corba naming • Services d’annuaires connus : LDAP, DNS Des fonctionnalités communes • Principe : Fournir une API (java) uniforme à des services de nommage ou d’annuaire • Utilisation de pilotes SPI dynamiquement chargeables – LDAP, DNS, NIS, NDS, RMI, CORBA, … et FileSystems . -3- Différences Serveur de Noms et Annuaire ? . -4- Unicité des noms EPU SI pinna . MAM arthur clémen t BIO ELEC estelle arthur -5- Association d’attributs EPU SI pinna Email Password login . BIO MAM arthur Email Password login clémen tEmail Password login ELEC estelle Email Password login arthur Email Password login -6- Exemples Serveur de Noms et Annuaire ? . -7- Service providers (SPI) SPI est l’interface permettant d’attaquer différents providers de manière uniforme. Les providers « compatibles » doivent fournir un ensemble de classes implémentant javax.naming.spi. . -8- Configuration JNDI ? . -9- Configuration de JNDI : ContextFactory & Provider Deux façons de configurer ces propriétés : – Paramétrer le contexte initial : Hashtable env = new Hashtable(); env.put("java.naming.factory.initial", ...); env.put("java.naming.provider.url", ...); javax.naming.Context ct = new InitialContext(env); – Passer en paramètre de ligne de commande de Java : java -Djava.naming.factory.initial=value -Djava.naming.provider.url=value Server . - 10 - ContextFactory : exemples • FileSystem : com.sun.jndi.fscontext.FSContextFactory • Lightweight Directory Access Protocol (LDAP) : com.sun.jndi.ldap.LdapCtxFactory • CORBA services (COS) naming service : com.sun.jndi.cosnaming.CNCtxFactory • Java Remote Method Invocation (RMI) Registry : com.sun.jndi.rmi.registry.RegistryContextFactory • NIS : com.sun.jndi.nis.NISCtxFactory • NDS : com.novell.naming.service.nds.NdsInitialContextFactory . - 11 - Providers et formats d’accès : exemples • FileSystem : file://directory_path • Lightweight Directory Access Protocol (LDAP) : ldap://host:port • CORBA services (COS) naming service : corbaloc::host:port/NameService • Java Remote Method Invocation (RMI) Registry : rmi://host:port/ • NIS : nis://servername/domain • NDS : . nds://ndsTreeName - 12 - IIOP ? 2 Corba sont ils toujours interopérables ? . - 13 - Protocoles : GIOP, IIOP • GIOP (General Inter-ORB Protocol) spécifie un standard de communications entre ORBs • IIOP (Internet Inter-ORB Protocol) est l'implémentation la + populaire du protocole GIOP au dessus de TCP/IP . - 14 - Communication inter-ORB composant java composant c++ (O.R.B.) (O.R.B.) IIOP BD IIOP composant cobol (O.R.B.) TCP/IP network ? DCE-CIOP . composant IIOP DCE-CIOP Bridge (O.R.B.) DCE network (O.R.B.) Java-RMI ? IIOP (O.R.B.) DCE-CIOP (O.R.B.) composant BD - 15 - RMI et Corba interopérables ? Différences RMI et Corba ? . - 16 - Protocoles : JRMP • JRMP (Java Remote Method Protocol) est le protocole utilisé par Java RMI . - 17 - Pourquoi JNDI ? . - 18 - JNDI Enregistrement de l’objet distant via JNDI – InitialContext.rebind("obj_ref", obj); Obtenir un objet distant toujours via JNDI – InitialContext IC = new InitialContext(env); – Object obj = IC.lookup("obj_ref"); – MyObject myobj = (MyObject)PortableRemoteObject.narrow(obj,MyObje ct.class); Lancement du service de nommage choisi : (rmiregistry, CosNaming, …) . - 19 - RMI IIOP ? . - 20 - . - 21 - Souches identiques ? . - 22 - Procédure de compilation : rmic -iiop Implementation File (MyObjectImpl.class) Coté client rmic -iiop _MyObject_Stub.class Coté serveur _MyObject_Tie.class Interface File (MyObject.class) Coté client rmic -iiop _MyObject_Stub.class . - 23 - Influence sur la communication RMI Corba? IDL vs interface ? . - 24 - Intégration Java-RMI/CORBA • Quel sous ensemble de JAVA RMI peut être utilise pour faire du CORBA – Passage par valeur : un équivalent à la sérialisation Java – rmic -idl . - 25 - Client CORBA + Serveur RMI IDL CORBA de l’objet 3) jidl 2) rmic -idl Interface RMI de l’objet Implémentation RMI de l’objet Client CORBA 1) rmic -iiop Stub CORBA ORB . Squelette RMI Protocole IIOP ORB - 26 - Client RMI + Serveur CORBA Interface RMI de l’objet 3) rmic -iiop 1) rmic -idl Implémentation CORBA de l’objet Client RMI Stub RMI ORB . IDL CORBA de l’objet 2) jidl Squelette CORBA Protocole IIOP ORB - 27 - Serveur RMI ou Serveur Corba? . - 28 - Client RMI + Serveur CORBA Interface RMI de l’objet 3) rmic -iiop 1) rmic -idl Implémentation CORBA de l’objet Client RMI Stub RMI ORB IDL CORBA de l’objet 2) jidl Squelette CORBA Protocole IIOP ORB Étape 1 pas naturelle ! Ne marche que pour l’intégration de nouvelles applications . - 29 - Mise en œuvre . - 30 - Compatibilité IIOP : Différences de développement coté serveur (1/2) 1. Clause d’importation – javax.rmi.PortableRemoteObject au lieu de java.rmi.UnicastRemoteObject – javax.naming.InitialContext au lieu de java.rmi.Naming 2. Définition de l’objet distant – pas de différence au niveau de l’interface de l’objet – au niveau de l’implémentation : public class MyObjectImpl extends PortableRemoteObject implements MyObject 3. Enregistrement de l’objet distant via JNDI – InitialContext.rebind("obj_ref", obj); 4. Génération des souches compatibles IIOP : rmic -iiop . - 31 - Compatibilité IIOP : Différences de développement coté serveur (2/2) 5. Lancement du service de nommage choisi : (rmiregistry, CosNaming, …) 6. Dans le cas de l’interopérabilité avec CORBA, une étape supplémentaire : génération de l’IDL avec rmic -idl Pour générer les bonnes souches CORBA . - 32 - Compatibilité IIOP : Différences de développement coté client 1. Clause d’importation (idem serveur) – javax.rmi.PortableRemoteObject; – javax.naming.InitialContext; 2. Obtenir un objet distant toujours via JNDI – InitialContext IC = new InitialContext(env); – Object obj = IC.lookup("obj_ref"); – MyObject myobj = (MyObject)PortableRemoteObject.narrow(obj,MyObject.class); 3. Génération des souches compatibles IIOP : rmic -iiop . - 33 - Conclusion • Interopérabilité CORBA/Java RMI peu courante mais – Première approche d'unification : CORBA/Java RMI contre Micro$oft => effort pour faire face aux solutions tout Microsoft – des utilisations plus fréquentes depuis l'apparition des EJB • Importance de l’interopérabilité face à la prolifération des langages, des middlewares, ... • Maturation des technologies émergence des middlewares orientés composants : ccm, .net • Réalité différente dans les entreprises : solutions tout XML nécessité de traduire de A vers XML puis de XML vers B même mécanismes sous-jacents (langage intermédiaire, conversion des données, ...) Pourquoi réinventer la roue ? . - 34 - Quelques références ... • Complément de cours : http://www.essi.fr/~pinna/Sar/AppRep/CoursIIOPJNDI2.ppt • Le site de Sun sur RMI-IIOP : http://java.sun.com/j2se/1.4.2/docs/guide/rmi-iiop/ • Un article sur l’interopérabilité RMI/CORBA : http://www.javaworld.com/jw-12-1999/jw-12-iiop.html • Tutorial JNDI http://java.sun.com/products/jndi/tutorial/TOC.html . - 35 - Message Oriented Middleware Pourquoi ? . - 36 - Plan • • • • Pourquoi un nouveau type de middleware? Quelle lignée logicielle ? Historique JMS : Java Message Server L’implémentation Joram L’avenir pour ce type de middleware . - 37 - Pourquoi un nouveau type de middleware? Quelles sont les contraintes RPC derrière RMI ? . - 38 - Intention Quelles sont les contraintes RPC derrière RMI ? communication synchrone Client-Serveur le serveur est prédominant dans la communication On souhaite ne pas être bloqué pendant une communication (asynchrone) ne pas connaître toujours au préalable ceux avec qui on communique . - 39 - Exemples d’applications non adaptées? . - 40 - Exemple l’administration de réseaux • Gestion à distance de machines, serveurs, hubs, etc • Notification des événements en cas de panne – Intégration de modules hétérogènes distribués – Indépendance (asynchronisme) – Fiabilité . - 41 - Quelle lignée logicielle ? Historique Ce que vous connaissez déjà . - 42 - Quelle lignée logicielle ? Historique • Communication par message au niveau socket : communication udp et multicast • Connexions faibles entre objets : le design Pattern Observer Observable • Programmation Java : interface graphique et gestion d’événements (listeners) • Et en Corba : le service d’événements . - 43 - Communication par message : Envoi de datagrammes Serveur Client req1 rep1 application . reqn repn opération - 44 - Communication par diffusion : Multicast Serveur Client1 application Client2 Gr application Clientn application . - 45 - Observer Observable ? . - 46 - Motivation • Un effet de bord fréquent de la partition d’un système en une collection de classes coopérantes est la nécessité de maintenir la consistance entre les objets reliés entre eux. • On ne veut pas obtenir la consistance en liant étroitement les classes, parce que cela aurait comme effet de réduire leur réutilisabilité. . - 47 - Moyen Définir une dépendance de “1” à “n” entre des objets telle que lorsque l’état d’un objet change, tous ses dépendants sont informés et mis à jour automatiquement . - 48 - Quand l’appliquer • Lorsqu’une abstraction possède deux aspects dont l’un dépend de l’autre. – L’encapsulation de ces aspects dans des objets séparés permet de les varier et de les réutiliser indépendemment. – Exemple : Modèle-Vue-Contrôleur • Lorsqu’une modification à un objet exige la modification des autres, et que l’on ne sait pas a priori combien d’objets devront être modifiés. • Lorsqu’un objet devrait être capable d’informer les autres objets sans faire d’hypothèses sur ce que sont ces objets, . - 49 - Besoin d’événements • Le pattern “Observer” décrit – comment établir les relations entre les objets dépendants. • Les objets-clés sont – la source • Peut avoir n’importe quel nombre d’observateurs dépendants • Tous les observateurs sont informés lorsque l’état de la source change – l’observateur. • Chaque observateur demande à la source son état afin de se synchroniser . - 50 - Structure . - 51 - Bénéfices • Utilisation indépendante des sources et des observateurs. – On peut réutiliser les sources sans réutiliser les observateurs et vice-versa. – On peut ajouter des observateurs sans modifier la source et les autres observateurs. • Support pour la communication “broadcast” – La source ne se préoccupe pas du nombre d’observateurs. . - 52 - Implémentations Java du pattern Une classe et une interface : class Observable {... } et interface Observer Un objet Observable doit être une instance de la classe qui dérive de la classe Observable Un objet observer doit être instance d’une classe qui implémente l’interface Observer void update(Observable o, Object arg); Des listeners . - 53 - Le service d’événement Corba . - 54 - Récepteur Emetteur message Destination . Emetteur et récepteur connaissent seulement la destination Plusieurs émetteurs et récepteurs sur la Même destination Persistance du message (reçu ou non reçu) Format du message libre Acheminement par un bus de message - 55 - Le service de notification d'événements Corba La plupart des requêtes CORBA se traduisent par l’exécution synchrone d’une opération (le client connaît la référence de l’objet auquel la requête s’adresse et le client ainsi que l’objet doivent être tous deux actifs) et sinon? Le service d'Evénements ou Event service permet de découpler la communication entre objets. Mode de communication découplé : lorsque le client et l’objet ne se connaissent pas; lorsque le client et l’objet ne sont pas actifs simultanément. . - 56 - Communication événementielle principes de fonctionnement • concepts de base : événements, réactions (traitements associés à l’occurrence d’un événement) • principe d’attachement : association dynamique entre un nom d’événement et une réaction • communication anonyme : indépendance entre l’émetteur et les “consommateurs” d’un événement . - 57 - Un canal d’évènements Flot des évènements Consommateur Producteur Consommateur Producteur Canal Consommateur Consommateur . - 58 - Un canal d’évènements : notification PushConsumer Consommateur PushSupplier Push Producteur void push(in any data) raises(Disconnected); Consommateur Producteur Push Canal Consommateur Consommateur Producteur actif / Consommateur réactif Le canal diffuse les évènements . - 59 - Un canal d’évènements : demande Consommateur Pull() Producteur Consommateur Producteur Pull() Canal Consommateur PullSupplier { //demande de production d’un événement demande any pull() raises(Disconnected); Consommateur // présence d’un événement any try_pull(out boolean has_event) raises(Disconnected); Producteur réactif / Consommateur actif Le canal procure les évènements . - 60 - Un canal d’évènements : file d’évènements Consommateur Pull() Producteur Consommateur Producteur Push() Canal Consommateur Consommateur Producteur actif / Consommateur actif Le canal gère des files d’évènements . - 61 - Un canal d’évènements : collecte d’évènements Consommateur Push() Producteur Consommateur Producteur Pull() Canal Consommateur Consommateur Producteur réactif / Consommateur réactif Le canal est une entité active voire intelligente . - 62 -