Architectures Logicielles

Distribuées

2ème Année GI

Mohammed Karim GUENNOUN

1
 Points abordés
 Concepts généraux des architectures logicielles
– Les niveaux d’abstraction d’une application
– Les modèles architecturaux classiques
– La communication
– Les modèles de développement
 Projection vers des middlewares
– Sockets
 Démo/TP
– RMI
 Démo/TP

2
 Les trois niveaux
d’abstraction

3
 Les niveaux d’abstraction

 En règle générale, une application est

constituée de 3 niveaux d’abstraction:
– La couche présentation
(presentation layer) Client
– La couche application

Système d’information
(application logic layer) Présentation
– La couche gestion des ressources
Applicative
(ressource management layer)
Ressources
4
 La couche présentation (1/2)

 Tout système doit communiquer avec des entités

externes:
– Humains
– Autres machines …
 Besoin de présenter convenablement l’information
à ces entités:
– Objectif: permettre de soumettre des opérations et d’avoir
les réponses
 Les éléments qui permettent ce type de traitement
appartiennent à la couche présentation
5
 La couche présentation (2/2)

 Les éléments de cette couche ne doivent pas

être confondus avec le client.
 Le client est l’utilisateur du système
 Exemples de module de présentation:
– Interface graphique (GUI)
– Pages/Formulaires HTML
– Application mobile

6
 La couche application

 Le système doit délivrer de l’information

 Généralement, il effectue des tâches de
calcul sur des données
 Il implémente les opérations requises par le
client à travers la couche présentation
 Les modules, programmes et composants
qui réalisent cette implémentation constituent
la couche applicative.
7
 La couche application

 Les éléments sont appelés: services

 Exemple: service de retrait sur compte bancaire:
– Prend la requête de retrait
– Vérifie que le compte est assez approvisionné
– Vérifie que le plafond de retrait n’est pas atteint
– Donne l’autorisation de retrait pour la somme demandée
– Met à jour le nouveau solde
 Autre appellation pour ce niveau: processus
business, logique business, règles business, ou
simplement: serveur.

8
 La couche gestion de ressources

 Les systèmes d’information ont besoin de

données sur lesquels travailler
 Les données sont stockées sur
– Bases de données
– Fichiers
– ERPs…
 La couche ressources correspond à ce type
d’entités
9
 Couche gestion de ressources

 Autre appellation: couche données

 Cela correspond au mécanismes de
stockage persistant des données
 Dans des architectures plus complexes, la
couche gestion de ressources peut aussi
être un autre système d’information

10
 Des couches conceptuelles
vers les tiers
 Les trois couches présentation, application, et ressources sont des
couches conceptuelles pour séparer les fonctionnalités d’un système
 Dans les systèmes réels, ces couches peuvent être distribuées et
combinées de différentes manières
 On parle alors de tiers
 Selon l’organisation considérée pour ces tiers, on obtient les
modèles architecturaux:
– 1-tier
– 2-tier
– 3-tier
– N-tier

11
 L’architecture 1-tier

12
 Il était une fois…
l’architecture 1-tier

 Historiquement, au début
– Gros serveurs et calculateurs déconnectés Client
– Une interface réduite à un invite de
commande Présentation
– Problématique principale: utiliser
efficacement la CPU
 Systèmes monolithiques Application
 Les trois couches sont dans le même
tier Ressources
 Le système vu comme une boîte noire Architecture
 Pas d’interaction avec d’autres 1-tier
13
systèmes ni d’API
 Avantages

 Possibilité de fusionner à souhait les différentes

couches pour optimiser l’application
 Pas besoin de maintenir et de publier une
interface,
 Aucune raison d’investir dans des
transformations complexes de données pour la
compatibilité
 Coût nul concernant le développement des
clients et le déploiement de l’application.
 Sécurisation et diagnostiquabilité plus simples

14
 Inconvénients

 Un code monolithique et rigide

 Efficace mais très couteux et difficile à
maintenir
 Obsolète par rapport au matériel
 L’industrie du logiciel à pris le chemin
opposé.

15
 L’architecture 2-tier

16
 L’architecture 2-tier
 Emergence due à l’apparition du PC
 Coexistence de machines moins puissantes (PC et stations de
travail) avec de grosses machines (calculateurs et serveurs)
 Pour les designers:
