Objets Distribués Chronique dune invasion annoncée Pourquoi? Comment? Qui : Corba / COM-DCOM / Java RMI...

Présentation au sujet: "Objets Distribués Chronique dune invasion annoncée Pourquoi? Comment? Qui : Corba / COM-DCOM / Java RMI..."— Transcription de la présentation:

1 Objets Distribués Chronique dune invasion annoncée Pourquoi? Comment? Qui : Corba / COM-DCOM / Java RMI...

2 Pourquoi ? Maturation de la technologie orientée objet –ADA, Modula –Smalltalk, C++, Java Maturation des communications Client- Serveur –sockets –RPC –couches OSI

3 Maturation de la technologie orientée objet Crediter debiter Compte AM montant Objet = module logiciel Compte AM Crediter 1000 Interaction entre objets : message

4 Exemple : annuaire des surnoms enregistrer lister oter AnnuaireEssi listePersonnes Enregistrer(AnneMarie,AM) lister()

5 Objets + Messages module logiciel indépendance de la programmation et de la construction unité autonome Méthode = comportement des objets Message = interaction entre objets de lapplication Application = Collection d objets interagissant

6 Classes et héritage Mécanisme dabstraction + Généralisation Surcharge des méthodes par héritage

7 Exemple : annuaire des surnoms Annuaire persistant sauver restaurer Annuaire enregister oter lister

8 Classe et Composition CARROSSERIE MOTEUR VEHICULE

9 Exemple : annuaire des surnoms Personnes Annuaire Le composite exporte-t-il ou non les services de ses composants ?

10 Architectures à base d objets Objets Classes Messages Base de données IHM Modèles et méthodologies de développement C++ Smalltalk Java

11 Application traditionnelle vs application à base dobjets 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 dassemblage dobjets existants

12 Objets = briques logicielles Assembler des briques élémentaires Réduire la complexité des systèmes dinformation Séparation entre interface et implémentation Représentation et types de données Mécanismes dabstraction

13 Séparation entre interface et implémentation séparation de la définition et de limplémentation : encapsulation interface : partie visible de lobjet implémentation : partie privée inaccessible depuis dautres objets interface = contrat entre lobjet et le monde extérieur

14 Exemple : annuaire des surnoms interface : partie visible de lobjet (enregistrer, oter, lister, …) implémentation : partie privée inaccessible depuis dautres objets (listePersonnes : un vecteur de Personne ou un tableau ou ….) interface = contrat entre lobjet et le monde extérieur (save impossible par exemple)

15 Séparation entre interface et implémentation Assemblage des objets dépend uniquement des interfaces, le changement local dun objet ne perturbe pas lensemble de lapplication. Importance de la nomenclature des objets substitution logique liée à la substitution physique

16 Exemple : annuaire des surnoms Importance de la nomenclature des objets Comment identifier lAnnuaire de l ESSI? Celui de lESINSA ?

17 Représentation et Types de données Définition de nouveaux types Choix dun 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

18 Mécanismes dabstraction 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

19 Exemple : annuaire des surnoms Annuaire persistant sauver restaurer Annuaire enregister oter lister Héritage = extension dun service Annuaire Fichier sauver restaurer Composition = composition de services enregister oter lister

20 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 limplémentation)

21 Infrastructure Client Serveur CLIENT SERVEUR requêtes

22 Exemple CLIENT Essifun SERVEUR de Surnoms oter infrastructure

23 Appel de Procédure à Distance CLIENT SERVEUR Préparation de la requête Envoi de la requête Attente 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éponse Envoi de la réponse

24 Appel de Procédure à Distance CLIENT SERVEUR F(1, x) marshalling unmarshalling F(1,x) 10

25 Exemple : annuaire des surnoms EssiFun SERVEUR de Surnoms enregistrer(« paul », »bug ») marshalling unmarshalling 0111000101000.. 101.. enregistrer(« paul », »bug ») TRUE

26 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

27 Exemple : annuaire des surnoms XDR et RPC de SUN 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

28 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

29 Circulation de messages et machines hétérogènes Couche de services Objets de lapplication qui résultent de la conception du modèle Couche de transport Responsable de ladministration des objets et de lacheminement des messages Infrastructure informatique de distribution

30 Introduction de services Gestionnaires de noms (x500, nis, dns…) Synchronisation (transaction …) Sécurité

31 CLIENT SERVEUR Transport TCP IP... Service (marshalling..) transaction sécuriténommage Infrastructure ?

32 Objets distribués Un programme (objet) peut être à la fois client de certains serveurs et serveur dautres clients Il peut y avoir reconfiguration dynamique des rôles Client Serveur

33 Infrastructure Objets Distribués ClientClient ServeurServeur Objet1 Objet2Objet3

