Vous êtes sur la page 1sur 108

DÉPARTEMENT SI

AM DERY
Invocation de Méthode à distance
Exemple : Java
Remote Method Invocation
À travailler seuls
Concepts généraux
Mise en œuvre Java
Merci à Rémi Vankeisbelck, Michel Riveill etc
Client Serveur
2
Invocation de méthodes distantes
3
 Mécanisme qui permet à des objets localisés sur des
machines distantes de s’échanger des messages
(invoquer des méthodes)
RMI
4
 Core API (intégré au JDK 1.1)
 Gratuit
 100 % Java
 Développé par JavaSoft
 Réservé aux objets Java
 Utilise les sockets et le protocole JRMP
Invocation de méthodes distantes
5
Stubs et encodage des paramètres
6
 le code d’un objet client invoque une méthode sur un
objet distant
 Utilisation d’un objet substitut dans la JVM du client : le stub
(souche) de l ’objet serveur
Stubs et encodage des paramètres
7
Du côté du client
8
 Appel d’une méthode du stub (de façon entièrement
transparente)
 le stub construit un bloc de données avec
 identificateur de l’objet distant à utiliser
 description de la méthode à appeler
 paramètres encodés qui doivent être passés
 puis il envoie ce bloc de données au serveur...
Du côté du serveur
9
 un objet de réception (Squeleton) effectue les
actions suivantes :
 décode les paramètres encodés
 situe l ’objet à appeler
 invoque la méthode spécifiée
 capture et encode la valeur de retour ou l ’exception
renvoyée par l ’appel
Encodage des paramètres
10
 Encodage dans un bloc d ’octets afin d ’avoir une
représentation indépendante de la machine
 Types primitifs et «basiques» (int/Integer...)
 Encodés en respectant des règles établies
 Big Endian pour les entiers...
 Objets ...
Générateur de stubs
11
 Les stubs gèrent la communication ainsi que
l'encodage des paramètres
 Processus évidemment complexe...
 Entièrement automatique
 Un outil permet de générer les stubs pour les OD
Stubs et rmic
12
 La commande rmic du jdk rend transparent la
gestion du réseau pour le programmeur
 une référence sur un ODréférence son stub local
 syntaxe = un appel local
 objetDistant.methode()
Un exemple : le sempiternel « Hello World » !!!
13
Interfaces et classes prédéfinies
14
Interface = protocole d ’application
15
 L ’interface HelloWorld
import java.rmi.*;
interface HelloWorld extends Remote {
public String sayHello()
throws RemoteException;
}
Rôle de l ’interface
16
HelloWorld
HelloWorld
Les exceptions
17
 L’exception RemoteException doit être déclarée
par toutes les méthodes distantes
 Appels de méthodes distants moins fiables que les appels
locaux
 Serveur ou connexion peut être indisponible
 Panne de réseau
 ...
Du côté client
18
HelloWorld hello = ...;
// Nous verrons par la suite comment obtenir
// une première référence sur un stub
String result = hello.sayHello();
System.out.println(result);
Du côté Serveur
19
 Implémentation de la classe qui gère les méthodes de
l’interface HelloWorld
// Classe d'implémentation du Serveur
public class HelloWorldImpl
extends UnicastRemoteObject
implements HelloWorld {
public String sayHello() throws RemoteException {
String result = « hello world !!! »;
System.out.println(« Méthode sayHello invoquée... » +
result);
return result;
}
}
Classe d’implémentation
20
 doit implanter l’interface HelloWorld
 doit étendre la classe RemoteServer du paquetage
java.rmi
 RemoteServer est une classe abstraite
 UnicastRemoteObject est une classe concrète qui
gére la communication et les stubs
Classe d’implémentation
21
HelloWorld
HelloWorld
HelloWorldImpl
L’outil RMIC
22
 outil livré avec le JDK permet de générer les stubs
> rmic -v1.2 HelloWorldImpl
génère un fichier HelloWorldImpl_stub.class
rmic doit être passé pour toutes les classes
d'implémentation des OD afin d'en générer les stubs
 Depuis la v3, les stubs sont générés dans un package sous
