You are on page 1of 38

Informatique

Architecture client serveur

Larchitecture client serveur

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 1/38

Informatique

Architecture client serveur

PLAN
I. Introduction A. Caractristiques des grands systmes B. Caractristiques de larchitecture client serveur II. Quest-ce que le modle client serveur ? A. La classification du Gartner Group B. Caractristiques des systmes client serveur. III. Les diffrentes catgories de client serveur A. Serveur de fichier B. Serveur de bases de donnes C. Serveur de transactions D. Serveur de groupware E. Serveur dobjets F. Serveur Web IV. Les cubes du jeu de construction A. Prsentation B. Anatomie dun client C. Anatomie dun serveur V. Les briques de base du middleware A. A chacun son middleware B. Principes des techniques de communication VI. Le middleware SQL A. Rappels SQL B. Interface SQL appel direct (CLI) C. Linterface CLI ODBC de Microsoft VII. Client serveur et INTERNET A. Prsentation B. Technologies C/S derrire le Web : les fondations C. Interaction entre un client et un serveur web D. Les formulaires, le protocole CGI E. Conclusion VIII. Glossaire

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 2/38

Informatique

Architecture client serveur

IX. Annexes A. NOTIONS DOBJETS B. Workflow C. Multithreading

Bibliographie
Client serveur : guide de survie (ORF0ALI, HARKEY, EDWARDS : International Thomson Publishing) Client serveur (G. et O. GARDARIN : Eyrolles) Intranet client-serveur universel (Alain Lefebvre : Eyrolles) Dcision micro & rseaux (N 380 avril mai 1999)

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 3/38

Informatique

Architecture client serveur

I. Introduction
En quelques annes, larchitecture informatique a volu des grands systmes centraliss vers une architecture client serveur, dernier cri en matire de plate-forme ouverte. A. Caractristiques des grands systmes Machine norme comportant un systme dexploitation unique. Rseau frontal tentaculaire raccordant tous les terminaux. Stockage de masse par disques et bandes magntiques. Organes de surveillance et de maintenance. Mthodes de dveloppement et AGL propritaires.

Cet ensemble tait fourni par un seul constructeur qui constituait linterlocuteur unique. Le mtier dinformaticien tait relativement confortable : les volutions taient simples et planifies. Cette architecture assurait emploi et plan de carrire.

Terminaux passifs Bases de donnes Applications

Systme dexploitation

Exemple darchitecture centralise B. Caractristiques de larchitecture client serveur Cette architecture ce distingue par la facult de pouvoir mlanger et apparier des composants tous les niveaux. Llaboration dune solution informatique est entirement la carte. Aussi, larchitecte est-il confront des choix trs complexes. quelle plate forme serveur ? quelle plate forme client ? quels protocoles rseau ? quel serveur de bases de donnes ? quel middleware ? quels outils de gestion du systme ? quelle technologie utiliser pour btir des applications ? - serveur de bases de donnes, - moniteur transactionnel ?

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 4/38

Informatique

Architecture client serveur

- groupware ? - objets rpartis ? - internet, intranet ? Contrairement aux solutions entirement propritaires, larchitecte est seul (ou presque) pour assembler le tout et le faire fonctionner : il est lintgrateur du systme.

SERVEUR SGBD OS/2, UNIX, NOVELL, WINDOW NT Requtes Rsultats Rseau d entreprise Donnes

WINDOWS Applications

OS/2 Applications

UNIX Applications

Architecture moderne des annes 80

II. Quest-ce que le modle client serveur ?


A. La classification du Gartner Group Larchitecture client serveur est un mode de dialogue entre deux processus : le client demande lexcution de services au serveur qui retourne les rponses. Le serveur doit bien sr tre en mesure de traiter les requtes de plusieurs clients. La classification du Gartner Group dpend de la rpartition de trois fonctions : graphiques : affichage et saisie des donnes gestion des donnes : accs aux fichiers ou aux bases de donnes. Excution du code applicatif. 1. Le client serveur de prsentation

Ce type darchitecture permet dassurer une meilleure qualit du dialogue homme machine. Dfinition : Type darchitecture client serveur dans lequel un processus excute seulement les fonctions de dialogue avec lutilisateur, lautre gre les donnes et excute le code applicatif.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 5/38

Informatique

Architecture client serveur

Remarque : la dfinition correspond exactement la description du schma, sauf que lon ne prcise pas qui est le client, qui est le serveur. Toute lambigut rside dans le fait que lon peut appliquer le raisonnement client serveur aux machines ou au processus. Le processus qui excute le code applicatif sadresse un autre pour les entres / sorties graphiques. Selon la dfinition, il est le processus client mais est hberg par la machine serveur. On parle alors de dialogue client serveur invers. Client

Serveur

2.

Le rhabillage ou revamping

Ce type darchitecture caractrise la transformation des anciennes applications centralises : une machine cliente intelligente capable dexcuter une interface graphique sophistique vient remplacer un terminal mode caractre. Lobjectif est bien entendu de minimiser les modifications de lapplication initiale Dfinition : Type darchitecture client serveur dans lequel un processus excute seulement la fonction de dialogue sophistiqu avec lutilisateur. Lautre processus gre les donnes, excute le code applicatif et assure le dialogue simplifi avec lutilisateur. L encore, le dialogue client serveur est qualifi invers. Client

Serveur

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 6/38

Informatique

Architecture client serveur

3.

Client serveur de donnes

Cest larchitecture la plus rpandue. Exemple : un PC accde des donnes partages gres par un serveur SQL. Dfinition : type darchitecture dans lequel un programme dapplication, contrl par une interface de prsentation sur une machine cliente, accde des donnes sur une machine serveur par des requtes. Cette architecture est qualifie de premire gnration. Client

Serveur

4.

Client serveur de procdures

Cest une volution de larchitecture prcdente. La base de donnes intgre des procdures stockes : procdures applicatives recevant des paramtres dentre et retournant des paramtres de sortie. Dfinition : type darchitecture client serveur dans lequel un programme applicatif contrl par une interface de prsentation sur une machine cliente, sous-traite lexcution de procdures applicatives une machine serveur. Remarque : le serveur de procdures inclue un serveur de donnes bas sur SQL. Le client peut donc accder aux donnes directement via SQL ou appeler des procdures qui manipulent les donnes. Le client serveur de procdures est en fait une architecture client serveur de donnes et procdures. Client

