Objets Distribués Chronique d ’une invasion annoncée Pourquoi ? Comment? Qui : Corba / COM-DCOM / Java RMI...
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 Client-Serveur – sockets– RPC – couches OSI
Maturation de la technologie orientée objet
Crediterdebiter
Compte AM
montant
Objet = module logiciel
Compte AMCrediter1000
Interaction entre objets : message
Objets + Messages
• 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
Application = Collection d ’objets interagissant
Classes et héritage
Com pte CodeviDeposer
com pte PELDéb ite r
Com pte de particulierC red ite rD eb ite r
Mécanisme d ’abstraction + GénéralisationSurcharge des méthodes par héritage
Classe et Composition
CARROSSERIE
MOTEUR
VEHICULE
Architectures à base d ’objets
ObjetsClasses
Messages
Base de données
IHM
Modèles et méthodologiesde développement
C++SmalltalkJava
Application traditionnelle vsapplication 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 objetssubstitution 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 SERVEUR
Préparation de la requêteenvoi de la requêteattente du résultat….
Analyse du résultat reçu
Connexion au serveur Attente de requêtes
Analyse de la requête…..Exécution….Préparation de la réponseenvoi de la réponse
Appel de Procédure à Distance
CLIENT SERVEUR
F(1, x)
marshalling
marshalling
unmarshalling
unmarshalling
F(1,x)
10
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
Générateurs de Stubs
RPCGEN / MAVROS
ASN1 XDR
Librairie marshalling et unmarshalling
squelettes du client et du serveur
Spécificationsdes données
Générateurs
Types de donnéesC Lisp Java
Types de données
C
Fichiersgénérés
Circulation de messages et machines hétérogènes
• Couche de services
• Objets de l ’application qui résultent de la conception du modèle
• Couche de transport
• Responsable de l ’administration des objets et de l ’acheminement des messages
Infrastructure informatique de distribution
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
Client Client Serveur Serveur
Objet1
Objet2 Objet3
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
• 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. JavaSpécificationsdes données
Générateurs
Fichiersgénérés Stubs Skeletons Proxy
(mise en œuvre de la sérialisationet 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
Invoquer les services dont il a besoin par envoi de requêtes
Accès à l ’objet destinataire par une référence à son implémentation par l ’interface
Rôle du client
Unités autonomes - solidité - robustesse - adaptation
ID
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
ORB pour CORBAnorme Corba 1
DCOM pour OLEnon formelle
JDK1.1
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 ORBset 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 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
• 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 COMDCOM
IDL ORBIIOP
Java RMIApplet
Interfaces IUNKnownprédéfinies
Définies enIDL
Définies enJava
Un bref comparatif
Interface+ Agrégationcomposition
Héritage Héritageextends
Langage C++ C C++Smalltalk
Java
Infrastr. Proxystub
Stubskeleton
ProxyR O
Un bref comparatif
Serveur AppliDLL
AppliBiblioBDD
Appli Java
Client AppliDLL
AppliBiblioBDD
Appli JavaApplets
Création IFactory Instanciéen LOO
InstanciéEn Java
Un bref comparatif
Appeldyn.
IDispatch DII Introsp.beans
Ident. Reg. OLE Service denommage
URL
Comm. DCOMDCE
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
papaVirginie
maman
ezcbbbbbb,,,,,;,;;,;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;