Vous êtes sur la page 1sur 167

Universit Mohammed V Souissi

Ecole Nationale Suprieure dInformatique et


dAnalyse des Systmes (ENSIAS)

Architecture
Client/Serveur
Dr. Youns EL BOUZEKRI EL IDRISSI
y.elbouzekri@gmail.com
Cours prpar par Pr. Rachida AJHOUN (ENSIAS)

Anne universitaire 2012-2013


1

Objectifs
Comprendre les concepts de base du
modle C/S
Comprendre les techniques de
dveloppement des applications C/S
Utilisation dun Middleware
tude de larchitecture Web
Futur Client/Serveur

INTRODUCTION AU
CLIENT-SERVEUR

Historique
1 tape:
1 seule (norme) machine, 1 seul utilisateur (son concepteur)
E/S: interrupteurs, voyants lumineux
2 tape:
Amlioration des E/S: lecteur (de cartes!), imprimante
Multi-utilisateurs, 1 programme la fois
3 tape:
Monte en puissance : multi-excution
Temps partag, Apparition des terminaux
4 tape:
PCs des annes 80
Emulateurs de terminaux pour les relier aux systmes centraux
En // : volution des rseaux pour permettre aux systmes centraux de
communiquer
5 tape:
4
Stations de travail, Terminaux X

Historique
Systmes centraliss des annes 1970
(Gros systmes)
Architecture centralise:
terminaux passifs, monotechnologie, mono OS,
systme propritaire,
BD non relationnelles:
IDS2, DB2,
langages de programmation:
COBOL,
5

Besoins
Consiste raliser une intgration de linformatique
personnelle dans le SI de lentreprise avec les objectifs
suivants:
Tout utilisateur dans lentreprise doit pouvoir accder toute
information utile sa tche ds lors que cet accs est autoris
par les rgles de confidentialit et de scurit.
Laccs doit tre instantan et doit pouvoir tre fait partir de
nimporte quel poste de travail.
Laccs linformation doit avoir lieu par une interface aussi
simple que possible, choisie par lutilisateur.
Il faut prserver les investissements passs.
6

Evolution

SERVEUR

Architecture rpartie:

Rseaux, PC plus
puissants, OS ouverts
Interfaces et API
standards,
BD relationnelles
Langages 4GL: SQL,
Outils de dveloppement
Outils de transport

SGBD
OS

BD

Rseau dentreprise
Windows

OS/2

Unix

Applications

Applications

Applications

CLIENTS
7

La solution client/serveur
Larchitecture Client/Serveur est laboutissement dun
ensemble dvolutions technologiques survenues dans les
annes 80:
capacits mmoires,
performances des processeurs et des rseaux,
volutions des logiciels : interfaces graphiques, multimdia,
des interfaces de communications.

Dfinition : Modle darchitecture applicative o les


programmes sont rpartis entre processus clients et serveurs
communiquant par des requtes avec rponses
N.B: le rseau n'est pas vraiment ncessaire
8

Downsizing
Dfinition
Migration dune application dune plate-forme informatique

de type grand systme vers une plate-forme plus petite et


conomique. Les modles et fonctionnalits ne sont pas
ncessairement modifis par cette opration .

Quel rapport avec C/S ?


A priori aucun, le C/S est un modle de fonctionnement,
donc une technique alors que le downsizing est une pratique.

Caractristiques du modle C/S


Notion de service: le serveur est fournisseur de
service. Le client est consommateur de services.
Partage des ressources: un serveur traite plusieurs
clients en mme temps et contrle leurs accs aux
ressources.
Redimensionnement: il est possible dajouter et de
retirer des stations clientes. Il est possible de faire
voluer les serveurs.
Intgrit: les donnes du serveur sont gres sur le
serveur de faon centralise. Les clients restent
individuels et indpendants.
10

Une grande diversit doutils


Il comporte les composants suivants:
Un systme ouvert: bas sur les standards
Un SGBD sexcutant sur le serveur
Des stations de travail personnelles avec interface
graphique connectes au rseau
Des outils de dveloppement dapplications
Des logiciels de transport de requtes et rponses associs
au SGBD ou indpendant
Des outils de conception, de dploiement et de
maintenance pour permettre le suivi du cycle de vie des
applications
11

Pourquoi le Client/Serveur pour


lentreprise ?
Adapt lorganisation des socits modernes
==> structures en entits de moindre taille
==> nouveaux besoins de communication

Grer les contraintes de lentreprise


mieux satisfaire les clients
faire face lvolution des rgles
produire mieux et plus vite

Mieux matriser le systme dinformations


Prendre en compte lvolution des technologies

12

Exemples dapplication

Serveur dimpression
Serveur Web
Serveur dautorisation de cartes bancaires
Serveur de mail
Traitement dun appel (tablissement,raccrochage...)
dans un commutateur tlphonique
Localisation dun mobile GSM lors dun appel vers
ce mobile
13

ARCHITECTURE
CLIENT-SERVEUR
1.

DEFINITIONS

2.

TECHNIQUES DE DIALOGUE CLIENT-SERVEUR

3.

DIFFERENTS TYPES DE CLIENT-SERVEUR

14

Rappel: Architectures classiques des


Applications rparties

Couplage fort
Ex : Architecture peer-to-peer (tous les processus ont
le mme rle)
Grappes de calculateurs

Couplage faible
Architecture client/serveur

15

Couplage fort
Interdpendance entre les composants de lapplication
P1

P2

P3

Il existe au moins un cycle dans le graphe


de dpendances entre les composants de
lapplication

P4

Ce type darchitecture pose problme tant pour le


dveloppement que pour la maintenance.
A viter tant que possible

16

Couplage faible
Pas Interdpendance entre les composants de lapplication
P1

P2

P3

Pas de cycle dans le graphe de


dpendances entre les composants de
lapplication

P4

Permet de maitriser la complexit de lapplication:


pour le dveloppement
pour le test
pour la maintenance
17

Modle client/serveur
principe
Processus
client
Systme
Hardware

Client

Application

Processus
serveur
Systme
Hardware

Serveur

18

Client

Dfinition :
Processus demandant lexcution dune opration un autre
processus
par envoi dun message contenant le descriptif de lopration
excuter, et
attendant la rponse cette opration par un message en retour.
Il est tjs linitiateur du dialogue
Requte
Serveur

Client
Rponse

19

Serveur

Dfinition :
Processus accomplissant une opration
sur demande dun client, et
transmettant la rponse ce client.
Notion de session!!!
Client

Req
Rep

Serveur

Client

20

REQ & REP

Requte:

Message transmis par un client un serveur


dcrivant lopration excuter pour le compte du client

Rponse:
Message

transmis par un serveur un client


suite l excution dune opration contenant les paramtres
de retour de lopration

21

Architecture client/serveur
Points forts
Couplage faible (le serveur na pas besoin des clients)
La maintenance et ladministration du serveur sont
simplifies
Souplesse : il est possible dajouter/supprimer
dynamiquement des clients sans perturber le
fonctionnement de lapplication
Les ressources sont centralises sur le serveur
Scurisation simple des donnes : 1 seul point dentre
Pas de problme dintegrit/cohrence des donnes
Points faibles
Un maillon faible : le serveur
Cot lev : le serveur doit tre trs performant pour
honorer tous les clients
22

Dialogue Client/Serveur
Serveur
Client
Requte
Rponse

SendRequest()

