Prsentation de l'architecture d'un systme client/serveur

De nombreuses applications fonctionnent selon un environnement client/serveur, cela signifie que desmachines clientes (des machines faisant partie du rseau) contactent un serveur, une machine gnralement trs puissante en terme de capacits d'entresortie, qui leur fournit des services. Ces services sont des programmes fournissant des donnes telles que l'heure, des fichiers, une connexion, etc. Les services sont exploits par des programmes, appels programmes clients, s'excutant sur les machines clientes. On parle ainsi de client (client FTP, client de messagerie, etc.) lorsque l'on dsigne un programme tournant sur une machine cliente, capable de traiter des informations qu'il rcupre auprs d'un serveur (dans le cas du client FTP il s'agit de fichiers, tandis que pour le client de messagerie il s'agit de courrier lectronique).

Avantages de l'architecture client/serveur

Le modle client/serveur est particulirement recommand pour des rseaux ncessitant un grand niveau de fiabilit, ses principaux atouts sont : des ressources centralises : tant donn que le serveur est au centre du rseau, il peut grer des ressources communes tous les utilisateurs, comme par exemple une base de donnes centralise, afin d'viter les problmes de redondance et de contradiction une meilleure scurit : car le nombre de points d'entre permettant l'accs aux donnes est moins important une administration au niveau serveur : les clients ayant peu d'importance dans ce modle, ils ont moins besoin d'tre administrs un rseau volutif : grce cette architecture il est possible de supprimer ou rajouter des clients sans perturber le fonctionnement du rseau et sans modification majeure

Inconvnients du modle client/serveur

L'architecture client/serveur a tout de mme quelques lacunes parmi lesquelles : un cot lev d la technicit du serveur un maillon faible : le serveur est le seul maillon faible du rseau client/serveur, tant donn que tout le rseau est architectur autour de lui ! Heureusement, le serveur a une grande tolrance aux pannes (notamment grce au systme RAID)

Fonctionnement d'un systme client/serveur

Un systme client/serveur fonctionne selon le schma suivant :

Le client met une requte vers le serveur grce son adresse IP 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 cliente et son port

Dernire modification le mardi 14 octobre 2008 17:40:26.Ce document intitul Environnement Client/Serveur issu de Comment a Marche(www.commentcamarche.net) est mis disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixes par la licence, tant que cette note apparat clairement.

Architecture mainframe
Les premiers rseaux informatiques taient architecturs autour d'un ordinateur central, appel mainframe . Le mainframe reprsente ainsi un ordinateur central de grande puissance charg de grer les sessions utilisateurs des diffrents terminaux qui lui taient relis. Grce cette architecture, il est ainsi possible de consolider, c'est--dire de grer de manire centralise, l'ensemble des applications mtiers de l'entreprise. Cependant, dans le modle mainframe, la performance du systme tout entier repose sur les capacits de traitement de l'ordinateur central, c'est la raison pour laquelle ce modle est parfois qualifi d' informatique lourde . Par ailleurs, dans un environnement mainframe, les terminaux du rseau ne peuvent voir que le serveur central.

Prsentation de l'architecture 2 niveaux

L'architecture deux niveaux (aussi appele architecture 2-tier, tier signifiant range en anglais) caractrise les systmes clients/serveurs pour lesquels le client demande une ressource et le serveur la lui fournit directement, en utilisant ses propres ressources. Cela signifie que le serveur ne fait pas appel une autre application afin de fournir une partie du service.

Prsentation de l'architecture 3 niveaux

Dans l'architecture 3 niveaux (appele architecture 3-tier), il existe un niveau intermdiaire, c'est--dire que l'on a gnralement une architecture partage entre : 1. Un client, c'est--dire l'ordinateur demandeur de ressources, quipe d'une interface utilisateur (gnralement un navigateur web) charge de la prsentation ; 2. Le serveur d'application (appel galement middleware), charg de fournir la ressource mais faisant appel un autre serveur

