Module SI4 Applications r

1
Module SI4 Applications réparties

• Questions
• Réponses

Extraits de Mireille Blay-Fornarino, Audrey
Occello et Didier Donsez
2
JNDI ?
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
Différences Serveur de Noms etAnnuaire ?
5
Unicité des noms
EPU
ELEC
BIO
SI
MAM
pinna
arthur
estelle
arthur
clément
6
Association dattributs
EPU
ELEC
BIO
SI
MAM
pinna
arthur
estelle
arthur
clément
Email Password login
Email Password login
Email Password login
Email Password login
Email Password login
7
Exemples Serveur de Noms etAnnuaire ?
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
Configuration JNDI ?
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.initialvalue
  -Djava.naming.provider.urlvalue Server

11
ContextFactory exemples

• FileSystem com.sun.jndi.fscontext.FSContextFacto
  ry
• 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.NdsInitialCon
  textFactory

12
Providers et formats daccès exemples

• FileSystem file//directory_path
• Lightweight Directory Access Protocol (LDAP)
  ldap//hostport
• CORBA services (COS) naming service
  corbalochostport/NameService
• Java Remote Method Invocation (RMI) Registry
  rmi//hostport/
• NIS nis//servername/domain
• NDS nds//ndsTreeName

13
IIOP ?2 Corba sont ils toujours interopérables ?
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
Communication inter-ORB
IIOP
IIOP
TCP/IPnetwork
IIOP
16
RMI et Corba interopérables ?Différences RMI et
Corba ?
17
Protocoles JRMP

• JRMP (Java Remote Method Protocol) est le
  protocole utilisé par Java RMI

18
Pourquoi JNDI ?
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.na
  rrow(obj,MyObject.class)
• Lancement du service de nommage choisi
  (rmiregistry, CosNaming, )

20
RMI IIOP ?
21
(No Transcript)
22
Souches identiques ?
23
Procédure de compilation rmic -iiop
Implementation File(MyObjectImpl.class)
rmic -iiop
Coté client
Coté serveur
_MyObject_Stub.class
_MyObject_Tie.class
24
Influence sur la communication RMI Corba?IDL vs
interface ?
25
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

26
Client CORBA Serveur RMI
Interface RMI de lobjet
IDL CORBA de lobjet
Implémentation RMI de lobjet
Client CORBA
Squelette RMI
Stub CORBA
Protocole IIOP
ORB
ORB
27
Client RMI Serveur CORBA
Interface RMI de lobjet
IDL CORBA de lobjet
Implémentation CORBA de lobjet
Client RMI
Squelette CORBA
Stub RMI
Protocole IIOP
ORB
ORB
28
Serveur RMI ou Serveur Corba?
29
Client RMI Serveur CORBA
Interface RMI de lobjet
IDL CORBA de lobjet
Implémentation CORBA de lobjet
Client RMI
Squelette CORBA
Stub RMI
Protocole IIOP
ORB
ORB

• Étape 1 pas naturelle !
• Ne marche que pour lintégration de nouvelles
  applications

30
Mise en œuvre
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
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
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.na
  rrow(obj,MyObject.class)
• 3. Génération des souches compatibles IIOP rmic
  -iiop

34
Conclusion

• Interopérabilité CORBA/Java RMI peu courante mais
  
• Première approche d'unification CORBA/Java RMI
  contre Microoft gt 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
Quelques références ...

• Complément de cours http//www.essi.fr/pinna/S
  ar/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.ht
  ml
• Tutorial JNDIhttp//java.sun.com/products/jndi/tu
  torial/TOC.html

36
Message Oriented Middleware

• Pourquoi ?

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
Pourquoi un nouveau type de middleware?

• Quelles sont les contraintes RPC derrière RMI ?

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
Exemples dapplications non adaptées?
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
Quelle lignée logicielle ? Historique

• Ce que vous connaissez déjà

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
Communication par message Envoi de datagrammes
Serveur
opération
Client
req1
application
rep1
reqn
repn
45
Communication par diffusion Multicast
Serveur
Client1
application
Gr
Client2
application
Clientn
application
46
Observer Observable ?
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
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
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
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
Structure
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
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
Le service dévénement Corba
55
Récepteur
Emetteur
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
message
Destination
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
Communication événementielleprincipes 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
Un canal dévènements
Flot des évènements
Consommateur
Producteur
Consommateur
Producteur
Canal
Consommateur
Consommateur
59
Un canal dévènements notification
PushConsumer
PushSupplier
Consommateur
Producteur
Push
void push(in any data) raises(Disconnected)
Consommateur
Producteur
Canal
Push
Consommateur
Consommateur
Producteur actif / Consommateur réactif Le canal
diffuse les évènements
60
Un canal dévènements demande
Consommateur
Producteur
Pull()
Consommateur
Producteur
Canal
Pull()
Consommateur
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)
demande
Consommateur
Producteur réactif / Consommateur actif Le canal
procure les évènements
61
Un canal dévènements file dévènements
Consommateur
Producteur
Pull()
Consommateur
Producteur
Canal
Push()
Consommateur
Consommateur
Producteur actif / Consommateur actif Le canal
gère des files dévènements
62
Un canal dévènements collecte dévènements
Consommateur
Producteur
Push()
Consommateur
Producteur
Canal
Pull()
Consommateur
Consommateur
Producteur réactif / Consommateur réactif Le
canal est une entité active voire intelligente