Objets Distribués

Objets Distribués
Chronique d ’une invasion annoncée
Pourquoi ? Comment?
Qui : Corba / COM-DCOM / Java RMI...
Pourquoi ?
• Maturation de la technologie orientée objet
– ADA, Modula
– Smalltalk , C++, Java
• Maturation des communications ClientServeur
– sockets
– RPC
– couches OSI
Maturation de la technologie
orientée objet
Compte AM
Crediter
debiter
Compte AM
Crediter
1000
Interaction entre objets : message
montant
Objet = module logiciel
Objets + Messages
Application = Collection d ’objets interagissant
• Modules logiciels
• indépendance de la
programmation et de
la construction
• unité autonome
• Méthode =
comportement des
objets
• Messages = interaction
entre objets de
l ’application
Classes et héritage
Compte de particulier
Crediter
Debiter
Compte Codevi
Deposer
compte PEL
Débiter
Mécanisme d ’abstraction + Généralisation
Surcharge des méthodes par héritage
Classe et Composition
VEHICULE
CARROSSERIE
MOTEUR
Architectures à base d ’objets
C++
Smalltalk
Java
Base de données
Objets
Classes
Messages
IHM
Modèles et méthodologies
de développement
Application traditionnelle vs
application objets
• Réponse ponctuelle à
une tâche ou à une
opération particulière
• déroulement linéaire
des étapes
• adaptation aux
changements difficile
• Représentation des
entités physiques des
processus réels
• entités réutilisables
• lisibilité
• processus
d ’assemblage
d ’objets existants
Objets = briques logicielles
• Assembler des briques élémentaires
• Réduire la complexité des systèmes
d ’information
Séparation entre interface et implémentation
Représentation et types de données
Mécanismes d ’abstraction
Séparation entre interface et
implémentation
• Séparation de la définition et de
l ’implémentation : encapsulation
• interface : partie visible de l ’objet
• implémentation : partie privée inaccessible
depuis d ’autres objets
• interface = contrat entre l ’objet et le monde
extérieur
Séparation entre interface et
implémentation
• Assemblage des objets dépend uniquement
des interfaces, le changement local d ’un
objet ne perturbe pas l ’ensemble de
l ’application.
Importance de la nomenclature des objets
substitution logique liée à la substitution physique
Représentation et
Types de données
• Définition de nouveaux types
• Choix d ’un type pour une donnée (ex.
montant) devient une contrainte sur la
conception.
Types de données Abstraits
considérés comme des types de base
Mécanismes d ’abstraction
• Abstraction des données : essence du
procédé de construction de systèmes
d ’information à base d ’objets distribués
• par Classe et/ou Composition
Des mises en œuvre différentes selon les cas
Maturation des communications
Client Serveur
• Des programmes (fonctionnant sur des
machines différentes) qui communiquent au
travers du réseau.
• Un programme Client envoie des requêtes à
un programme serveur (qui prend en charge
l ’implémentation)
Infrastructure Client Serveur
CLIENT
SERVEUR
requêtes
Appel de Procédure à Distance
CLIENT
Connexion au serveur
Préparation de la requête
envoi de la requête
attente du résultat
….
Analyse du résultat reçu
SERVEUR
Attente de requêtes
Analyse de la requête
…..
Exécution
….
Préparation de la réponse
envoi de la réponse
Appel de Procédure à Distance
CLIENT
F(1, x)
SERVEUR
F(1,x)
unmarshalling
marshalling
10
unmarshalling
marshalling
Langages de spécifications
• Spécifications des types de données qui
transitent sur le réseau
Protocole := CHOICE {
requete [0] REQUETE,
reponse [1] REPONSE }
ASN.1 et norme ISO
• XDR et RPC de SUN
Programme reqrep {
version {
REPONSE rerep(REQUETE) = 1
}= 1
} = 10000
Générateurs de Stubs
Spécifications
des données
XDR
ASN1
Générateurs
RPCGEN / MAVROS
Fichiers Types de
générés données
C Lisp
Java
Librairie marshalling
et unmarshalling
squelettes du client et
du serveur
Types de
données
C
Circulation de messages et
machines hétérogènes
Infrastructure informatique de distribution
• Couche de services
• Couche de transport
• Objets de
l ’application qui
résultent de la
conception du modèle
• Responsable de
l ’administration des
objets et de
l ’acheminement des
messages
Introduction de services
• Gestionnaires de noms (x500, nis, dns…)
• Synchronisation (Transaction …)
• Sécurité
Objets distribués
• Un programme (objet) peut être à la fois
client de certains serveurs et serveur
d ’autres clients
• Il peut y avoir reconfiguration dynamique
des rôles Client Serveur
Infrastructure Objets Distribués
Objet2
Objet3
Objet1
Client
Client Serveur
Serveur
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, DCOM et JAVA
• Une interface = une
unité élémentaire
• héritage des interfaces
• aucune interface
imposée
• normalisation des
interface
• héritage
• Au moins une interface :
Iunknown
• non transmissible par
héritage
• composition d ’interfaces
de classe
• implémentation de plusieurs interfaces possibles
Générateurs
Spécifications
des données
Int. Java
IDL
Générateurs
RMIC / Orbix...
Fichiers
générés
Stubs Skeletons Proxy
(mise en œuvre de la sérialisation
et désérialisation…)
Comment activer des objets
distribués ?
• Messages échangés entre objets =
– Requêtes ou Résultats
• Certains envois de messages n ’attendent
pas de résultats
• Requête = Destinataire + nom de méthode +
Paramètres
• Résultat = Donnée ou indication d ’une
erreur ou d ’une défaillance
Comment activer des objets
distribués ?
• Mécanisme d ’exécution ou de transport
– définit comment les messages sont véhiculés de
l ’objet client vers l ’objet serveur (destinataire)
– retrouver et activer les objets adéquats
• Un objet client a deux manières d ’envoyer
des messages
– invocation statique
– invocation dynamique
Invocation statique
• Le nom de l ’objet destinataire et le
message sont connus au moment du
développement
• Ne permet ni l ’ajout ni le retrait d ’objets
dans les serveurs
Invocation dynamique
• Permet au programme client de découvrir
–
–
–
–
les objets à l ’exécution
les interfaces proposés par ces objets
construire dynamiquement messages et requêtes
envoyer et recevoir le résultat de telles requêtes
• Systèmes réactifs faciles à modifier
OFFERT PAR CORBA, DCOM et JAVA
Invocation dynamique
+ surcharge
• Flexibilité du code
• briques logicielles avec les mêmes
messages pour des objets de différentes
natures
– définir de nouveaux objets sans modifier
l ’interface
– changements qui n ’affectent pas les clients
Rôle du client
Invoquer les services dont il a besoin par envoi
de requêtes
ID
Accès à l ’objet destinataire par une référence
à son implémentation par l ’interface
Unités autonomes - solidité robustesse - adaptation
Rôle de l ’infrastructure
• administre les implémentations, la création
et la destruction d ’objets
• réceptionne les requêtes, localise le serveur,
vérifie son état et celui du destinataire
• active au besoin le serveur, lui envoie les
données de la requête
• ramène les résultats au client
• doit être informée de l ’arrêt d ’un serveur
• doit gérer la persistance
Rôle du serveur
• Administrer un flot de requêtes pour un ou
plusieurs objets dont il a la responsabilité
• Ordonnancer la séquence des opérations de
réponses à une requête
Rôle du serveur d ’objets
•
•
•
•
active si besoin l ’objet destinataire
recherche et exécute la méthode
passe le résultat à l ’infrastructure
plusieurs requêtes peuvent arriver
simultanément
• arrêt du serveur : desactiver tous les objets
et enregistrer leur état
Un peu plus sur l ’infrastructure
• Transport des messages
• localisation des serveurs et des objets
• persistance
JDK1.1
ORB pour CORBA
norme Corba 1
DCOM pour OLE
non formelle
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
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
– En OLE
stub + skeleton
• 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
• 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
Un bref comparatif
Origine
Microsoft
OMG
JavaSoft
Archi
COM
DCOM
IDL ORB
IIOP
Java RMI
Applet
Interfaces IUNKnown Définies en
prédéfinies IDL
Définies en
Java
Un bref comparatif
Interface+ Agrégation Héritage
composition
Héritage
extends
Langage
C++
C C++
Smalltalk
Java
Infrastr.
Proxy
stub
Stub
skeleton
Proxy
RO
Un bref comparatif
Serveur
Appli
DLL
Appli
Biblio
BDD
Appli Java
Client
Appli
DLL
Appli
Biblio
BDD
Appli Java
Applets
Création
IFactory
Instancié
en LOO
Instancié
En Java
Un bref comparatif
Appel
dyn.
IDispatch
DII
Introsp.
beans
Ident.
Reg. OLE
Service de
nommage
URL
Comm.
DCOM
DCE
IIOP
RMI
(TCP/IP)
Petite Conclusion
• Problèmes d ’intégration et
d ’interopérabilité
• Arrivée de internet
– Effort d ’interopérabilité et d ’efficacité
OUFFFFF
• Virginie
• maman
• papa
maman
Virginie
papa
,,,,;,;;,;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;