– Besoin de garder ensemble les couches gourmandes en ressources
– La couche présentation est mise avec le client
 Avantages principaux:
– Liés intrinsèquement à la distribution
– Rendre possible la définition de plusieurs présentations pour la même
application sans la rendre plus complexe
– La couche présentation est déplacée dans le PC libérant de la puissance
de calcul pour les deux autres couches
17
 L’architecture 2-tier
Client
 L’architecture 2-tier devient Présentation

Système d’information
très populaire. On parle
alors d’architecture Client-
Serveur Application

Serveur
 Le tier client correspond à la
couche présentation Ressources

 Le tier serveur englobe les

deux couches application et
gestion des ressources
18
 Client léger Vs Client lourd

 Le client peut implémenter quelques fonctionnalités du serveur.

 Selon la complexité du client on parle de
– Clients légers qui offrent seulement des fonctionnalités minimales
– Clients lourds avec la prise en compte de certains traitements
 Les clients légers
– Sont faciles à installer, déployer, maintenir
– Ont besoin de peu de ressources de calcul
– Peuvent être déployés sur un large spectre de machines
 Les clients lourds
– Ont besoin de plus de ressources de calcul
– Ne peuvent être déployés sur des machines légères

19
 Développements associés à
l’architecture Client-Serveur

 Les systèmes client-serveur ont permis plusieurs

avancées dans les domaines du logiciel et du matériel
avec une boucle vertueuse:
– Avec l’augmentation des ressources dans les PCs et les stations
de travail, la couche client est devenue de plus en plus
sophistiquée.
– La sophistication des clients a poussé vers une amélioration des
performances dans les machines et dans les réseaux
 L’approche C-S est associée avec des développements
cruciaux dans les systèmes distribués
– La notion de RPC (Remote Procedure Call). Interaction à base
d’appel de procédure.
– La notion d’interface de connexion
20
 Avantages sur le 1-tier

 La distribution avec tous ses avantages…

 Les couches application et ressources sont
ensembles
– L’exécution des opérations reste performante
 Indépendance du client et du serveur
– Portabilité sur plusieurs plateformes
– Possibilité de définir des couches présentation
différentes pour différents clients à moindre coût

21
 Inconvénients

 Apparition de problématiques nouvelles

– Les problématiques de communication
– Les accès concurrents
– Passage à l’échelle (scalability)
– Sécurité
– La recherche et publication
– Les transactions

22
 Architecture 3-tier

23
 L’architecture 3-tier
 Une séparation claire entre les
différentes couches abstraites:
Client
– La couche présentation réside
chez le client Présentation

Système d’information
– La couche application réside
dans le tier du milieu
Middleware
 L’infrastructure qui supporte le
développement de la logique Application
business est appelée middleware
– La couche gestion de ressources
réside dans un troisième tier Ressources
24
 Comparaison avec l’architecture 2-tier

 Dans l’architecture 2-tier la couche application et gestion des ressources sont

co-localisées
– Avantage: le coût de la communication est nul
– Inconvénient: il faut une machine puissante pour exécuter les deux
 Pour l’architecture 3-tier, séparation des deux couches
– Avantage:
 Possibilité de les distribuer sur différentes machines
 Augmentation de la performance
 Les deux sont moins liées
 Reutilisabilté
 Maintenabilité
– Inconvénient:
 Complexité de l’architecture
 Coût de communication additionnel entre les deux couches
25
 Développements liés à l’architecture 3-tier

 L’apparition d’architectures 3-tiers a engendré des avancées:

– Les gestionnaires de ressources ont dû s’adapter pour offrir des interfaces
permettant la communication avec la couche application qui s’exécute dans le
middleware
– Apparition de standards de communication pour les gestionnaires de
ressources pour un accès uniforme de la couche application
 Java DataBase Connectivity: JDBC
 ORMs
 L’architecture 2-tier a forcé l’apparition d’API pour la couche
application alors que l’architecture 3-tier a provoqué
l’apparition d’API pour la couche gestion des ressources

26
 Développements liés à l’utilisation des
middlewares (1/2)

 L’apparition des architectures 3-tier a induit

l’apparition de middleware permettant:
– Une intégration aisée de la logique métier
– Des fonctionnalités pour la gestion des
ressources:
 Recherche/Publication
 Communication
 Accès concurrents/gestion des instances
 Persistence
 Garanties transactionnelles