Primitives de service:
SendRequest()
ReceiveResponse()
ReceiveRequest()
SendResponse()

SendResponse()

ReceiveResponse()

ReceiveRequest()

Session

Session

Transport

Transport
Rseau
23

Messages Client/serveur

En gnral on a trois types de messages: REQ, REP et ACK.


Accessoirement, on peut avoir dautres:

AYA (Are You Alive):

IAA (I Am Alive):

Utilis par le client quand le serveur tarde donner une rponse et que le client ne veut pas
retransmettre sa requte.
Utilis par le serveur pour demander au client d attendre un peu plus (ex. le serveur est occup
faire un long travail).
Si le client perd patience (aprs plusieurs tentatives), il arrte tout.

TA (Try Again):

Utilis si le message REQ ne peut tre accept (ex. bote aux lettre trop pleine, adresse
processus de destination inconnue)

REQ
REP

REQ
ACK
AYA

REQ
ACK
S

REP
ACK

IAA
REP

ACK
24

changes de messages

Dans un environnement htrogne, on doit effectuer une


prsentation adquate des donnes:

Traduction des donnes: XDR (SUN) , ASN.1(CCITT),


Assemblage des paramtres mis (Marshalling) et des rsultats
Dsassemblage des paramtres reus (Unmarshalling) et de rsultats

Traduction
Assemblage

Traduction
Dsassemblage

Prsentation

Prsentation

Session

Session

Transport
25

changes de messages (suite)


Assemblage (Marshalling):
A lmission de la requte, les paramtres sont arrangs et cods
Dfinition :
Procd consistant prendre une collection de paramtres, les
arranger et les coder en format externe pour constituer un
message mettre

Dsassemblage (Unmarshalling):
A larrive, les rsultats doivent tre remis en format interne
partir du message reu
Dfinition :
Procd consistant prendre un message en format externe et
reconstituer la collection de paramtres quil reprsente en format
interne
26

Modes de dialogue C/S

Mode synchrone:

Nutilise pas de file dAttente


Les messages sont mis sans attente.
Les commandes dE/S sont bloquantes (ex. HTTP).

Mode asynchrone:

Utilise une file dattente


Lune au moins des commandes dE/R est non bloquante
Favorise le multitche (ex.: email, )
27

Modes de communication
mode non-connect: larrive des donnes + ordonnancement +
non duplication ne sont pas garantis par le protocole ==> grer
par lapplication.
lapproche non-connect implique gnralement une connexion
synchrone
Client

programme

Rseau
message dappel

Serveur

prise en compte de
la requte
Rveil du serveur

rception du rsultat

Excution requte
message rponse
poursuite du traitement
28

Modes de communication (suite)


le mode connect: implique une diminution des
performances par rapport au mode non connect: ceci est
une contrainte pour certaines applications.
le mode connect permet une implmentation asynchrone
des changes, plus complexe mais plus performantes que
le mode non-connect.

29

Le mode connect
Client
demande de
connexion

Rseau

Serveur
prise en compte de
la connexion

message de connexion

Cration dun contexte

Excution des

mission de requtes
Rception de rsultats
Synchronisation

requtes et

gestion de la

mission de requtes
Rception de rsultats
Synchronisation

demande de
dconnexion

synchronisation

message de dconnexion

prise en compte de
la dconnexion
30

Libration du contexte

Diffrentes combinaisons pour


les dialogues C/S
mode comm.

Avec connexion

Sans
connexion

APPC
RDA
pipes

RPC

dialogue

synchrone
asynchrone

Message
queuing

RPC: (Remote Procedure Call) est prfrable dans le cas ou les changes
sont sporadiques
APPC: (Application Program to Program Communication) utile pour la
gestion des transactions dans les bases de donnes.
Message queuing: mcanisme simple mais manque de contrle sur le dlai
dobtention dune rponse (ex: courrier lectronique)
31

3- DIFFERENTS TYPES DE
CLIENT-SERVEUR

32

Couches dune application


Une application informatique est reprsente selon un
modle en trois couches:
la couche prsentation (interface Homme/Machine):
gestion de laffichage (exemple Windows, X-window, etc.),
logique de laffichage, partie intrinsque de lapplication qui
transmet la gestion de laffichage, les lments de prsentation.

la couche traitement qui constitue la fonctionnalit


intrinsque de lapplication:
la logique des traitements : lossature algorithmique de lapplication,
la gestion des traitements dclenchs par la logique de traitements
qui ralise la manipulation des donnes de lapplication (ex:
procdures SQL)
33

Couches dune application (suite)


la couche donnes qui assure la gestion des donnes:
la logique des donnes constituant les rgles
rgissant les objets de la base de donnes,
la gestion des donnes (consultation et mise jour
des enregistrements). Un systme de type SGBDR,
habituellement, est responsable de cette tche.
Le dcoupage permet de structurer une application en
mode client/serveur;
le module de gestion des donnes peut tre hberg par un
serveur distant,
le module de logique de laffichage peut galement tre
gr par un serveur distant (un Terminal X par exemple).
34

C/S orient client ou serveur


Orient client
GUI

Client

Client

Orient serveur
Application

Donnes

Serveur

lourd (Fat Client):

Stocke

les donnes et les applications localement. Le serveur stocke les


fichiers mis jour,
Le client obtient une bonne partie du traitement: serveurs de bases de
donnes, de fichiers, ...
Le serveur est plus allg
35

C/S orient client ou serveur

Serveur lourd (Fat Server):

On met plus de charge sur le serveur: groupeware, transactions,


objets,
Plus facile grer car on peut enrichir le serveur sans trop affecter les
clients.

Client lger (Thin Client):

Client fonctionnalit minimale: Terminaux X, stations de travail sans


disque dur, Ordinateur Rseau (Network Computer),
Beaucoup de charge sur le serveur
Donnes et
applications

Applet, donnes

Traitement
local, Caching,

Client lger
Serveur

36

C/S orient client ou serveur

Client riche (Rich Client Platform):


Dvelopper des applications traditionnelles, ou des
applications type client-serveur.
Propose un environnement d'excution comprenant des
composants de base sur lequel seront dployes les
applications.
Propose un Framework de dveloppement et des
composants de base pour faciliter le travail des
dveloppeurs.

37

Diffrents types de C/S


Modle

de Gartner pour les systmes deux niveaux (2-tiers) :

Prsentation

Donnes

traitement

client

serveur
prsentation

rhabillage

donnes

Transaction
rpartie

Systme
rpartie

38

Diffrents types de C/S (suite)

C/S de prsentation

Le client ne gre que les


dialogues avec lutilisateur
interface utilisateur

Rhabillage (revamping)

Emulation des terminaux

Prsentation repartie
On rajoute un client une
application existante
sparation clients
utilisateurs
Clients
Ex: X-Window

telnet
39

Diffrents types de C/S (suite)


C/S de donnes

Service de fichiers
Accs aux donnes
requtes du type SQL

Transactions rparties

Application des 2 cts


sous-traitance
Ex: le Web
HTML, Java, JS

CGI, httpd server

40

Systmes rpartis

tous des 2 cts


coopration
pas les limites des modles classiques :

rutilisation
transparence de la localisation
scurit
persistance

41

Situation actuelle!!
Les Applications construites sont de plus en
plus complexes :
Application de commerce en ligne
Radio/tlvision numrique interactive
Moteur de recherche

Dans le modle client/serveur toute la


