Figure 1. Structure répartie

Transcription

1 Chapitre I: Applications Réparties et Middleware 1. Définition d une application répartie Une application répartie est constituée d un ensemble de processus (d objets, d agents, d acteurs) s exécutant sur plusieurs sites et reliés par un réseau de communication. Ces processus : Communiquent entre eux via un réseau de communication Evoluent de manière cohérente Remplissent une fonction identifiable Ne sont pas forcément interdépendants Différent types de distribution existent : Distribution des données : données distribuées, traitement centralisé. Distribution du contrôle : données centralisées, contrôle distribué. Distribution des utilisateurs : données et contrôle centralisé, utilisateurs distribués. Une application distribuée est une combinaison de tout ces types de distribution. Figure 1. Structure répartie 2. Exemples d applications réparties Coordination d activités : Systèmes à flots de données («workflow»). Systèmes à agents. Communication et partage d informations : Bibliothèques virtuelles. Collecticiels : pour le travail coopératif, les bibliothèques, musées et magasins virtuels sur Internet, la presse et le commerce électronique, etc. Quelques exemples de collecticiels : o Édition coopérative. o Téléconférence. o Ingénierie concourante. Applications temps réel : Contrôle de procédés industriels. Avionique, etc. Localisation de mobiles. Toutes les applications qui nécessitent des utilisateurs ou des données réparties. III. Qualités requises dans les applications réparties 1. Qualité de service : Recouvre plusieurs notions, qui doivent être précisées au cas par cas. 1