Serveur

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 7/38

Informatique

Architecture client serveur

5.

Systme rparti

Larchitecture systme rparti est une architecture client serveur de donnes et procdures dans laquelle le client peut accder des donnes qui sont rparties sur plusieurs serveurs mais peuvent galement tre gres en local.

Client

Serveur

B. Caractristiques des systmes client serveur. Ce paragraphe prsente les lments qui caractrisent une architecture client serveur. 1. Service

Le modle client serveur est une relation entre des processus qui tournent sur des machines spares. Le serveur est un fournisseur de services. Le client est un consommateur de services. 2. Partage de ressources

Un serveur traite plusieurs clients et contrle leurs accs aux ressources. 3. Protocole asymtrique

Consquence du partage de ressources, le protocole de communication est asymtrique : le client dclenche le dialogue ; le serveur attend les requtes des clients. 4. Transparence de la localisation.

Larchitecture client serveur doit masquer au client la localisation du serveur (que le service soit sur la mme machine ou accessible par le rseau). Transparence par rapport aux systmes dexploitation et aux plates-formes matrielles. Idalement, le logiciel client serveur doit tre indpendant de ces deux lments. 5. Messages

Les messages sont les moyens dchanges entre client et serveur.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 8/38

Informatique

Architecture client serveur

6.

Encapsulation des services.

Un client demande un service. Le serveur dcide de la faon de le rendre une mise niveau du logiciel serveur doit tre sans consquence pour le client tant que linterface message est identique. 7. Evolution

Une architecture client serveur doit pouvoir voluer horizontalement (volution du nombre de clients) et verticalement (volution du nombre et des caractristiques des serveurs). Larchitecture client serveur correspond la rpartition de lintelligence sur le rseau.

III.Les diffrentes catgories de client serveur


Les diffrentes architectures client serveur peuvent tre classes en fonction du service rendu aux utilisateurs. A. Serveur de fichier Le client (gnralement un PC) requiert des enregistrements de fichiers en mettant des requtes sur le rseau en direction dun serveur de fichier.

Application

Application Clients

Serveur de fichiers

Client / serveur avec serveur de fichiers Caractristiques. - Trs utilis ce jour (partage de fichiers sur le rseau). - Forme primitive de service de donnes. - Nombreux changes de messages sur le rseau pour obtenir le rsultat. - Indispensable pour les banques de documents, dimages etc.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 9/38

Informatique

Architecture client serveur

B. Serveur de bases de donnes Le client met des requtes SQL sous forme de message. Le serveur renvoie le rsultat de chaque requte.

Application Serveur de bases de donnes

Application Clients

Client / serveur avec serveur de bases de donnes Caractristiques. - Meilleure rpartition de la puissance : le serveur utilise sa capacit de traitement (SGBD) pour slectionner les rponses. - Ncessit dcrire du code pour lapplication cliente. - Cest la base des systmes daide la dcision.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 10/38

Informatique

Architecture client serveur

C. Serveur de transactions Le client invoque des procdures distantes rsidant sur le serveur qui comporte un moteur de bases de donnes. Chaque procdure correspond un ensemble de requtes SQL appel transaction. Lchange consiste en un message requte / rponse, .contrairement au cas prcdent ou il y a un message par instruction SQL. Le code applicatif est rparti sur le client et le serveur. Cot serveur, il porte le nom de traitement de transaction en ligne OLTP (On Line Transaction Processing). Il existe deux formes de transactionnel : transactionnel lger : les procdures sont fournies par lditeur du SGBD. Transactionnel lourd : moniteurs transactionnels fournis par lditeur dapplications OLTP.

Application

Application Clients

Base de donnes Moniteur TP

Client / serveur avec serveur de transactions D. Serveur de groupware Le groupware est fond sur 5 technologies de base : gestion de documents multimdia workflow (Annexes page 37) courrier lectronique gestion de confrences planification de runions

Il ny a pas de produit groupware regroupant toutes ces technologies qui ont une particularit commune : tout se passe comme sil sagissait dune relation de client client et non une relation client serveur. Les applications sont cres laide dun langage de script et des gabarits dinterface fournis par le vendeur. Le middleware est galement spcifique de lditeur.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 11/38

Informatique

Architecture client serveur

Application Clients

Serveur de groupware

Client / serveur avec serveur de transactions E. Serveur dobjets Lapplication client serveur est crite sous forme dobjets communiquants. Les objets client communiquent avec les objets serveur au moyen dun ngociateur de requtes objet ou ORB (Object Request Brocker). Fonctionnement : (Annexes page 36) Le client appelle une mthode appartenant une classe du serveur objet. LORB localise une instance de la classe, appelle la mthode demande et renvoie le rsultat lobjet client. Les serveur dobjets doivent bien sr traiter le partage des objets. Quelques ORB sont conforme au standard CORBA de lOMG. -

Application

ORB ORB

ORB

Objet Clients
Client serveur avec objets distribus

Objets

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 12/38

Informatique

Architecture client serveur

F.

Serveur Web

Il sagit dune rvolution dans larchitecture client serveur. Elle a t possible grce la croissance de la bande passante et lapparition des systmes dexploitation multithread (Annexes page 37) dots de fonctionnalits rseau. Cest le pays de cocagne du client serveur : toute machine situe sur une autoroute de linformation peut tre la fois client et serveur. Un graphique complet sera prsent plus loin.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 13/38

Informatique

Architecture client serveur

IV.Les cubes du jeu de construction


A. Prsentation
e

Spcifique du service
SQL/ TxRPCCourrier ORB DAPI

id d

Client

lew ar

Serveur

GUI/OOUI

SNMP

CMIP

DME

DSM

Fichiers Annuaires Scurit distribus RPC Files d attente gal Egal

NOS

Objets Groupware OLTP SGBD

DSM

OS

Piles de transport
Netbios TCT/IPIPX/SPX SNA

OS

Bien que les chapitres qui suivent ne traitent que du middleware SQL et Web, ce paragraphe traitera larchitecture client serveur en gnral. 1. Le cube client

Client

GUI/OOUI

DSM

OS

