Systèmes Distribués Philippe Truillet IRIT/ CENA

Présentation au sujet: "Systèmes Distribués Philippe Truillet IRIT/ CENA"— Transcription de la présentation:

1 Systèmes Distribués Philippe Truillet IRIT/ CENA

2 Plan Rappel : Modèle OSI de l’ISO Modèle Client-Serveur
Ex : protocole http Systèmes Distribués COM, CORBA, RMI, Ivy

3 Définitions Open Systems Interconnexion de l’International Standardization Organisation Système ouvert : se dit d’un système informatique qui désire échanger des données avec un autre

4 Qui, Quoi, Pourquoi ? Émanation de l’ Union Internationale des
Télécommunications ISO

5 Principes de normalisation
Constructeur > équipement > fonctions publications de travaux norme “de fait” proposition des travaux pour une normalisation ([inter]nationale) modifications mineures spécifications normalisées

6 Qui, Quoi, Pourquoi ? Modèle normalisé pour faciliter les échanges de données entre systèmes ouverts

7 Avis (recommandations) de l’UIT ou de l’ISO (ex : X.224, ISO 8073)
Qui, Quoi, Pourquoi ? norme de structure (nombre de couches, rôles, …) norme de services (fonctions rendues) normes protocolaires Avis (recommandations) de l’UIT ou de l’ISO (ex : X.224, ISO 8073)

8 Modèle OSI º Boîte à outils
Qui, Quoi, Pourquoi ? Expliquer simplement, logiquement, de manière structurée comment les échanges de données peuvent s’effectuer entre systèmes ouverts à travers un réseau Modèle OSI º Boîte à outils

9 L’analogie slip chaussettes maillot de corps chemise pantalon pull
chaussures sol

10 Le Modèle OSI Processus applicatif Nom Niveau Rôle Services Couche 7
Protocoles Couche 7 Couche 6 Couche 5 Couche 4 Couche 3 Couche 2 Couche 1 Ligne de transmission

11 Comment ça marche ? Principe de l’encapsulation des données Exemple :

12 Les couches du modèle

13 Les couches du modèle Couches hautes (5 à 7)
interfaces utilisateur, niveau stations émettrices et réceptrices Couches intermédiaires (3, 4) recherche d’un chemin, fiabilité du chemin Couches basses (1, 2) : normes associées aux réseaux locaux

14 Circulation verticale des données
Chaque couche s’interface avec les couches adjacentes une couche N-1 rend des services à la couche N (ex : la couche 3 rend un service d’acheminement des paquets dans le réseau à la couche 4)

15 Protocol Data Unit

16

17 Liaison entre 2 équipements

18 Acheminer les bits sur un support de transmission physique
Couche 1 : physique Acheminer les bits sur un support de transmission physique mise du signal en série synchronisation du signal gestion du dialogue entre DCE et DTE adaptation du signal au support

19 Ethernet IEEE 802.3 écoute du média
attente éventuelle tant que le média n’est pas libre émission délai entre les trames : 96 bits-time (pour un débit de 10 Mb/s, bit-time = 0,1 micro-seconde)

20 utilisation d’un Transceiver
Ethernet : collision utilisation d’un Transceiver détection de la collision arrêt de l’émission attente émission

21 Couche 2 : liaison de données
Assurer le transfert de blocs de données entre équipements directement connectés avec un taux d’erreur résiduel négligeable formatage d’une trame assurance de la transparence du protocole contrôle des erreurs de transmission gestion du dialogue

22 Couche 2 : liaison Chaque réseau (Ethernet, …) est une solution particulière au problème de l’accès au média Réseau LLC 802.2 MAC 802.3 802.4 802.5 X3T9.5 Physique

23 Modèle 802.x : scinde la couche en 2 :
Couche 2 : liaison Ethernet (CSMA/CD) IEEE 802.3 Token Bus IEEE 802.4 Token Ring IEEE 802.5 FDDI ANSI X3T9.5 Modèle 802.x : scinde la couche en 2 : LLC (Logical Link Control) MAC (Medium Access Control)

24 Couche 2 : liaison LLC (IEEE 802.2) : interface homogène
MAC : gère et attribue à chaque instant le droit de parole

25 Couche 3 : Réseau Offrir les moyens d’accéder à un réseau et les procédures pour acheminer les données établissement d’une connexion gestion d’un format d’adresse gestion de la fragmentation gestion des priorités d’acheminement

26 Couche 3 : Réseau Datagramme : paquets indépendants
Circuit virtuel : chemin unique le choix a des conséquences sur la couche 4 (ordonnancement des paquets) ex : X.25 : mode connecté, circuits virtuels IP : datagramme non connecté