le répertoire de travail
 Deux nouvelles options :
"-idl" and "-iiop" pour générer des IDL and des stubs pour
IIOP.
Fichiers générés
Un squelette(skeleton) pour un objet serveur au dessus du
protocole JRMP qui contient une méthode qui répartit les
appels aux implémentations des objets distants
Un talon (tie) pour un objet serveur similaire au squelette, qui
communique avec le client en utilisant le protocole IIOP.
Un stub ou proxy pour l’objet distant responsable pour faire des
appels aux méthodes sur les objets du sserveur.
Le protocole JRMP est utilisé dans la génération par défault. U
Référence sur un objet
24
 On sait implanter un serveur d ’un côté, et appeler
ses méthodes de l ’autre
MAIS
 Comment obtient-on une référence vers un stub de
notre objet serveur ???
Localisation des objets de serveur
25
 On pourrait appeler une méthode sur un autre objet serveur
qui renvoie une référence sur le stub...
 Mais quoi qu ’il en soit, le premier objet doit lui aussi être
localisé (La poule et l ’œuf) !!!
 On a alors recours a un Service de Nommage
Les Services de Nommage
26
 Obtention d'une première référence sur un objet
distant : « bootstrap » à l’aide d’un Service de
Nommage ou Annuaire
 Enregistrement des références d'objets dans
l'annuaire afin que des programmes distants
puissent les récupérer
Exemple : Le RMIRegistry
27
 Implémentation d'un service de nommage
 Fourni en standard avec RMI
 Permet d'enregistrer des références sur des objets de serveur
afin que des clients les récupèrent
 On associe la référence de l'objet à une clé unique (chaîne de
caractères)
 Le client effectue une recherche par la clé, et le service de
nommage lui renvoie la référence distante (le stub) de l'objet
enregistré pour cette clé
Le RMIRegistry
28
 Programme exécutable fourni pour toutes les plates formes
 S'exécute sur un port (1099 par défaut) sur la machine
serveur
 Pour des raisons de sécurité, seuls les objets résidant sur la
même machine sont autorisés à lier/délier des références
 Un service de nommage est lui-même localisé à l'aide d'une
URL
La classe Naming
29
 du package java.rmi
 permet de manipuler le RMIRegistry
 supporte des méthodes statiques permettant de
 Lier des références d'objets serveur
 Naming.bind(...) et Naming.rebind(...)
 Délier des références d'objets serveur
 Naming.unbind(...)
 Lister le contenu du Naming
 Naming.list(...)
 Obtenir une référence vers un objet distant
 Naming.lookup(...)
Enregistrement d’une référence
30
 L’objet serveur HelloWorld (coté serveur bien
entendu…)
 On a créé l'objet serveur et on a une variable qui le
référence
HelloWorld hello = new HelloWorldImpl();
 On va enregistrer l'objet dans le RMIRegistry
Naming.rebind("HelloWorld",hello);
 L'objet est désormais accessible par les clients
Obtention d'une référence coté client
31
 sur l'objet serveur HelloWorld
 On déclare une variable de type HelloWorld et on
effectue une recherche dans l'annuaire
HelloWorld hello =
(HelloWorld)Naming.lookup("rmi://www.helloworldserver
.com/HelloWorld");
 On indique quelle est l'adresse de la machine sur
laquelle s'exécute le RMIRegistry ainsi que la clé
 La valeur retournée doit être transtypée (castée) vers
son type réel
Remarque
32
 Le Service de Nommage n'a pas pour fonction le
référencement de tous les objets de serveur
 Il devient vite complexe de gérer l'unicité des clés
 La règle de bonne utilisation du Naming est de lier des
objets qui font office de point d'entrée, et qui
permettent de manipuler les autres objets serveurs
Une autre utilisation du rmiRegistry
33
 import java.rmi.registry.LocateRegistry;
 import java.rmi.registry.Registry;
Client
 Registry registry;
registry = LocateRegistry.getRegistry();
Hello hello = (Hello) registry.lookup("coucou");
Serveur
LocateRegistry.createRegistry(port); // port=1099
Hello stub = (Hello) UnicastRemoteObject.exportObject(unHello, 0);
Naming.rebind("rmi://"+"localhost"+":"+ port +"/coucou", stub);
JNDI
 Les applications JNDI applications
peuvent accéder aux objets enregistrés dans
l’annuaire RMI
RMI peut utiliser d’autres serveurs de noms via JNDI
LDAP ou le serveur de noms Corba par exemple
Conception, implémentation et exécution de
l'exemple
35
 Rappel
 On veut invoquer la méthode sayHello() d'un objet de
serveur distant de type HelloWorld depuis un
programme Java client
 Nous allons devoir coder
 L'objet distant
 Le serveur
 Le client
 Et définir les permissions de sécurité et autres
emplacements de classes...
Processus de développement
36
 1) définir une interface Java pour un OD
 2) créer et compiler une classe implémentant cette interface
 3) créer et compiler une application serveur RMI
 4) créer les classes Stub (rmic)
 5) démarrer rmiregistry et lancer l’application serveur RMI
 6) créer, compiler et lancer un programme client accédant à des