Il excute la partie cliente de lapplication et tourne sous un systme dexploitation qui fournit linterface graphique utilisateur. On distingue deux sortes dinterfaces graphiques : - GUI (graphic user interface) - OOGUI (object oriented graphic user interface) Le cube client accde des services rpartis et passe la main au middleware pour les services non locaux. En gnral, il excute galement un composant de ladministration du systme complet. (DSM : gestionnaire distribu de systme)

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 14/38

Informatique

Architecture client serveur

2.

Le cube serveur

Serveur

Objets Groupware OLTP SGBD

DSM

OS
Le cube serveur excute la partie serveur de lapplication. Celle-ci sinstalle par dessus un logiciel serveur spcifique au type dapplication : - objets, - web, - groupware, - OLTP, - SGBD. Le systme dexploitation assure linterface avec le cube middleware. Le cube serveur excute galement un composant DSM : soit un agent de celui-ci, soit la partie serveur de ce logiciel. 3. Le cube du middleware

Middleware
Spcifique du service
SQL/ TxRPCCourrier ORB DAPI

DSM
SNMP CMIP DME Fichiers Annuaires Scurit distribus Files Egal gal RPC d attente

NOS

Piles de transport
Netbios TCT/IPIPX/SPX SNA

Il se trouve sur la partie client et serveur dune application. Le middleware peut tre dcompos en trois parties : - piles de transport, - systme dexploitation rseau, - middleware spcifique au service rendu. A ces trois parties, il faut ajouter les composants du DSM.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 15/38

Informatique

Architecture client serveur

4.

Les relations entre serveurs

Ces relations sont par nature de type client serveur. Un serveur est client dun autre serveur. Cependant, certaines actions ncessitent un middleware spcifique : on peut citer par exemple le protocole de validation deux phases (two phase commit) qui intervient dans la validation des requtes multi-serveur. B. Anatomie dun client 1. Les diffrents clients

Le cube client fournit laspect, la prsentation des services offerts par le systme. Toutes les applications clientes ont une fonction commune : elle rclament les services dun serveur. Elles se diffrencient par contre par la faon dont elles dclenchent leurs requtes et par linterface graphique. On distingue ainsi les clients sans interface graphique les clients interface graphique les clients interface graphique oriente objet. 1.1. Clients sans interface graphique

Testeurs, fax, stations service intelligentes, tlphones cellulaires, robots, lecteurs de codes barres, ardoises intelligentes se caractrisent par un minimum dinteraction humaine. Certaines de ces applications peuvent ncessiter des services multitches. 1.2. Clients interface graphique

Les requtes au serveur rsultent de linteraction entre lutilisateur et linterface graphique. Ces applications graphiques clientes sont en gnral la transcription graphique des dialogues qui sinstauraient auparavant sur des terminaux passifs. Le dialogue relve du modle objet/action dans lequel lutilisateur choisit lobjet traiter puis la commande lui appliquer. Il sagit de linterface courante pour les applications OLTP et serveur bases de donnes. Ce modle dinteraction avec lutilisateur est appel modle graphique CUA 89 (exemple : Windows 3.X, OSF Motif). 1.3. Client interface graphique oriente objet

Ces applications sont utilises par des personnes qui effectuent des tches multiples, variables et sans ordre prdfini. Les objets du bureau communiquent entre eux et avec les serveurs externes par des dialogues en temps rel, interactifs et simultans. En gnral, on ne sait pas o commence lapplication et o finit le bureau du systme. Les objets et programmes du bureau peuvent tre runis pour accomplir une tche (exemple : le dpt de lobjet rservation sur licne fax provoque la transmission du fax de rservation). Dans ce type dinterface, lapplication est transparente lutilisateur ou du moins ses limites sont floues : le bureau est une collection dobjets qui cooprent et de fentres associes ces objets. A linverse, dans une interface GUI, lapplication est lance en cliquant sur une icne. A partir de l, il faut utiliser les menus et sous menus : la structure de travail est rigide, les contours de lapplication nets.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 16/38

Informatique

Architecture client serveur

2.

LOS du client

Le tableau ci-dessous prsente les caractristiques de lOS dune machine cliente. Le cas de linterface non GUI nest pas prsent car il sloigne du contexte de ce cours.

Dispositif de lOS

Client GUI

Client OOUI
OUI OUI OUI OUI OUI OUI OUI OUI OUI

Mcanisme de requte / rponse (de prfrence OUI avec transparence local / distant) Transfert de fichiers textes, dextraits de bases de donnes Multitche premptif (1) Prioritisation des tches Communications interprocessus dimages, OUI Prfrable Prfrable Prfrable

Threads (2) pour communications darrire OUI (sinon : sablier) plan avec le serveur et rception des appels OS robuste avec protection intertches et Prfrable appels OS rentrants (3) Modle graphique CUA 89 Interface OOUI OUI NON

(1) Premptif : lorsquune une ressource est attribue un processus, elle peut lui tre retire (pour attribution un autre processus) sans provoquer de dysfonctionnement si le systme est premptif. (2) En utilisant des threads diffrents pour linterface utilisateur et les tches darrire plan, le programme peut rpondre aux actions de lutilisateur alors quun thread spar prend en charge la relation avec le serveur. (3) Rentrants : les primitives du noyau peuvent tre utilises par plusieurs processus applicatifs. 3. Evolution

Lintelligence et les donnes se dportent de plus en plus vers le cube client. Aussi, dans cette volution, les OS clients doivent tre en mesure de fournir une fonction de serveur lger car : les clients bases de donnes conservent localement des extraits de tables, les clients moniteurs transactionnels coordonnent les transactions multiserveur, les clients groupware grent les files dattente, les clients multimdia enregistrent les dossiers en entre et en sortie et les clients objets rpartis acceptent des requtes dobjets situs nimporte o.

Par opposition un serveur complet, un serveur lger na pas besoin de supporter laccs simultan des ressources partages, lquilibrage de la charge et les communications multithread.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 17/38

Informatique

Architecture client serveur

C. Anatomie dun serveur 1. Les activits dun serveur

Le rle dun serveur est de fournir des services de multiples clients intresss parses ressources partages. Voici les principales activits qui en dcoulent. 1.1. Attente des requtes mises par les clients