27 Assurer le contrôle de bout en bout à travers les réseaux empruntés
Couche 4 : Transport Assurer le contrôle de bout en bout à travers les réseaux empruntés connexions entre processus contrôle de flux

28 Couche 4 : Transport Transport des messages de bout en bout
modes connectés / non connectés Complément de service / aux couches 1, 2 et 3 (classes 0 à 4) niveaux de services (0 : simple ; 4 : sophistiqué)

29 Couche 4 : Transport Fragmentation Multiplexage Assemblage
Contrôle de flux Reprise sur erreur signalée Fragmentation Assemblage 2 1, 2, 3 : réseau fiable et sans erreur 4 : réseau peu fiable 1 Multiplexage 3 4 Reprise sur erreur non signalée

30 Gérer le dialogue entre entités applicatives
Couche 5 : Session Gérer le dialogue entre entités applicatives gestion du dialogue synchronisation du dialogue

31 è RPC (Remote Procedure Call) ç
Couche 5 : Session Initialisation de la communication : ouverture session transfert données fermeture session è RPC (Remote Procedure Call) ç couche souvent absente

32 Couche 6 : Présentation Assurer l’adaptation des données entre les systèmes hétérogènes — Gérer la représentation des données négociation de la syntaxe de transfert confidentialité

33 ASN.1 (Abstract Syntax Notation 1)
Couche 6 : Présentation Représentation des données ASN.1 (Abstract Syntax Notation 1) Compression en pratique, au niveau des couches 2, 3, 4 Sécurité, Confidentialité DES (Data Encryption Standard) couche souvent absente ou peu importante

34 Rendre des services génériques aux applications
Couche 7 : Application Rendre des services génériques aux applications

35 Fonctions de communication
Couche 7 : Application Fonctions de communication Transfert de fichiers (norme FTAM (File Transfert Access et Management), FTP) Messagerie électronique (X400, X500, SMTP) Emulation de terminal virtuel (VTS (Virtuel Terminal Service), Telnet)

36 Architecture Client-Serveur

37 Client/Serveur (1) Les Serveurs
On appelle logiciel serveur un programme qui offre un service sur le réseau. Le serveur accepte des requêtes, les traite et renvoie le résultat au demandeur. Le terme serveur s’applique aussi à la machine sur lequel s’exécute le logiciel serveur. Pour pouvoir offrir ces services en permanence, le serveur doit être sur un site avec accès réseau permanent et s’exécuter en permanence (daemon - suffixe d pour le nom du logiciel ex : ftpd). Les Clients On appelle logiciel client un programme qui utilise le service offert par un serveur. Le client envoie une requête et reçoit la réponse. Le client peut-être raccordé par une liaison temporaire (liaison modem par exemple).

38 Client/Serveur (2) Architecture client/Serveur
C’est la description du fonctionnement coopératif entre le serveur et le client. Les services Internet sont conçus selon cette architecture. Ainsi, chaque application est composée d’un logiciel serveur et d’un logiciel client. A un logiciel serveur, peut correspondre plusieurs logiciels clients développés dans différents environnements : Unix, Mac, PC... ; la seule obligation est le respect du protocole entre les deux processus communicants. Ce protocole étant décrit dans une RFC (Request For Comment).

39 Client/Serveur (3) Identification d’un service
Un site peut offrir plusieurs services. Chacun de ces services est fourni sur un port de communication identifié par un numéro. Ce numéro identifie le service quelque soit le site (ex : le service FTP est offert sur le port numéro 21, Telnet sur le port 23...).

40 Protocole http (1)

41 Protocole http (2) Connexion
   Connexion Le client ouvre une connexion TCP-IP en indiquant le nom de domaine ou l’adresse IP de l’hôte ainsi que le numéro de port. Si le numéro de port n’est pas spécifié, le numéro de port 80 est utilisé. Le serveur accepte la connexion. 

42 Protocole http (3) Requête
La requête est lancée avec une première ligne contenant la méthode à appliquer à l’objet demandé. Request = Simple Request | FullRequest SimpleRequest = GET <uri> CrLf FullRequest = Method <uri> ProtocolVersion CrLf ProtocolVersion = HTTP/V1.1 …

43 Protocole http (4) Réponse
La réponse à un GET est un message en HTML : c’est un flot de données en caractères ASCII. Le message se termine par la fermeture de la connexion par le serveur.  La réponse du serveur commence avec la syntaxe suivante :  <status line> ::= <version http> <code statut> <raison> De l’information peut suivre en format MIME. La signification de ces données dépend du code statut. (2xx : succès, 4xx : codes d’erreur, …)

