1 / 77

Objets Distribués et Composants

Objets Distribués et Composants . Les applications actuelles et futures Cours Harmonisation. 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

Mia_John
Télécharger la présentation

Objets Distribués et Composants

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Objets Distribuéset Composants Les applications actuelles et futures Cours Harmonisation

  2. Chronique d’une invasion annoncée Pourquoi? Comment? Qui : Corba / COM-DCOM / Java RMI…

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

  4. L’héritage de la programmation par objets Communication par envoi de messages Encapsulation et Interface Héritageet Composition

  5. 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

  6. 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

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

  8. 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

  9. 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

  10. L’héritage de la programmation Client Serveur Appel de procédures à distance Importance du marshalling Des serveurs accessibles simultanément par plusieurs clients Enregistrement des serveurs dans des annuaires de noms Communication connectée ou par message…..

  11. 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 Programme reqrep { version { REPONSE rerep(REQUETE) = 1 }= 1 } = 10000 • XDR et RPC de SUN

  12. Exemple : annuaire des surnoms ASN.1 et norme ISO Protocole := CHOICE { enregistrerReq [0] SEQUENCE{PrintableString nom, PrintableString surnom} enregistrerRep[1] BOOLEAN, listerReq [2] NULL, listerRep [3] SET OF Personnes, ….} XDR et RPC de SUN Programme surnoms { version { boolean enregistrer(nomSurnom) = 1; listePersonnes lister(void)=2 }= 1 } = 10000

  13. Générateurs de Stubs Spécifications des données XDR ASN1 Générateurs RPCGEN / MAVROS Fichiers générés Types de données C Lisp Java Librairie marshalling et unmarshalling squelettes du client et du serveur Types de données C

  14. 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 Circulation de messages et machines hétérogènes Infrastructure informatique de distribution

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

  16. Des Annuaires de Noms Yellow Pages X500 LDAP

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

  18. 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

  19. Infrastructure Objets Distribués Objet2 Objet3 Objet1 Client Client Serveur Serveur

  20. Corba indépendant des langages de programmation Projections C,C++, Java Un langage de Spécification IDL Orienté C++ Implémentation des objets distribués Tout Java

  21. 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 CORBA, DCOM et JAVA • héritage de classe • implémentation de plusieurs interfaces possibles

  22. 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…)

  23. 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); ….. }; }; CORBA

  24. 1- Exemple introductif Compilation interface IDL Surnoms.idl jidl Surnoms.idl A écrire Compilateur IDL/Java Généré Répertoire grid Répertoire grid Répertoire grid Répertoire Surnoms Client Serveur StubForSurnoms.java Surnoms.java _SurnomsImplBase.java I SurnomsHelper.java Client.java SurnomsImpl.java SurnomsHolder.java Serveur.java

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

  26. RMIClasses et Interfaces Remote Machine locale Machine distante InterfaceDistante InterfaceDistante Souche Squelette Appel méthode m() Appel méthode m() ClasseLocale ClasseDistante

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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

  32. 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

  33. Rôle du client 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 ID Unités autonomes - solidité - robustesse - adaptation

  34. 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

  35. 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

  36. 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 : désactiver tous les objets et enregistrer leur état

  37. Un peu plus sur l’infrastructure • transport des messages • localisation des serveurs et des objets • persistance JDK ORB pour CORBA norme Corba 1 DCOM pour OLE non formelle

  38. 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

  39. ORB Client ou Serveur resolve_initial_references ("NameService"); CosNaming:: NamingContext conversion ajout,retrait,lecture,... Scénario d ’obtention de la référence du service de nommage

  40. 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);

  41. 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)

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

  43. 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

  44. 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

  45. Invocations • Invocations statiques • IDLen 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

  46. Invocations • Invocations dynamiques • DII en CORBA • IDispatch en OLE • java reflect • Du ressort de l’infrastructure

  47. 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

  48. Services normalisés Seulement certains sont implémentés Naming, Trading, Event Le programmeur doit les connecter… Services et Objets Distribués Des services en Programmant avec Java Securité,Threads, Événements Url et Web Non intégrés à RMI

  49. 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

  50. Les points communs des middlewares en objets distribués(aspect réseau) 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.....

More Related