. - 1 - Module SI4 Applications réparties Questions Réponses Extraits de Mireille Blay-Fornarino, Audrey Occello et Didier Donsez.

Présentation au sujet: ". - 1 - Module SI4 Applications réparties Questions Réponses Extraits de Mireille Blay-Fornarino, Audrey Occello et Didier Donsez."— Transcription de la présentation:

1 . - 1 - Module SI4 Applications réparties Questions Réponses Extraits de Mireille Blay-Fornarino, Audrey Occello et Didier Donsez

2 . - 2 - JNDI ?

3 . - 3 - JNDI en quelques mots Services de nommages connus : rmiregistry, Corba naming Services dannuaires connus : LDAP, DNS Des fonctionnalités communes Principe : Fournir une API (java) uniforme à des services de nommage ou dannuaire Utilisation de pilotes SPI dynamiquement chargeables –LDAP, DNS, NIS, NDS, RMI, CORBA, … et FileSystems

4 . - 4 - Différences Serveur de Noms et Annuaire ?

5 . - 5 - Unicité des noms EPU SI ELECBIO MAM pinna arthurestelle clémen t arthur

6 . - 6 - Association dattributs EPU SI ELECBIO MAM pinna arthurestelle clémen t arthur Email Password login Email Password login Email Password login Email Password login Email Password login

7 . - 7 - Exemples Serveur de Noms et Annuaire ?

8 . - 8 - Service providers (SPI) SPI est linterface permettant dattaquer différents providers de manière uniforme. Les providers « compatibles » doivent fournir un ensemble de classes implémentant javax.naming.spi.

9 . - 9 - Configuration JNDI ?

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

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

12 . - 12 - Providers et formats daccè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

13 . - 13 - IIOP ? 2 Corba sont ils toujours interopérables ?

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

15 . - 15 - (O.R.B.) composant c++ TCP/IP network (O.R.B.) composant java IIOP (O.R.B.) composant cobol BD IIOP Communication inter-ORB IIOP (O.R.B.) composant BD composant (O.R.B.) DCE network DCE-CIOP (O.R.B.) Bridge (O.R.B.) IIOP DCE-CIOP Java-RMI ? ?

16 . - 16 - RMI et Corba interopérables ? Différences RMI et Corba ?

17 . - 17 - Protocoles : JRMP JRMP (Java Remote Method Protocol) est le protocole utilisé par Java RMI

18 . - 18 - Pourquoi JNDI ?

19 . - 19 - JNDI Enregistrement de lobjet 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, …)

20 . - 20 - RMI IIOP ?

21 . - 21 -

22 . - 22 - Souches identiques ?

23 . - 23 - Procédure de compilation : rmic -iiop Implementation File (MyObjectImpl.class) rmic -iiop _MyObject_Stub.class_MyObject_Tie.class Coté clientCoté serveur Interface File (MyObject.class) rmic -iiop _MyObject_Stub.class Coté client

24 . - 24 - Influence sur la communication RMI Corba? IDL vs interface ?

25 . - 25 - Quel sous ensemble de JAVA RMI peut être utilise pour faire du CORBA –Passage par valeur : un équivalent à la sérialisation Java –rmic -idl Intégration Java-RMI/CORBA

26 . - 26 - Implémentation RMI de lobjet Client CORBA + Serveur RMI Client CORBA Stub CORBA ORB Squelette RMI ORB Interface RMI de lobjet 1) rmic -iiop IDL CORBA de lobjet 2) rmic -idl 3) jidl Protocole IIOP

27 . - 27 - Client RMI + Serveur CORBA Implémentation CORBA de lobjet Client RMI Stub RMI ORB Squelette CORBA ORB Interface RMI de lobjet IDL CORBA de lobjet 1) rmic -idl Protocole IIOP 2) jidl 3) rmic -iiop

28 . - 28 - Serveur RMI ou Serveur Corba?

29 . - 29 - Client RMI + Serveur CORBA Implémentation CORBA de lobjet Client RMI Stub RMI ORB Squelette CORBA ORB Interface RMI de lobjet IDL CORBA de lobjet 1) rmic -idl Protocole IIOP Étape 1 pas naturelle ! Ne marche que pour lintégration de nouvelles applications 2) jidl 3) rmic -iiop

30 . - 30 - Mise en œuvre