44 Protocole http (5) Déconnexion
La connexion TCP-IP se termine quand le document entier a été transféré. Le client peut cependant terminer le transfert quand il le souhaite.

45 Systèmes répartis La distribution d’objets est un concept qui permet à des objets d’être utilisables à travers des réseaux hétérogènes par d’autres objets distants

46 Systèmes répartis : avantages
Les programmeurs peuvent distribuer les objets qui forment une application sur des ordinateurs optimisés pour l’utilisation de ces objets sans avoir à changer l’application. Comme les objets distribués apparaissent comme étant locaux, l’utilisateur de ces objets ne sait rien sur l’ordinateur distant qui les exécute. Le but des systèmes distribués est de rendre le traitement de l’information plus efficace et plus flexible sans être plus complexe. Les systèmes distribués répondent aux problèmes posés par les architectures lourdes client/serveur.

47 Objet C'est l’encapsulation au sein d'une même entité des données et des traitements. L’objet est manipulable, dans son contexte, au travers de son interface

48 Objet distribué Les services offerts par l’objet sont accessibles indépendamment de sa localisation

49 COM COM fournit la technologie composant pour les architectures d’applications distribuées Windows de Microsoft (Windows DNA). Ces architectures permettent d’intégrer des applications web client/serveur dans une architecture unique et unifiée. En utilisant COM, les développeurs peuvent créer des composants distribués écrits dans n’importe quel langage et qui inter-agissent à travers n’importe quels réseaux.

50 CORBA : Origines L’Object Management Group
né en avril 1989 (Helwett Packard, Sun, Canon, American Airlines, Unisys, Philips, 3COM,…) Buts de l'OMG But principal  promotion de la “technologie objet”. Modèle de référence de l’OMA (Object Management Architecture) Ce modèle fournit la trame qui aspire à la philosophie de la technologie objet vue par l'OMG.

51 CORBA CORBA (Common Object Request Architecture)
CORBA définit précisément l’architecture des environnements basés sur un ORB (Object Request Broker, courtier en requêtes sur les objets).

52 CORBA et OSI (1) Situé au niveau de la couche application (couche 7).
fournit une architecture client/serveur “cache” au client l'hétérogénéité du système informatique, permet au programmeur de faire abstraction des couches les plus basses ; peu importe où est le serveur, quels sont son état, son processeur et son système d’exploitation.

53 CORBA et OSI (2) Les objets se découvrent mutuellement a l'exécution et peuvent invoquer leurs différentes fonctions. Un constructeur de systèmes devrait pouvoir sélectionner des objets venant de vendeurs différents et les connecter facilement

54 CORBA : ORB L‘ORB (Object Request Broker) fournit les mécanismes d'échanges transparent de requêtes et de réponses. C'est en fait un bus de communication logiciel. Les Object Services forment un ensemble de services optionnels qui peuvent être utilisés dans certains environnements objets. Les common facilities sont les services les plus utilisés dans les environnements. Les application objects sont les objets spécifiques d'une application.

55 Rôle de l’ORB L’ORB (Object Request Broker, courtier en requêtes d’objet en français) doit : trouver le lieu où l'objet est implémenté préparer l'objet à recevoir la requête transférer les données de la requête du client au serveur transmettre la réponse ou une exception au client.

56 Structure de l’ORB

57 L’ORB et ses interfaces

58 Composants Techniques (1)
IDL (Interface Definition Language) définit les types des objets manipulés par l’ORB en spécifiant leurs interfaces. est le moyen par lequel une implémentation d’objet précise à ses clients potentiels quelles opérations sont disponibles et comment les invoquer.   Les clients ne sont pas implémentés en IDL mais dans leur propre langage (généralement le langage C) appelé language mapping.

59 Composants Techniques (2)
L’interface ORB Cette interface fait directement appel à l’ORB. Elle est la même pour tous les ORB et ne dépend ni des interfaces ni de l’adaptateur d’objet. En fait, la plupart des fonctionnalités de l’ORB sont fournies par l’adaptateur d’objet, les souches IDL, les squelettes IDL et le DII. Seules quelques rares opérations sont communes à tous les objets. Cette interface est donc rarement utilisée.

60 Composants Techniques (3)
Trois catégories d’interfaces de l’ORB : les interfaces pour les opérations identiques pour toute implémentation de l’ORB (DII, interface ORB) les interfaces pour les opérations spécifiques à un type d’objet particulier (souche et squelette IDL) les interfaces pour les opérations spécifiques à des styles particuliers d’implémentation d’objets