OD du serveur
Hello World : L'objet distant
37
 Une interface et une classe d'implémentation
 stubs générés automatiquement par rmic
 toutes les classes nécessaires à l’objet de client doivent
être déployées sur la machine cliente et accessibles au
chargeur de classes (dans le CLASSPATH)
 L'interface HelloWorld (HelloWorld.class)
 Le stub HelloWorldImpl_stub généré par rmic pour cet objet
Hello World : Le serveur
38
 instancie un objet de type HelloWorld et attache au service de
nommage
 puis objet mis en attente des invocations jusqu'à ce que le serveur soit
arrêté
import java.rmi.*;
import java.rmi.server.*;
public class HelloWorldServer {
public static void main(String[] args) {
try {
System.out.println("Création de l'objet serveur...");
HelloWorld hello = new HelloWorldImpl();
System.out.println("Référencement dans le RMIRegistry...");
Naming.rebind("HelloWorld",hello);
System.out.println("Attente d'invocations - CTRL-C pour
stopper");
} catch(Exception e) {
e.printStackTrace();
}
}
}
Serveur (suite)
39
 Apres avoir compilé le tout...
 Pour démarrer le serveur, il faut tout d'abord lancer le
RMIRegistry
 Attention : La base de registres RMI doit connaître les interfaces et les
stubs des objets qu'elle enregistre (CLASSPATH) !!!
> rmiregistry &
 et ensuite on lance le serveur
> java HelloWorldServer
Création de l'objet serveur...
Référencement dans le RMIRegistry...
Attente d'invocations - CTRL-C pour stopper
Hello World : client
40
 obtenir une référence sur l'objet de serveur HelloWorld,
invoquer la méthode sayHello(), puis afficher le résultat de
l'invocation sur la sortie standard
import java.rmi.*;
public class HelloWorldClient {
public static void main(String[] args) {
try {
System.out.println("Recherche de l'objet serveur...");
HelloWorld hello =
(HelloWorld)Naming.lookup("rmi://server/HelloWorld");
System.out.println("Invocation de la méthode sayHello...");
String result = hello.sayHello();
System.out.println("Affichage du résultat :");
System.out.println(result);
System.exit(0);
} catch(Exception e) {
e.printStackTrace();
}
}
}
Le client (suite)
41
 Il suffit ensuite de lancer le programme
> java HelloWorldClient
Recherche de l'objet serveur...
Invocation de la méthode sayHello...
Affichage du résultat :
hello world !!!
 Au niveau du serveur, le message...
Méthode sayHello invoquée... hello world !!!
 ...s'affichera dans la console
Passage de paramètres
42
 On sera souvent amenés a passer des paramètres
aux méthodes distantes...
 Les méthodes distantes peuvent retourner une
valeur ou lever une exception...
 On a deux types de paramètres
 Les objets locaux
 Les objets distants
Passage de paramètres: ATTENTION
43
 Certains objets sont copiés (les objets locaux), d'autres non (les
objets distants)
 Les objets distants, non copiés, résident sur le serveur
 Les objets locaux passés en paramètre doivent être sérialisables afin