Un serveur passe le plus clair de son temps attendre les requtes de ses clients qui lui parviennent sous forme de messages. Plusieurs techniques peuvent tre mises en uvre pour traiter ces requtes : assignation dune session particulire chaque client, cration dun jeu dynamique de sessions rutilisables, solution mixte.

La performance dun serveur sera lie son aptitude rpondre tous ses clients en affrontant les heures de pointe. 1.2. Excution simultane de nombreuses requtes

Un client ne doit pas monopoliser les ressources dun serveur et celles-ci doivent rester intgres. Pour cela, un serveur doit tre multitches, multithread et protger ses ressources partages. 1.3. Attribution de priorits

Un serveur doit tre en mesure de proposer diffrents niveaux de priorit ces clients. Une impression, un traitement par lots peuvent tre diffrs lorsque survient un traitement transactionnel. 1.4. Lancement et excution de tches de fond

Certaines tches indispensables mais non lies un besoin immdiat doivent pouvoir tre lances et excutes en tches de fond. Citons par exemple, le rafrachissement H+24 dune base de donnes. 1.5. Fonctionnement ininterrompu

Un programme serveur est une application critique devant fonctionner 24 heures sur 24 sans rupture de service. Le serveur et son environnement doivent donc tre particulirement robustes. 1.6. Voracit

Linflation des besoins en mmoires et puissance est permanente. Le programme serveur et son environnement doivent tre volutifs.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 18/38

Informatique

Architecture client serveur

2.

LOS dun serveur

Les services de base font partie dun systme dexploitation (serveur) de base tandis que les services tendus sont des composants logiciels modulaires complmentaires. La limite entre les deux est floue : les extensions daujourdhui seront vraisemblablement intgres demain. 2.1. Services de base

Pour offrir un haut niveau de simultanit, il est souhaitable dassigner une tche chaque client servi par le serveur un instant donn. De plus, les applications complexes peuvent tre dcomposes en un ensemble de tches concurrentes et logiquement distinctes ce qui a pour effet damliorer les performances, le dbit, la modularit et la ractivit du serveur. En allant encore plus loin, le code du serveur sera plus efficace si les tches sont alloues diffrentes parties dun mme programme plutt qu des programmes diffrents. Ces tches, unit lmentaire dexcution, sont alors appeles thread. Tous les services de base sont lis la ncessit de disposer dune gestion multitches voire multithread et aux mcanismes associs cette gestion. 2.1.1. Premption des tches

Stratgie qui autorise la suspension de lexcution dun processus au profit dun autre. Elle soppose la stratgie dexcution jusqu achvement des premiers systmes. Lorsque le systme dexploitation gre lui mme cet aspect de premption des tches, les programmes serveurs sont beaucoup plus srs et plus simples crire. 2.1.2. Priorit des tches

Le systme dexploitation doit ordonnancer les tches selon leur niveau de priorit. 2.1.3. Smaphores

Le systme dexploitation doit offrir un mcanisme simple pour viter que des tches sexcutant simultanment soient en conflit lors daccs des ressources partages. Ces mcanismes, les smaphores, permettent de synchroniser les actions de plusieurs tches serveur indpendantes et de les alerter si une erreur survient. 2.1.4. Communications interprocessus

Le systme dexploitation doit fournir les outils ncessaires lchange et au partage de donnes entre processus indpendants. 2.1.5. Communications entre processus locaux ou distatnts

Le systme dexploitation doit tre capable dtendre les communications interprocessus au-del de la machine et ce de faon transparente pour lapplication. 2.1.6. Threads

Units lmentaires dexcution. Ils sont utiliss pour crer des programmes vnementiels traitements simultans. Chaque vnement en attente peut tre

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 19/38

Informatique

Architecture client serveur

affect un thread qui attend que cet vnement survienne. Pendant ce temps dattente, dautres threads du mme programme peuvent tre activs. 2.1.7. Protection intertches

Une tche ne doit pas provoquer lcroulement du systme. LOS doit prvenir les interfrences entre tches sur les mmes ressources. 2.1.8. Systme de fichier multi-utilisateurs haute performance

Le systme de gestion de fichiers doit accepter le multitche et offrir les verrous ncessaires au maintien de lintgrit des donnes. Le systme doit pouvoir ouvrir un grand nombre de fichiers sans consquences sur les performances. 2.1.9. Gestion efficace de la mmoire

La gestion de la mmoire doit pouvoir prendre en compte des blocs de donnes et programmes volumineux en lecture, criture, par blocs de taille adapte. 2.1.10. Extensions lies dynamiquement lexcution Les services du systme dexploitation doivent tre extensibles. En effet, lors de linstallation du noyau du systme, ladministrateur a le choix dinstaller tout ou partie de certains services. LOS doit donc fournir un mcanisme dextension dun service pendant son excution. 2.2. Services tendus

Ces services permettent de faciliter la gestion du systme et son volution. Certains seront intgrs terme aux systmes dexploitation. On peut citer rapidement : piles de protocoles : pour permettre la communication avec le plus grand nombre de clients et de serveurs. Extension rseau du systme dexploitation : plus particulirement pour les services de fichiers et d'impression. Pour une application, la localisation de ce genre de priphrique doit tre transparente. Gestion des gros objets binaires (blobs) : protocoles dchanges de blobs et daffectation de ceux-ci aux programmes adapts. Annuaires globaux et pages jaunes : les clients doivent pouvoir localiser les ressources du rseau par leur nom. Ces annuaires doivent faire lobjet dune mise jour dynamique par les serveurs qui proposent les ressources. Services dauthentification et dautorisation Gestion intgr du rseau et du systme : configuration, performances de tous les lments, alertes en cas derreur, distribution de logiciels, dtection de virus et dintrus et mesure du temps dutilisation des ressources payantes. Synchronisation des horloges SGBD intgr avec gestion du transactionnel lger voire lourd. Services Internet

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 20/38

Informatique

Architecture client serveur

Services orients objets : ngociateur, rfrentiel, change dobjets.

V. Les briques de base du middleware


