Cours d introduction. Modèles d interactions pour le client serveur et exemples d architectures les implantant

Transcription

1 Cours d introduction Modèles d interactions pour le client serveur et exemples d architectures les implantant Gérard Florin Conservatoire National des Arts et Métiers Laboratoire CEDRIC Modèles pour le client serveur 1

2 Introduction Problématique de la coopération Application coopérative Application réalisée par des programmes communicants (processus, objets,...). Avantages potentiels - Modularité. - Réutilisation (par composition). - Performances. Motivations actuelles importantes pour les applications coopératives - Applications systèmes et réseaux (algorithmique répartie). - Applications objets, objets répartis, à base de composants. - Systèmes d informations, Parallélisme, Intelligence artificielle => Presque tous les types d applications informatiques sont concernées. Modèles pour le client serveur 2

3 Des problèmes spécifiques à la coopération Cycle de vie - Exprimer la coopération. - Développer l application. - Déployer l application. - Gérer son exécution. Sous des hypothèses d environnement - Performances. - Pannes. - Sécurité. - Répartition. Modèles pour le client serveur 3

4 Exprimer la coopération Le principal problème abordé actuellement. Coopération : Le point de vue local Ensemble de programmes coopérants utilisant des données locales Programmes : schéma de contrôle local à un site (flot d exécution local). Données : traitées par le programme, disponibles localement sur le site. Vision plutôt ascendante : émergence du comportement coopératif. Terminologies multiples Application répartie, distribuée, coopérative, n tiers Modèles pour le client serveur 4

5 Coopération : Le point de vue global Une application coopérative offre un service externe en encapsulant une structure de données réparties Programme réparti : schéma de contrôle global à un ensemble de sites (comportement de groupe). Données : une structure de données encapsulée par le traitement (en fait distribuée sur les différents sites, structure de données partitionnée). Vision plutôt descendante : le comportement coopératif visé est placé a priori. Modèles pour le client serveur 5

6 Coopération avec utilisation d interactions client serveur Client serveur : une approche universellement adoptée pour structurer les applications coopératives. A l origine des services généraux offerts par les couches application réseau. Client A Serveur Service 1 Client B Service n Exemples : Serveurs de fichiers Serveurs de base de données, Serveurs d impression Serveurs de noms (annuaires) Serveurs applicatifs usager. Modèles pour le client serveur 6

7 Modèle client serveur Un ensemble de choix de réalisations de l interaction de communication en point à point ayant des points communs. Client serveur : Vue du client Requête Client Service distant Réponse - Mode de synchronisation locale des primitives requête, réponse. - Mode de synchronisation distante. - Parallélisme interne au client. Modèles pour le client serveur 7

8 Client serveur : Vue du serveur Requêtes Exécution du service Réponses - Gestion des requêtes. - Exécution du service : séquentiel, concurrent - Mémorisation ou non de l état du client. Alternatives au mode client serveur Des schémas de contrôle applicatifs réutilisables ( design patterns ) générant directement des modes complexes d interaction Impliquant des groupes d entités communicantes. Modèles pour le client serveur 8

9 Développer une application en client-serveur Choisir une sémantique de base précise supportant le mode client serveur Pour exprimer la synchronisation entre des coopérants au moyen d une interaction de base ( design pattern ). Propriétés des outils d expression de la coopération 1 Définition d un modèle d interaction et d exécution. Présentation des différentes catégories de modèles dans cette introduction. 2 Définition d une API (interface de programmation) supportant le modèle. Dans les cours de détail. 3 Outils de développement. 4 Environnements d exécution. Services systèmes d accueil sur différents types d infrastructure. Modèles pour le client serveur 9