complexit est concentre dans le serveur
Problme de performance/disponibilit
Rpartition de charge (load balancing)

Problme pour matriser la complexit


Architectures multicouches (N- Tiers)
42

Rpartition de charge
Load balancing
Un serveur traite simultanment les requtes de
plusieurs clients
Les requtes de deux clients sont indpendantes
Lide du load balancing est de parallliser sur
plusieurs serveurs identiques sexcutant sur des
machines diffrentes le traitement des requtes
concurrentes

43

Rpartition de charge
Les requtes des clients passent par un rpartisseur de
charge qui les rpartit sur N serveurs identiques.
C1

S1
rpartisseur

C1

S1

S1

44

Rpartition de charge
Rle principal
Diriger les requtes des clients en fonction de la charge de chacun des
serveurs

Rle annexe
Grer les sessions des clients (2 solutions)
Toutes les requtes dun client sont diriges vers un seul serveur
Les donnes de session sont transmises avec la requte
Ex: gestion des donnes concernant un client

Grer les dfaillances :


Ne plus diriger de requtes sur un serveur crash
Assurer le passage lchelle (scalabilit)
Permettre lajout et le retrait de serveurs sans interruption de service
45

Rpartition de charge
Points forts
Transparent pour les clients
Scalable : le nombre de serveurs peut tre adapt la demande
Tolrant aux dfaillances : la dfaillance dun serveur
ninterrompt pas le service
Plus besoin de machines trs chres : il suffit den mettre plus

Point faible
Les donnes ne sont plus centralises mais dupliques
Le rpartiteur de charge devient le maillon faible

46

Matriser la complexit
Lapplication devient complexe :

Difficile dvelopper
Difficile tester
Difficile maintenir
Difficile faire voluer

Solution : les architectures multicouches


Inspir par le dveloppement en couches des protocoles
rseaux et des architectures base de composants

47

Les niveaux dune architecture C/S


2 niveaux:
Plusieurs clients et un serveur.
Dcoupage en deux de la charge de lapplication
Client

Serveur

Client

3 ou N niveaux:
Un client, plusieurs serveurs
Rpartition de la charge entre le client et plusieurs serveurs
Client

Serveur

Serveur
48

Quand utiliser un modle 3 niveaux?


La rponse de Gartner Group
Lapplication comprend plus de 50 classes ou services
Les applications sont programmes dans des langages
diffrents ou crites par des organisations diffrentes
Il existe au moins deux sources de donnes htrognes,
telles que deux SGBD diffrents
La dure de vie des applications est suprieure 3 ans
La charge est leve, plus de 50000 transactions par jour ou
plus de 300 utilisateurs accdant la mme base
Les communications entre applications sont nombreuses.

49

Cot de dveloppement et de maintenance

Architecture
2 niveaux

Architecture
3 niveaux

Complexit et dure de vie des applications

50

Client/serveur 3 niveaux
Modle de Gartner pour les systmes 3 niveaux (3-tiers ):
Client

Prsentation

Prsentation

Prsentation

Prsentation

traitement

traitement
donnes

Serveur
de milieu

traitement

traitement

traitement

traitement

donnes

traitement
Serveur

donnes

donnes

traitement

donnes

donnes
51

4- FONCTIONNEMENT DUN
SYSTEME CLIENT-SERVEUR

52

Fonctionnement dun systme C/S


Client

Req
Rep

Serveur

Client

Le client met une requte vers le serveur grce son adresse et


le port, qui dsigne un service particulier du serveur
Le serveur reoit la demande et rpond l'aide de l'adresse de la
machine client et son port
53

Architecture dun client


Une application cliente est moins complexe que son
homologue serveur car:
la plupart des applications clientes ne grent pas
dinteractions avec plusieurs serveurs,
la plupart des applications clientes sont traites comme un
processus conventionnel.
la plupart des applications clientes ne ncessitent pas de
protection supplmentaires, le systme dexploitation assurant
les protections lmentaires suffisantes.

54

Architecture dun serveur


Processus serveur:
Offre une connexion sur le rseau
Entre indfiniment dans un processus dattente de requtes
clientes
Lorsquune requte arrive, le serveur dclenche les
processus associs cette requte, puis met la ou les
rponses vers le client.
Problme : grer plusieurs client simultanment.
Les types de serveurs
serveurs itratifs: ne grent quun seul client la fois
serveurs parallles : fonctionnent en mode concurrent .

55

Serveur itratif
Les requtes sont traites squentiellement par le
mme processus. Mais pour viter de perdre des
requtes qui arrivent pendant un traitement,
lattente et la mmorisation des requtes dans la
file dattente se font en parallle avec les
traitements.

56

Serveur itratif (suite)


2 types : connect ou non-connect selon le protocole de transport

le serveur itratif en mode non-connect:


offre une interface de communication sur le rseau en mode nonconnect,
indfiniment : rceptionne une requte client, formule une rponse, et
renvoie le message rponse vers le client selon le protocole applicatif
dfini.

le serveur itratif en mode connect:

offre une connexion sur le rseau en mode connect,


(*) rceptionne une connexion client,
offre une nouvelle connexion sur le rseau,
rptitivement : rceptionne une requte pour cette connexion, formule
une rponse, et renvoie le message rponse vers le client,
lorsque le traitement pour ce client est termin -->(*).
57

Serveur itratif (suite)


Client i

Serveur itratif

initialisation
Initialisation
mission Requte

Mise en coute

File dattente

Traitement dune requte

Rception rponse
58

Serveur Parallle
Chaque requte est traite par un processus fils ddi cre cet effet. Une
requte trop langue ne pourra plus retard dune faon trop importante
dautres traitements
2 modes de communication: connect et non-connect
le serveur parallle en mode non-connect:

offre une interface de communication en mode non-connect,


rptitivement : rceptionne la requte client; offre une nouvelle
interface de communication sur le rseau, et cre un processus
secondaire (PR. S.) charg de traiter la requte courante.
(PR. S.) : formule une rponse la requte client, et renvoie le
message,
(PR. S.) : lorsque le traitement est termin, libre la
communication, Exit.
59

Serveur Parallle (suite)


le serveur parallle en mode connect:
offre une connexion sur le rseau en mode connect,
rptitivement : rceptionne une connexion client, offre une
nouvelle connexion sur le rseau, crent un PR. S. charg de
traiter la connexion courante.
(PR. S.) : rptitivement : rceptionne une requte pour cette
connexion, formule une rponse, et renvoie le message rponse
vers le client selon le protocole applicatif dfini,
(PR. S.) : lorsque le traitement est termin (propre au protocole
applicatif), libre la connexion, Exit.

60

Serveur Parallle (suite)


Client i

Serveur parallle

initialisation

Initialisation
Mise en coute

mission Requte

P0

File dattente

Cration processus ddi

P1

P0

Traitement requte i

Rception rponse

Fin P1
61

Comment choisir un type


serveur itratif en mode non-connect :
Ncessite trs peu de traitement par requte (pas de concurrence)
Exemple: serveur TIME

serveur itratif en mode connect :


Ncessite trs peu de traitement par requte mais requirent un
transport fiable de type TCP. Peu utilis.

serveur concurrent en mode non-connect si :


temps de cration dun processus extrmement faible (dpend du
systme dexploitation hte) par rapport au temps de traitement
dune requte,
les requtes ncessitent des accs priphriques importants (dans
ce cas, la solution itrative est inacceptable).
62