Le middleware peut tre dfini de faon trs gnrale comme tant lensemble des logiciels rpartis ncessaires linteraction entre un client et un serveur. Son domaine daction couvre lAPI cot client (demandeur du service), la transmission de la requte sur le rseau. Par contre, le logiciel fournissant le service demand, linterface utilisateur et la logique de lapplication ne sont pas de son ressort. Dans ce chapitre, nous dcouperons le middleware en deux grandes parties et citerons des exemples de produits correspondants puis nous aborderons les principes des techniques de communication. A. A chacun son middleware Tenter de dcouper le middleware en plusieurs parties relve de lexercice intellectuel purement formel. Il ny a pas de stricte vrit en la matire : les produits qui seront cits cidessous et dans la suite de ce chapitre remplissent un certain nombre de fonctions quil est souvent difficile de cataloguer. Il ne sagit donc l que dune proposition de dcoupage qui a le mrite de fixer les ides mais qui peut tre facilement conteste. De faon trs globale, on peut considrer quil existe un middleware gnral et le middleware propre un service. 1. Le middleware gnral les piles de communication, les annuaires rpartis, les services dauthentification, la synchronisation horaire sur le rseau, lappel de procdures distantes, la gestion des files dattentes.

Il comporte :

Citons quelques produits qui remplissent tout ou partie de ces fonctions : DCE, ONC+, Ntware, Named Pipes, Lan server, Lan manager, Vines, TCP/IP, APPC, NetBios, MOM (Message Oriented Middleware) 2. Les middleware propres un service Pour les bases de donnes ODBC, DRDA, EDA/SQL, SAG/CLI, et Clue (Oracle). Transactionnel ATMI et Ws/Tuxedo. Transactionnel RPC (Encina). Tx RPC et XATMI (X/OPEN) Groupware MAPI, VIM, VIC, SMTP et les appels Lotus Notes.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 21/38

Informatique

Architecture client serveur

Objets rpartis CORBA (OMG), Netwotk OLE/DCOM (Microsoft) Internet HTTP, S-HTTP, SSL Administration du systme SNMP, CMIP et les ORB

B. Principes des techniques de communication Comment font un client et un serveur pour communiquer ? Comment sont synchronises les requtes et rponses ? Comment traiter les diffrences de reprsentation des donnes entre machines ? Que se passe-t-il quand un interlocuteur est indisponible ? Voil les principales difficults qui doivent tre rsolues par les techniques de communication. De plus, le NOS doit assurer la transparence de linformatique rpartie et nous viter ainsi de traiter avec les protocoles de communication, les rseaux et piles de transport. Le NOS offre trois types dinterfaces de communication : poste poste, RPC MOM.

Les communications poste poste seffectuent selon une smantique denvoi / rception que lon qualifie au raz du cble. RPC, lappel de procdures distantes, donne le sentiment que tout serveur est accessible par un appel de fonction. MOM pratique lchange de messages au travers des files dattentes. 1. Communication de poste poste : lexemple des sockets

Les sockets sont supportes pratiquement par tous les systmes dexploitation. LAPI de Windows appele Winsock standardise lutilisation de TCP/IP sous Windows. Les sockets constituent un standard de fait pour les fournisseurs dapplications sur les rseaux TCP/IP. Principe Pour tablir une communication entre processus par sockets, le programmeur fait appel des services dfinis par le RFC. Chaque service est identifi pour tous les systmes dexploitation par une adresse sur 16 bits. Sur le systme dexploitation Windows NT4, le fichier services donne la liste des services disponibles, leur adresse et le type de protocole utilis : TCP ou UDP. Avec TCP, lenvoi est effectu avec assurance de rception. UDP est qualifi de mode non connect : la communication est plus rapide mais la rception nest pas certaine. Dans tous les cas, la communication stablit par louverture dun canal de communication en prcisant ladresse IP de la machine distante (32 bits) ainsi que ladresse du service utilis. La communication est constitue de trames dinformation dont le formalisme est particulier chaque service.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 22/38

Informatique

Architecture client serveur

Lapplication WTNVT a t dveloppe en utilisant les services sockets. 2. Lappel de procdures distantes (RPC)

RPC utilise lappel de procdure connu des programmeurs : un processus client appelle une fonction dun serveur et suspend son excution jusqu obtention du rsultat.. Principe de fonctionnement Le logiciel excutable RPC rassemble les valeurs des paramtres de communication, constitue un message et lexpdie au serveur distant. Celui-ci reoit la requte, dsassemble les paramtres, appelle la procdure cible et retourne la rponse au client. Derrire cette description de principe se cachent de nombreuses difficults qui doivent tre rsolues par RPC : 3. la localisation et le lancement des procdures du serveur, le formatage et la transmission des paramtres, le traitement des pannes (non rponse dun correspondant), la scurit la localisation du serveur, le codage des donnes pour assurer une communication indpendante du codage de chaque correspondant. MOM

Il sagit de la mthode de communication la plus simple si lapplication tolre un niveau de rponse indpendant du temps. On parle alors darchitecture client serveur nomade : il est possible daccumuler les transactions en attendant que la connexion soit tablie. Le client et le serveur peuvent fonctionner des moments diffrents. Principe de fonctionnement Les applications communiquent par dpt et retrait de message au travers de files dattente.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 23/38

Informatique

Architecture client serveur

VI.Le middleware SQL


A. Rappels SQL SQL est un langage ensembliste puissant spcialis pour les bases de donnes relationnelles. Il permet essentiellement la manipulation, la dfinition et le contrle des donnes. Il est caractris par la sparation nette de laspect physique et de la reprsentation logique des donnes laccs aux donnes est logique, sans aucune considration du support physique utilis. 1. Les normes.

SQL 89 correspond lunification des diffrents produits existants lpoque. SQL 92 (SQL 2) est un sur ensemble de SQL 89. LISO suggre trois tapes pour effectuer la transition de SQL 89 SQL 92. Ces trois tapes correspondent aux trois niveaux que constituent SQL 92 : Le niveau entre permet une transition simple avec peu de reprise des applications. Niveau intermdiaire Compatibilit totale.

SQL 3 est la future version. Le texte prliminaire est dj en circulation. Il ne faut jamais perdre de vue que SQL reste une norme sa seule existence physique ce titre est un support papier. Les diteurs sefforcent de coller au plus prs de la norme mais fournissent toujours leur propres particularits. En utilisant un SGBD la norme SQL, il faut donc effectuer le choix de se limiter strictement aux possibilits de la norme ou dutiliser la puissance des particularits du SGBD avec en contre partie, une perte de portabilit. 2. ESQL

