Objets Distribués et Composants

Présentation au sujet: "Objets Distribués et Composants"— Transcription de la présentation:

1 Objets Distribués et Composants
Les applications actuelles et futures Cours ESSI3 SAR5

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éritage et 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 Circulation de messages et machines hétérogènes
Infrastructure informatique de distribution Couche de transport Responsable de l’administration des objets et de l’acheminement des messages Couche de services Objets de l’application qui résultent de la conception du modèle

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 Service (marshalling..)
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
Client Client Serveur Serveur

20 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

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

22 Générateurs Stubs Skeletons Proxy 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 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); ….. };

24 Compilation interface IDL
1- Exemple introductif 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 RMI Classes 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 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,...

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 Interaction Client Enregistreur
serveur registre Lookup : où est objetDistant ? stub Il est ici Envoyez le stub Le voici squelette objet Distant result = objetDistant.m() result 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 IDL et ODL sont incompatibles
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

46 Invocations Invocations dynamiques Du ressort de l’infrastructure
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 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

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

51 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

52 Un bref comparatif Origine Microsoft OMG JavaSoft Archi COM IDL ORB
Java RMI DCOM IIOP Applet Interfaces IUNKnown Définies en Définies en prédéfinies IDL Java

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

54 Un bref comparatif Serveur Appli Appli Appli Java DLL Biblio BDD
Client Appli Appli Appli Java DLL Biblio Applets BDD Création IFactory Instancié Instancié en LOO En Java

55 Un bref comparatif Appel IDispatch DII Introsp. dyn. beans Ident.
Reg. OLE Service de URL nommage Comm. DCOM IIOP RMI DCE (TCP/IP)

56 Des objets distribués aux composants
Chronique d’une invasion annoncée Pourquoi? Comment? Qui : / Corba3 CCM/ Web Services (.net, J2EE) / EJBs …

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

58 Un Service Web, c’est quoi ?
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

59 Architecture globale

60 Points communs avec les middlewares objets
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

61 Cycle de vie d’utilisation
Serveur 2 : J’ai trouvé! Voici le serveur hébergeant ce service web Annuaire UDDI 1 : Je recherche un service WEB 3 : Quel est le format d’appel du service que tu proposes? Contrat SOAP 4 : Voici mon contrat (WSDL) XML Client XML 5 : J’ai compris comment invoquer ton service et je t’envoie un document XML représentant ma requête XML 6 : J’ai exécuté ta requête et je te retourne le résultat

62 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

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

64 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é ?

65 Un composant, c’est quoi ?
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

66 Exemple des différents éléments

67 Exemple de modèle de composant

68 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

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

70 Un vrai cycle de vie Fichier de déploiement Packaging d'assemblage
Approche déclarative basée sur XML

71 Prochaine invasion dans la lignée ?
Approche composant revisitée : Open CCM : une meilleure solution CCM + MDA (+ d'abstraction des inrastructures, projections vers des middlewares connus…) Des Composants à conteneurs ouverts (travaux de recherche) Des composants adaptables (fractal)

72 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

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

74 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 ?

75 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é ....)

76 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

77 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