10 Architecture globale Outils de développement Application Outils d administration Médiateur (Middleware) Services applicatifs (fichiers répartis, transactionnels, Services systèmes (communications, désignation, sécurité ) Systèmes d exploitation Machines et réseaux Modèles pour le client serveur 10

11 Plan du cours : Les modèles d interactions actuels pour le client serveur Modèles de communication par messages. Modèles de communication à événements. Modèles client serveur de base de données. (ODBC). Modèles client serveur en RPC. - Client serveur à RPC traditionnel (DCE). - Client serveur à objets répartis. (CORBA, DCOM). - Client serveur à composants (EJB, CCM). Egalement Modèles à base de code mobile. Modèles à mémoire virtuelle partagée répartie. Modèles pour le client serveur 11

12 MODELES CLIENT SERVEUR A MESSAGES Modèles pour le client serveur 12

13 Client serveur par messages: Introduction Mode de communication basique par messages asynchrones - Communication asynchrone : Emission non bloquante Réception bloquante. - Communication par messages typés. - Communication sur les processus destinataires ou sur des boites à lettres (portes) de communication. Send(bals, serv, params Msg=get(bals) CLIENT Requète bals Réponse balc Msg=get(bals) exec(serv) Put(balc,res) SERVEUR Modèles pour le client serveur 13

14 Communications par messages : exemples de mise en oeuvre Interfaces des piles réseaux Couche transport : Sockets, TLI, NetBEUI. Interfaces de programmation parallèle PVM, MPI. Interfaces de systèmes répartis Chorus, Mach Autres environnements par message Multi-agent, Dernière version du modèle : les MOM (fin des années 1980) Mode messages asynchrones + Mode asynchrone avec persistance : les files de messages. Modèles pour le client serveur 14

15 Communication à files de messages : MOM Messages Oriented Middleware Deux modes de fonctionnement:. mode message (habituel).. mode file de messages (caractéristique) Messages Identification unique. Structure. Entête : identifiant, informations protocolaires pour l acheminement. Attributs : couples (nom, valeur) utilisables pour la sélection des messages. Données : charge utile. Paramètres d acheminement. Durée de vie Priorité Sécurité. Confidentialité, contrôle d accès. Modèles pour le client serveur 15

16 Motivations pour les files de messages Les styles Asynchrones et Synchrones ont des forces et des faiblesses. Mode synchrone (bloquant) Il est terminant (on est certain de la fin). Avec acquittement (réponse). PB : arrêt complet du fonctionnement du client quand le serveur ne répond pas. Mode asynchrone (non bloquant) Pour assurer l acquittement et la terminaison il faut un protocole. L asynchronisme des modes messages habituels devient assez vite également bloquant car on peut saturer un site distant qui ne peut pas tenir le rythme des services demandés (serveur non opérationnel). => Amélioration : les files de messages. Modèles pour le client serveur 16

17 Files de messages Structures de données de stockage de messages asynchrones - Identification unique - Propriétés de persistance (style transactionnel) Les messages dans les files sont journalisés (résistance aux défaillances, gestion des clients en ligne ou hors ligne). - Partagées (par les applications). - Mode de réception variable (selon le destinataire). Exemples : IBM MQSeries, Microsoft Message Queue Server, DECmessageQ, TIPCO, etc. Modèles pour le client serveur 17

18 EXEMPLE MOM : IBM MQSERIES LES QUATRE TYPES DE MESSAGES Datagram : messages isolés Request : l émetteur attend une réponse. Reply : réponses aux requêtes Report : pour informer d événements exceptionnels. LES ONZE PRIMITIVES MQCONN - Connecte une application à un gestionnaire de file ( queue manager ). MQOPEN - Ouvre un objet MQSeries comme une file et retourne un descriptif ( handle ). MQGET - Demande pour obtenir des messages d une file locale. MQGET peut être utilisée de façon bloquante ou non. Modèles pour le client serveur 18

19 LES ONZE PRIMITIVES (SUITE) MQPUT - Envoie un message sur une file locale ou distante MQPUT1 - Séquence de MQOPEN, MQPUT d un message et MQCLOSE. MQCLOSE - Fermeture avec destruction d une file. MQDISC - Déconnexion avec un gestionnaire de files MQSeries. MQINQ - Interrogation d attributs d objets MQSeries (des files). MQSET - Positionnement ou modification d attributs d objets MQseries. MQCMIT - Indique au gestionnaire de la file que toutes les opérations get et put depuis le précédent point de synchronisation sont validées. MQBACK - Demande de reprise arrière pour tous les get et put depuis le dernier point de synchronisation. Modèles pour le client serveur 19

20 Les files de messages : conclusion Avantages Une interaction par message asynchrone avec des améliorations. Augmentent l interopérabilité, la portabilité dans la mesure ou l interface MOM isole l application des logiciels sous jacents. Les infrastructures client serveur à MOM sont assez simples et donc à maturité => de nombreuses entreprises utilisent des MOM (exemple le secteur bancaire). Les autres styles de middleware ne sont pas simples ni jugés aussi murs. => Introduction de service MOM en CORBA (chez IBM Mqseries en DSOM) Inconvénients Sémantique limitée du mode message asynchrone. Modèles pour le client serveur 20

21 MODELES CLIENT SERVEUR A EVENEMENTS Modèles pour le client serveur 21

22 Client serveur à événements : Introduction Besoin : définir une approche asynchrone (événementielle) de communication.. Programmation événementielle :systèmes réactifs, messages asynchrones, graphique, Environnements : un plus dans les environnements objets répartis (services d événements CORBA, composants CORBA, JMS Java Messaging Service). Concepts - Notions d événements (un signal) et de réactions (un code, une procédure exécuté par un abonné lors d un événement). - Attachement : association dynamique entre un événement et une réaction. - Communication anonyme : indépendance entre l émetteur d un événement et les consommateurs de cet événement. Modèles pour le client serveur 22

23 Communication événementielle : schéma général - Des sources produisent des événements : publish. - Des consommateurs s abonnent à des événements : subscribe. Programme prod Publish (event1) 2 Service de gestion des événements et des abonnements Subscribe (event1, 1 Programme cons Subscribe (event1, reaction1) Reaction1 : Bal 3 Modèles pour le client serveur 23

24 Communication événementielle : Sémantique de consultation des boites à lettre Mode Pull - Le consommateur doit consulter sa boite à lettre pour traiter les événements en attente. => Il contrôle le moment de traitement des événements. Mode Push - Le consommateur attache une méthode à chaque type d événement. => L occurrence d un événement déclenche automatiquement le traitement associé. Modèles pour le client serveur 24

25 Communication événementielle : Architecture du service d événement centralisée Mode Hub and Spoke Client producteur Client producteur Courtier centralisé d événements Client consommateur - Le service centralisé de gestion des événements dialogue en mode point à point avec des clients producteurs ou consommateurs d événements. Modèles pour le client serveur 25

26 Communication événementielle : Architecture du service d événement répartie Mode Snowflake Client producteur Client producteur Courtier Courtier Courtier Client consommateur - Les courtiers coopèrent pour offrir un service réparti de gestion des événements. Modèles pour le client serveur 26

27 Communication événementielle : Architecture du service d événement à bus de messages Client producteur Client producteur Courtier Courtier Courtier Répéteur Client consommateur - Les courtiers coopèrent au moyen d un protocole à diffusion des événements. Modèles pour le client serveur 27

28 ENVIRONNEMENT A EVENEMENTS, EXEMPLE : JMS JAVA MESSAGE SERVICE Une API JAVA pour offrir un accès unique aux différents protocoles de files de messages (MOM MQSeries, Tibco ). - Gestion événementielle des messages. - Mode publish / subscribe Client producteur Client consommateur JMS Accès MQ X JMS Accès MQ X JVM JVM Pile MQ X Pile MQ X Réseau Modèles pour le client serveur 28

29 Java Message Service : Architecture JNDI JMS Client Destination Connection factory Message Producer Connection Message Consummer Session Modèles pour le client serveur 29

30 Commentaires Architecture JMS - JMS utilise JNDI ( Java Naming and Directory Interface ) pour trouver la localisation des ressources souhaitées. - Un client JMS (le créateur d une application JMS) doit réaliser les étapes : 1.Créer une connexion avec le prestataire d échange de messages. 2.Créer une ou plusieurs sessions pour émettre et recevoir des messages. 3.Créer des producteurs de messages ( MessageProducers ) qui publient des messages et des consommateurs de messages ( MessageConsumers ) qui reçoivent les messages. Modèles pour le client serveur 30

31 Client serveur à événements : Conclusion Avantages Une sémantique de communication asynchrone demandée par différentes applications (différents métiers). - Diffusion d informations sur le WEB (Smartsockets, Castanet, Ambrosia, ActiveWeb, ibus, TIB/rendezvous). - Diffusion de logiciels. - Workflow Inconvénients - Des outils souvent propriétaires. - Des outils de développement sommaires. Modèles pour le client serveur 31

32 Modèle client serveur De données Modèles pour le client serveur 32

33 Le client serveur de données : Principes généraux Une approche des applications client serveur orientée accès distant à une base de données. Fonctions du client Traitements applicatifs non lié au stockage des données : - dialogue avec l utilisateur, - traitements divers, -. Fonctions du serveur Stockage des données, - Interprétation des requêtes, - Optimisation des requêtes - Gestion de la persistance - Gestion de la sécurité des données -.. Modèles pour le client serveur 33

34 Le client serveur de données : schéma de base Client Code client Médiateur (Middleware) Requête SQL Résultats: tuples Serveur SGBD Très nombreux standards et produits propriétaires. Modèles pour le client serveur 34

35 Exemple : Client serveur de bases de données relationnelles L'API CLI de l X/OPEN "Call Level Interface" Une API en mode message pour l'accès à des BD relationnelles (31 primitives). Une standardisation de la formulation des requêtes offrant la conformité SQL2. AllocHandle BindCol BindParam Cancel CloseCursor Connect CopyDesc DescribeCol Disconnect EndTran ExecDirect Execute Fetch FreeHandle GetCol GetCursorName GetConnectAttr GetDescField GetDescRec GetDiagField GetDiagRec GetEnvAttr GetStmtAttr NumResultCols Prepare ReleaseEnv SetCursorName SetDescField SetDescRec SetEnvAttr SetStmtAttr Modèles pour le client serveur 35

36 Exemple : Le client serveur de bases de données orientées objet Objectifs Permettre la portabilité des sources d une application utilisant une approche BD objet sur différents moteurs de SGBD objets. Solutions ODMG : Object Data Management Group - Choix d un modèle objet (sur ensemble du modèle objet de l OMG Object Management Group ). - Langage de définition de données ODL ( Object Description Language ) basé sur IDL CORBA). - Langage d interrogation orienté objet OQL ( Object Query Language ) - Intégration aux langages objets existants. Modèles pour le client serveur 36

37 Environnements client serveur de données : Exemple ODBC "Open Data Base Connection". Un produit définit par extensions à partir la CLI de l X/OPEN (depuis 1992).. Ensuite de très nombreux rattachements à ce standard de facto. Existence sur les principaux OS de pilotes pour un grand nombre de bases de données.. Mais des évolutions successives avec des variations importantes (V1, V2, V3..). Exemple ODBC 2.0. Noyau: 23 primitives de base.. Niveau 1: 19 appels pour les accès aux catalogues des bases de données, les gros objets et des fonctions spécifiques des pilotes.. Niveau 2: 19 appels supplémentaires pour des accès utilitaires. Modèles pour le client serveur 37

38 Organisation générale de ODBC API ODBC Gestionnaire de pilotes FAP 1 SQL*Net API Pilotes fournisseurs Pilote 1 Oracle Pilote 2 DB2 FAP 2 DRDA - Couche de réception des requêtes ODBC. - Couche de gestion des pilotes (à quel pilote passer une requête?) - Selon un format standard pour les pilotes ODBC. - Chaque pilote de bases de données encapsule les requêtes dans le format propre à chaque fournisseur de bases de données. - Notion de FAP ( Format And Protocol ) structure des messages et codage des données pour un SGBD. Modèles pour le client serveur 38

39 Client Serveur de données : Conclusion - La transmission à distance de requêtes d'accès à des bases de données est un problème résolu:. Choix d'un service (dérivé de SQL). Choix d'un protocole. - Difficulté : le client serveur de données est rendu très opaque par le jeu des éditeurs de logiciels qui veulent couvrir tout le spectre des interactions client serveur dans des solutions propriétaires :. Commandes de bases SQL enrichies de multiples fonctionnalités.. Procédures stockées et déclencheurs ajoutent des RPC synchrones ou asynchrones.. Les propositions propriétaires non standardisées sont trop nombreuses. Nombreux problèmes à résoudre pour une homogénéisation des approches et peu de volonté d'y arriver. Modèles pour le client serveur 39

40 Modèle client serveur en RPC traditionnel Modèles pour le client serveur 40

41 APD Appel de procédure distante RPC Remote Procedure Call Introduction Objectif d un RPC Présenter les interactions distantes sous une forme (syntaxe) et un effet (sémantique) analogue à celui d un appel de procédure local. - L opération appelée (le serveur) est présentée sous la forme d une procédure située sur un site distant dont un programme appelant (le client) demande l exécution. - L interaction est généralement synchrone comme un appel de procédure habituel (le mode asynchrone est possible) - Le RPC offre un changement important par rapport à la structuration au mode message (qui ne permet qu un déclenchement asynchrone d action à distance définie par une séquence de code). Modèles pour le client serveur 41

42 RPC : Principes de réalisation en communication par messages Birrell et Nelson 1984 Appelant Souche Appelant Souche Appelé Appelé 1 R é s e a u V V 4 Modèles pour le client serveur 42

43 RPC : Notion de souche ou talon ( stub ) Deux procédures intermédiaires (chez le client et le serveur) pour l adaptation de l invocation à l environnement réparti. Elles transforment un appel local en appel distant. Z Un exemple type de démarche réflexive de tissage ( wrapping ). Souche Appelant ( stub ) - Reçoit l appel en mode local. - Emballe les paramètres d appel dans un message de requête ( marshalling ). - Emet le message de requête. - Se met en attente du message de réponse. - Déballe les paramètres réponse. - Retourne les paramètres réponse comme un retour local. Modèles pour le client serveur 43

44 Souche Appelé ( skeleton ) - Reçoit le message d appel. - Déballe les paramètres d appel ( unmarshalling ). - Fait réaliser l exécution par la procédure appelée. - Récupère par le retour local les résultats. - Emballe les paramètres réponse dans le message de réponse. - Emet le message réponse vers la souche appelant. Modèles pour le client serveur 44

45 Invocation distante et invocation locale Objectifs pour une invocation distante Le plus souvent affiché : obtenir en invocation distante la même sémantique qu en invocation locale (atteindre une transparence de la répartition). Très difficile à atteindre (actuellement on est encore loin de compte) - Syntaxe : beaucoup plus lourde en appel distant qu en appel local Description de la signature en IDL. Usage d interfaces systèmes (API). Modes de désignation (références). - Sémantique de l appel distant différente de celle de l appel local Performances Transmission des arguments Modes de panne Modèles pour le client serveur 45

46 RPC : De nombreuses difficultés de mise en œuvre Performances Réalisation des invocations distantes avec des temps de réponse satisfaisants. Gestion des pannes Pannes franches du client ou du serveur. Ouverture (interopérabilité) Des langages évolués utilisés. De la représentation des données. Des systèmes d exploitation utilisés. Des architectures de réseau. Désignation et liaison Structuration des références. Localisation des serveurs. Sécurité Autorisation des accès aux procédures Authentification des clients Vérification des droits. Modèles pour le client serveur 46

47 RPC : Traitement des pannes Cas des pannes franches ou transitoires - Mécanismes de reprise - Sémantique des reprises en cas de panne dans l exécution d un RPC. Nombre de fois ou le serveur est exécuté Exactement une fois - Difficile (sauvegarde totale du contexte, reprise sur erreur). Au plus une fois ( at most once ) - Identification des appels, une seule exécution. Exception si erreur. Au moins une fois ( at least once ) - Tentatives d exécution jusqu à ce que l une réussisse. N importe quoi Modèles pour le client serveur 47

48 RPC Interopérabilité : Problèmes de représentation des données Présentation = Conversion des paramètres échangés entre l appelant et l appelé. A partir d une syntaxe abstraite : description dans un langage évolué des types de données échangés Génération d une syntaxe de transfert : syntaxe de la représentation des paramètres dans les messages. Opérations de codage / décodage : à partir de la génération des souches. Modèles pour le client serveur 48

49 RPC : Syntaxes de transfert Choisir un format de représentation des données échangées. - facile à comprendre, à générer. Coder et décoder efficacement à partir des représentations locales. - rapidement, - faible volume généré. Solutions des codages binaires Les paramètres sont codés sous une forme binaire prédéfinie, compacte, non directement lisible (exemple format CDR de CORBA). Solutions de codages caractères Les paramètres sont codés en format texte lisible ( human readable ) typiquement en utilisant XML. Modèles pour le client serveur 49

50 RPC : Syntaxes abstraites Besoin de langages de description d interface : IDL Interface Definition Language - Spécification unique de l appel (IDL des langages de déclaration de types commun appelant/appelé). - Spécification indépendante du langage de programmation de l appel (IDL langage unique, langage pivot). - Amélioration de la réalisation de l invocation distante par des directives spécifiques (références uniques, paramètres modes in out, contraintes d échéances,.). Mise en œuvre - IDL langage déclaratif de typage. - Utilisé pour générer des souches. - Code stocké dans un répertoire d interfaces. Modèles pour le client serveur 50

51 RPC : Utilisation du code IDL Procédure appelante (client) Compilateur langage client Souche client Code de l appelant (client) Description IDL de l interface appelée Générateur de souches Souche serveur Définitions communes Bi bli ot hè qu e Procédure appelée (serveur) Compilateur langage serveur Code de l appelé (serveur) Modèles pour le client serveur 51

52 RPC : Désignation et de liaison Désignation (nommage) Créer des références (des structures de données) qui supportent le mécanisme d invocation (ici à distance). De préférence indépendantes de la localisation (migration). - L adresse du site du serveur (@IP). - L adresse dans le protocole qui permet de l atteindre (@port TCP) - La procédure à exécuter. Plus finement - Le conteneur de la procédure à atteindre. - La désignation de la procédure dans le conteneur. Modèles pour le client serveur 52

53 Liaison Retrouver la procédure à partir de la référence. - Liaison statique (au préalable) - Liaison dynamique avec utilisation d un annuaire de références. - Liaison dynamique avec utilisation d un annuaire d interfaces (liaison retardée). RPC : Mise en œuvre de la liaison Procédure Appelante (client) Interaction RPC Procédure Appelée (serveur) Souche Appelant (client) Consul tation Service de nommage (désignation) Enre gistre ment Souche Appelé (serveur) Pile réseau Appelant (client) Communication réseau Pile réseau Appelé (serveur) Modèles pour le client serveur 53

54 EXEMPLE : ENVIRONNEMENT D'APPEL DE PROCEDURE DISTANTE DCE DCE : ARCHITECTURE - DCE DISTRIBUTED COMPUTING ENVIRONMENT est une boite à outils pour développer des applications réparties. - Services organisés autour d un RPC. APPLICATION DCE ACTIVITES "THREADS" Appel de procédure distante RPC SERVICES DE SECURITE SERVICES ANNUAIRE DNS X500 SERVICES DE FICHIERS REPARTIS SERVICES DE SYNCHRO D'HORLOGE FONCTIONS DE TRANSPORT D'UNE ARCHITECTURE RESEAU SYSTEME D'EXPLOITATION Remarques - Certains services en utilisent d autres. - Existence de fonctions transversales : administration et outils de développement. Modèles pour le client serveur 54

55 DCE : Evaluation Avantages - Accès à un ensemble d API systèmes répartis via des interfaces normalisées. - Pour une structuration d applications réparties gros grain (les entités communicantes sont plutôt des processus) - Un standard assez diffusé (surtout comme base de Microsoft DCOM). Inconvénients - Développement d applications grain fin (les entités sont de la taille d un objet ou d une variable) très lourde. Utilisation des API des services d activités ( threads ) et d appel distant (RPC). - Peu d outils de développement disponible. Modèles pour le client serveur 55

56 RPC Version de base : Conclusion Un mécanisme améliorant et simplifiant de façon significative la structuration des applications réparties par rapport au mode message. Un mécanisme de bas niveau - Permet de décrire l interaction d appel de procédure entre deux programmes : pas de vision globale de l application. - Mécanisme de base d appel synchrone : besoin de sémantiques plus variées, de services additionnels : désignation, sécurité, - Outils de développement limités à la génération automatique des souches mais à la base rien pour le déploiement, la mise au point. Modèles pour le client serveur 56

57 MODELES CLIENT SERVEUR A OBJETS REPARTIS Modèles pour le client serveur 57

58 Client serveur à objets répartis A la convergence de deux approches. L'approche objet - Objet : une unité de programmation très utilisée permettant une structuration des applications performante. - Objet : associe les traitements et les données en rendant les codes moins coûteux à développer, à maintenir, à réutiliser. Données Methode M2 Methode M1 Objet O Abstraction Comportement communs => Typage. Encapsulation Association des actions aux données. Héritage Réutilisation du code. Polymorphisme Réutilisation des références. Modèles pour le client serveur 58

59 La répartition Une intégration de l univers objet et de l univers réparti Données Méthode M2 Méthode M1 Données Méthode M3 Site S1 Objet O1 M3 Site S2 Objet O2 - Placement des objets sur différents sites, les réseaux permettent réalisation de l opération d invocation entre objets. - L'interface du système d'objet réparti est un ensemble de primitives ou un langage objet concurrent et réparti offrant la possibilité d'implanter et d'exécuter à la demande des objets (donnée, traitement) sur des sites quelconques.. Création à distance d'instances. Exécution à distance des méthodes.. Autres fonctions ou services: transactionnel, sécurité, placement... Modèles pour le client serveur 59

60 Objets répartis : Réalisation d une invocation Eléments d une invocation - Référence d objet ( pointeur universel d objet au niveau système réparti) - Identification de la méthode appelée (une chaîne). - Paramètres d appel et de retour et signaux d exception Modes de transmission possibles. par valeur (types élémentaires et types construits).. par référence (objets) Modèles pour le client serveur 60

61 Client serveur à objets répartis : mise en œuvre d une invocation Objet client Objet serveur A P P E L S O U C H E C L I E N T S S O E U R C V H E E U R Etat Méthode 1 Méthode 2 Méthode n Référence Méthode Paramètres Retour Paramètres Exceptions Modèles pour le client serveur 61

62 Systèmes d objets répartis homogènes langages - Une représentation unique des objets propre à un langage. Typiquement java, Instanciation de classes java. - Un mode d interaction optimisé (simplifié). Typiquement Java RMI ( Remote Method Invocation ). Modèles pour le client serveur 62

63 Systèmes d objets répartis hétérogènes ouverts - Supportent une variété importante de formes d objets (choix des références, de représentation, d invocation,.) définis par différents environnements langages et systèmes. - Un mode d interaction unique sur lequel se projettent tous les modes d interaction. OMG/CORBA Object Management Group / Common Object Requests Broker Architecture Microsoft OLE/DCOM "Object Link Embedding / Distributed Component Object Model". Modèles pour le client serveur 63

64 ENVIRONNEMENT A OBJETS REPARTIS, EXEMPLE : CORBA Un modèle de référence pour une architecture dédiée aux d'objets répartis. Environnement cooperatif de composants client-server Objets applicatifs Services CORBA Facilités CORBA Echangeur de requêtes objets "ORB Object Request Broker" CORBA permet à des objets (des composants) d'interagir en univers ouvert Découvrir la localisation, réaliser les invocations, pour de nombreux langages, environnements d'exécution, réseaux de communication. Modèles pour le client serveur 64

65 ARCHITECTURE CORBA 2.0 Client (appelant) Operation () In Arguments Valeurs d'appel Out Arguments Valeurs retour Serveur (appelé) Invocation dynamique DII Souches clients (invocation statique) IDL Stubs Interface ORB Squelettes Souches serveurs dynamique Squelettes DSI IDL Skeletons Adaptateur d'objets Noyau échangeur de requêtes ("ORB Core") (protocoles GIOP / IIOP) "OA Object Adapter" Référentiel d'interfaces Référentiel d'implantations Ex : L'interface d'invocation statique Langage IDL CORBA ("Interface Definition Language"). Les souches clients sont définies dans l'idl CORBA ("Interface Definition Language"). Modèles pour le client serveur 65

66 Exemple de déclaration d'interface en langage IDL module Voiture { /* Définition d'une classe cabriolet */ interface Cabriolet : véhicule_thermique ; { attribute integer consommation ; exception Panne (string explication) ; void accélère ( in short durée) raises (Panne) ; void freine ( in short durée) raises (Panne) ;... } interface Monospace : véhicule_thermique; { attribute integer place ; void accélère ( in short durée)... } } /* Fin de module */ Modèles pour le client serveur 66

67 Objets répartis : Conclusion Avantages Si le paradigme objet réparti est adopté : uniformisation de toutes les abstractions utilisées sous le concept objet. Simplifie et uniformise les accès et les communications offerts par les réseaux, les interfaces systèmes et les codes utilisateurs. - Désignation universelle. - Interactions de communication simplifiées et universelles. - Protection et sécurité universelle Modèles pour le client serveur 67

68 Inconvénients (actuels) - Performance des systèmes et applications développées en approche objets répartis. Les solutions objets imposent des délais d'interactions très importants. - Faiblesse des outils de développement (production des applications, déploiement, administration. - Faiblesse de la normalisation permettant l'interopérabilité des applications. Modèles pour le client serveur 68

69 MODELES CLIENT SERVEUR A COMPOSANTS Modèles pour le client serveur 69

70 Client serveur à composants : Origines La gestion de documents composites Objectif : simplification du processus de création et d utilisation des documents composites c est à dire formés à partir de documents d origines différentes. Problèmes à résoudre : interopérabilité entre composants logiciels binaires créés par des utilitaires différents. Solutions : Environnement d interaction unique en approche client serveur, formats de données pivot, procédure de conversion. Exemples:OLE/COM, OPENDOC/CORBA La synthèse graphique A partir d objets graphiques : même problème que précédemment. Modèles pour le client serveur 70

71 Illustration gestion de documents composites OLE/COM : Objects Linking and Embedding Component Object Model Opendoc : Incorporation (embedding) Document 3 (texte) Lien vers document 1 Copie de document 3 Lien vers document 2 Document 1 (image) Liens (linking) Document 2 (tableau) Document composite Modèles pour le client serveur 71

72 Client serveur à composants : la vision actuelle (1) Quelques idées pour une notion de composant qui diffère du modèle objet réparti. 1 Composant : une unité de code de taille significative Idée assez souvent reprise bien qu un peu controversée. 2 Composant : une unité de réutilisation et d intégration Réutilisation : code (binaire) existant à intégrer dans une application. Notion de composant sur étagères. COTS : Components Off The Shelf. Intégration : rajouter de la glu. ADL : Architecture Definition Language. Modèles pour le client serveur 72

73 Client serveur à composants : la vision actuelle (2) 3 Composant :une unité d administration en réparti Déploiement : Un code développé pour un environnement système et qui doit retrouver pour son exécution cet environnement (conteneur). Suivi : du fonctionnement du composant. 4 Composant: pour associer des propriétés non fonctionnelles à un code Code de base : pour un environnement donné, doit être adapté pour supporter un autre environnement : pannes, temps réel, Propriétés non fonctionnelles : ajoutées à la sémantique fonctionnelle du service. Persistance : service transactionnel. Echéances : QOS temps réel, Sécurité : authentification des clients et autorisation des accès. Modèles pour le client serveur 73

74 Composants : Les avantages attendus La possibilité de construire des logiciels par assemblage de composants commerciaux. Réutilisation de logiciels existants testés. Amélioration de la modularité et des interfaces. Cycle de développement raccourci. Extensibilité en exécution ( Run-time ) des applications basées composants. Des systèmes plus maintenable. Amélioration des moyens de communication. Construction de systèmes plus portables. Des modèles de développements logiciels plus abstraits (scripts langages ADL) Modèles pour le client serveur 74

75 ENVIRONNEMENT A COMPOSANTS, EXEMPLE : CCM CORBA COMPONENTS MODEL Un apport important de CORBA 3 qui étend sur différents points le modèle objet réparti. CORBA extensions CIDL Component Implementation Definition Language Notion de ports facettes, réceptacles, sources et puits d événements, attributs. Pour définir un graphe de connexions. - Interfaces multiples. - Interfaces offertes (réceptacles) et demandées (clauses use et provide) Un service de configuration de composants - Notion d attributs Modèles pour le client serveur 75

76 Fonctionnalités CCM Un service d événements prévu d emblée Notification Service (modèle push) Une standardisation du cycle de développement CIF Component Implementation Framework Une standardisation du cycle de déploiement Notion de conteneur : gère un composant selon ses besoins. - Une vue unifiée pour le composant de l environnement en exécution. - Interfaces offertes aux composants pour les services CORBA (minimum POA et ORB, autres services persistance, sécurité, selon besoins). Une proposition qui récupère la base objets répartis CORBA existante Modèles pour le client serveur 76

77 Client serveur à composants : Conclusion Avantages Un objectif atteint: offrir des solutions à quelques problèmes bien identifiés de l approche objets répartis en insistant d abord et avant tout sur la réutilisation. Inconvénients De nombreux problèmes restent posés - Courtage : Retrouver un composant en fonction de ses propriétés syntaxiques mais aussi sémantiques pour apparier les interfaces demandées et offertes, les besoins systèmes et les conteneurs. - Cadre pour l adaptation des composants à des environnements quelconques : programmation par aspects. - Faiblesse de la réflexion d ensemble sur la répartition. Modèles pour le client serveur 77

78 MODELES CLIENT SERVEUR A CODE MOBILE Modèles pour le client serveur 78

79 Code Mobile : Généralités Assurer les interactions distantes en déplaçant le code à exécuter. Exemples : requêtes SQL, applet Java, sérialisation d objets JAVA Motivation essentielle Rapprocher les traitements des données pour réduire le volume des échanges. Nombreux exemples évoqués - Collecte d informations disséminées dans un réseau (recherche et filtrage). - Surveillance de données. - Administration de réseaux. - Reconfiguration, Placement. - Réseaux actifs. - Distribution d informations ciblées. - Applications orientées flots de données ( workflow ). - Négociation (agendas, commerce électronique, enchères, ). - Calcul parallèle (envoi de calculs). - Jeux en réseaux. Modèles pour le client serveur 79

80 Code Mobile : Nombreux problèmes Interopérabilité des codes exécutables : - Mêmes architectures machines, mêmes environnements systèmes - Utilisation d interpréteurs dans les mêmes environnements. Sécurité (avec méfiance mutuelle) - du site acceptant du code. - De l agent mobile Structuration des applications à base de code mobile : Intégration avec d autres approches du client serveur. Transparence de la programmation en code mobile? Partage des ressources Quelle cohérence? Que déplace t on?comment? Migration faible/forte? Modèles pour le client serveur 80

81 Code Mobile : Modèles d exécution pour la mobilité - Code à la demande. Mobilité Faible. On bouge du code sans contexte variable (Exemple : applet java) Site A Code Site B Processus Code - Agents Mobiles. Mobilité Forte. On bouge du code exécutable, des données locales, un contexte d exécution Site A Processus 1 Code, CTX Site B Processus 2 Code, CTX Modèles pour le client serveur 81

82 Code Mobile : Etude de la mobilité forte Notions utilisées Objets: les unités de codes exécutables (clients et serveurs) (objets passifs). Sites : environnements d exécution. Activités: flots de contrôle des appels s étendant sur plusieurs objets ou sites. Domaines : ensembles de droits sur des ressources d une machine (en particulier sur des segments de mémoire). Base de la classification - Les activités sont dans le même domaine. - Les activités sont dans des domaines différents du même site. - Les activités sont dans des domaines différents de sites différents. Modèles pour le client serveur 82

83 Types de partage Partage dans le même domaine - Réalisé systématiquement (notion de grappe, cluster d objets). Partage entre domaines différents - Opération de changement de domaine. - Mécanisme de couplage entre domaines et objets. Partage en exclusion mutuelle - Une seule activité est autorisée à un instant donné à utiliser un objet - Agréable pour assurer la cohérence de sérialisation des objets. Partage avec réplication - Nécessité de mise en œuvre d une stratégie de cohérence par l application entre les différentes copies. Modèles pour le client serveur 83

84 Partage par migration en exclusion mutuelle N autoriser le partage que sur un seul site. => Exclusion mutuelle entre les sites ayant accès à l objet. => Mécanisme de déplacement des objets ou des activités. Migration des activités - Une activité voulant accéder à un objet déjà couplé sur un autre site change de site. - On effectue alors un partage d accès entre activités sur le même site (même domaine ou domaines différents). Migration des objets - Une activité voulant accéder à un objet d un autre site demande le découplage de l objet (opération de fermeture nécessaire si l objet est en cours d accès). - L objet est déplacé sur le site client. - L objet est couplé sur le site client. Modèles pour le client serveur 84

85 Partage par réplication - Autoriser la possibilité le couplage d un même objet sur plusieurs sites en même temps. - Assurer la cohérence entre les versions des objets qui permet aux applications utilisatrices de fonctionner correctement. a) Les problèmes de cohérences sont vus au niveau applicatif : détection des lectures et des écritures dans les variables partagées à la compilation => Appel à un code de mise en œuvre d une cohérence de partage. b) Les problèmes de cohérence sont vus au niveau des accès mémoire : plus facile en exécution à l aide des outils de détection matériels. => Le partage est vu au niveau de la mémoire physique (approche de mémoire virtuelle partagée répartie). Modèles pour le client serveur 85