27
 …
 Développements liés à l’utilisation
des middlewares (2/2)

 Les concepteurs se concentrent sur la logique

métier et profitent du support offert par le
middleware pour le développement des
interactions complexes
 La perte de performance liée à l’augmentation du
coût de communication est généralement
compensée par la possibilité de distribuer le tier du
milieu sur plusieurs nœuds machine augmentant la
scalabilité et la disponibilité de la communication

28
 Inconvénients

 Les inconvénients de l’architecture 3-tier sont

aussi liés aux problèmes d’intégration
– Pour l’architecture 2-tier, le problème venait de la
difficulté de faire interagir un client avec différents
types de serveurs
– Pour l’architecture 3-tier, le problème vient de la
nécessité d’intégrer des applications inter-
organisations et inter-réseaux
– L’absence de standard de communication entre les
différentes architectures est un handicap majeur

29
 L’architecture N-tier

30
 L’architecture N-tier

 Les architectures N-tier ne constituent pas

réellement une évolution architectural par
rapport à l’architecture 3-tier
 C’est une extension de ce modèle en
considérant l’Internet comme canal
d’intéraction
 La majorité des systèmes construits
actuellement

31
 Une architecture N-tier Client
Explorateur
Web

 La couche Présentation est scindée

en deux tiers Serveur
– Un tier Client comprenant un Web
Tier Web
explorateur Web et des pages

Système d’information
Moteur
HTML, HTML
– Un tier Web comprenant le
serveur Web et le code qui
prépare les pages HTML Middleware
Couche
 Les tiers Application et Gestion de Application
données gardent la même
sémantique
Couche
Ressources
32
 La distribution
 En passant de l’architecture 1-tier vers la 2-tier, 3-tier, et
N-tier, on assiste a une constante addition de tiers.
 Avec chaque tier,
– l’architecture gagne en
 Flexibilité
 Fonctionnalité
 Distribution
– Perd en performance par rapport à l’augmentation du coût
des communications entre les différents tiers
– Introduit plus de complexité pour la gestion et la maintenance
 Il faut que le gain en flexibilité et en scalabilité compense la
33
perte de performance due à la communication
 Communication
dans les systèmes
d’information

34
 La communication dans les systèmes
d’information

 Nous avons discuté comment les couches

abstraites et les tiers peuvent être combinés et
distribués
 Séparer le systèmes en plusieurs tiers implique
l’implémentation d’une certaine communication
entre ces éléments
 La caractéristique dominante des différents
mode d’interaction correspond aux choix
synchrone ou asynchrone
– Appels bloquants ou non bloquants

35
 Interactions
Synchrones

36
 Interaction synchrone

 Dans une interaction synchrone un processus qui appelle

un autre doit attendre la réponse avant de continuer ses
traitements.
Le processus Le processus
appelant invoqué
Période de

Requête
blocage

Réponse

37
 Avantages (1/2)

 Attendre la réponse avant de continuer

présente plusieurs avantages:
– Simplifier la conception
– L’état du processus appelant n’est pas altéré entre
son appel et la réponse
– Corrélation simple entre le code qui fait l’appel et le
code qui traite la réponse (les deux bouts de code
sont en séquence)
– Les composants sont fortement liés pour chaque
interaction. Plus de facilité pour le test, le débogage,
38
et l’analyse de performance
 Avantages (2/2)

 Au passage de l’architecture 1-tier vers 2-tier, la

majorité des systèmes utilisent du synchrone
pour la communication entre clients et serveur

 Au passage vers l’architecture 3-tier, la majorité

des serveurs de données offrent une
communication synchrone avec la couche
application

39
 Inconvénients

 Tous les avantages peuvent être aussi vus comme des

inconvénients spécialement quand l’interaction n’est pas
de type requête-réponse (e.g. one way)
 Perte de temps et de ressources calcul si le traitement
côté serveur est long
 Le problème de performance augmente avec
l’augmentation du nombre de tiers
 En terme de tolérance aux fautes, le processus appelant
et le processus invoqué doivent être connectés et
opérationnels lors de l’invocation. Ils doivent le rester tout
au long de l’exécution de la requête
40  Les procédures de maintenance doivent être faites offline
 Interactions