Depuis la version SQL 92, ce standard propose embedded SQL, cest dire linclusion dinstructions SQL dans les langages de troisime gnration (C, COBOL, FORTRAN, PASCAL, MUMPS, ADA Des marqueurs propres chaque langage permettent de dlimiter les instructions SQL au sein des programmes. Le SQL source doit tre trait par un pr-compilateur pour obtenir un fichier de code reonnu par le compilateur du langage. Lutilisation de embedded SQL pose quelques problmes voqus ci-dessous : la base cible doit tre connue au moment de lcriture du programme. A linstallation, les applications doivent tre lies au serveur auquel elles se connectent. Les pr-compilateurs sont associs au SGBD : il faut donc re-compiler le code SQL incorpor pour chaque serveur venant dun autre diteur.

Tout ceci constitue un handicap pour les fournisseurs dapplications client serveur clef en main.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 24/38

Informatique

Architecture client serveur

B. Interface SQL appel direct (CLI) Exemple de la CLI du SAG devenue la CLI de X/OPEN. 44 diteurs de bases de donnes ont cr le consortium SAG dans le but de proposer des standards daccs aux bases de donnes distantes. Cest une API SQL qui ne ncessite pas de pr_compilateur. LAPI permet de crer et excuter les instructions SQL au moment de lexcution ce qui permet de dvelopper des applications portables indpendantes de tout produit SGBD. Les fonctions SQL correspondent au standard SQL 89. On peut dgager les grands principes suivants : smantique et syntaxe SQL communs codification des types de donnes notification et traitement des erreurs dfinition dun ensemble de catalogues systme service de gestion des connexions (Exemple Busines Object) qui permet au client de spcifier les connexions aux SGBD distants.

Plus prcisment, les API du SAG permettent de raliser les oprations suivantes : connexion une base de donnes travers un pilote local (3 appels) prparation de requtes (5 appels) excution de requtes(2 appels) rcupration des rsultats (7 appels) fin de commandes (3 appels) fin de connexion

Par opposition lexcution de requtes, la prparation permet de mmoriser des requtes au niveau du serveur SQL de neffectuer quune seule fois leur traitement par le serveur de donnes puis dy faire appel pour excution. C. Linterface CLI ODBC de Microsoft ODBC est lAPI SQL de Windows. Cest une version amliore de la CLI du SAG. ODBC comporte 54 appels, dont 23 constituant le noyau sont bass sur la CLI du SAG. Il existe 3 niveaux de conformit : le noyau comporte 23 appels pour assurer la connexion, dconnexion, lextraction de rsultats, la validation et lannulation de transctions. Le niveau 1 complte le noyau par 19 appels qui permettent : - Lexploitation du catalogue dune base de donnes, - lextraction de gros objets (BLOB), - lutilisation de fonctions spcifiques des pilotes. Le niveau 2 comporte 19 appels pour assurer lextraction de donnes sous contrle de curseurs avec dfilement avant et arrire.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 25/38

Informatique

Architecture client serveur

La plupart des diteurs de serveurs supportent lAPI ODBC en plus de leur API SQL native. On constate ce jour une utilisation frquente de ODBC dans les outils daide la dcision. ODBC comporte trois ensembles : le gestionnaire de pilotes, les pilotes et les sources. Le gestionnaire de pilotes (accessible depuis le systme dexploitation) est une dll (librairie dynamique) qui effectue le routage des appels de fonctions vers le pilote concern. Le pilote (galement une librairie dynamique) est spcifique au SGBD cible le gestionnaire de pilotes gre autant de pilotes que de SBGBD auxquels Microsoft souhaite sinterfacer. Il rceptionne les appels de fonction et les traduit en langage daccs natif du SGBD cible. La source. La mise en place dune configuration de travail avec ODBC ncessite la cration dune source qui est en fait la duplication du pilote appropri, complt par les paramtres de la base de donnes cible.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 26/38

Informatique

Architecture client serveur

VII.Client serveur et INTERNET


A. Prsentation 1. INTERNET : le plus grand rseau public du monde

30 000 rseaux interconnects sur 70 pays ; ce chiffre double chaque anne. Les mmes protocoles, interfaces, et infrastructures rseau peuvent tre utiliss pour des rseaux privs (INTRANET). 2. Web : world wide web

Lapplication qui a fait connatre INTERNET au grand public. Cest la plus grande application C/S du monde. Quelques chiffres du juin 1996. plus de 100 000 serveurs 500 000 pages daccueil 30 millions dutilisateurs (1 million de plus par mois) 3 000 nouveaux sites par jour web double sa taille tous les 53 jours.

Les protocoles applicatifs du web tournent tels quels sur INTERNET. On peut considrer le web comme laddition des protocoles dINTERNET. Tous sont des services qui tournent sous TCP/IP. Num service 25 23 21 119 70 Sigle SMTP Telnet FTP NNTP Gopher File transfert Protocol Network News Transfert Protocol Protocole Simple Mail Transfert Protocol

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 27/38

Informatique

Architecture client serveur

B. Technologies C/S derrire le Web : les fondations Dans une premire gnration, le web a t limit la lecture : les documents ne sont pas modifiables mais les principales difficults sont contournes. On peut considrer le web comme un systme hypertexte global. 1. Hypertexte

Mcanisme logiciel qui lie un document dautres sur la mme machine ou travers le rseau. Les documents lis peuvent eux-mmes contenir des liens vers dautres documents. Plutt que de parler de documents lis, il faut raisonner en ressources lies telles que images, sons, excutables

Avec le web, le monde devient un gigantesque document hypertexte. 2. Les URL (Uniform Ressource Locator)

Toutes les ressources du web sont nommes selon le mme protocole URL. URL dfinit ou se trouve une ressource et comment y accder. URL supporte les protocoles web les plus rcents (HTTP) et les plus anciens (FTP, Goffer etc.). URL est une chane de caractres ASCII imprimable comprenant quatre parties. Nom du protocole HTTP (natif) @ serveur N du port Ressource :/path/dir/file Certains protocoles acceptent le point dinterrogation pour rechercher une ressource (HTTP, Gopher, WAIS)

://www.adresse.com N spcifi ou port FTP (le + ancien) Nom du site ou dfaut standard (80, 21, Gopher (prcurseur) adresse IP 70) News Mailto WAIS

3.

HTTP: Hypertext transfert protocol)