86 ENVIRONNEMENTS A CODE MOBILE, EXEMPLE : LES AGLETS Une extension proposée par IBM Japon qui étend le modèle des applets Java. - Comme une applet une aglet permet la transmission d un code Java. - L API Aglet permet également le transport de l état (en fait une partie). - La gestion de la sécurité est renforcée par l utilisation par les aglets d un gestionnaire de sécurité spécifique. Modèles pour le client serveur 86

87 Le cycle de vie d une aglet Created: création : initialisation de l état, lancement des activités threads. Cloned: duplication : l état courant original d une aglet est dupliqué dans un clone). Dispatched: Une aglet migre sur un autre hôte avec son état. Retracted: Une aglet ayant migré est ramenée du site distant avec son état. Deactivated: Une aglet est mise en sommeil : son état est stocké sur disque. Activated: Une aglet désactivée est réctivée : son état est restauré partir du disque. Disposed of: Une aglet est détruite : son état est perdu. Modèles pour le client serveur 87

88 Migration d une aglet Mécanisme de sérialisation Java (JDK 1.1) Un objet Java appartenant à une aglet est transmis d un site à un autre au moyen du mécanisme de sérialisation : transformation en une suite d octets et opération inverse. Sérialisation d une aglet - Sérialisation d un objet Java de base associé à l aglet. - Sérialisation de l arbre des objets Java formant l aglet. - Sérialisation d une partie du contexte. Image du tas dans sa partie données. Pas de sérialisation du pointeur d exécution courant, ni de la pile (difficultés techniques liées à la JVM). => Pas tout à fait encore complet. => Tout ce que l on veut envoyer doit être placé manuellement dans le tas au moment de la migration. Modèles pour le client serveur 88