asynchrones

41
 Les interactions asynchrones

 Quand il est nécessaire de travailler de manière

interactive, le choix synchrone s’impose
 Dans plusieurs cas, cela n’est pas nécessaire
– Impression
 J’envois une demande d’impression
 La demande est insérée dans la liste des taches
 L’imprimante traite la tache quand elle est disponible
 La machine est notifiée de la fin du traitement

42
 Les interactions asynchrones
 Au lieu de faire une requête et attendre la réponse
– Envoyer la requête
– Vérifier plus tard si une réponse a été retournée
Le processus Le processus
appelant invoqué
Le processus

put fetch
reste actif

Tampons

fetch put

43
 Avantages

 Suivre une approche non bloquante permet:

– Au programme appelant de continuer à réaliser d’autres tâches
pendant le traitement de sa requête
– D’éliminer le traitement de la coordination entre les deux
processus
 Réduction des problèmes dus
– Au nombre de connections
– À la dépendance entre composants
– À la tolérance aux fautes
 Modèle adéquat dans certaines situations (style
publisher-subscriber)
– Un serveur dissémine l’information vers plusieurs clients
44 – Différents clients s’intéressent à différents types d’information
 Evolution des concepts de
développement logiciel

45
 Applications Procédurales Centralisées

 E.g. C, Pascal, Ada

 L’univers est constitué principalement de
procédures et de fonctions
 Le programme s’exécute sur une machine
unique
 Interactions principalement via une interface
IHM locale

46
 L’orienté objet
 E.g. Java, C++, Eiffel
 Vision plus proche du monde réel
 L’univers est constitué principalement d’objets
– Attributs
– Méthodes
 L’orienté objet est plus une vision relative à l’organisation de
l’implantation
– La distribution et le déploiement ne sont pas pris en compte
 Concepts nouveaux:
– Attributs (caractéristiques d’un objets)
– Méthodes (actions possibles sur un objet)
– API

47
 L’orienté composant
 E.g. RMI, Corba, ejb
 Au-delà de l’orienté objet
 On s’intéresse maintenant à la structure en terme de
– Décomposition du code exécutable stand-alone (composants)
– Déploiement au niveau des environnements d’exécution
 Objectifs principaux, au sein d’une entité:
– Réutilisation
– Composition
– Facilitation de développement
 Nouveaux Concepts:
– Interface
– Connexions
– Middleware

48
 L’orienté service
 E.g. Services Web
 Au-delà de l’orienté-composant
 Le web et les applications inter-entités
 Objectifs principaux
– Développer le e-business
– Publier-rechercher des services sur le web
– Composition dynamique de services
 Nouveaux concepts
– Registres de publications
– Standards de
 Description
 Communication
 Publication

49
 Paradigmes de communication
pour les middlewares

 MOM
– Orienté messages
 RPC
– Orienté procédures
 RMI
– Orienté méthodes

50
 Ce qu’il faut retenir

51
 Retour sur les thèmes abordés

 Trois couches conceptuelles sont identifiées

– Présentation
– Application
– Gestion de ressources
 Quatre modèles architecturaux
– 1-tier, 2-tier, 3-tier, N-tier
 Deux modèles de communication:
– Client-Serveur
– Publisher-Subscriber
52
 La distribution, c’est Darwin!

 La distribution des couches conceptuelles a évolué en

réponse à des évolutions au niveau matériel et réseau
– Avec les gros serveur et calculateurs: l’architecture 1-tier
– Avec les réseaux locaux et l’apparition des PCs et des
stations de travail: l’architecture client-serveur
– Avec la prolifération de l’information et l’augmentation de la
bande passante: l’architecture 3-tier
– Avec l’avènement d’Internet, une bande passante en
augmentation constante, et l’essor du e-business:
l’architecture N-tier

53
 L’évolution de la programmation

 De programmes monolithique isolés

 Vers une structuration des applications en services distribués à
travers le Web
 Développement d’outils et de standards
– Conception
– Développement
– Déploiement
 De plus en plus de génération automatique de code
– Stubs / Skeletons, classes de support
 Décharger un maximum le développeur pour se consacrer à la
logique business

54
Un middleware MOM:
La communication
par Sockets en Java
 Fonctionnement
 Deux composants élémentaires