Protocole semblable au RPC qui permet daccder aux ressources dsignes par leur URL. HTTP est un protocole applicatif (dernier niveau du modle OSI) indpendant du protocole de transport (en gnral TCP / IP). Lchange entre un client et un serveur du web est sans session donc sans synchronisation. Le demon HTTP du serveur tourne en coute de son port de communication. A la rception dune demande, il tablit une connexion C/S

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 28/38

Informatique

Architecture client serveur

reoit ou transmet les paramtres (dont la ressource dsigne par son URL) coupe la connexion C/S.

Pour un serveur HTTP, tous les clients sont gaux : ils ne distinguent pas un client MAC dun PC. Ce sont les navigateurs qui soccupent des dtails propres chaque plate-forme en informant les serveurs des donnes quils reconnaissent. La requte mise par le client peut faire appel essentiellement 4 mthodes (il en existe 13 dans la version HTTP 1.0) reconnues par le serveur HTTP : GET, HEAD, POST, PUT GET : demande lextraction de lURL dsigne. HEAD : est une demande identique GET. Le serveur ne renvoie pas lURL dsigne mais seulement les en-ttes de rponse ce qui permet au client de tester la validit des liens hypertexte. POST : transmet des donnes du client lURL dsigne du serveur. PUT : permet de transmettre une page HTML complte au serveur. Ces deux dernires mthodes sortent du domaine de la simple consultation pour offrir une possibilit dinteraction entre client et serveur. 4. HTML : Hypertext Markup Language

Langage qui permet dinclure des liens hypertexte et de dcrire la structure logique des documents. Entirement portable sur tout systme dexploitation, toutes architectures CPU. Le web est une collection de documents HTML lis les uns aux autres. Un document du web est un fichier texte ASCII dans lequel on imbrique des commandes HTML pour : dcrire la structure du document donner des informations sur les polices daffichage et les graphiques, lier dautres ressources.

Les documents HTML vivent dans des serveurs HTTP : les serveurs web. 5. Le navigateur web : client universel

Il interprte les commandes du serveur et prsente le contenu dune page HTML en excutant des commandes HTML. Exemples : Netscape, Spyglass sont des interprteurs de commandes HTML. Le navigateur utilise les liens hypertexte pour aller dune page lautre et soccupe des dtails propres chaque plate-forme en informant les serveurs des donnes quils sont en mesure de reconnatre. Cest ainsi que pour un serveur HTTP, tous les clients semblent gaux et que lon qualifie un navigateur web de client universel.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 29/38

Informatique

Architecture client serveur

C. Interaction entre un client et un serveur web 1. Architecture


Navigateur Web HTML PC

HTTP Internet TCP/IP HTTP


Documents HTML

Navigateur Web HTML MAC

Client

Middleware

Serveur Web

Interaction client / serveur sur le Web : consultation

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 30/38

Informatique

Architecture client serveur

2.
Priode

MOT de linteraction
Utilisateur Navigateur Serveur Type

Application particulire

Saisie URL

Clic sur lien hypertexte

Choix URL OU Emission requte HTTP Insre URL dans demande HTTP Manuel

Demande HTTP

Traitement requte _ Etablissement connexion (socket) _ Recherche fichier HTML _ Transmission rponse

Manuel

Affichage indicateur attente Ressource et info de contrle

Manuel

Indicateur d'attente

Test type de ressource Manuel Autre ressource Doc HTML Fermeture connexion

Manuel

Autre ressource

Document HTML Connexion ferme

Traitement spcialis

Interprtation Dcodage balises

Manuel Manuel

Document affich

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 31/38

Informatique

Architecture client serveur

D. Les formulaires, le protocole CGI Jusqu prsent, notre raisonnement sest limit une premire gnration dans laquelle les applications web sont limites la lecture. Lobjectif est maintenant de dpasser cette limite et doffrir au client la possibilit daccder nimporte quel service (SGBD, OLTP ) avec des actions de mise jour. Comment peut-on passer dune navigation passive (lecture simple) un support C/S interactif (mise jour) ? Les formulaires et le protocole CGI sont les deux points clefs de cette volution. 1. Les formulaires

Un formulaire est une page HTML contenant un ou plusieurs champs remplir et un bouton soumettre qui permet denvoyer au serveur Web les donnes contenues dans le formulaire. Le navigateur collecte les donnes du formulaire, les rassemble dans un message HTTP comportant une des mthodes de mise jour (GET ou POST) ainsi que la dsignation du programme CGI excuter. 2. Le protocole CGI

CGI (Common Gateway Interface) est un standard de relativement bas niveau qui permet dcrire des programmes compatibles avec quasiment tous les serveurs HTTP. Un programme CGI doit tre en mesure : de rcuprer les donnes du formulaire dentre, interagir avec une ressource darrire plan (un SGBD, une transaction), prendre en compte les rponses issues de cette ressource pour les mettre au format HTML, transmettre ce rsultat au serveur HTTP qui se charge de le retourner au client.

Le diagramme darchitecture prcdent se complte ainsi.

Navigateur Web HTML et formulaires Documents HTML

HTTP

Internet TCP/IP

HTTP

Client Web

CGI Applications

SGBD ... ... OLTP

Serveur Web

Architecture client serveur Web : forme interactive

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 32/38

Informatique

Architecture client serveur

3.

Inconvnients du protocole CGI

Chaque invocation provoque le lancement dun excutable CGI qui ne peut rien conserver entre deux appels. En effet, ce protocole est sans tat : il oublie tout aprs avoir fournit sa rponse au client. Il existe des solutions pour contourner ce problme ce qui est heureux car la plupart des actions dun client peuvent difficilement se concevoir laide dun seul formulaire (exemple : formulaire de slection de marchandises, suivi du formulaire qui prsente la facture et demande les lments de paiement). De plus, les excutables CGI ne sont pas partageables entre plusieurs clients simultans : il faut en lancer autant dinstance que de clients. E. Conclusion Malgr quelques inconvnients, la simplicit des techniques mise en uvre sur le Web a assur leur succs. Le protocole CGI a ouvert la voie une architecture de forme client serveur de prsentation dans laquelle le client, muni dun navigateur Web (client universel disponible sous tous les environnements) ne supporte pas le code applicatif. On vite ainsi les problmes lis la configuration des machines clientes, la diffusion et la mise jour des applications qui reprsentent un frein considrable larchitecture client serveur classique.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 33/38