61 Les entrepôts (1) L’entrepôt d’interface
C’est un service qui fournit des objets persistants représentés par de l’information IDL disponible à l’exécution. L’ORB doit avoir accès à la définition de l’objet qu’il gère ; cela peut se faire de deux façons : L’information est contenue dans la requête L’ORB prend cette information dans l’entrepôt d’interface

62 Les entrepôts (2) L’entrepôt d’implémentation
Il contient les informations qui permettent à l’ORB de localiser et activer les implémentations d’objet Cet entrepôt contient aussi des informations supplémentaires concernant les implémentations, comme par exemple des informations sur le debugging, la sécurité,...

63 Côté Serveur L’implémentation de l’objet Le squelette IDL
Elle fournit la sémantique de l’objet (données pour l’objet et code pour ses méthodes). Le squelette IDL C'est l’interface pour l’accès aux méthodes qui implémentent l’objet. L’existence d’un squelette IDL n’implique pas obligatoirement l’existence d’une souche IDL associée. Le squelette IDL est différent pour chaque type d’objet. L’adaptateur d'objets Il adapte la référence d’objet à l’objet.

64 Côté Client La souche IDL
Les souches IDL font des appels aux autres éléments de l’ORB en utilisant des interfaces qui lui sont privées. La DII (Dynamic Invocation Interface, interface d'invocation dynamique) La DII, comme son nom l’indique, permet la construction et l’invocation dynamique des requêtes d'objet. L’interface ORB Cette interface fait directement appel à l’ORB.

65 Requêtes CORBA (1) Pour effectuer une requête, le client doit :
avoir accès à une référence de l’objet connaître le type de l’objet connaître le type d’opération à effectuer

66 Requêtes CORBA (2) Trois types de requêtes :
par le DII (Dynamic Invocation Interface), qui est totalement indépendant de l’objet cible et reste le même quelle que soit l’implémentation de l’ORB. par la souche IDL. La souche IDL dépendante du squelette IDL (interface de l’implémentation de l’objet cible). en appelant directement l’ORB (par l’interface ORB) pour certaines fonctions spéciales.

67 Requêtes CORBA (3) Exécution de la requête :
L’ORB situe le code nécessaire à la satisfaction de la requête, et la transmet avec ses paramètres au squelette IDL. Pendant le traitement de la requête, le code qui implémente l’objet peut faire appel à des services de l’ORB via l’adaptateur d’objet. L’implémentation de l’objet peut choisir quel adaptateur d'objet à utiliser. Cela dépend du type de service dont elle a besoin. Quand le traitement de la requête est fini, les valeurs de sortie sont renvoyées au client.

68 RMI Remote Method Invocation (RMI) système d’objets distribués de JAVA
fournit des mécanismes pour pouvoir invoquer à partir d’une JVM des Objets résidents dans une autre JVM.  Les objets ainsi distribués se comportent comme des objets locaux (appel de méthodes et autres manipulations…) alors qu’ils sont distants.

69 RMI

70 Composants Techniques (1)
Sérialisation permet de transformer un objet en tableau d’octets qui pourra être stocké, envoyé, transmis…puis retransformé en objet

71 Composants Techniques (2)
Stub et Skeleton   Lors d’un appel d’objet distribué, le serveur envoie non pas une copie de l’objet mais un objet spécial appelé “Stub”. Ce Stub communique avec un objet sur le serveur appelé “Skeleton”.  Stub et Skeleton se chargent de la communication entre client et serveur, de façon transparente pour les utilisateurs.

72 Composants Techniques (3)
Interface    L’utilisation des objets partagés n’est possible que si client et serveur voient la même définition d’un objet. Utilisation d’interfaces (définitions des méthodes et attributs d’un objet). Le serveur implémente cette interface Le client la liera avant d’invoquer l’objet distant.  Ainsi le client ne pourra utiliser que des méthodes qui existent sur le serveur.

73 Ivy (CENA)

74  http://www.tls.cena.fr/products/ivy
Ivy Bus logiciel basé sur la notion de souscription à des messages 

75 Ivy Implémenté dans plusieurs langages sur de multiples plateformes.
 Langage C (Unix and Windows), C++ (Mac, Unix, Windows), Java and Perl. Messages formatés en texte, souscription basée sur des expressions régulières. Quelques fonctions : Connexion à un bus IvyInit (b, “ :2011”) Envoyer un message IvySend (b, "HELLO %s", world)