– Serveur
– Client
 Deux phases
– Établissement de la connexion
– Interaction à base d’échange de messages
 Mode synchrone connecté
 L’envoi de message est réalisé par une écriture sur un flux
 La réception de message est réalisée par une lecture sur un
flux

56
Architecture

Sockets
Machine 1 d’échange Machine 2

Client Serveur

… … … …

Socket
d’échange Socket
d’écoute
Envoi de messages entre Machine1:Port1 et Machine2:Port2

Port 1
Port 2
Le package

 Le package utilisé pour l’implantation de la

communication par sockets: java.net
 Comprend les classes
– java.net.InetAddress: permet de manipuler les adresses
IP
– java.net.ServerSocket: permet de programmer
l’interface côté serveur (sockets d’écoute)
– java.net.Socket: permet de programmer la
communication côté client et serveur (sockets
d’échange)
La classe InetAddress (1/2)

 3 méthodes statiques pour créer des objets adresse IP

– public static InetAddress getLocalHost() throws
UnknownHostException
 renvoie l'adresse du site local d'appel.
– public static InetAddress getByName(String host) throws
UnknownHostException
 construit un nouvel objet InetAddress à partir d'un nom textuel de site.
 Le nom du site est donné sous forme symbolique (www.ehtp.ac.ma) ou
sous forme numérique (147.127.18.03).
– public static InetAddress[] getAllByName(String host) throws
UnknownHostException
 permet d'obtenir les différentes adresses IP d'un site.
La classe InetAddress (2/2)

 Trois méthodes pour obtenir les informations

sur l’objet adresse IP
– public String getHostName()
 obtient le nom complet correspondant à l'adresse IP
– public String getHostAddress()
 obtient l'adresse IP sous forme %d.%d.%d.%d
– public byte[] getAddress()
 obtient l'adresse IP sous forme d'un tableau d'octets
La classe ServerSocket (1/2)

 Les constructeurs
– public ServerSocket()
 Créée un objet socket d’écoute non liée
– public ServerSocket(int p) throws IOException
 Crée un objet socket à l’écoute du port p. Une valeur 0 implique une
allocation automatique d’un port libre.
 Les getters
– public InetAddress getInetAddress()
 Permet de récupérer l’objet adresse IP
– public int getLocalPort()
 Permet de récupérer le port d’écoute
La classe ServerSocket (2/2)

 Les méthodes
– public Socket accept() throws IOException
 Acceptation de la connection d’un client
 Opération bloquante
 Par défaut, le temps d’attente est infini
– public void setSoTimeout(int timeout) throws SocketException
 L’argument est en milliseconds
 Définit un délai de garde. 0 implique un temps de garde infini
 À l’expiration, l’exception java.io.InterruptedIOException est levée
– public void close()
 Ferme la socket d’écoute
La classe Socket (1/3)
 Utilisée pour la programmation des sockets connectées côté client et serveur.
 Création
– Côté Serveur: résultat de l’appel de la méthode accept
– Côté Client: par l’appel des constructeurs
 public Socket(String host, int port) throws UnknownHostException, IOException
– Ouvre une socket sur une machine et un port côté serveur. Le choix côté client n’est
pas spécifié.
 public Socket(InetAddress address, int port) throws IOException
– Utilise l’objet InetAddress au lieu d’une chaine de caractères
 public Socket(String host, int port, InetAddress localAddr, int localPort) throws
UnknownHostException, IOException
– Spécifie une adresse et un port côté Client
 public Socket(InetAddress addr, int port, InetAddress localAddr, int localPort) throws
IOException
La classe Socket (2/3)

 Les getters
– public InetAddress getInetAddress()
 L’adresse IP distante
– public InetAddress getLocalAddress()
 L’adresse IP locale
– public int getPort()
 Le port distant
– public int getLocalPort()
 Le port local
La classe Socket (3/3)

 Méthodes
– public OutputStream getOutputStream() throws IOException
 Ouvre un flux d’écriture sur la socket
 Permet de construire un objet PrintWriter
– public InputStream getInputStream() throws IOException
 Ouvre un flux de lecture sur la socket
 Permet de construire un objet BufferedReader
 L’opération de lecture est bloquante
– public void close()
 Ferme la socket et libère les ressources
