Applications Réparties et Middleware

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
ƒ
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
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
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
(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
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