Comment choisir un type (suite)


serveur concurrent en mode connect : offre un transport fiable
et est capable de grer plusieurs requtes de diffrents clients
simultanment
Implmentation:
Multi-instanciation de processus avec un processus primaire et des
processus secondaires traitant les connexions clientes,
avec un seul processus grant les multiples connexions par
lintermdiaire de requtes asynchrones et primitive dattente
dvnements multiples.
63

Service avec ou sans tat


Service avec tat:
le serveur conserve localement un tat pour chacun des clients connects :
informations sur le client, les requtes prcdentes,

Service sans tat:


le serveur ne conserve aucune information sur l'enchanement des
requtes...

Incidence sur les performances et la tolrance aux pannes dans le


cas o un client fait plusieurs requtes successives
performance --> service sans tat
tolrance aux pannes --> service avec tats

Exemple : accs un fichier distant


RFS avec tats, NFS sans tat (pointeur de fichier)
64

Hardware et Software
Client
GUI: Graphical User Interface
OS: Windows98, XP, Vista,
Video, audio,..

Serveur

Grande capacit de stockage


Tolrance aux pannes et la disponibilit dinformations
Performant, rapide
Systmes dexploitation serveur :
Windows Server 2008
OS/2 SMP (IBM)
Solaris (Sun)
UnixWare2 (Novell)
65

MIDDLEWARE
1- Concepts de base
2- Types de Middleware
a- BD
b- RPC, Web
c- MOM

66

Dfinition
Dfinition: ensemble des services logiciels
construits au-dessus dun protocole de transport
afin de permettre lchange de requtes et des
rponses associes entre client et serveur de
manire transparente:
Transparence aux rseaux
Transparence aux serveurs
Transparence aux langages

67

Objectifs dun Middleware


Transports de requtes et rponses
Simplification de la vision utilisateur
Dveloppement dAPI transparente
Intgration uniforme aux langages

Harmonisation des types de donnes


Performance
Gestion de caches clients et serveurs
Parcours des rsultats complexes (ensembles, objets longs)

Fiabilit
Gestion de transaction intgre
Communication (rmission, dtection de double mission)
68

Fonctions dun Middleware

Procdure de connexion:
Opration permettant d'ouvrir un chemin depuis un client vers
un serveur dsign par un nom, avec authentification de
l'utilisateur associ par nom et mot de passe et identifie la BD
Prparation de requtes:
Opration consistant envoyer une requte avec des
paramtres non instancis un serveur afin qu'il prpare son
excution
Excution de requtes
Opration consistant envoyer une demande d'excution de
requte prcdemment prpare un serveur, en fournissant les
valeurs des paramtres

69

Fonctions dun Middleware (suite)


Rcupration des rsultats:
Opration permettant de ramener tout ou partie du rsultat d'une requte
sur le client

Cache de rsultats:
Technique permettant de transfrer les rsultats par blocs et de les
conserver sur le client ou/et sur le serveur afin de les rutiliser pour
rpondre des requtes

Cache de requtes:
Technique permettant de conserver des requtes compiles sur le
serveur afin de les rutiliser pour rpondre des requtes similaires

Procdure de dconnexion:
Opration inverse de la connexion, permettant de fermer le chemin
ouvert depuis le client vers le serveur associ
70

Modle fonctionnel

API: interface utilisateur


FAP: module de formatage et daccs
71

Diffrents types de Middleware

72

Architecture du middleware
Application client

Middleware

Application serveur

I3

Middleware

NOS

NOS

NIC

NIC

Client

Serveur

73

Architecture du middleware (suite)


I1 est linterface la plus simple dans larchitecture: Un
middleware est compatible a un OS ou non
I2 reprsente lintgration avec lapplication: API
I3 est une interface logique (la plus importante). Fournit
une intgration entre les composantes du middleware de la
machine client est la machine serveur
Les fonctionnalits reprsentes dans I2 sont limites selon
les possibilits de I3
Le choix dun Middleware dpend de la faon dont ces
interfaces (I1, I2, I3) adhrent

74

Liste compatibles dinterfaces


Interface

usage

Exemple

1- systme
dexploitation

Client OS
Serveur OS

Windows 7
Windows NT Server

2- application

Envt de
dveloppement

.NET, JEE,

3- Communication

Technique de
communication du
Middleware

ODBC, RPC, CORBA,


HTTP,

75

Catgories de middleware
Plusieurs implmentations du middleware
Aider au choix dun middleware: mettre en
catgorie
En se basant sur des critres dordre techniques et
non marketing
2 catgories importantes:
Base sur lapplication (plates-formes)
Base sur la communication (canaux)

76

Les catgories bases sur les applications


Catgorie

Bases de donnes

Legacy/application
(hrites)
Web

Type dapplication

Intgrer des BDs


clients dans des
serveurs de BD
relationnelles
Intgrer un client dans
des applications
existants
Intgrer des clients
Web dans un serveur

Technologie

SQL
ODBC

TPM

CGI, ASP, PHP


JSP,

77

La mthodologie de communication
Cette catgorie technique est indpendante de lapplication
supporte par le middleware
Catgorie

Exemple/standard

Remote Procedure Calls

DCE

Message-Oriented

Message Queuing
Message Passing

TPM: moniteur transactionnel

CICS, IMS, ACMSxp

Orient objet

CORBA
DCOM
78

Middleware bases de donnes


Middleware: comprendre lapplication du
programmeur pour accder et manipuler les donnes
stockes dans les serveurs BDs distants
Client qui formate les donnes pour la prsentation
Structured Query Language (SQL) est un langage
standard dvelopp pour faciliter laccs aux
serveurs BD relationnel: ajout, mise a jour,...

79

SQL
Est un standard ANSI (Americain National
Standard Institute)
4 composantes principales:

Langage de dfinition de schma (table, vues,)


Langage de manipulation (slection, mise a jour,)
Spcification de modules appelables (procdures)
Intgration aux langages de programmation

4 verbes de base:
SELECT, INSERT, UPDATE, DELETE

http://ceria.dauphine.fr/cours98/BD-wl-98.html
80

SQL (suite)
La norme SQL tait trs restreinte et incomplte
tendre la norme par les diteurs de SGBDR dans les
productions commerciales
Vendeur BD

Serveur BD

Middleware

Oracle

Oracle

PL/SQL

CA-Ingres

Ingres

Open Ingres

IBM

DB2

SQL PL

Microsoft

SQL Server

Transact SQL
81

Open DataBase Connectivity (ODBC)


Objectif: liminer la relation entre lapplication
client et le serveur de BD. Dveloppement des
applications ouvertes
Dveloppe au dbut de 1992 et prsente comme
une interface universelle daccs aux services de
donnes
Conue autour du modle SQL

82

Architecture de ODBC
CLIENT

SERVEUR

Application

SGBD

Gestionnaire
de pilotes

Pilote Traitant

Fichiers Dbase

Pilote
Transparent

Adaptateur

FAP

FAP

Rseau

83

ODBC (suite)
Architecture ODBC consiste en deux couches:
Gestionnaire de pilotes: dfinir le pilote adquat pour la
BD
Pilote ODBC: traduit les requtes SQL formules par
ODBC en message comprhensible par le SGBD cible

Laccs multi-source est possible sous certaines


conditions mais il nest pas transparent

84