d'être copiés, et ils doivent être indépendants de la plate-forme
 Les objets qui ne sont pas sérialisables lèveront des exceptions
 Attention aux objets sérialisables qui utilisent des ressources locales
!!!
Que doit connaître le client ?
44
 Lorsqu’un objet serveur est passé à un programme,
soit comme paramètre soit comme valeur de
retour, ce programme doit être capable de
travailler avec le stub associé
 Le programme client doit connaître la classe du
stub
Que doit connaître le client ?
45
 les classes des paramètres, des valeurs de retour et
des exceptions doivent aussi être connues...
 Une méthode distante est déclarée avec un type de valeur de
retour...
 ...mais il se peut que l ’objet réellement renvoyé soit une
sous-classe du type déclaré
Que doit connaître le client ?
46
 Le client doit disposer des classes de stub, classes
des objets retournés…
 copier les classes sur le système de fichiers local du client
(CLASSPATH)...
 ...cependant, si le serveur est mis à jour et que de nouvelles
classes apparaissent, il devient vite pénible de mettre à jour le
client
 C ’est pourquoi les clients RMI peuvent charger
automatiquement des classes de stub depuis un autre
emplacement
 Il s ’agit du même type de mécanisme pour les applets qui
fonctionnent dans un navigateur
Chargement dynamique des classes
47
 Problème de sécurité
 Le programme client télécharge du code sur le réseau
 Ce code pourrait contenir des virus ou effectuer des opérations
non attendues !!!
 Utilisation d ’un gestionnaire de sécurité pour les applications
de clients RMI
 Possibilité de créer des gestionnaires de sécurité personnalisés
pour des applications spécifiques
 RMI fournit des gestionnaires de sécurité suffisants pour un
usage classique
Chargement dynamique
48
 Pour ne plus déployer les classes du serveur chez
le client
 Utilisation des chargeurs de classes qui téléchargent des classes
depuis une URL
 Utilisation d ’un serveur Web qui fournit les classes
 Ce que ça change
 Bien entendu, les classes et interfaces de l ’ objet distant ne changent
pas
 Le code du serveur ne change pas
 le client et la façon de le démarrer sont modifiés
 Et lancer un serveur Web pour nos classes
Hello World : chargement dynamique
49
 Séparation des classes
 Serveur (fichiers nécessaires a l'exécution du serveur)
 HelloWorldServer.class
 HelloWorldImpl.class
 HelloWorld.class
 HelloWorldImpl_Stub.class
 Download (fichiers de classes à charger dans le
programme client)
 HelloWorldImpl_Stub.class
 Client (fichiers nécessaires au démarrage du client)
 HelloWorld.class
 HelloWorldClient.class
Hello World : Démarrage du serveur Web
50
 Mettre les classes Download dans le répertoire des
documents Web du serveur Web, accessibles via une
URL
 le chargeur de classes ira chercher les classes à un emplacement
de type http://www.class-server.com/classes/HelloWorldImpl_Stub.class
};
Hello World : Politiques de sécurité
51
 Le programme Java client doit pouvoir se connecter aux ports de
la base de registres RMI et des implémentations des objets de
serveur, ainsi qu'au port du serveur Web
 Fichier client.policy
grant {
permission java.net.SocketPermission
"*:1024-65535", "connect,resolve";
permission java.net.SocketPermission
"*:80", "connect";
};
Hello World : gestionnaire de sécurité RMI
52
 Le client intègre un gestionnaire de sécurité RMI pour les
stubs téléchargés dynamiquement
import java.rmi.*;
import java.rmi.server.*;
public class HelloWorldClient {
public static void main(String[] args) {
try {
// Installe un gestionnaire de sécurité RMI
System.setSecurityManager(new RMISecurityManager());
System.out.println("Recherche de l'objet serveur...");
HelloWorld hello =
(HelloWorld)Naming.lookup("rmi://server/HelloWorld");
System.out.println("Invocation de la méthode sayHello...");
String result = hello.sayHello();
System.out.println("Affichage du résultat :");
System.out.println(result);
} catch(Exception e) {
e.printStackTrace();
}
}
}
Hello World : Démarrage coté serveur
53
 1) Lancer la base de registres RMI (elle doit pouvoir accéder aux
classes Download - CLASSPATH)
> rmiregistry
 2) Lancer le serveur Web servant les fichiers de classes Download
 3) Lancer le serveur (les classes Server doivent être accessibles)