31 . - 31 - Compatibilité IIOP : Différences de développement coté serveur (1/2) 1. Clause dimportation –javax.rmi.PortableRemoteObject au lieu de java.rmi.UnicastRemoteObject –javax.naming.InitialContext au lieu de java.rmi.Naming 2. Définition de lobjet distant –pas de différence au niveau de linterface de lobjet –au niveau de limplémentation : public class MyObjectImpl extends PortableRemoteObject implements MyObject 3. Enregistrement de lobjet distant via JNDI –InitialContext.rebind("obj_ref", obj); 4. Génération des souches compatibles IIOP : rmic -iiop

32 . - 32 - 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 linteropérabilité avec CORBA, une étape supplémentaire : génération de lIDL avec rmic -idl Pour générer les bonnes souches CORBA

33 . - 33 - Compatibilité IIOP : Différences de développement coté client 1. Clause dimportation (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

34 . - 34 - 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 linteropé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 ?

35 . - 35 - Quelques références... Complément de cours : http://www.essi.fr/~pinna/Sar/AppRep/CoursIIOP- JNDI2.ppt Le site de Sun sur RMI-IIOP : http://java.sun.com/j2se/1.4.2/docs/guide/rmi-iiop/ Un article sur linteropé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

36 . - 36 - Message Oriented Middleware Pourquoi ?

37 . - 37 - Plan Pourquoi un nouveau type de middleware? Quelle lignée logicielle ? Historique JMS : Java Message Server Limplémentation Joram Lavenir pour ce type de middleware

38 . - 38 - Pourquoi un nouveau type de middleware? Quelles sont les contraintes RPC derrière RMI ?

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

40 . - 40 - Exemples dapplications non adaptées?

41 . - 41 - Exemple ladministration 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é

42 . - 42 - Quelle lignée logicielle ? Historique Ce que vous connaissez déjà

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

44 . - 44 - Communication par message : Envoi de datagrammes application opération Client Serveur req1 rep1 reqn repn

45 . - 45 - Communication par diffusion : Multicast application Clientn Serveur application Client1 application Client2 Gr

46 . - 46 - Observer Observable ?

47 . - 47 - Motivation Un effet de bord fréquent de la partition dun 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é.

48 . - 48 - Moyen Définir une dépendance de 1 à n entre des objets telle que lorsque létat dun objet change, tous ses dépendants sont informés et mis à jour automatiquement

49 . - 49 - Quand lappliquer Lorsquune abstraction possède deux aspects dont lun dépend de lautre. –Lencapsulation 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 Lorsquune modification à un objet exige la modification des autres, et que lon ne sait pas a priori combien dobjets devront être modifiés. Lorsquun objet devrait être capable dinformer les autres objets sans faire dhypothèses sur ce que sont ces objets,

50 . - 50 - 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 nimporte quel nombre dobservateurs dépendants Tous les observateurs sont informés lorsque létat de la source change – lobservateur. Chaque observateur demande à la source son état afin de se synchroniser

51 . - 51 - Structure

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

53 . - 53 - 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 dune classe qui implémente linterface Observer void update(Observable o, Object arg); Des listeners

54 . - 54 - Le service dévénement Corba

55 . - 55 - Emetteur Récepteur Destination message 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

56 . - 56 - Le service de notification d'événements Corba La plupart des requêtes CORBA se traduisent par lexécution synchrone dune opération (le client connaît la référence de lobjet auquel la requête sadresse et le client ainsi que lobjet 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 lobjet ne se connaissent pas; lorsque le client et lobjet ne sont pas actifs simultanément.

57 . - 57 - Communication événementielle principes de fonctionnement concepts de base : événements, réactions (traitements associés à loccurrence dun événement) principe dattachement : association dynamique entre un nom dévénement et une réaction communication anonyme : indépendance entre lémetteur et les consommateurs dun événement

58 . - 58 - Un canal dévènements Producteur Consommateur Canal Flot des évènements

59 . - 59 - Un canal dévènements : notification Producteur Consommateur Canal Producteur actif / Consommateur réactif Le canal diffuse les évènements Push PushSupplier PushConsumer void push(in any data) raises(Disconnected);

60 . - 60 - Un canal dévènements : demande Producteur Consommateur Canal Producteur réactif / Consommateur actif Le canal procure les évènements Pull() demande PullSupplier { //demande de production dun événement any pull() raises(Disconnected); // présence dun événement any try_pull(out boolean has_event) raises(Disconnected);

61 . - 61 - Un canal dévènements : file dévènements Producteur Consommateur Canal Producteur actif / Consommateur actif Le canal gère des files dévènements Push() Pull()

62 . - 62 - Un canal dévènements : collecte dévènements Producteur Consommateur Canal Producteur réactif / Consommateur réactif Le canal est une entité active voire intelligente Pull() Push()