3. Le serveur de donnes, fournissant au serveur d'application les donnes dont il a besoin.

Etant donn l'emploi massif du terme d'architecture 3 niveaux, celui-ci peut parfois dsigner aussi les architectures suivantes : Partage d'application entre client, serveur intermdiaire, et serveur d'entreprise ; Partage d'application entre client, serveur d'application, et serveur de base de donnes d'entreprise.

Comparaison des deux types d'architecture

L'architecture deux niveaux est donc une architecture client/serveur dans laquelle le serveur est polyvalent, c'est--dire qu'il est capable de fournir directement l'ensemble des ressources demandes par le client. Dans l'architecture trois niveaux par contre, les applications au niveau serveur sont dlocalises, c'est--dire que chaque serveur est spcialis dans une tche (serveur web/serveur de base de donnes par exemple). L'architecture trois niveaux permet : Une plus grande flexibilit/souplesse ; Une scurit accrue car la scurit peut tre dfinie indpendamment pour chaque service, et chaque niveau ; De meilleures performances, tant donn le partage des tches entre les diffrents serveurs.

L'architecture multiniveaux
Dans l'architecture 3 niveaux, chaque serveur (niveaux 2 et 3) effectue une tche (un service) spcialise. Un serveur peut donc utiliser les services d'un ou plusieurs autres serveurs afin de fournir son propre service. Par consquent, l'architecture trois niveaux est potentiellement une architecture N niveaux...

Dernire modification le mardi 14 octobre 2008 17:40:27.Ce document intitul Rseaux - Architecture client/serveur 3 niveaux issu de Comment a Marche(www.commentcamarche.net) est mis disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixes par la licence, tant que cette note apparat clairement.