ODBC (suite)
ODBC est devenu un standard par SAG (SQL
Access Group)
Il existe plus de 700 pilotes disponibles sur le
march
ODBC a amlior la portabilit des applications
clients
Evolution: RDO, DAO, OLE DB, ADO, ADO+
Dans .NET ADO.NET
85

Remote Procedure Call


RPC a t dvelopp pour UNIX. Elle a t largement utilise
pour le dveloppement des applications C/S
Objectif: l'invocation d'un service situ sur une machine distante
(analogue celui dun appel de procdure local)
Middleware bas sur RPC: DCE (Distributed Computing
Environment) de lOSF
DCE propose des standards de services pour la mise en place
dapplication C/S:

Service de scurit (login et authentification)


Service de rpertoires des ressources (annuaire)
Gestion de fichiers distribus (DFS)
RPC

RMI (J2EE), .NET Remoting (Microsoft .NET)

86

RPC
Le modle RPC utilise lapproche "conception oriente
application" et permet lexcution de procdure sur des sites
distants.
Lappel de la procdure distante constitue la requte cliente,
le retour de la procdure constitue la rponse serveur.
but : conserver le plus possible la smantique associe un
appel de procdure conventionnel, alors quil est mis en
oeuvre dans un environnement totalement diffrent.
Un appel de procdure obit fonctionnement synchrone:
une instruction qui suit un appel de procdure ne peut pas
sexcuter tant que la procdure appele nest pas termine.

87

RPC : le modle
Encapsulation du protocole de communication dans un appel
de procdure
Programme
principal

Procdure A
(serveur)

procA()

procB()

return

return

Machine 1

rseau

Machine 2

Procdure B
(serveur)

return
rseau

Machine 3
88

Diffrences entre procdures distantes et


procdures locales
les temps de dlais ds au rseau peuvent engendrer des
temps dexcution considrablement plus long
Un appel de procdure distant ne peut contenir dargument
de type pointeur
Les descripteurs dentre/sortie ne sont pas accessibles au
procdures distantes, leur interdisant lutilisation de
priphriques locaux (exemple criture de messages
derreur impossible).

89

Fonctionnement du RPC
Application

Procdure

Souche client

Souche serveur

assemblage

desassemblage

SendRequest()
ReceiveReply()

assemblage

desassemblage

SendReply()
ReceiveRequest()

90

Composants dune application


RPC
Client
Localiser le serveur et sy connecter
Faire des appels RPC (requtes de service)
Emballage des paramtres
Soumission de la requte
Dsemballage des rsultats

Stub client
+
Primitives XDR

Serveur
Attendre les requtes du client et les traiter
Stub serveur
Dsemballage des paramtres
+
Appel local du service (procdure) demand(e)
Primitives XDR
Emballage des rsultats

91

Les problmes rsoudre


Gestion du processus serveur:
Cration
Dsignation et liaison

Transmission des paramtres et des rsultats


Espace dadressage client et serveur disjoints
Htrognit des langages et des machines
Passage de structures dynamiques (tableaux de taille
variable, listes, arbres, graphes, etc.)

Gestion des dfaillances


Transparence
92

Identification dune procdure


Principe: regrouper diffrentes procdures
relatives un mme domaine ou un service
particulier en un programme RPC
Les paramtres didentifications sont:

Numro du programme
Numro de la version du programme utiliser
Numro de la procdure appeler
Les diffrents paramtres de la fonction et leur type

Un processus dmon se charge de lancer le


dialogue avec le processus de service qui
excutera la procdure souhait
93

La mise en uvre sous UNIX


chaque machine offrant des programmes RPC dispose dun service
dassociation de port dynamique: le port mapper.
Lorsquun programme RPC (serveur) dmarre, il alloue
dynamiquement un numro de port local, puis contacte le port
mapper de la machine sur laquelle il sexcute, puis informe ce
dernier de lassociation (identifier le programme RPC / numro de
port).
Le port mapper maintient une base de donnes renseignant les
associations.
Lorsquun client dsire contacter un programme RPC sur une machine
M, il sadresse au pralable au port mapper de M afin de connatre le
port de communication associ.
Le port mapper sexcute toujours sur le port de communication 111.
94

Nommage dynamique
Machine S
Client sur machine C

Programme serveur

...
Appel (S,... );
...

(6)

...
Register(adr,... );
...

(1)
(3)

(5)

(2)

... adr

adr
Port 111

Portmapper

(4)
95

Problme dhtrognit
Solution de Sun Microsystems
Format eXternal Data Representation ou XDR
Librairie XDR (types de donnes XDR + primitives de
codage/dcodage pour chaque type)
rpc/xdr.h

96

XDR: eXternal Data Representation


Objectif: reprsentation standard des donnes
dfinit comment les donnes doivent tre vhicules sur
un rseau.
permet dchanger des donnes entre machines ayant
des reprsentations internes diffrentes.

Pratiquement:
propose des fonctions de conversion dun objet typ de
sa reprsentation locale vers une reprsentation
normalise et vice versa

97

Principe gnral de XDR


Les processus metteur et rcepteur associent respectivement
leur sortie et leur entre standard un flot XDR dencodage et de
dcodage
XDR: le type dun descripteur de flot

Flot XDR
de
dcodage
Processus

Processus
recepteur

Flot XDR

emetteur

d'encodage

Dcodage

Encodage

98

Oprations de lencodage/dcodage
Principe:
chaque type dobjet correspond une fonction spcifique
agissant comme filtre
Un encodage, un dcodage ou mme une libration
despace allou au cours dun dcodage prcdent sera
ralis selon la nature du flot XDR
Pour chaque type dobjet lmentaire type un filtre xdrtype est associ avec 2 paramtres:
Un pointeur sur un descripteur de flot de type XDR
Un pointeur sur un objet du type correspondant

99

Le traitement de type de base/1


Plusieurs fonctions existent:

Char: xdr_char (XDR *, char *);


Int :
xdr_int(XDR *, int *);
Enum : xdr_enum(XDR *, enum_t *);
String : xdr_string(XDR *ptr_xdr, char **ptr, const
unsigned int longueur_max);
Vector: xdr_vector(XDR *ptr_xdr, void *ptr, unsigned
int longueur, const unsigned int taille_element,
xdrproc_t xdr_type);
Array: xdr_array(XDR *ptr_xdr, void **ptr, unsigned
int ptr_longueur, const unsigned int longueur_max,
const unsigned int taille_element, xdrproc_t xdr_type)
100

Le traitement de type de base/2


xdr_int (xdrs, ip)
XDR *xdrs
Int *ip

xdrs

ip
Forme interne

Sens
Forme rseau

xdr_array (xdrs, arrp, sizep, maxsize, elsize, elproc)


*arrp: pointeur vers tableau
*sizep: nombre dlments de taille elsize
maxsize: nombre max dlments
elproc: filtre xdr pour convertir llment
101

Structure dfinie par lutilisateur