Ecriture du code: côté serveur
 Créer une socket d’écoute
– ServerSocket SS= new ServerSocket(NumeroPort);
 Récupérer la socket d’échange
– Socket S=SS.accept();
 Ouvrir un flux de lecture sur la socket
– BufferedReader BR = new BufferedReader(new
InputStreamReader(S.getInputStream()));
 Ouvrir un flux d’écriture sur la socket
– PrintWriter PW = new PrintWriter(S.getOutputStream());
 Réaliser les traitements
 Communication à travers les flux de lecture et d’écriture
– BR.readLine();
– PW.println(message);
Ecriture du code: côté Client

 Créer la socket d’échange

–Socket S=new Socket(AdresseServeur,port);
 Ouvrir un flux de lecture sur la socket
– BufferedReader BR = new BufferedReader(new
InputStreamReader(S.getInputStream()));
 Ouvrir un flux d’écriture sur la socket
– PrintWriter PW = new PrintWriter( S.getOutputStream());
 Réaliser les traitements
 Communication à travers les flux de lecture et d’écriture
– BR.readLine();
– PW.println(message);
– PW.flush();
Remote Method Invocation
RMI
Remote Method Invocation

 RMI technologie pour la mise en œuvre d’objets

distribués
 Le but de RMI est de permettre l'appel, l'exécution et
le renvoi du résultat d'une méthode exécutée dans
une machine virtuelle différente de celle de l'objet
l'appelant
 S’appuie sur le stub pour implémenter la
communication distante
 Package: java.rmi
 Les deux parties
 Une application RMI est constituée généralement de
deux programmes:
– Partie Serveur:
 Crée des objets distants
 Crée des références sur ces objets pour les rendre accessibles
 Attends les requêtes des clients: appels distants sur les méthodes de
ces objets
– Partie Client:
 Obtient une ou plusieurs références sur des objets distants localisés
sur un ou plusieurs serveurs
 Effectue des appels distants sur les méthodes des objets

70
 Interfaces, objets et méthodes
distantes

 Comme n’importe quelle application Java, une application

distribuée RMI est constituée d’interfaces et de classes
– Les interfaces déclarent des méthodes
– Les classes implémentent ces méthodes et d’autres méthodes
additionnelles
 Les objets possédant des méthodes pouvant être appelées à
travers plusieurs JVMs sont appelés objets distants.
– Ils implémentent une interface distante (remote interface) possédant
les caractéristiques suivantes:
 Hérite de java.rmi.Remote
 Chaque méthode de l’interface peut lever l’exception:
java.rmi.RemoteException

71
 Fonctionnement de l’invocation
distante dans RMI
 RMI traite un objet distant de manière différente par rapport à
un objet local
– RMI utilise un stub (côté client) pour chaque objet distant:
 Le stub joue le rôle d’un représentant local (ou proxy) pour l’objet distant
 Le client invoque la méthode sur le stub local
 Le stub transporte l’appel de méthode vers l’objet distant
 Le stub d’un objet distant implémente la même interface
distante que l’objet distant
– Permet d’intercepter tous les appels sur ces méthodes
– Seules les méthodes déclarées dans l’interface peuvent être
invoquées à distance

72
 Etapes de création des
applications RMI

 Le développement d’une application RMI

correspond à 4 étapes
– Design et implémentation des composants de
l’application distribuées
– Compilation des sources
– Connexion des classes sur le réseau
– Démarrage de l’application

73
 Design et implémentation
 Définir l’architecture de l’application
– Quels objets sont locaux et lesquels sont distants
– Définir les interfaces distantes pour les objets distants
 Spécifier les méthodes invocables à distance par les clients (types des paramètres et
type de retour)
 Implémentation des objets distants:
– Les objets distants
 Doivent implémenter une ou plusieurs interfaces distantes
 Peuvent implémenter d’autres interfaces et méthodes qui ne peuvent être appelées
que localement
 Implémentation des clients:
– Les clients qui utilisent les objets distants peuvent être implémentés à
n’importe quel moment après la définition des interfaces

74
 Compilation des sources

 Génération des codes exécutables:

– Compiler les codes sources (serveurs , clients,
classes d’implémentation…)
– => javac
 Génération du stub
– Compiler l’interface (deprecated depuis la version
1.5/ supprimée depuis la version 15)
 => rmic