34 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

35 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 dinterfaces héritage de classe implémentation de plusieurs interfaces possibles

36 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…)

37 CORBA module Surnoms { typedef string Nom ; struct Personne {Nom nom; string surnom;}; typedef sequence ListePersonnes; interface Surnoms{ exception ExisteDeja{string surnom;}; boolean enregistrer(in Personne personne) raises (ExisteDeja); ….. };

38 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 Surnoms I SurnomsHelper.java SurnomsHolder.java jidl Surnoms.idl

39 RMI public interface Surnoms extends java.rmi.Remote { public Boolean enregistrer(String nom, String surnom) throws java.rmi.RemoteException, ServeurSurnoms.surnoms.ExisteDeja ; …. }

40 RMI Classes et Interfaces ClasseLocale SoucheSquelette ClasseDistante InterfaceDistante Remote Appel méthode m() Machine localeMachine distante InterfaceDistante

41 Comment activer des objets distribués ? Messages échangés entre objets = –Requêtes ou Résultats Certains envois de messages nattendent pas de résultats Requête = Destinataire + nom de méthode + Paramètres Résultat = Donnée ou indication dune erreur ou dune défaillance

42 Comment activer des objets distribués ? Mécanisme dexécution ou de transport –définit comment les messages sont véhiculés de lobjet client vers lobjet serveur (destinataire) –retrouver et activer les objets adéquats Un objet client a deux manières denvoyer des messages –invocation statique –invocation dynamique

43 Invocation statique Le nom de lobjet destinataire et le message sont connus au moment du développement Ne permet ni lajout ni le retrait dobjets dans les serveurs

44 Invocation dynamique Permet au programme client de –découvrir les objets à lexé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

45 Linvocation dynamique API (DII) de construction de requêtes –sans passer par des souches prégénérées Un objet Request = un nom dopération, une liste de couples valeur - type (au sens de lIR) et une structure pour le résultat –invoke –send_deferred + get_response, poll_response –send_oneway

46 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 linterface –changements qui naffectent pas les clients

47 Invoquer les services dont il a besoin par envoi de requêtes Accès à lobjet destinataire par une référence à son implémentation par l interface Rôle du client Unités autonomes - solidité - robustesse - adaptation ID

48 Rôle de linfrastructure administre les implémentations, la création et la destruction dobjets 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 larrêt dun serveur doit gérer la persistance

49 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

50 Rôle du serveur dobjets active si besoin lobjet destinataire recherche et exécute la méthode passe le résultat à linfrastructure plusieurs requêtes peuvent arriver simultanément arrêt du serveur : désactiver tous les objets et enregistrer leur état

51 Un peu plus sur linfrastructure transport des messages localisation des serveurs et des objets persistance ORB pour CORBA norme Corba 1 DCOM pour OLE non formelle JDK1.1

52 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

53 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,...

54 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);

55 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)

56 Interaction Client Enregistreur client serveur clientregistre Lookup : où est objetDistant ? stub Il est ici Envoyez le stub Le voici stubsquelette objet Distant result = objetDistant.m() result RMIRegistry + ClassLoader

57 Interface avec linfrastructure 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 dune interface en RMI BOA Objects Adaptaters

58 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

59 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

60 Invocations Invocations dynamiques –DII en CORBA –IDispatch en OLE –java reflect Du ressort de linfrastructure

61 CORBA vs OLE définition du serveur très générale laissée à limplémentation flexibilité primordiale pour lintégration de systèmes (BDD…) processus formel avec lOMG un serveur est une application ou une DLL stratégie commerciale et pratique

62 Un bref comparatif OrigineMicrosoftOMGJavaSoft ArchiCOM DCOM IDL ORB IIOP Java RMI Applet InterfacesIUNKnown prédéfinies Définies en IDL Définies en Java

63 Un bref comparatif Interface+Agrégation composition Héritage extends LangageC++C Smalltalk Java Infrastr.Proxy stub Stub skeleton Proxy R O

64 Un bref comparatif ServeurAppli DLL Appli Biblio BDD Appli Java ClientAppli DLL Appli Biblio BDD Appli Java Applets CréationIFactoryInstancié en LOO Instancié En Java

65 Un bref comparatif Appel dyn. IDispatchDIIIntrosp. beans Ident.Reg. OLEService de nommage URL Comm.DCOM DCE IIOPRMI (TCP/IP)

66 Conclusion Problèmes dintégration et dinteropérabilité entre le monde Microsoft et le reste Arrivée de internet –Effort dinteropérabilité et defficacité –RMI et Corba en Java Des nouveautés avec les composants –les Enterprise Java Beans –Corba Components –et aussi C# et net Affaire à suivre