Struct structure {
type_1 champ_1;
type_2 champ_2; ..
type_n champ_n;

xdr_structure(XDR *ptr_xdr, struct structure *ptr_objet) {


return (xdr_type_1(ptr_xdr, &ptr_objet->champ_1)
&&(xdr_type_2(ptr_xdr, &ptr_objet->champ_2) .
&&(xdr_type_n(ptr_xdr, &ptr_objet->champ_n));}

102

Niveaux de programmation RPC


Couche haute:
Le rseau, le S.E et la machine sont transparents
Utilisation des fonctions existantes uniquement

Couche intermdiaire:
Plus intressante pour le dveloppeur
Connaissance minimal de XDR et RPC
Aucune connaissance des sockets

Couche basse
Si les options choisies dans C.I sont insuffisantes
(utilisation de TCP)
Beaucoup plus complexe
103

RPC: Couche haute


Lutilisation du RPC la plus simple
Les fonctions:
Getrpcport:
obtenir le numro de port associe a une version dun
programme donn

Rusers: renvoie le nombre dutilisateurs connects


Rnusers: fournit des informations plus compltes sur les
utilisateurs connects
Rwall: permet de demander lenvoi dun message tous
les utilisateurs de la machine spcifie

104

RPC: Couche intermdiaire


Le point de vue du serveur
Fonction denregistrement
Int registerrpc (

Unsigned long numero-programme,


Unsigned long numero-version,
Unsigned long numero-procedure,
Void *(*fonction)(),
xdrproc_t xdr-parametres,
xdrproc_t xdr_resultat
);

Lattente de clients
void svc_run()
105

Couche intermdiaire (suite)


Leffacement dun service:
Void pmap_unset(
unsigned int numero_programme,
unsigned int numero_version
);

Le point de vue des clients:


Lappel dune fonction:
int callrpc(
char *nom_machine,
unsigned long numero_programme,
unsigned long numero_version ,
unsigned long numero_procedure ,
xdrproc_t xdr_parametres,
void *ptr-parametres
xdrproc_t xdr-resultats,
void *ptr_resultat
);
106

Couche intermdiaire (suite)


Limitations:
Les applications sappuient sur le protocole UDP. Cela
limite la taille des informations.
Aucune procdure dauthentification des requtes nest mise
en uvre
Pas de diffusion

107

RPC: Couche basse


Cette interface nest utilise que lorsque lune au
moins des options adoptes par la couche
intermdiaire nest pas adapte au service
implmenter
Les fonctionnalits fournies:

Cration dun service UDP et TCP


Appel de fonctions diffus (broadcast);
Intgration des mcanismes dauthentification
Permettre des appels asynchrones
Charger le processus inetd de crer dynamiquement le
processus dun service RPC lorsquun client sollicite ce
service
108

Gestion des dfaillances/1


Le client est incapable de localiser le serveur
Le serveur est en panne
Linterface du serveur a chang
Solutions : retourner -1 !!!, exceptions, signaux

La requte du client est perdue


Temporisation et r-mission de la requte

La rponse du serveur est perdue


Temporisation et r-mission de la requte par le
client

109

Gestion des dfaillances/2


Problme : risque de r-excuter la requte plusieurs
fois (opration bancaire !!!!)
Solution : un bit dans len-tte du message indiquant
sil sagit dune transmission ou retransmission

Le serveur tombe en panne aprs rception


dune requte

(i) Aprs excution de la requte et envoi de rponse


(ii) Aprs excution de la requte, avant lenvoi de la
rponse
(iii) Pendant lexcution de la requte
Comment le client fait-il la diffrence entre (ii) et (iii) ?
110

Gestion des dfaillances/3


Trois coles de pense (smantiques)
Smantique une fois au moins : le client r-met jusqu
avoir une rponse (RPC excut au moins une fois)
Smantique une fois au plus : le client abandonne et
renvoie un message derreur (RPC excut au plus une
fois)
Smantique ne rien garantir : le client na aucune aide
(RPC excut de 0 plusieurs fois)

Le client tombe en panne aprs envoi dune


requte
Requte appele orphelin. Que doit-on en faire ?
111

Gestion des dfaillances/4


Solutions de Nelson
Extermination : Le client utilise un journal de trace et tue les
orphelins : solution coteuse en espace et complexe
Rincarnation : Dfinition de priodes dactivit incrmentale
du client. Aprs une panne, il diffuse un message indiquant
une nouvelle priode. Ses orphelins sont dtruits.
Rincarnation douce : variante de la prcdente. Un orphelin
est dtruit seulement si son propritaire est introuvable.
Expiration : Chaque RPC dispose dun quantum q de temps
pour sexcuter. Il est dtruit au bout de ce quantum. Pb :
valeur de q ?
Problme de ces solutions : si lorphelin dtruit a verrouill
des ressources ?!!!

112

RPC : rpcgen
Rpcgen est un outil de gnration de logiciel produisant

le talon client,
Le talon serveur,
les procdures XDR pour les paramtres et les rsultats,
un fichier contenant les dfinitions communes.

SUN fournit une mthodologie complte assiste par:


les routines de conversion XDR pour les types simples,
les routines XDR qui formatent les types complexes (tableaux et
structures) utiliss dans la dfinition de messages RPC,
les fonctions run-time RPC qui permettent un programme
dappeler une procdure distante, enregistrer un service auprs du
port mapper , dispatcher une requte dappel de procdure vers la
procdure associe, lintrieur du programme distant;
113

RPC : rpcgen
rpcgen produit quatre fichiers source dont les noms sont drivs du
nom de la spcification en entre. Si le fichier en entre est Q.x, les
fichiers gnrs sont:
Q.h : dclarations des constantes et types utiliss dans le code gnr pour
le client et le serveur,
Q_xdr.c : procdures XDR utiliss par le client et le serveur pour
encoder/dcoder les arguments,
Q_clnt.c : procdure stub ct client,
Q_svc.c : procdure stub ct serveur.

114

RPC : rpcgen
Client application

Q.x

Q_clnt.c

compiler
Q.h

rpcgen

client
server

Q.xdr.c

compiler
Q.svc.c

remote procedures
115

Langage RPCL
spcification du prog, de la version et des fonctions
program nom-programme {
listes-versions
}=numero-programme;

Listes-versions est la concatnation de:


Version nom-version {
liste-procedures
}=numero-version

Listes-procedures est la concatnation de:


Type-resultat nom-procedure(type-parametre)=numeroprcedure,

La dfinition de constantes et de types


Const identificateur=valeur-entiere;

Les structures sont dfinies de la mme manire quen C


116

Exemple RPC
La couche intermdiaire
Laddition de deux entiers en utilisant une procdure
add distance
En entre: 2 entiers
En sortie: un entier (la somme de deux entiers de lentre)

Mthode:
La mise en uvre de cette application ncessite trois
fichiers:
Fichier commun
Fichier serveur
Fichier client
117

Fichier commun xdr_couple.c


#include <stdio.h>
#include <rpc/types.h>
#include <rpc/xdr.h>
#define ADD_PROG 0x23333333
#define ADD_VERS1 1
#define ADD_PROC 1
struct couple {
int e1;
int e2;};

xdr_couple(xdrp, p)
XDR *xdrp;
struct couple *p;
{return (xdr_int(xdrp, &p->e1)&&(xdr_int(xdrp, &p->e2));
}
118

fichier serveur
#include "xdr_couple.c"
Char *add(p)
struct couple *p;
{ static int res;
Res=p->e1+p->e2;
Return((char*)&res);
}
main()
{ int rep;
rep=registerrpc(ADD_PROG, ADD_VERS1,ADD_PROC,add, xdr_couple, xdr_int);
if (rep==-1)
{ fprintf("erreur registerrpc (ass)\n");
exit(2);}
Svc_run();
Exit(3);
}
119

Fichier client
#include "xdr_couple.c"
Main(n,v)
Char *v[];
Int n;
{
Struct couple don;
Int res;
Int op, m;
don.e1=12;
don.e2=5;
m=callrpc(v[1], ADD_PROG, ADD_VERS1, ADD_PROC, xdr_couple, &don, xdr_int,
&res);
If (m==0)
//visualiser la somme de e1 et e2
Else
//message derreur
120

Modle Web
Historique
Dbut 1990: apparition du premier prototype au CERN (Conseil Europen pour
la Recherche Nuclaire) dun systme pour amliorer la diffusion des
informations internes (1986 les bases, 1991 premier serveur).
Cration dun logiciel "World Wide Web" en C par Tim Berners-Lee
capable de consulter un serveur HTTPD (HyperText Transfer Protocol
Daemon)
World Wide Web sappuie sur un protocole applicatif permettant de passer
automatiquement du document consult un autre document li:
lhypertexte
But affich: tre en mesure de centraliser les applications et de les consulter
sur un poste client lIHM volue

121

Architecture
Exemple:

122

World Wide Web


1991- Lancement officiel du Web
1991- Premier navigateur en mode texte
1992- Dveloppement des premiers navigateurs graphiques
violawww, Lynx

1993- Lancement de Mosaic


1994- Lancement de Netscape Navigator
1994- Fondation du W3C
1995-- Commercialisation du Web

123

W3C
www.w3.org
Processus de recommandation en quatre principales tapes:

Working Draft (WD)


Candidate Recommendation (CR)
Proposed Recommendation (PR)
W3C Recommendation (REC)

Exemples de spcifications:
HTML, CSS, XML, XHTML, SOAP, WSDL, .

124

Les acteurs du Web


CERN (Conseil Europen pour la Recherche Nuclaire)
NCSA (National Center for Supercomputing Applications)
W3C (World Wide Web Consortium) fond en 1994. initialement
MIT+CERN+INRIA+Universit de Keio puis de nombreux autres
Unifier les dveloppement
Proposer une recommendation
IETF: crer les standards (RFC)
Microsoft, IBM, Sun,
Standards de fait (frames, cookies, plug-in,)

125

Les normes
Le Web sappuie sur des "normes":
HTTP comme protocole de transfert dinformations entre client et serveur

RFC 1945 (septembre 1997): HTTP 1.0


RFC 2616 (Juin 1999): HTTP 1.1
Une syntaxe dadressage des ressources: les URL/URI/URN

RFC 3986 (Janvier 2005): dfinition de la syntaxe des URI


Un langage de description dactions excuter:
ECMA-357 (dcembre 2005): 2ime version de lECMAScript
(Netscape et Microsoft ont chacune leurs variantes)

126

La norme HTTP: fonctionnement


Bas sur un paradigme requte/rponse
Etablissement par le client dune connexion puis envoi dune
requte sous la forme:
Mthode-URI-version du protocole utilis par le client
Entte de la requte
Corps de la requte
Rponse du serveur sous la forme:
Ligne de statut
Entte de la rponse
Corps de la rponse
Dconnexion du serveur

127

HTTP: les mthodes


Mthode GET:
Rcupre le contenu de la ressource identifi par lURI
Peut tre associe lentte if-modified-since pour une rcupration
conditionnelle (emploi du cache)

Mthode HEAD
Identique GET mais rcupre seulement lentte de la rponse
Utilise a des fins dhyperliens (vrification dexistence)

Mthode POST
Envoi de donnes au serveur sur lURI spcifie

128

HTTP: les mthodes


Mthode PUT:
Demande au serveur denregistrer lentit sous lURI vis

Mthode DELETE:
Demande de suppression de ressource

Mthode LINK:
Demande dtablissement de liaisons entre lURI vise et
dautres ressources

Mthode UNLINK:
Suppression de liaisons entre lURI vise et dautres
ressources

129

HTTP: lentte de requte


Permettent la transmission dinformation complmentaires
Sur la requte
Sur le client lui-mme
Agissent comme modificateurs de la requte
Format: nom_entte: valeur de lentte
Des enttes sont normaliss, le reste est considr comme des
champs dentte propres lentit

130

Exemple
Requte:
Connect to 196.200.135.4 on port 80 ... ok
GET / HTTP/1.1
Host: www.ensias.ma
Connection: close
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Accept-Encoding: gzip
Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7[
Cache-Control: no
Accept-Language: de,en;q=0.7,en-us;q=0.3
Referer: http://web-sniffer.net

131

Exemple
Rponse:
HTTP/1.1 200 OK
Date : Wed, 04 Feb 2009 04:51:56 GMT
Server : Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
Set-Cookie: 3a43d2b0aad33b43e1269c3f820247b5=-; path=/
Content-Type : text/html; charset-UTF-8
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Wed, 04 Feb 2009 04:59:26 GMT

Outil de visualisation des enttes http: http://web-sniffer.net/

132

132

HTTP: lentte de requte


MIME (Multipurpose Internet Mail Extensions)

Sert typer les documents transfrs par HTTP


Format: Content-type: type_mime_principal/sous_type_mime
Exemple: Content-type:image.gif
Les grands types MIME: TEXT, APPLICATION, IMAGE, AUDIO,
VIDEO, MESSAGE, MULTIPART (mixed, alternative, parallel,)

133

HTTP: La rponse du serveur


Les principaux codes dtat:
1xx: indique une rponse provisoire
2xx: les succs
3xx: les redirections
4xx: les erreurs clients
5xx: les erreurs serveurs

134

134

HTTPS
HTTPS nest pas une norme mais une encapsulation
dHTTP au sein du protocole SSL dcrit dans la RFC
2246
Les donnes envoyes sont encapsules dans une structure
Le destinataire de la structure dchiffre la structure de
donnes de manire avoir les donnes originales

135

HTTP: les URI

URI pour Uniform Ressource Identifier


Permet didentifier la ressource que lon souhaite consulter
Format: nom de schema: chemin daccs la ressource
Exemples:
ftp://ftp.iana.com:rfc/rfcxxx.txt
mailto:webaster@ensias.ma
http://www.google.fr
Le schema HTTP
Format: http://nom-serveur ou adresse IP[:port]/chemin-absolu
Port=80 par dfaut

136

HTTP: les URI


Liste des schemas grs par lIANA (Internet Assigned Numbers Autority)
sur http://www.iana.org/numbers.html

Exemple:
RFC 2817: HTTP
RFC 4289: MIME
Possibilit de rcuprer un fragment dune URI:
http://www.ensias.ma/index.htm#section

Un chemin au sens HTTP est diffrent de son emplacement physique


Dfinition des chemins par les logiciels serveurs

137

MAIS Comment faire pour ces


applications?
surveillance de ltat de machines, de systmes
d exploitation et d applications
flot continuel de donnes en provenance de sources
diverses sur le rseau
les lments du systme peuvent apparatre,
disparatre, migrer, etc.
les administrateurs doivent pouvoir accder
l information quel que soit leur localisation
138

Solution traditionnelle
interrogation rgulire des lments surveiller par
l application d administration et m--j dune base de
donnes centralise
utilisation dune configuration complexe afin de connatre
lensemble des lments surveiller
maintien de cette configuration lorsque des machines ou des
applications rejoignent, quittent ou se dplacent dans le
systme

interrogation par les administrateurs de la base


centrale
139

MOM
MOM (Message Oriented Middleware)
Solution base sur les messages:
les diffrents lments administrs mettent des messages:

chgt dtat et de configuration


alertes, statistiques
un ou plusieurs dmons reoivent ses notifications et
maintiennent ltat courant du systme

suivi des chgts de configuration dynamique


mission de messages signalant les changements
dtat significatifs ou les mises jour

analogie:
mail (asynchronisme), liste de diffusion (multicast), News
(subject based)
140

MOM (suite)
Objectif: transport de linformation sous forme des
messages indpendants
Supporte les communications synchrones et
asynchrones
Les middleware bass sur les messages sont de 3
catgories:
Message passing
Message queuing
Publication/abonnement

141

Message Passing
Modle de communication directe: program-to-program
Intressant pour les applications fortement lies et
dpendant du temps
supporte les modes synchrone et asynchrone
supporte des connexions concurrentes vers plusieurs
serveurs
Exemple:
PIPES de PeerLogic.
MPI (Message Passing Interface) est un standard:
bibliothques de communication par passage de messages.

142

Message Queuing
Remplace la connexion directe entre les applications par
une queue de messages
Communication point point
indpendance de lmetteur et du destinataire
Anonymat:
lmetteur n a pas reconnatre l identit du destinataire; il
peut le designer par un nom logique, de groupe ou par un
ensemble de proprits

gestion de lhtrognit:
des donnes, des systmes et des systmes de
communication

143

Message Queuing
Cela facilite:
Implmentation des politiques de priorit
Balancement de la charge (+ serveurs prlvent
messages de la mme queue)
Gestion dapplications tolrantes aux pannes
Amlioration des performances (client non bloquant)

144

Message Queuing

145

Gestionnaire de messages
Responsable de la gestion de queues de
messages
services fournis:
dlivrance fiable des messages
garantir la dlivrance des messages
garantir la non-duplication des messages dlivrs

Gestion de la priorit
ordonnancement

146

Gestionnaire de messages
La gestion de la persistance des messages:
les queues de messages non-persistants sont perdus aprs
un arrt du systme
les queues de messages persistants sont stocks sur le
disque

performance: les queues de messages nonpersistants


fiabilit: les queues de messages persistants
le choix dpend de lapplication
147

Exemples
Message Queuing est un modle de
communication trs utilis dans les MOM
actuels:
MSMQ (Microsoft)
MQSeries (IBM)
JMS (SUN)

Modle facile utiliser pour interconnecter les


applications

148

Limitations
Message queuing a ses limites:
lmetteur doit connatre le nom et ladresse du
destinataire
envoi un groupe: plusieurs envois, un pour chaque
destinataire

149

Publication/Abonnement
Publication/Abonnement est similaire
labonnement dans un journal
le message est envoy un gestionnaire qui se
charge de le rpartir ceux qui se sont abonns
ce type de message
Communication multipoint

150

Publication/abonnement (suite)
Permet aux client (ou aux composants serveur )
de faire connatre leur intrt pour certains
messages en se faisant enregistrer auprs dun
gestionnaire dvnements.
Il y a 2 types de participants:
fournisseurs (providers) qui envoient des vnements
dans le systme
consommateurs (consumers) qui sabonnent certaines
catgories d vnements du systme sur certains
critres
151

Critres dabonnement
Il existe deux politiques d abonnement:
subject-based: la plus rpondue et la plus utilise.
propose par l interface JMS (Java Message Service) de
SUN
content-based: une alternative la technique subjectbased. Elle permet un filtrage parmi les diffrentes
valeurs

content-based est plus gnral car il peut tre utilis


pour implmenter le subject-based

152

153

Les principales caractristiques


Dcouplage des applications:
possibilit d'ajouter ou d'enlever un diteur ou un abonn
sans impacter le fonctionnement du systme.

Rapidit d'change des messages :


utilis dans environnement fort volumtrie et temps
contraint, il utilise gnralement des protocoles de transport
naturellement ddis ce mode de communication tels que
IP multicast.

154

Exemple : Tibco
Inventeur de la technologie:
http://www.tibco.com
Architecture: bus de messages

Protocole fiable de multicast


Un dmon par host pour mettre et recevoir
Routeurs intelligents de messages
Proprits:
Routage de messages en fonction de leurs sujets
Fiable et garantie de dlivrance

155

Synthse
Communication
synchrone

Message
passing

Communication
asynchrone

Concentration
de messages

Scurit

diffusion

Message
Queuing

Publication/A
bonnement

156

Implantation
Serveur centralis (Hub &
spoke)
Simplicit de mise en
uvre
Peu tolrant aux pannes
Passage lchelle difficile

client

client

Serveur
client

client

157

Implantation
Serveur rparti (Snow flake)
Chaque serveur connat un
ensemble dautres serveurs
Routage des messages
Rpartition de la charge
Fiabilit relative
Passage lchelle

client

client

client

serveur

serveur

client

serveur

serveur
client

158

Support des MOMs sur


J2EE et .NET
J2EE
Spcification JMS (Java Messaging Service)
Support les MQ et Pub/abon.
Composants logiciels: JORAM, OpenJMS (OpenSource)

.NET
MSMQ (MicroSoft Message Queuing)
Service a fait son apparition dans Windows NT4
Support uniquement les MQ

159

TPM: Transaction Process Monitors

Contrle le traitement des transactions dans les


bases de donnes
implment comme middleware 3 niveaux
Gestion des communications client/serveur:
Invocation des composantes de lapplication au
moyen de plusieurs paradigmes :RPC, MOM,...

160

Proprits des transactions


Principe ACID:
Atomicit: excution selon le principe du tout-ou-rien.
Cohrence: lexcution garde la cohrence des donnes de la
BD
Isolation: les mises jours d une transaction nont pas
deffets visibles avant sa fin.
Durabilit: leffet dune transaction doit tre durable.
Mme aprs une panne.

161

Transactions rparties
Une transaction rpartie implique plusieurs sites.
Un client demande le transfert d'argent entre deux de ses comptes
Un client demande le transfert d'argent entre comptes dans des
banques diffrentes.

On a deux types de transactions rparties:

Transactions simples
Site
Client

T11

Site X

Site Y

T1
T21

Site
Client
T2

T22

Transactions imbriques
Site Z
162

Transactions imbriques
Utilises lorsqu une transaction ncessite la collaboration
de plusieurs sites:
Retrait(A,1000)

Retrait(B,2000)

Client

Dpt(C,1000)
Dpt(D,2000)

163

Protocole tow-phase commit


Protocole de validation 2 phases
Utile pour les oprations sur plusieurs sites
Synchronise les mises jour
Standard OSI-TP de lISO dfinit limplmentation du
protocole: 1992

164

Quand faut-il utiliser un TPM


Daprs Standish Group, un TPM est intressant
utiliser pour Les applications C/S :
qui ont plus de 100 clients
Traite plus de 50 transactions par minute
Utilise plus de 3 serveurs physiques et/ou plus dune base
de donnes

165

Support TPM sur


J2EE et .NET
J2EE
Spcification JTS (Java Transaction Service)
Spcification JTA (Java Transaction API) dcrit la
communication de JTS avec les applications

.NET
MTS (MicroSoft Transaction Server)
DCOM est le mcanisme responsable de la communication
entre les clients et les composants MTS

166

Middleware Orient Objet


Les middlewares les plus connus sont:
CORBA (Common Object Request Broker
Architecture) de OMG
DCOM (Distributed Common Object Model) de
Microsoft
OTM (Object Transaction Monitor) utilise la
technologie objet en plus de la robustesse et les
performances des moniteurs TP

167