– Génération dynamique (à partir de la version 1.5)
75
 Rendre les objets accessibles

 Enregistrement sur le registre rmi

– Spécification d’une localisation

– Attribution d’un nom

– Méthode bind (rebind) de la classe

java.rmi.Naming

76
 Lancement de l’application

 Exécution:

– Du registre d’objets RMI

– Du Serveur

– Du client

77
Récapitulons…
 Côté serveur:
– Définition de l’interface d’accès distant
– Implémentation de la classe de ou des objets distants
– Implémentation du serveur qui crée l’objet distant et
l’enregistre sur le registre de nommage RMI (RMI registry)
 Côté client: implémentation comprenant
– L’obtention d’une référence sur l’objet distant à travers le
registre de nommage RMI
– La réalisation des appels de méthodes distantes en utilisant
cette référence
DEMO
Un exemple simple:
L’objet Hello

 L’application est constituée des classes

– Hello: implémente l’objet
– HelloInt: l’interface de l’objet distant
– Serveur: la partie serveur de l’application
– Client: la partie client de l’application
L’interface

 Doit hériter de l’interface java.rmi.Remote

 Publie les méthodes accessibles par appels
distants
 Dans un fichier HelloInt.java:
package hello;
import java.rmi.*;
public interface HelloInt extends Remote
{
public void SayIt() throws RemoteException;
}
L’implémentation

 Implémente le code de l’objet distant

 Implémente toutes les méthodes déclarées
dans l’interface
 Hérite de la classe UnicastRemoteObject
 Toutes les méthodes y compris le constructeur
lèvent l’exception RemoteException
La classe Hello.java

package hello;
import java.rmi.*;
import java.rmi.server.*;
public class Hello extends UnicastRemoteObject implements HelloInt {
public Hello() throws RemoteException {
super();
}
public void SayIt()throws RemoteException {
System.out.println("bonjour");
}
}
Le serveur

 Crée l’objet distant

 L’enregistre sur le serveur de nommage RMI
 Dans un fichier Serveur.java
import java.rmi.*;
import java.rmi.registry.*;
import hello.*;
public class Serveur{
public static void main(String[] args) throws Exception {
// création de l’objet
Hello h = new Hello();
Le serveur

 L’enregistrement d’un objet se fait à travers la méthode

bind
 Prend en paramètre:
– L’objet
– Sa localisation: port et nom attribué
 Introduire le reste du code du serveur:
System.out.println("Je vais enregistrer mon objet");
Naming.bind("rmi://localhost:1099/hello",h);
System.out.println("C est fait!");
}}
Le client

 La première étape est d’obtenir une

référence sur l’objet distant:
– Utiliser la méthode statique lookup de la classe
naming
– Retourne le stub en faisant une recherche sur le
nom de l’objet référencé dans le registre de
nommage
– Retourne l’exception NotBoundException si la
recherche échoue
Le code du client
import hello.*;
import java.rmi.*;
public class Client{
public static void main(String[] args)
{
try {
Remote remote_h = Naming.lookup("rmi://localhost:1099/hello");
if (remote_h instanceof HelloInt)
{
((HelloInt) remote_h).SayIt();
}
}
catch (Exception e) {
}
}}
Structuration de l’application
 Côté Serveur:
– Code de l’interface, de la classe d’implémentation
– Code du serveur
 Compilation + génération du stub
– javac *.java
– rmic hello.Hello (en option)
 Côté Client
– Code de l’interface, du stub
– Code du client
 Compilation du code du client
Exécution

 Dans le répertoire MON_PREMIER_RMI

– Lancement du registre de nommage
 java sun.rmi.registry.RegistryImpl 1099
– Lancement du serveur
 java Serveur
 Lancement du client
– java Client
 La communication

 Implantation de la communication entre les

composants:
– Client  Servant
 e.g. Transférer un identifiant du client vers le Servant
– Servant  Client
 e.g. renvoyer le nbre des invocations
– Serveur  Servant
 e.g. communiquer un identifiant du Serveur
– Serveur  Client
 e.g. renvoyer l’identifiant du serveur vers le client

90
 Des architectures plus complexes

Client C1
Serveur S
Client C2

Serveur S1
Client C
Serveur S2

Client C Serveur S1 Serveur S2

91