89 L API Aglets Cinq classes standards peuvent être redéfinies pour adapter l aglet lors d une opération de migration: oncloning() : appelé avant clonage ondispatch() : appelé avant migration. OnReverting(): appelé avant retraction. ondeactivating() : appelé avant la désactivation. ondisposing() : appelé avant la destruction. Les points d entrées correspondants sont : clone(), dispatch(), retract(), deactivate(), dispose(). Lors d une initialisation, on exécute selon les cas run()de la classe. oncreation() : la première fois onclone() : lors d un clonage onarrival() : lors d une migration ou d un retour onactivation() : lors d une activation. Modèles pour le client serveur 89

90 Code Mobile : Conclusion - Des avantages indiscutables pour le client serveur dans certaines circonstances : besoin de dynamicité, d adaptabilité, Possibilité d exécution à distance Code à la demande - Un domaine très porteur Nombreux prototypes de recherche Concepts et mécanismes encore en cours d étude. - Des problèmes non résolus Sécurité. Environnements de développement. Des applications à réaliser. Modèles pour le client serveur 90

91 MODELES CLIENT SERVEUR A MEMOIRE PARTAGEE REPARTIE Modèles pour le client serveur 91

92 Mémoire partagée répartie: Généralités Réalisation des interactions distantes en mémoire commune répartie comme espace de communication. Exemples Opération read et write sur des pages. Exemples : treadmarks, Modèles à espaces de tuples Exemples : BD réparties, javaspaces Modèles à espaces d objets répartis partagés. Motivation essentielle Offrir à un développeur les conditions de travail de l univers centralisé : programmation de la coopération par variables partagées masquant les difficultés de la répartition. Modèles pour le client serveur 92