Client lourd
Le terme client lourd (en anglais fat client ou heavy client ), par opposition au client lger, dsigne une application cliente graphique excute sur le systme d'exploitation de l'utilisateur. Un client lourd possde gnralement des capacits de traitement volues et peut possder une interface graphique sophistique. Nanmoins, ceci demande un effort de dveloppement et tend mler la logique de prsentation (l'interface graphique) avec la logique applicative (les traitements). Ce type d'application tant gnralement install sur le systme d'exploitation de l'utilisateur, une nouvelle version doit tre installe afin de la faire voluer. Pour y remdier, les diteurs d'applications lourdes les dotent gnralement d'une fonctionnalit excute au lancement de l'application, permettant de vrifier sur un serveur distant si une version plus rcente est disponible et le cas chant propose l'utilisateur de la tlcharger et de l'installer.

Client lger
Le terme client lger (parfois client pauvre , en anglais thin client ), par opposition au client lourd, dsigne une application accessible via une interface web

(en HTML) consultable l'aide d'unnavigateur web, o la totalit de la logique mtier est traite du ct du serveur. Pour ces raisons, lenavigateur est parfois appel client universel. L'origine du terme lui-mme provient de la pauvret du langage HTML, qui ne permet de faire des interfaces relativement pauvres en interactivit, si ce n'est pas le biais du langage javascript. Le fait que l'essentiel des traitements soit ralis du ct du serveur et que l'interface graphique est envoye au navigateur chaque requte permet une grande souplesse de mise jour. En contrepartie, l'application doit s'affranchir des diffrences d'interprtation du code HTML par les diffrents navigateurs et l'ergonomie de l'application possde un champ rduit.

Client riche
Un client riche est un compromis entre le client lger et le client lourd. L'objectif du client riche est donc de proposer une interface graphique, dcrite avec une grammaire de description base sur la syntaxe XML, permettant d'obtenir des fonctionnalits similaires celles d'un client lourd (glisser dposer, onglets, multi fentrage, menus droulants). Les clients riches permettent ainsi de grer l'essentiel des traitements du ct du serveur. Les donnes sont ensuite transmises dans un format d'change standard utilisant la syntaxe XML (SOAP, XML-RPC), puis interprtes par le client riche. Les principaux standards permettant de dfinir une application riche sont les suivants : XAML (eXtensible Application Markup Language), prononcez zammel , un standard XML propos par Microsoft, utilis notamment dans les applications utilisant le framework .NET ; XUL, prononcez zoul , un standard XML propos par la fondation Mozilla, utilis par exemple dans le client de messagerie Mozilla Thunderbird ou dans le navigateur Mozilla Firefox ; Flex, un standard XML propos par la socit Macromedia.

Prsentation de l'architecture d'gal gal

Dans une architecture d'gal gal (en anglais peer to peer), contrairement une architecture de rseau de type client/serveur, il n'y a pas de serveur ddi. Ainsi chaque ordinateur dans un tel rseau est un peu serveur et un peu client. Cela signifie que chacun des ordinateurs du rseau est libre de partager ses ressources. Un ordinateur reli une imprimante pourra donc ventuellement la partager afin que tous les autres ordinateurs puissent y accder via le rseau.

Inconvnients des rseaux d'gal gal

Les rseaux d'gal gal ont normment d'inconvnients : ce systme n'est pas du tout centralis, ce qui le rend trs difficile administrer la scurit est trs peu prsente

aucun maillon du systme n'est fiable Ainsi, les rseaux d'gal gal ne sont valables que pour un petit nombre d'ordinateurs (gnralement une dizaine), et pour des applications ne ncessitant pas une grande scurit (il est donc dconseill pour un rseau professionnel avec des donnes sensibles).

Avantages de l'architecture d'gal gal

L'architecture d'gal gal a tout de mme quelques avantages parmi lesquels : un cot rduit (les cots engendrs par un tel rseau sont le matriel, les cbles et la maintenance) une simplicit toute preuve!

Mise en oeuvre d'un rseau peer to peer

Les rseaux poste poste ne ncessitent pas les mmes niveaux de performance et de scurit que les logiciels rseaux pour serveurs ddis. On peut donc utiliser Windows NT Workstation, Windows pour Workgroups ou Windows 95 car tous ces systmes dexploitation intgrent toutes les fonctionnalits du rseau poste poste. La mise en oeuvre d'une telle architecture rseau repose sur des solutions standards : Placer les ordinateurs sur le bureau des utilisateurs Chaque utilisateur est son propre administrateur et planifie lui-mme sa scurit

Pour les connexions, on utilise un systme de cblage simple et apparent Il s'agit gnralement d'une solution satisfaisante pour des environnements ayant les caractristiques suivantes : Moins de 10 utilisateurs Tous les utilisateurs sont situs dans une mme zone gographique La scurit nest pas un problme crucial Ni lentreprise ni le rseau ne sont susceptibles dvoluer de manire significative dans un proche avenir

Administration d'un rseau poste poste

Le rseau poste poste rpond aux besoins dune petite entreprise mais peut savrer inadquat dans certains environnements. Voici les questions rsoudre avant de choisir le type de rseau : On dsigne par le terme "Administration" : 1. Gestion des utilisateurs et de la scurit 2. Mise disposition des ressources 3. Maintenance des applications et des donnes 4. Installation et mise niveau des logiciels utilisateurs Dans un rseau poste poste typique, il ny a pas dadministrateur. Chaque utilisateur administre son propre poste. D'autre part tous les utilisateurs peuvent partager leurs ressources comme ils le souhaitent (donnes dans des rpertoires partags, imprimantes, cartes fax etc.)

Notions de scurit
La politique de scurit minimale consiste mettre un mot de passe une ressource. Les utilisateurs dun rseau poste poste dfinissent leur propre scurit et comme tous les partages peuvent exister sur tous les ordinateurs, il est difficile de mettre en oeuvre un contrle centralis. Ceci pose galement un problme de scurit globale du rseau car certains utilisateurs ne scurisent pas du tout leurs ressources.