Informatique

Architecture client serveur

VIII.Glossaire
API Application programming Interface. Interface de programmation dapplications. CLI Client Interface ? Call Level Interface ? DSM Gestionnaire distribu de systme. Lapplication DSM sexcute sur chaque nud dun rseau. La station gestionnaire rcupre les informations auprs de tous les agents et les prsente ladministrateur sous forme gnralement graphique. La station gestionnaire peut aussi dlguer des actions lun de ses agents : il sagit dun rseau dans le rseau. DLL Dynamic link library : bibliothque de fonctions lies dynamiquement un programme (lors de son chargement en mmoire) par opposition aux bibliothque ajoutes un excutable lors de ldition des liens. GARTNER GROUP ISO International Standard Organisation. Organisme intgr aux nations unies qui entrine les standards internationaux. LANSI est sa branche US. MOM Message Oriented Middleware. NOS Network Operating System. Systme dexploitation rseau. ODBC Open DataBase Connectivity OSI Open Systems Interconnect : une initiative de lISO pour standardiser les protocoles rseaux. Il ne reste de cette initiative que le modle 7 couches. RFC Request For Comments RPC Remote Procedure Call. Appel de procdure distante. SAG Sql Access Group. Groupe de constructeurs indpendants. Ces travaux dans le cadre des mdiateurs ont t repris par X/OPEN. Exemple : linterface dapplication standard : lAPI CLI.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 34/38

Informatique

Architecture client serveur

X/OPEN Association internationale but non lucratif (1984) compose de constructeurs essentiellement Amricains. Dfinit et diffuse les technologies et standards en matire de systmes ouverts. Leurs documents de spcifications prcisent et compltent les standards.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 35/38

Informatique

Architecture client serveur

IX.Annexes
A. NOTIONS DOBJETS 1. A lorigine :

Tout programmeur a pass une partie de son temps crire des procdures quil avait dj traites sous une autre forme. De ce problme est ne la volont de raliser des applications avec des modules rutilisables donc gnriques. Lapparition des langages permettant au programmeurs de crer des structures a t dterminante surtout lorsque ces structures ont t responsables des mthodes qui leur sont associes. Une classe est une structure compose de proprits (les diffrents lments de la structure) et de mthodes. Les donnes ne peuvent tre manipules que par les mthodes de la classe. La programmation par classes (programmation objets) consiste dfinir des classes (structures) et les mthodes associes pour manipuler les donnes. Exemple La classe VOITURE, contenant les proprits : PROPRIETAIRE ETAT IMMATRICULATION et les mthodes qui agissent sur les proprits : Changement de propritaire Changement dimmatriculation Acclrer, Freiner Une instance de classe est une variable dclare comme tant du type de la structure. 2. Hritage :

Il est possible de btir une classe partir dune autre. Cette nouvelle classe hrite des proprits et des mthodes de la classe dorigine. Elle peut bien sr tre complte par ses propres proprits et mthodes. La conception dune application objet est donc radicalement diffrente. Il faut faire linventaire de toutes les entits que lon devra manipuler et les regrouper par proprits et mthodes communes tout en utilisant pleinement le principe dhritage. Exemple : la classe des chaises comportant ses proprits et ses mthodes peut tre utilise pour crer une classe des chaises hauteur et dossier rglable. On peut imaginer comme mthodes propres cette nouvelle classe, le rglage de la hauteur et linclinaison du dossier.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 36/38

Informatique

Architecture client serveur

3.

Utilisation

Aprs de longues considrations philosophiques on peut admettre que dans lunivers, tout est objet communiquant par des messages. Ainsi, une imprimante en action est un objet imprimante ayant reu un message dimpression ayant comme paramtre le document imprimer. La programmation par classe est ainsi devenue la programmation objet. Lutilisation dun objet se fait en prcisant linstance, la mthode et les arguments ncessaires. Mthode et arguments constituent le message. Instance.methode (arguments) 4. Que signifie localiser une instance de la classe ? la classe EMPLOYE avec ses proprits et la mthode CALCULSALAIRE ; La classe COMMERCIAL qui hrite demploy et dont la mthode CALCULSALAIRE utilise la mthode du mme nom de la classe employ en y ajoutant les commissions.

Considrons

Localiser une instance de la classe signifie que pour calculer le salaire de M. Dupond, le systme devra dterminer quelle classe appartient linstance afin de lui appliquer la bonne mthode. Cette difficult nest pas spcifique une architecture client serveur (elle est traite par les SGBDO) mais ce type darchitecture la rend encore plus complexe. B. Workflow Le workflow est lacheminement automatique des vnements et des tches dun programme au programme suivant. Un progiciel de workflow doit tre capable de prendre en compte la description de QUI fait QUOI, QUAND, dans quel but, les itinraires parallles (plusieurs acteurs peuvent raliser la mme tche), la logique de construction dynamique des itinraires au moment de lexcution ainsi que les exceptions aux rgles. Cette description peut tre compare celle dun MOT qui ne serait pas seulement graphique mais galement dynamique. Un workflow permet ainsi de distribuer des rles, suivre et acheminer le travail en cours, veiller aux dates dchance, suivre lexcution des tches (QUI, QUAND). C. Multithreading Le multithreading correspond au dcoupage dune mme application en plusieurs tches, dans le but de tirer partie des machines multiprocesseurs. Lapplication doit tre conue de faon particulire : elle doit faire appel des tches lmentaires, indpendantes les unes des autres, quil sera possible dexcuter en parallle. Des bibliothques de fonctions sont disponibles sur le march. Le principal problme rsoudre est la synchronisation entre threads : il faut viter par exemple que deux threads ralisent simultanment une criture dans un fichier. Une des

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 37/38

Informatique

Architecture client serveur

faons de rsoudre cette difficult est lutilisation des smaphores. Le noyau du systme dexploitation LINUX gre lordonnancement des threads.

DMSI/ANA/clergerie_p / le 29/08/200909

21520497.doc

Page 38/38

You might also like