Pourquoi des applications réparties ?

Communication en mode non connecté Communication en mode connecté

- Développement des réseaux (internet, Wifi, Bt)

- Partage et mise en commun des ressources (agents, datawareHouse,…)
- Intégration d’objets du monde réel, informatique omniprésente

Un système gère les ressources communes et l’infrastructure, proche du matériel

Une application est une solution logicielle à un problème spécifique pour un ensemble d’utilisateur

MIDDLEWARE Serveur itératif traite séquentiellement les données (adapté aux requêtes rapide à exécuter)

Serveur concurrent accepte les requêtes puis les délègue à un processus fils (requête longue…)

Service avec états : le serveur conserve localement un état pour chacun des clients connectés :
tolérance aux pannes
Middleware
Service sans états : aucune informations sur l’enchaînement des requêtes sauvegardées :
- Fournit une couche logicielle pour permettre la répartition d'applications (services) de
performance
manière transparente
- Intermédiaire de communication entre plusieurs applications

Application répartie : se décompose en plusieurs processus qui communiquent

Système réparti - Communication par mémoire partagée
- Transparence à la localisation (l’utilisateur ignore la situation géographique des ressources) - Communication par passage de messages
- Transparence d’accès (l’utilisateur ignore s’il accède à une ressource locale ou distante)
- Transparence à l’hétérogénéité (différences matérielles ou logicielles des ressources)
- Transparence aux pannes réseaux, machines, logicielles(cachées à l’utilisateur)
L’API est une interface entre l’application et la couche transport : sockets, Remote Procedure Call
- Transparence à l’extension des ressources (aucune gêne lors de l’extension/réduction du
(RPC)
système)
Socket : canal de communication entre deux programmes ou processus (échange ds les deux sens)
Le client effectue une demande de service auprès du serveur(requête)
Le serveur est la partie de l’application qui offre un service et répond au service demandé - Socket stream, datagram
Le client et le serveur ne sont pas identiques, ils forment un système coopératif
Socket() crée une socket
- Les parties client et srveur peuvent s’exécuter sur des sytèmes différents, un serveur peut
répondre à plusieurs clients simultanément Bind() lie un point de communication défini par une @ et un port

Application clients/serveurs : Listen() met la socket en attente de connexion

- Couche présentation : IHM qui assure la gestion de l’affichage et de l’intéraction avec l’Ut.
Connect() établit une connexion avec un serveur
- Couche logique : traitements qui assure la fonctionnalité de l’application (algo)
- Couche données : assure la gestion des données de l’application (stockahe et accès) Accept() permet la connexion en acceptant un appel

Send() écrit dans une socket pour encoyer des données

Recv() lit dans une socket

Middleware :
- Assure le processus client serveur(gestion des appels de fonction, gestion renvoi result)
- Mettre en forme les données pour la prise en charge par la couche transport
 FAP, propre à chaque protocole réseau, met en forme les données au niveau du réseau
 L’interface de communication se charge des connexions/déconnexions, transfert des
requêtes, réception des résultats
 L’API transmet au FAP du client les requêtes destinées au serveur qui va conditionner