> java HelloWorldServer
Création de l'objet serveur...
Référencement dans le RMIRegistry...
Attente d'invocations - CTRL-C pour stopper
Hello World : Démarrage coté client
54
 Le client doit pouvoir se connecter à des machines distantes pour
la base de registres RMI, les objets de serveur ainsi que le serveur
Web
 On doit lui fournir un fichier client.policy
 Le client doit bien connaître l'emplacement des classes afin de
pouvoir les télécharger
 On va le lui préciser lors du lancement
> java -Djava.security.policy=client.policy
-Djava.rmi.server.codebase=http://www.class-server.com:80/
HelloWorldClient
Erreurs classiques
Stub inaccessible au rmiregistry
 java.rmi.ServerException: RemoteException
occurred in server ...
java.rmi.UnmarshalException: error
unmarshalling ...
java.lang.ClassNotFoundException:
Le stub est accessible au serveur MAIS PAS AU rmiregistry
Attention à l’ordre d’appel : génération des stubs et appel du rmiregistry
rmiregistry pas lancé
 java.net.ConnectException
Oubli du constructeur pour le RemoteObject
unreported exception java.rmi.RemoteException in default constructorpublic class HelloImpl extends
UnicastRemoteObject implements Hello { ^
rmiregistry déjà lancé
java.rmi.server.ExportException: Port already in use: 1099On peut lancer un autre registry mais sur
un autre port.
Erreurs classiques
 La classe d’implémentation n'hérite pas de
UnicastRemoteObject
S'il n'hérite pas de UnicastRemoteObject, il n'est pas Remote
donc on lui demande d'être Serializable ...
Trouble: java.rmi.MarshalException: error marshalling
arguments; nested exception
is: java.io.NotSerializableException: CalculatorImpl
ATTENTION aux CLASSPATH et package Java
Conclusion
57
 On a vu ce qu'est une invocation de méthode
distante
 On a vu le mécanisme des stubs, ainsi que
l'encodage des paramètres
 On a vu le déploiement avec téléchargement des
classes dynamiquement
 Nous avons même appliqué ces concepts au
travers de l'exemple "HelloWorld » en RMI
CHRONI QUE D’ UNE I NVASI ON ANNONCÉE
POURQUOI ? COMMENT?
QUI : CORBA / COM- DCOM / JAVA RMI …
Protocoles d’application et
Langages de spécifications
 Spécifications des types de données qui transitent sur le réseau
XDR et RPC de SUN
Protocole := CHOICE {
requete [0] REQUETE,
reponse [1] REPONSE }
Programme reqrep {
version {
REPONSE rerep(REQUETE) = 1
}= 1
} = 10000
ASN.1 et norme ISO
Exemple : annuaire des surnoms
XDR et
RPC
Protocole := CHOICE {
enregistrerReq [0] SEQUENCE{PrintableString nom,
PrintableString surnom}
enregistrerRep[1] BOOLEAN,
listerReq [2] NULL,
listerRep [3] SET OF Personnes, ….}
Programme surnoms {
version {
boolean enregistrer(nomSurnom) = 1;
listePersonnes lister(void)=2
}= 1
} = 10000
ASN.1 et
norme
ISO
Générateurs de Stubs
RPCGEN / MAVROS
ASN1
XDR
Librairie marshalling
et unmarshalling
squelettes du client et
du serveur
Spécifications
des données
Générateurs
Types de
données
C Lisp
Java
Types de
données
C
Fichiers
générés
Implémentation des objets distribués
 Corba indépendant des
langages de
programmation
 Projections C,C++,
Java
 Un langage de
Spécification IDL
Orienté C++
Tout Java
CORBA, DCOMet JAVA
 une interface = une
unité élémentaire
 héritage des interfaces
 aucune interface
imposée
 normalisation des
interface
 au moins une interface :
Iunknown
 non transmissible par
héritage
 composition d’interfaces
• héritage de classe
• implémentation de plusieurs interfaces possibles
Générateurs
RMIC / Orbix...
IDL
Int. Java
Spécifications
des données
Générateurs
Fichiers
générés
Stubs Skeletons Proxy
(mise en œuvre de la sérialisation
et désérialisation…)
CORBA
module Surnoms {
typedef string Nom ;
struct Personne {Nom nom;
string surnom;};
typedef sequence<Personne> ListePersonnes;
interface Surnoms{
exception ExisteDeja{string surnom;};
boolean enregistrer(in Personne personne) raises
(ExisteDeja);
…..
};
};
Surnoms.java
Compilation interface IDL
Client
StubForSurnoms.java
_SurnomsImplBase.java
Serveur
SurnomsImpl.java
Client.java
Serveur.java
A écrire
Généré
1- Exemple
introductif
Surnoms.idl
Compilateur IDL/Java
Répertoire grid
Répertoire grid
Répertoire grid
Répertoire Surnoms
SurnomsHelper.java
SurnomsHolder.java
jidl Surnoms.idl
RMI
public interface Surnoms extends java.rmi.Remote
{
public Boolean enregistrer(String nom, String surnom) throws
java.rmi.RemoteException,
ServeurSurnoms.surnoms.ExisteDeja ;
….
}
RMI
Classes et Interfaces
ClasseLocale
Souche Squelette
ClasseDistante
InterfaceDistante
Remote
Appel méthode m()
Appel méthode
m()
Machine locale Machine distante
InterfaceDistante
Invocation dynamique
 Permet au programme client de
 découvrir les objets à l’exécution et les interfaces
proposés par ces objets
 construire dynamiquement messages et requêtes
 envoyer et recevoir le résultat de telles requêtes
 Rend les systèmes réactifs et faciles à modifier
OFFERT PAR CORBA, DCOM et JAVA
L’invocation dynamique
 API (DII) de construction de requêtes
 sans passer par des souches prégénérées
 Un objet Request = un nom d’opération, une liste
de couples valeur - type (au sens de l’IR) et une
structure pour le résultat
 invoke
 send_deferred + get_response, poll_response
 send_oneway
Un peu plus sur l’infrastructure
 transport des messages
 localisation des serveurs et des objets
 persistance
ORB pour CORBA
norme Corba 1
DCOM pour OLE
non formelle
JDK
Transport des messages
 Références aux objets
 identifiant (libre choix d ’implémentation dans le norme
CORBA)
 nombres codés sur 128 bits en OLE
 url Uniform Resource Locator en Java RMI
Performances différentes et
incompatibilités entre ORBs
et entre ORB et COM
Scénario d ’obtention de la référence du
service de nommage
Client ou Serveur
ORB
CosNaming::
NamingContext
resolve_initial_references ("NameService");
conversion
ajout,retrait,lecture,...
Enregistrer un objet
• Opération pour publier un Objet
– en général, opération réalisée par le serveur
• Scénario Type
1. Créer un objet
2. Construire un chemin d ’accès (Name)
3. Appeler l ’opération « bind » ou « rebind » avec le chemin et la référence de
l ’objet
void bind (in Name n, in Object obj)
raises (NotFound, CannotProceed, InvalidName, AlreadyBound);
Retrouver un objet
 Opération réalisée par un client ou un serveur
 Scénario type :
 construire un chemin d ’accès (Name)
 appeler l ’opération « resolve » avec le chemin
 convertir la référence obtenue dans le bon type
Object resolve (in Name n)
raises (NotFound, CannotProceed, InvalidName)
Interaction Client Enregistreur
client
serveur
client registre
Lookup : où est objetDistant ?
stub
Il est ici
Envoyez le stub
Le voici
stub squelette
objet
Distant
result = objetDistant.m()
result
RMIRegistry + ClassLoader
Interface avec l’infrastructure
Un peu de vocabulaire
 Coté client :
 stub en CORBA
 proxy en OLE
 stub/proxy en Java
 Côté Serveur :
 stub en OLE
 skeleton en CORBA
 implémentation d’une interface en RMI
 BOA Objects Adaptaters
Mécanisme de Transport :
Client - Serveur
 Appel direct : DLL (in process - utilisation du même
espace mémoire)
 Appel indirect :
 LRPC (application sur la même machine) passe par le proxy
 RPC (sur 2 machines différentes)
 IIOP en Corba
Invocations
 Invocations statiques
 IDL en CORBA stub + skeleton
 En OLE
 appel direct si in process
 proxy + stub si application fournis uniquement pour les
applications MicroSoft
 Versions récentes définition du langage ODL
 IDL et ODL sont incompatibles
Invocations
 Invocations dynamiques
 DII en CORBA
 IDispatch en OLE
 java reflect
 Du ressort de l’infrastructure
CORBA vs OLE
 définition du serveur
très générale laissée à
l’implémentation
 flexibilité primordiale
pour l’intégration de
systèmes (BDD…)
 processus formel avec
l’OMG
• un serveur est une
application ou une
DLL
• stratégie commerciale
et pratique
Services et Objets Distribués
 Services normalisés
 Seulement certains
sont implémentés
 Naming, Trading,
Event
 Le programmeur doit
les connecter…
Des services en
Programmant avec Java
Securité,Threads,
Événements
Url et Web
Non intégrés à RMI
Les points communs des middlewares en
objets distribués (aspect réseau)
Adressage :
à tout objet doit être affecté une référence unique
Transport :
pour établir une communication entre 2 nœuds
et transmettre une requête
Marshalling :
transformation de la requête pour passer sur le
réseau
Les points communs des middlewares en
objets distribués
Activation :
activer les implémentations des objets
Dispatching :
gestion des threads
Protocol :
transmission des requêtes entre exécutables
Des services communs
Services de nommage, Interface repository.....
Les points communs des middlewares en
objets distribués (aspect objet)
Encapsulation :
Interdire l'accès direct au contenu de l'objet
Interface :
Permettre l'évolution du code
Héritage / Composition :
Gérer les versions
Envoi de messages
Privilégier les communications synchrones
Des objets distribués aux
composants
CHRONI QUE D’ UNE I NVASI ON ANNONCÉE
POURQUOI ? COMMENT?
QUI : / CORBA3 CCM/ WEB SERVI CES
( . NET, J2EE) / EJBS …
Quels Composants ?
Une vision « simplifiée » : les Web Services
Des composants « normalisés » : CCM
Des composants pratiques : EJB
Et tout ce que l'avenir nous réserve : OpenCCM,
Fractal ….
 Une « unité logique applicative »
 Une «librairie» fournissant des données et des
services à d’autres applications.
 Un objet métier déployé sur le web (vision objet)
 Un « module » ou « composant » (Application
avec JAX-RPC : un composant simple avec une
interface RMI )
 Une sorte d'objet… plutôt qu'un composant
Un Service Web, c’est quoi ?
Architecture globale
Un langage de description : WSDL
Une infrastructure : Le Web et http
Une communication par envoi de messages : SOAP
Du marshalling : XML
Un service de nommage « dynamique » : UDDI
Points communs avec les middlewares objets
Annuaire
UDDI
Client
XML
5 : J’ai compris comment invoquer
ton service et je t’envoie un document
XML représentant ma requête
Serveur
2 : J’ai trouvé! Voici le serveur
hébergeant ce service web
3 : Quel est le format d’appel du
service que tu proposes?
Contrat
SOAP
4 : Voici mon contrat (WSDL)
XML
XML
6 : J’ai exécuté ta requête et je te retourne le résultat
1

:

J
e

r
e
c
h
e
r
c
h
e
u
n

s
e
r
v
i
c
e

W
E
B

Cycle de vie d’utilisation
Cycle de vie plus complet…
 Déploiement du service Web
 Enregistrement du service Web
 Découverte du service Web
 Invocation du service Web par le client
Pour être de vrais composants…
- Description des interfaces requises
- Langage pour gérer le flux d’exécution :
WSFL
- des services spécifiques
- sécurité (SAML, …)
- transactions (BTP, …)
- une découverte des services web (W3C)
Des environnements intégrés .net
 Toute la mécanique est cachée
 On peut se concentrer sur la conception
 Aide à l'assemblage ?
 Des adeptes et des sceptiques
 Passage à l'échelle ?
 Evolution ?
 Interopérabilité ?
 Une brique permettant la programmation par
assemblage
 Une solution facilitant le déploiement, la gestion du
cycle de vie des applications logicielles
 Une meilleure intégration des services
 plus qu'un objet
Un composant, c’est quoi ?
Exemple des différents éléments
E
Exemple de modèle de composant
30
Modèle abstrait de composant CORBA
I
m
p
l
é
m
e
n
t
a
t
i
o
n

d
e

f
a
c
e
t
t
e
Consommateur
Payer,
sélectionner,
prendre
Ouvrir,
remplir,
mettre Monnaie…
Fournisseur
Ouvrir capot,
fermer,
Réparateur
F
a
c
e
t
t
e
s
réceptacle
Prise de courant
Prise d’eau
*
Plus de monnaie
vide
*
Température
Source d’évènements
Puit d’évènements
On/Off
Attributs
III. Composants :
3. CORBA C.
EJB – CORBA 3:
Points communs avec les middlewares objets
Langages de description : CIDL ou Interfaces Java
Infrastructure : RMI / ORB
Marshalling : repose sur Corba / RMI
Nommage : Home ++
Interface : Héritage + Composition
EJB – CORBA 3: Apports
Interfaces entrées et sorties : ports requis et offerts
Conteneur : intégration des propriétés non
Fonctionnelles (sécurité, persistance, transaction)
Home : fabrique et navigation
Communication par envoi de message et notification
(événement)
Un vrai cycle de vie
 Fichier de déploiement
 Packaging d'assemblage
Approche déclarative basée sur XML
Prochaine invasion dans la lignée ?
Approche composant revisitée :
Open CCM : une meilleure solution CCM + MDA
(+ d'abstraction des infrastructures, projections vers
des middlewares connus…)
Des Composants à conteneurs ouverts
(travaux de recherche)
Des composants adaptables (fractal)
Les problèmes à résoudre encore
 Problèmes d’interopérabilité
 RMI et Corba en Java
 entre le monde Microsoft et le reste
 Arrivée des Web Services : la solution ?
 Les composants encore nouveaux….
 les Enterprise Java Beans
 Corba Components
 et aussi C# et net
Les plus grosses difficultés
 Sont conceptuelles
 Comment choisir les composants adaptés ?
(manque de sémantique, Web sémantique)
 Comment accepter plus de services ? (propriétés
non fonctionnelles)
Etre plus architecte que programmeur ….
Quelques interrogations ?
Comment choisir le bon middleware (intergiciel) ?
Il y en a de plus en plus
Corba, RMI, DCOM, DSA + CCM, J2EE
+ Web Services, .net ....
Savoir les comparer
Identifier les points communs
Interopérabilité : XML une solution suffisante ?
Des Critères de Comparaisons
Autour du concept objet ?
Communication synchrone ou asynchrone ?
Description via des interfaces ou des messages ?
Communication directe ou indirecte ?
Spécifique ou indépendant langage ?
Possibilité de transformation de messages ou non ?
Protocole de communication binaire ou textuelle ?
Prise en compte de QoS ou non ?
(transaction, sécurité ....)
Comment faire interopérer les middlewares ?
Aller vers un middleware standard ?
(J2EE / Corba)
Construire une couche au dessus des middlewares ?
des familles de middlewares, des middlewares
génériques (Jonathan, PolyOrb, ...)
Avoir une approche architecturale ?
des design patterns
Faire interopérer des middlewares existants?
M2M
L’avenir ?
Après les approches par composants,
des middlewares au dessus de JMS
Une réflexion de plus haut niveau pour
sortir les schémas communs
extérioriser quand et comment on les utilise
ne pas confondre les problèmes avec XML
Format URL
 rmi://[host][:port][/[object]]
 rmi:[/][object]
 If the object name is absent, then the URL names
the registry at the given host and port. Otherwise, it
names the remote object registered at that registry
under the name provided. If the host is omitted, the
local host is assumed. If the port is omitted, the
default registry port 1099 is assumed.