93 Mémoire partagée répartie : Les problèmes principaux Performance des implantations. Support des diverses cohérences. Cohérences fortes Atomique, séquentielle Cohérences faibles Causale, relachée. Support des outils de développement existants : langages, compilateurs, dévermineurs. Modèles pour le client serveur 93

94 Mémoire partagée répartie : principes de réalisation Une simulation d un espace mémoire unique dans un ensemble d espaces mémoires réels distribués. Site A Mémoire Objet 1 Site B Mémoire Objet 3 Espace virtuel commun Objet 1 Objet 2 Objet 3 - Espace d objets répartis partagés. - Interface d accès commune (nommage, invocation des méthodes, ) - Mode de réalisation par projection de l espace virtuel partagé dans l espace mémoire réel des différents sites. Modèles pour le client serveur 94

95 ENVIRONNEMENTS MEMOIRE PARTAGEE REPARTIE, EXEMPLE : JAVASPACES - Un javaspace : un espace de tuples ou entrées. - Une entrée : un ensemble de références à des objets Java. JAVASPACE Références Entrée Modèles pour le client serveur 95

96 Javaspaces : les opérations de base - Ecriture dans un javaspace (read). - Lecture dans un javaspace (write) - Retrait dans un javaspace (take) - Notification de l écriture d une entrée (notify). - Transaction regroupant plusieurs opérations dans plusieurs javaspaces (respect des propriétés ACID). Cohérence transactionnelle (de sérialisation) Persistance transactionnelle (technique de validation). Modèles pour le client serveur 96

