Ce document intitulé "Développement d'Applications Réparties" est destiné aux étudiants de Master 1 Réseaux et Systèmes Distribués de l'Université Abdelhamid Mehri – Constantine 2. Il couvre les caractéristiques et défis des systèmes distribués, incluant la concurrence, la transparence, l'hétérogénéité, l'ouverture, la sécurité, la scalabilité et la gestion des fautes.
Il explore également les applications réparties, leurs contraintes et les axes de recherche actuels dans ce domaine.
Cours Développement Applications Réparties -Développement d'applications réparties
Télécharger PDFCaractéristiques et défis des systèmes Distribués
Concurrence
Les éléments formant le système s'exécutent en parallèle et de manière autonome. Les problèmes de fiabilité en nombre accru, problème matériel d'une machine, problème de communication via le réseau, problème logiciel sur un des éléments du système. La communication est un point déterminant, potentiellement non fiable, avec des temps de communication non négligeables. Par exemple, lors d'enchères, plus la fin approche, plus il y a de requêtes. Les opérations doivent s'entrelacer dans le bon ordre. Donc, des mécanismes de synchronisation sont nécessaires pour mettre en œuvre la concurrence.
Transparence
C’est le fait pour une fonctionnalité, un élément d'être invisible ou caché à l'utilisateur ou un autre élément formant le système distribué. Le but est de cacher l'architecture, le fonctionnement de l'application ou du système distribué pour apparaître à l'utilisateur comme une application unique cohérente. Le système est perçu comme un tout plutôt que comme une collection de composants indépendants. L'ISO définit plusieurs transparences (norme RM-ODP ?) : accès, localisation, concurrence, réplication, mobilité, panne, performance, échelle. Un bon système distribué est un système qui "à l'air centralisé" (paradoxe). Afin de simplifier l'effort de programmation dans une application répartie, il vaut mieux masquer le plus possible les propriétés délicates de la répartition. Mais, il est impossible d'être transparent sur tous les aspects. Les propriétés de transparence incluent : transparence d'accès, transparence de localisation, transparence du partage, transparence de la réplication, transparence des fautes, transparence de la migration, transparence de charge, transparence d'échelle. L’idée est de masquer la répartition.
Hétérogénéité
On peut trouver l’hétérogénéité à différents niveaux : niveau des réseaux, niveau du matériel informatique, niveau des systèmes d’exploitation, niveau des langages de programmation, niveau des implantations. Comment maîtriser l’hétérogénéité ? Middleware : est une couche logicielle qui masque l’hétérogénéité des réseaux, matériels, systèmes d’exploitation et langage de programmation. CORBA : Common Object Request Broker Architecture - Java RMI. Code mobile : Code qui peut être transmis d’un ordinateur à l’autre et exécuté à la destination (ex: applets). Machine virtuelle : une façon de faire en sorte que le code soit exécutable indépendamment du matériel (ex: Java).
Ouverture
Un système distribué ouvert est un système qui offre des services selon des règles standards de description de la syntaxe et la sémantique de ces services. Un système d’information réparti est ouvert s’il peut être étendu par (extensibilité) : l’ajout d’ordinateurs au réseau (Matériel), l’ajout de nouveaux services, la ré-implémentation de services existants (indépendance des vendeurs).
Sécurité
Sécurité des interactions (Encryptage). Transmettre de l’information sensible dans un message qui voyagera sur un réseau. S’assurer de l’identité de l’émetteur d’un message. Sécurité contre les dénis de service. Perturbation d’un service. Sécurité du code mobile.
Scalability (Passage à l’échelle)
L'évolutivité d'un système peut être mesurée selon au moins trois dimensions différentes. Un système peut être évolutif en ce qui concerne sa taille, ce qui signifie que nous pouvons facilement ajouter plus d'utilisateurs et de ressources au système. Un système géographiquement évolutif est un système dans lequel les utilisateurs et les ressources peuvent être très distants. Un système peut être évolutif d’un point de vue administratif, il peut toujours être facile à gérer même s’il appartient à de nombreuses organisations administratives indépendantes. Malheureusement, un système évolutif dans une ou plusieurs de ces dimensions présente souvent une perte de performance à mesure que le système évolue.
Gestion des fautes
Fautes dans le matériel ou le logiciel : résultats erronés, arrêt du programme avant d’avoir terminé son calcul. Fautes dans un système réparti sont partielles : un composant peut faillir alors que les autres vont continuer à fonctionner.
Récap
La plupart des applications informatiques sont devenues réparties : exemple… Besoins propres des applications, communication, coopération, partage d’information, accès à des ressources distantes, répartition intrinsèque des applications, possibilités techniques (offertes), coût et performances des machines et des communications (accessible). Interconnexion généralisée : interpénétration Informatique-télécom-télévision, les applications informatiques utilisent les technologies télécom, les réseaux de télécom sont des systèmes informatiques, la télévision devient numérique et interactive. Exemple : Télévision Interactive, lancement d’une application.
Remarques (sur l’exemple)
Contraintes d’une application grand public : disponibilité du service : duplication active/passive, reprise, performances : bon dimensionnement, répartition de charge, simplicité de l’interface : terminal TV, passage à l’échelle : évolution incrémentale. Génie logiciel d’une grande application répartie : organisation client/serveur, modèle objets, utilisation systématique de l’IDL(langage de description d’interface), service de noms évolué & capacité d’évolution.
Axes de recherche des applications réparties
Par la Théorie
Pour bien comprendre la problématique de la répartition, il est important de pouvoir modéliser le plus formellement possible sa sémantique. Il s’agit donc d’élaborer des modèles de calcul traduisant de façon abstraite et formelle (mathématique) les propriétés d’un calcul réparti : algèbre de processus communicant, logiques pour la description des propriétés.
Par l'algorithmique
L’écriture d’algorithmes adaptés à une architecture répartie soulève des problèmes algorithmiques spécifiques qui ont pour origine les deux hypothèses « perdues » (détecter !!!). Pour pouvoir coopérer via des échanges de messages, une activité importante est de : définir des protocole de communication (point à point ou à diffusion), utilisation des standards tel que : l'appel de procédure à distance appliqué au temps réel. Des problèmes plus généraux que l’on peut classer en deux catégories : hérité du monde parallèle : exclusion mutuelle, interblocage, atomicité, réplication, …, problèmes nouveaux : le problème de terminaison d'une application répartie, le calcul d'états globaux, la réalisation d'un consensus …
Par les langages de programmation
Développement d’API permettant d'échanger des messages. Exemple : sockets. Apparition de langages spécifiques (ex: OCCAM) ou extension de langage existant (ex: ADA). Possibilité de faire des appels de services à distance - pas de changement dans le modèle de programmation. - modèle aujourd'hui le plus utilisé est un modèle client serveur - définition d'un IDL, stub, skeleton.
Par les systèmes d'exploitation
2 approches : 1. Création de nouveaux noyaux dédiés à la répartition (il faut repartir à 0) : les micro-noyaux répartis. Exemple : le système CHORUS (Chorus distributed real time operating system) utilisé par (MATRA ALCATEL). 2. Etendre les systèmes d'exploitation centralisés : ajout de système de gestion de fichiers répartis (NFS, …), ajout de moyen de communication (sockets, RPC,…). Enfin, avec l'apparition de environnements d'exécution répartie (middleware) : (combinaison de langages et OS). Maîtriser l'hétérogénéité matérielle et logicielle : basé sur le schéma de communication client/serveur, basé sur la notion de "bus logiciel" : accès à des services spécifiés par leur interface, utilisation d'annuaire permettant de trouver les nœuds serveurs (ex CORBA).
FAQ
Qu'est-ce que la transparence dans les systèmes distribués ?
La transparence dans les systèmes distribués est le fait pour une fonctionnalité ou un élément d'être invisible ou caché à l'utilisateur ou à un autre élément du système. Cela permet de masquer l'architecture et le fonctionnement de l'application pour qu'elle apparaisse comme une application unique et cohérente.
Comment gérer l'hétérogénéité dans les systèmes distribués ?
L'hétérogénéité peut être gérée grâce à des solutions comme le middleware, qui masque l'hétérogénéité des réseaux, matériels, systèmes d'exploitation et langages de programmation. Des technologies comme CORBA, Java RMI, et les machines virtuelles (comme Java) sont également utilisées pour cette gestion.
Quels sont les défis de la scalabilité dans les systèmes distribués ?
Les défis de la scalabilité incluent la capacité à ajouter plus d'utilisateurs et de ressources, à gérer des utilisateurs et des ressources distants, et à maintenir la gestion administrative même avec de nombreuses organisations indépendantes. Cependant, un système évolutif peut souvent présenter une perte de performance à mesure qu'il grandit.