2. Ingénierie informatique
est une discipline qui traite de la conception, du
développement et de la fabrication de systèmes
informatiques, à la fois matériels et logiciels.
L’ingénierie des systèmes répartis consiste à rendre la tache
de développement des applications réparties plus simple en
facilitant la gestion de la complexité inhérente aux
applications.
Notre but dans un premier temps est de voir une approche
de modélisation dite : MDA (Model Driven Architecture)
pour le développement des applications réparties.
2
4. Définitions
Déf1 :"Un système réparti est un ensemble de machines autonomes
connectées par un réseau,et équipées d’un logiciel dédié à la
coordination des activités du système ainsi qu’au partage de ses
ressources."
Déf2 : "Un système réparti est un système qui s’exécute sur
un ensemble de machines sans mémoire partagée, mais que
pourtant l’utilisateur voit comme une seule et unique
machine."
4
5. L’image de la fourmilière permet d’illustrer les systèmes
répartis :
chaque ordinateur est une fourmi, et l’ensemble des
ordinateurs collaborant est la fourmilière.
Chaque fourmi, prise seule, semble avoir un comportement
simple et rudimentaire. Mais d’un point de vue global, la
fourmilière a un comportement cohérent et efficace.
Le plus impressionnant est d’observer la robustesse d’une
telle structure : si l’on écrase la moitié des fourmis
composant la fourmilière, elle continuera à fonctionner.
5
6. Pourquoi un système réparti ?
1. Partage des ressources (données, applications, périphériques
chers).
2. Tolérance aux pannes (fiabilité, disponibilité).
3. Facilite la communication entre utilisateurs.
4. Concurrence, parallélisme
5. Prix des processeurs de petite puissance inférieur à ceux de
grande puissance =⇒raisons économiques.
6. Flexibilité, facilité d’extension du système (matériels, logiciels).
6
7. Inconvénients des systèmes répartis - distribués
Logiciel
relativement peu d’expérience de conception, mise en œuvre et
utilisation de logiciels distribués
la distribution doit elle être transparente aux utilisateurs ?
Réseau de communication
saturation
perte de messages
Sécurité
facilité de partage de données rend nécessaire la protection des
données confidentielles
7
8. Les principaux problèmes à résoudre:
– Répartition de l’application.
– Hétérogénéité des équipements et technologies, besoin
d’interopérabilité.
– Ouverture de système.
– Sécurité.
– Évolutivité.
–Tolérance aux fautes et la fiabilité/ Détection et isolation des
fautes/défaillances.
– Concurrence, Synchronisation et Interblocage.
–Transparence.
–Validation et tests.
8
9. Répartition de l’application:
Partitionnement de l'application en différents composants.
Equilibrer la charge de l’application à travers différents
composants répartis (client, nœuds de la grappe), statiquement
ou dynamiquement.
Architecture simple, propice à l'évolutivité et au maintien de la
sécurité.
9
10. Hétérogénéité:
– Réseaux et protocoles utilisés;
– Matériel;
– Systèmes d’exploitation;
– Langages de programmation;
– Implémentations;
– Représentations internes.
Solutions:
– Protocoles et formats de stockage normalisés;
– Intergiciels d'adaptation (e.g.CORBA,Java RMI,.NET).
10
11. Systèmes ouverts:
– Possibilité d'évoluer, de re-développer le système en tout ou en
partie.
– Interopérabilité avec des systèmes complémentaires.
– Portabilité vers du nouveau matériel.
– Services développés selon des règles normalisées, formalisées à
l'intérieur de protocoles, formats de stockage et interfaces de
programmation.
11
12. Sécurité :
–Transmettre des informations sensibles sur un lien de
communication non sécuritaire et non fiable de manière
sécuritaire.
– Confidentialité, intégrité, disponibilité.
12
13. Évolutivité
– Le système doit demeurer performant lorsque le nombre
d’utilisateurs et/ou de ressources augmente.
–Taille du système.
– Etendue géographique.
–Architecture du logiciel réparti.
13
14. Tolérance aux fautes et fiabilité
– Les fautes et les défaillances sont plus courantes que dans les
systèmes centralisés.
– Les défaillances sont habituellement indépendantes.
– Détection des fautes/défaillances.
– Masquage ou tolérance des fautes/défaillances.
– Redondance et réplication.
14
15. Concurrence:
– Permettre au système de traiter simultanément plusieurs
requêtes à une même ressource.
– Les opérations doivent être sérialisées ou donner un résultat
cohérent équivalent.
15
16. Transparence:
– Masquer à l’utilisateur tous les aspects reliés à la répartition du
système.
–Accès, localisation, concurrence, réplication, défaillance,
mobilité, performance, évolutivité.
16
17. Validation et Tests:
―Comment tester le système complet? Chaque composante?
― Les fautes lors des tests pourraient être masquées par la tolérance aux
pannes?
―Validation formelle de certaines portions.
SPIN, modelchecker développé par Bell Labs,
http://spinroot.com/spin/whatispin.html.
UPPAAL est un modelchecker développé par l'Université Uppsala, en
Suède et l'Université d'Aalborg en Danemark, http://www.uppaal.com/.
Standard OpenSource pour la fiabilité et interopérabilité:
― ServiceAvailability Forum (SAF) etAvailability
Management Framework (AMF), http://www.saforum.org/.
17
19. Le DNS (Domain Name System)
Le DNS (Domain Name System) : le système qui permet de
trouver l’adresse IP associée à un nom de machine. DNS est une
base de données répartie.
www.univ-saida.dz 193.194.87.133
19
20. DNS : traitement d’une requête
Je veux me connecter à cvs- etud.ufrmd.dauphine.fr :
1. demande du serveur local à un root server
2. réponse du root server : il faut demander à un serveur fr (délégation)
3. fr dauphine.fr
4. dauphine.fr ufrmd.dauphine.fr
5. ufrmd.dauphine.fr 193.51.89.162
Dans le cache après cette requête : adresses IP des serveurs DNS de fr,
dauphine.fr et ufrmd.dauphine.fr.
20
21. Le serveur WEB :
HyperTextTransfer Protocol (HTTP).
solution de base de type client/serveur
intrinsèquement réparti à cause des liens (par exemple, toutes les
requêtes CGI peuvent être exécutées sur un serveur différent du
serveur principal)
CGI : Common Gateway Interface (Interface de passerelle
commune).
21
23. 23
CGI est le standard industriel qui
indique comment transmettre la
requête du serveur HTTP au
programme, et comment récupérer
la réponse générée.
24. Le peer to peer :
peer to peer pur : pas de serveur connexions directes entre les
participants
peer to peer “pratique” : l’essentiel des communications
s’effectue entre les participants (mais il reste des serveurs).
24
25. Edonkey 2000 : Réseau Peer to Peer(P2P)
Programme eMul .
tout le monde peut devenir serveur
sur le serveur : liste des clients, pour chaque client : liste des
documents proposés au téléchargement.
Communication client vers serveur : le client demande un
document le serveur lui renvoie la liste des clients qui
possèdent le document
Communication client vers client : téléchargement des
documents morceaux par morceaux (un client peut
télécharger une partie d’un document d’un client et le reste
d’un autre).
25
26. Les grilles de calcul
Une grille de calcul permet de faire du calcul distribué : elle
exploite la puissance de calcul (processeurs, mémoires, ...) de
milliers d'ordinateurs afin de donner l'illusion d'un ordinateur
virtuel très puissant. Ce modèle permet de résoudre
d'importants problèmes de calcul nécessitant des temps
d'exécution très longs en environnement "classique".
26
29. Le Système Informatique
Est un ensemble organisé d'objets techniques – matériels,
logiciels – dont la mise en œuvre réalise l'infrastructure d'un
système d'information.
29
30. La modélisation
Le but de la modélisation d'un SI est d'aboutir à une
spécification qui soit une représentation simplifiée de sa
réalité passive ou active.
Les ingrédients de la modélisation des SIs sont bien connus :
modèle, langage, démarche, outil et méthode.
30
31. Un modèle est un instrument de travail intellectuel et pratique qui
permet de représenter une réalité observée à l'aide d'un formalisme
conventionnel et de règles de représentation de type
logicomathématique.
Exemples
modèle relationnel n-aire structuration des informations
modèles des réseaux de Petri la dynamique des systèmes
31
32. Catégories des méthodes
les méthodes dites d'analyse : CORIG, dans les années 1960.
les méthodes dites cartésiennes, comme SADT, des années
1970.
les méthodes systémiques, comme MERISE, des années
1980.
les méthodes objets, comme UML, des années 1990.
32
34. Outils et services pour les applications réparties
34
Parmi les services nécessaire à la mise en oeuvre d’applications
réparties, nous distinguons :
Les infrastructures de systèmes:
fournissent le support d’exécution et les outils de développement.
permettent la spécification, la programmation, l’intégration et la
mise au point des applications.
Les outils d’administration, qui permettent de mettre en place
l’application et de l’adapter à l’évolution des besoins.
35. Infrastructures de systèmes
35
Les années 1985-90 ont vu le développement de systèmes et
langages expérimentaux, à base d’objets partagés.
un exemple :
DCE (Distributed Computing Environment, défini par l’OSF).
En 1991, l’Object Management Group (OMG) définit une
architecture générique CORBA (Common Object Request Broker
Architecture).
vise à organiser les applications comme des ensembles d’objets
communiquant entre eux selon le schéma client-serveur (un
objet jouant souvent les deux rôles).
36. CORBA
36
Un langage de définition d’interfaces (Interface Definition
Language , ou IDL), qui sert à décrire les interfaces des objets.
Un "courtier d’objets" (Object Request Broker , ou ORB ), dont la
fonction est de mettre en relation un objet client et un objet
serveur et de réaliser la communication entre eux.
Un ensemble de services permettant de remplir des fonctions plus
élaborées que la simple communication (gestion d’objets
persistants, événements, transactions).