2 Performance : Cette qualité couvre plusieurs aspects, qui sont essentiels pour les applications en temps réel (applications dont la validité ou l'utilité repose sur des contraintes temporelles). Certains de ces aspects sont liés a la communication (bornes sur la latence, la gigue, la bande passante) ; d'autres s'appliquent a la vitesse de traitement ou a la latence (temps de réponse) d'accès aux données. Tolérance aux pannes et aux fautes : Nécessité d identifier les scénarios de fautes possibles, qu elles soient : Matériel Logiciel Système de communication Sécurité : La sécurité couvre des propriétés liées à l'usage correct d'un service par ses utilisateurs selon des règles d'usage spécifiées. Elle comprend : la confidentialité, l'intégrité, l'authentification, et le contrôle des droits d'accès. 2. Capacité de croissance, ou passage a grande échelle : A mesure que les applications deviennent de plus en plus étroitement interconnectées et interdépendantes, le nombre d'objets, d'usagers et d'appareils divers composant ces applications tend a augmenter. Cela pose le problème de la capacité de croissance (scalability) pour la communication et pour les algorithmes de gestion d'objets, et accroît la complexité de l'administration. Ainsi, les qualités d un système ne doivent pas se dégrader en cas de croissance : Du nombre d éléments du système (machines, réseaux, etc.) Du nombre d utilisateurs De l étendue géographique 3. Capacité d évolution : Les systèmes logiciels doivent s'accommoder au changement. En effet, les spécifications évoluent a mesure de la prise en compte des nouveaux besoins des utilisateurs, et la diversité des systèmes et organes de communication entraîne des conditions variables d'exécution. Afin de permettre cette possibilité d évolution, les applications réparties doivent avoir Une architecture modulaire (composants) Qualité de la décomposition : identifier les fonctions Qualité de la conception des interfaces : identifier ce qui est montré et ce qui est caché Un découplage fort: l impact des modifications locales doit si possible rester locale Une qualité de la documentation Documentation de la conception Documentation de la realization N.B. La transparence est une propriété fondamentale ; elle permet de masquer la distribution aux utilisateurs et aux programmes d application IV. Phases de Construction d applications réparties 1. Conception de l architecture de l application. 2. Programmation des entités logicielles : Utilisation d un mécanisme de communication avec un modèle d exécution (Socket, RMI, RPC, CORBA, etc.). Programmation en fonction du modèle d exécution. 3. Configuration des entités de diverses provenances : leur permettre de communiquer, d échanger des données. leur permettre d échanger des informations de contrôle. leur permettre de se comprendre. 4. Prendre en considération l installation et le déploiement. 2

3 5. Administration : Surveillance, maintenance et évolution des applications. V. Mécanismes d'interaction de base Les composants d une application répartie interagissent via un système de communication sous-jacent. Il existe différents mécanismes d interaction : 1. Modèle de communication par évènement : La forme la plus simple de communication est un événement transitoire asynchrone (Figure a.). Un composant A (plus précisément, un thread s'exécutant dans le composant A) produit un événement (c'est-à-dire envoie un message élémentaire a un ensemble spécifique de destinataires), et poursuit son exécution. Le message peut être un simple signal, ou peut porter une valeur. La réception de l'évènement par le composant B déclenche une réaction, c'est-à-dire lance l'exécution d'un programme (le traitant) associé à cet évènement (association dynamique entre un type d évènement et une réaction). Ce mécanisme peut être utilisé par A pour demander un service a B, lorsque aucun résultat n'est attendu en retour ; ou il peut être utilisé par B pour observer ou surveiller l'activité de A. Figure 2. Quelques mécanismes de base pour l'interaction 2. Modèle de communication par message a. Message asynchrone Une forme de communication plus élaborée est le passage asynchrone de messages persistants (b). Un message est un bloc d'information qui est transmis d'un émetteur à un récepteur. Cette émission est non bloquante (l émetteur continu son travail). L'attribut < persistant > signifie que le système de communication assure un rôle de tampon : si le récepteur attend le message, le système de communication le lui délivre ; sinon, le message reste disponible pour une lecture ultérieure. Deux modes de communication par message asynchrone existent : Communication directe entre processus (agents). Communication indirecte (boîtes aux lettres). b. Message synchrone Un autre mécanisme courant est l'appel synchrone (c), dans lequel A (le client d'un service fourni par B) envoie un message de requête a B et attend une réponse (cette émission est bloquante). Ce patron est utilisé dans le RPC. Les interactions synchrone et asynchrone peuvent être combinées, par exemple dans diverses formes de < RPC asynchrone >. Le but est de permettre au demandeur d'un service de continuer son exécution après l'envoi de sa requête. Le problème est alors pour le demandeur 3

4 de récupérer les résultats, ce qui peut être fait de plusieurs manières. Par exemple, le fournisseur peut informer le demandeur, par un évènement asynchrone, que les résultats sont disponibles ; ou le demandeur peut appeler le fournisseur a un moment ultérieur pour voir l'état de l'exécution. c. Appel avec Callback Il peut arriver que la fourniture d'un service par B à A repose sur l'utilisation par B d'un service fourni par A (le contrat entre fournisseur et client du service engage les deux parties). Par exemple, dans la figure suivante, l'exécution de l'appel depuis A vers B repose sur un rappel (en anglais callback) depuis B à une fonction fournie par A. Sur cet exemple, le rappel est exécuté par un nouveau thread, tandis que le thread initial continue d'attendre la terminaison de son appel. Figure 3. Synchronous Call with Callback d. Appel de procédure à distance : L'abstraction procédurale est un concept fondamental de la programmation. Une procédure, dans un langage impératif, peut être vue comme une < boite noire > qui remplit une tache spécifiée en exécutant une séquence de code encapsulée, le corps de la procédure. L'encapsulation traduit le fait que la procédure ne peut être appelée qu à travers une interface qui spécifie ses paramètres et ses résultats sous la forme d'un ensemble de paramètres formels. Un processus qui appelle une procédure fournit les paramètres effectifs, exécute l'appel, et reçoit les résultats lors du retour, c'est-à-dire à la fin de l'exécution du corps de la procédure. L'appel de procédure à distance peut être spécifié comme suit. Soit sur un site A un processus p qui appelle une procédure locale P (voir figure 4.a). Il s'agit de concevoir un mécanisme permettant à p de faire exécuter P sur un site distant B (voir Figure 4.b), en préservant la forme et la sémantique de l'appel (c'est-à-dire son effet global dans l'environnement de p). A et B sont respectivement appelés site client et site serveur, car l'appel de procédure à distance suit le schéma client-serveur de communication synchrone par requête et réponse. Fifure 4. Schéma de l'appel de procédure à distance Le problème du passage des paramètres est généralement résolu en utilisant le passage par valeur pour les types simples. Cette solution s'étend aux paramètres composés de taille fixe 4

5 (tableaux ou structures). Dans le cas général, l'appel par référence n'est pas possible ; on peut néanmoins construire des routines spécifiques d'emballage et de déballage des paramètres pour des structures à base de pointeurs, graphes ou listes. Principe de réalisation du RPC La réalisation standard du RPC repose sur deux modules logiciels (Figure 5), la souche, ou talon client (client stub) et la souche serveur (server stub). La souche client agit comme un représentant local du serveur sur le site client ; la souche serveur joue un rôle symétrique. Ainsi, aussi bien le processus appelant, coté client, que la procédure appelée, coté serveur, conservent la même interface que dans le cas centralisé. Les souches client et serveur échangent des messages via le système de communication. En outre, ils utilisent un service de désignation pour aider le client à localiser le serveur. La communication coté client est basée sur un envoi de message synchrone, i.e., le client doit être bloqué en attendant le retour de la procédure. Figure 5. Composants principaux de l appel de procédure à distance Emballage et déballage des paramètres. Les paramètres et les résultats doivent être transmis sur le réseau. Ils doivent donc être mis sous une forme sérialisée permettant cette transmission. Pour assurer la portabilité, cette forme doit être conforme a un standard connu, et indépendante des protocoles de communication utilises et des conventions locales de représentation des données sur les sites client et serveur, comme l'ordre des octets. La conversion des données depuis leur représentation locale vers une forme standard transmissible est appelée emballage (en anglais marshalling) ; la conversion en sens inverse est appelée déballage (en anglais unmarshalling). Un emballeur (marshaller) est un jeu de routines, une par type de données (par exemple writeint, writestring, etc.), qui écrivent des données du type spécifié dans un flot de données séquentiel. Un deballeur (unmarshaller) remplit la fonction inverse et fournit des routines (par exemple readint, readstring, etc.) qui extraient des données d'un type spécifié a partir d'un flot séquentiel. Ces routines sont appelées par les souches quand une conversion est nécessaire. L'interface et l'organisation des emballeurs et déballeurs dépendent du langage utilisé, qui spécifie les types de données, et du format choisi pour la représentation standard. Le middleware Est un complément de services du réseau permettant la réalisation du dialogue client-serveur : Prend en compte les requêtes de l application cliente Les transmet de manière transparente a travers le réseau jusqu au serveur Prend en comptes les données résultants du serveur vers l application cliente L objectif essentiel d un middleware (intergiciel) est d offrir une interface unifiée permettant l accès à l ensemble des services disponibles sur le réseau. Il réalise les taches suivantes : 5

6 1. cacher la répartition, c est-à-dire, le fait qu'une application est constituée de parties interconnectées s'exécutant a des emplacements géographiquement repartis ; 2. cacher l'heterogeneite des composants matériels, des systèmes d'exploitation et des protocoles de communication utilises par les différentes parties d'une application ; 3. fournir des interfaces uniformes, normalisées, et de haut niveau aux équipes de développement et d'intégration, pour faciliter la construction, la réutilisation, le portage et l'interopérabilité des applications ; 4. fournir un ensemble de services communs réalisant des fonctions d'intérêt général, pour éviter la duplication des efforts et faciliter la coopération entre applications. Organisation d un intergiciel 6