97 Javaspaces : les techniques d utilisation - Pas de modifications sur les données : on ajoute ou on retire des références. - Coopération entre applications réparties pour connaître des références (mécanismes d accès au moyen de templates, des modèles pour la recherche d entrées). Découplage entre client et serveur. - La sérialisabilité transactionnelle garantit la cohérence des accès. - Le partage des objets réels s effectue ensuite au moyen de l invocation de méthodes (RMI). - Les objets réels peuvent être dupliqués. Tout reste à construire (cohérence) dans le partage des objets réels. Modèles pour le client serveur 97

98 Mémoire partagée répartie: Conclusion Avantages - Facilité de développement d une application répartie ou de portage d une application centralisée en univers réparti. - Performances excellentes lorsque l objet est chargé localement. Inconvénients - Performances mauvaises lorsque l objet est distant (les cohérences fortes sont très coûteuses en réparti). - Les cohérences faibles sont plus performantes mais délicates d emploi. - L approche est très peu ouverte un seul langage interprété ou une seule forme de présentation des données sinon il faut en plus convertir les données à chaque déplacement. Modèles pour le client serveur 98

99 Conclusion : Modèles et outils de programmation pour le client-serveur Modèles pour le client serveur 99

100 Problème majeur pour le développeur d applications: quel modèle, quel outil Une très grande variabilité de l offre aussi bien sur le plan des modèles que sur celui des plateformes. - Mode de synchronisation distante : synchrone ou asynchrone. - Approche langage ou système effort de développement complexité du système produit. - Développement d un nouveau code pour le réparti ou intégration des solutions centralisées existantes. - Granularité des codes communicants grain moyen in the small : objet réparti gros grain in the large : composants. Modèles pour le client serveur 100

101 Bibliographie Références générales R. Balter Modes de structuration d applications réparties. Cours de l école d été : Construction des applications réparties. G.Gardarin, O. Gardarin. le client serveur Eyrolles 1996 R. Orfali, D. Harkey, J. Edwards Client serveur guide de survie Wiley Modèles à messages et à événements htttp:// Modèles à RPC et à Objets Modèles pour le client serveur 101

102 Bibliographie (suite) Modèles à code mobile D. Hagimont, J. Mossière Problèmes de désignation, de localisation et d accès dans les systèmes répartis à objets TSI 15(1) 1996 Sacha Krakowiak Code mobile, Principes et mise en œuvre Cours de l école d été : Construction des applications réparties. J.E. White, Telescript Technology: The Foundation for the Electronic Market-place, General Magic Inc., Mountain View, CA, Modèles pour le client serveur 102