les données au trasport
Fonction : portion de code représentant un sous programme qui effectue une tache/calcul
Procédure : routine, fonction renvoyant une valeur dont on ne se préoccupe pas du résultat
RPC :fournir aux langagex procéduraux un moyen d’appeler une procédure ou une fonction
exécutée dans un autre processus de la même machine ou sur une machine distante. Tout doit
être transparent le plus possible pour le programmeur
Les fonctions qui prennent en charge les connexions réseaux sont des stub
SUN RPC : une programme serveur se lance sur une machine, il indique au daemon portmapper
quels types de services RPC il fournira aux clients qui souhaitent se connecter à lui. Le client se
connecte au portmapper de la machine distante qui lui donnera les coordonnées du service à
contacter et pourra récupérer le résultat de façon transparente.
IDL Interface Definition Language est un terme générique, il y a autant d’IDL que de
middleware différents !
XDR définit les types utilisés pour l’échange de variables entre le client et le serveur qui ne sont pas
nécessairement sur la même plateforme et ne sont pas écrits dans le même langage (utilisation de
filtres XDR qui convertissent du format local à XDR et vis-versa)
DCE Distributed Computing Environnement : assemblage de technologies connues
séparément : DCE threads, DCE RPC, DC Directory Service compatible avec LDAP…
DCE est un environnement complet développement :création de RPC à travers un IDL
XML RPC : tous les échanges sont formalisés en XML donc lisibles, les requêtes et réponses sont
effectuées en http, pas de précompilation comme XDR, simplicité d’uilitsation
VOIR LES FEUILLES POUR LES ETAPES DE CONSTRUCTION D’UN PROGRAMME
ORB est un bus logiciel par lequel les objets envoient et reçoivent des requêtes et des réponses de
manière transparente (ces objets invoqués sont souvent des services)
La famille des ORB est une évolution des RPC pour prendre en compte les spécificités du
paradigme objet
Objectis de l’OMG : maximiser la portablilité, la réutilisabilité et l’intéropérabilité des logiciles
CORBA Common Object Request Broker Architecture : forme de middlewre qui appartient au
monde de la POO
- Capitalisation autour du paradigme objet
- Séparation de l’interface et de l’implémentation(utilisation d’un langage passerelle : IDL)
- Un ORB peut relier des objets écrits ds des langages différents
- Indépendance vis-à-vis de la localisation
- Utilisation transparente d’objets distants mais corba est asymétrique avec un rôle serveur et
un rôle client
- Intéropérabilité entre les ORB (deux ORB peuvent communiquer entre eux)
L’ORB au sens large est l’application qui permet
De contrôler le fonctionnement du bus CORBA
De manipuler ses services
D’obtenir des références sur les objets et les IOR des objets
Les stubs représentent un objet côté client, transmettent les appels de méthode à l’ORB(sérialise les
paramètres et désérialise les résultat)
Les skeletons sont les stubs côté serveur, désérialise les paramètre d’appel, sérialise les résultats
Le protocole d’échange GIOP permet le communication entre l’ORB du client et l’ORB du
serveur
Object Adapter (OA) crée une référence unique associée à chaque objet IOR
Le bus CORBA est la composante centrale d'une architecture logicielle complète pour la
construction d'applications distribuées à base d'objets, appelée OMA (Object Management
Architecture). Ce n’est pas simplement un middleware mais toute une paletted’outils
cohérents pour développer une application distribuée
OMA 5 couches :
- Fondamentaux de l’ORB
- COS (Common Object Services, CORBAservices) :ensemble de spécifications
pour les services fondamentaux
- Common Facilities (CORBAfacilities) : spécification de services de plus haut
niveau
- Domain Interfaces(Domain CORBAfacilities) : spécifications de hiérarchies
d’objets dédiées à un secteur industriel particulier
- Application Objects : extension des Domain Interfaces pour des appli dédiées
Deux modes de fonctrionnement : Accès distant aux fichiers(SQL, ODBC, JDBC)
- Mode statique : décrire d’abord des fonctionnalités distribuées - ODBC permet d’interfacer de façon standard une application à n’importe quel serveur
- Mode dynamique : découverte des services disponibles de bases de données(ODBC vise toutes les BD supportant le langage SQL)
- L’API JDBC permet aux appli java d’accéder par le biais d’une interface commune à
Le langage IDL permet de définir : des sources de données
- Une inclusion autorise à référencer dans un fichier IDL des types définis dans un autre o permet la connexion/déconnexion a des BD
fichier IDL o permet l’envoi de requêtes SQL et la gestion des transactions
- Un pragma permet de fixer les identifiants désignant les définitions OMG-IDL à
l’intérieur du référentiel des interfaces 4 types des pilotes JDBC :
- Un module sert à regrouper des définitions de types qui sont logiquement liés - Pilotes agissant comme passerelle
- Une constante, une structure, un tableau, une séquence, une exception, une opération, un - Pilotes d’API natifs
paramètre, un attribut - Pilotes convertissant les appels JDBC en un protocole indépendant de la base de
données
Un exemple de service CORBA : le service de nommage(facilite l’accès aux objets distants en - Pilotes convertissant les appels JDBC directement en un protocole réseau exploité par
permettant de les retrouver par leur nom, abstraction de la localisation totale la BD

Remote Method Invocation (RMI) permet à un langage java d’utiliser des objets
(fonctionmt proche de CORBAcoté client un stub, coté serveur le skeleton, service de nommage
rmiregistry)
Deuxcouches : 1. La couche des références d’objets RRL 2. Le stub et le skeleton communiquent
via une couche de transport
CORBA VS RMI : RMI est limité au monde Java, les points forts de CORBA sont la richesse des
services proposés et l’ouverture à tout langage de programmation
PROTOCOLE JABBER utilisé comme middleware générique, sert à transporter n’importe
quel type de données
Choix d’un middleware :
De quoi ai-je besoin ? Quelles sont mes contraintes ? Comment s’effectuera la mise en production ?
Comment le système risque-t-il d’évoluer ? Quels sont les facteurs humains ?

DCOM Distributed Component Object Model : brique Middleware de Microsoft

 Diffusions des messages dans DCOM par le biais des fonctionnalités de RPC de
l’environnement DCE
 Propose une extension de DCE : ORPC

MOM : Message Oriented Middleware famille de middleware orientés messages

 Fonctionnent par échanges asynchrones de messages
 Fournissent des fonctionnalités haut niveau pour gérer les queues de messages
 Deux appli veulent échanger des messages, on intercale le middleware qui gèrela file de
messages en attente
 Deux mode possibles : PUBLISH AND SUBSCRIBE & POINT TO POINT
Voir diapos

JMS Java Message Service est la spécification de Sun pour la gestion des messages

Les MOM sont des middleware asynchrones

 Insensibles à l’indisponibilité des applications
 Peuvent acheminer tous types de messages
 Manque de standard
 Beaucoup d’applications ou API concurrentes
Services web : système logiciel identifié par un URL dont les interfaces sont définies et
décrites en XML proposant diverses fonctionnalités
 Programme accessible par internet et par l’intermédiaire de messages XML, transmis par
HTTP
 Remplaçants des middlewares puisqu’ils sont conçus pour être distribués et intéropérables

URI : Uniform Ressource Identifier (URL, mail, FTP)

Interface : description des opérations proposées par le composant logiciel
Binding : spécification du protocole et du format des données utilisées pour échanger des messages
Découverte : obtention de la description d’un service web
XML :extensible Markup Langage INDISPENSABLE pour faire des services web
Protocoles internet : Bas niveau(TCP/IP), haut niveau(http, SMTP, FTP…)

But des services web : fournir une architecture générale pour les applications réparties sur
internet, faiblement couplées, supportant la montée en charge

Architecture de base : Le fournisseur de service/l’annuaire/le client

 Briques :
o SOAP protocole de transport de ces données basé sur http, appels de procédures
distantes en Client-Serveur. Il permet la transition de messages entre objets distants
 Une partie enveloppe contenant les informations sur le message pour
permettre son acheminement)
 Une partie modèle de données définissant le format du message (info à
transmettre)
o WSDL : dialecte XML permettant de décrire un service web
o UDDI : annuaire permettant d’enregistrer et de rechercher des descriptions de
services web(nom, description des produits, services applicatifs invocables a dist

Evolution de l’architecture :
- Sécurité
o Identifier l’envoyeur
o Garantir l’intégrité du contenant
- Fiabilité : être sûr que les messages arrivent