Transcript Aucun titre de diapositive

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 -