Arc Hi

Technologie des applications client-serveur UE RSX 102 Support de cours Tome 1 Anas ABOU EL KALAM
anas.abouelkalam@enseeiht.fr
Technos pour les applis C/S : Introduction
Anas ABOU EL KALAM
Page 1
Plan
Introduction / Notions gnrales De linformation centralise au client-serveur
Les "middlewares Les architectures distribues Application : architectures internet
Anas ABOU EL KALAM
Page 2
Plan
Les architectures distribues Les "middlewares Application : architectures internet
Anas ABOU EL KALAM
Page 3
Introduction : situation actuelle
Mutation permanente des concepts, des techniques et des organisations associes aux applications informatiques.
Effort de recherche et de production industrielle au niveau mondial : - l'apparition de composants de rapidit et de complexit en croissance continue. - la possibilit de dveloppement de solutions logicielles et organisationnelles irralistes quelques annes auparavant.
Anas ABOU EL KALAM
Page 4
Introduction : systmes disponibles

On dispose prix accessible pour les entreprises et le grand public de calculateurs puissants munis :
de SE volus d'IHM volues de capacits de stockage normes de capacits de traitements rapides de moyens d'interconnexion "rseaux locaux" trs performants de moyens d'interconnexion "longue distance" bas prix et de bande passante importante.
Standardisation, C/S, ...

Technos pour les applis C/S : Introduction Anas ABOU EL KALAM
Page 5
Introduction : Modes de comm entre progs
Modle conversationnel e.g., conversation tlphonique, sockets (dans TCP / IP) Modle appel de procdure e.g., Machine sous, RPC Modle asynchrone e.g., poste, mail
Page 6
Communication asynchrone par messages : avantages

Applis communicantes ne sont plus lies lune lautre. Peuvent avoir des caractristiques diffrentes de disponibilit et de dbit Applis font appel un gestionnaire de messages applicatifs nont plus se proccuper des problmes de comm inhrents aux changes Il leur suffit de placer / extraire messages dans des files dattente Rle gestionnaires : transiter messages de files dattente en files dattente + (ventuellement intgrit, ...) Sparation nette entre dveloppement dapplications et exploitation de systme La standardisation (API commune daccs) renforce utilisation ces techniques Asynchronisme permet de dvelopper des applications qui traitent infos au fil de leau , i.e. au fur et mesure que les donnes sont disponibles, tout en crtant les pointes dactivit, si cela est ncessaire
Page 7
Le C/S : dfinition (basique)

Architecture rseau dans laquelle : donnes localises et traits sur S // accessible aux C : client met des requtes, serveur rend le service demand. ...utiliser communication par messages de donnes en mode asynchrone offerte par les protocoles de transport 1er mssg : C envoie requte excution traitement au S 2nd mssg : S envoie rponse (aprs avoir effectu traitement)
Requte X-data-req Rponse X-data-ind X-data-req X-data-ind
CLIENT
SERVEUR
Anas ABOU EL KALAM
Page 8
Le C/S en mode message : Architecture gnrale

Fonctionnement le plus frquent en C/S : mode requte rponse pour une population de C et de S
Poste client
Rponse Requte
Architecture Rponse de communication Rseau "Middleware"
Poste client
Requte Requte
Rponse
Poste serveur
Anas ABOU EL KALAM
Page 9
Le C/S : applications (1/2) informatique de gestion algorithmique rpartie, informatique industrielle,
Applications internet ....
Dans son acception la plus complte: possibilit de dfinir n'importe quelle architecture de communication. Chaque entit est la fois client et serveur Chaque entit met et traite des requtes
Anas ABOU EL KALAM
Page 10
C/S : applications (2/2)

Applications coopratives ("Cooperative work") Ensemble d'entits logicielles cooprant au moyen d'un rseau la ralisation d'une tche informatique Systmes rpartie ("Distributed Computing") Applications systmes et rseaux indispensables au fonctionnement des machines en rseau Intelligence Artificielle Distribue ("Distributed AI") Application cooprative mettant en relation des agents qui fonctionnent selon des approches drives de l'IA Le calcul massivement parallle ("Grid Computing") Application de calcul ralis par le travail en parallle et en coopration d'un nombre lev de processeurs Les systmes rpartis de contrle commande de procds industriels Application de contrle en temps rel de procds tenant compte des contraintes de QoS et de sret de fonctionnement.
Page 11
Le C/S en mode message : Architecture gnrale
Notions & Questions traiter Modles de rpartition donnes traitements Dans une architecture rseau API Middleware ...
Page 12
Plan
Les "middlewares Les architectures distribues Application : architectures internet
Anas ABOU EL KALAM
Page 13
Niveaux d'abstraction d'une application
Couche prsentation (IHM)

interaction de l'application avec l'utilisateur.
Grer saisies clavier/souris, prsentation info lcran
Doit tre conviviale et ergonomique
Logique applicative, traitements

travaux raliser par l'application
Traitements locaux : contrles dialogue au niveau IHM, aide la saisie, Traitements globaux constituant lappli elle mme : business logic : rgles internes qui rgissent lentreprise
Donnes
mcanismes permettant la gestion des informations stockes par l'application
Anas ABOU EL KALAM
Page 14
Anas ABOU EL KALAM
Page 15

Ces trois niveaux peuvent tre imbriqus ou rpartis de diffrentes manires entre plusieurs machines physiques.
Le noyau de l'application est compos de

la logique de l'affichage/prsentation la logique des traitements.
Le dcoupage et la rpartition de ce noyau permettent de distinguer les architectures applicatives suivantes :

1-tiers (tage), 2-tiers ==> Client/Serveur 3-tiers ==> Applications distribues n-tiers.
Page 16
L'architecture un-tiers : dfinition

Les trois couches applicatives sont intimement lies et s'excutent sur le mme ordinateur On ne parle pas ici d'architecture client-serveur, mais d'informatique centralise. Dans un contexte multi-utilisateurs, on peut rencontrer deux types d'architecture mettant en uvre des applications un tiers :
des applications sur site central des utilisateurs accdant depuis des sites distinctes (terminaux passifs) aux mmes donnes ==> partage de fichiers physiquement localiss sur site central
Page 17
L'architecture un tiers : exemple du mainframe (1/2)

Accs multi-utilisateurs
Les utilisateurs se connectent aux applis l'aide de terminaux passifs

esclaves. qui prend en charge l'intgralit des traitements,

y compris l'affichage qui est simplement dport sur des terminaux passifs
Les applis sont excutes sur Serveur central (mainframe)
Anas ABOU EL KALAM
Page 18
L'architecture un tiers : mainframe (2/2) Avantages

Facilit d'administration Large palette d'outils de conception, de programmation et d'administration ayant atteint un niveau de maturit et de fiabilit Centralisation utilisation optimale des ressources Mais Mainframe ==> Point dur ... Dmods mergence des interfaces utilisateur Interface utilisateur en mode caractre juge obsolte par les utilisateurs <== mergence bureautique, ... r-habillage permet de rajeunir (GUI), mais au prix d'une lourdeur
Anas ABOU EL KALAM
Page 19
L'architecture un tiers : Limitations

Site central
Interface utilisateur en mode caractres Cohabitation d'applications micro exploitant des donnes communes n'est pas fiable au del d'un certain nombre d'utilisateurs.
Solution doit concilier

l'interface utilisateur moderne des applications sur micro-ordinateurs. Fiabilit des solutions sur site central, qui grent les donnes de faon centralise,
Donc
il faut scinder les applications en plusieurs parties distinctes et cooprantes gestion centralise des donnes, gestion locale de l'interface utilisateur.
Ainsi est n le concept du client-serveur ...

Page 20
Modles de rpartitions : schma du Gartner Group (1/5)
Anas ABOU EL KALAM
Page 21
Le schma du Gartner Group (2/5)
Prsentation distribue
habillage graphique de l'affichage en mode caractres dapplications fonctionnant sur site central Poste client conserve une position desclave / serveur
Prsentation distante

Client serveur de prsentation Serveur ensemble traitements Client que laffichage Inconvnient Gnration trafic rseau fort Aucune rpartition charge entre C/S Exemples X-Window, DecTP sur Vax, APPC sur IBM
Anas ABOU EL KALAM
Page 22

Gestion distante des donnes
Client serveur de donnes Client totalit de lappli SGBD centralis gestion donnes et contrle dintgrit Souvent pour applis type infocentre / banques de donnes Inconvnient Trafic rseau assez important Ne soulage pas normment le client
Traitement distribu
Client serveur de traitement Dcoupage de lappli se fait au plus prs de son noyau et les traitements sont distribus entre le client et le serveur Appel de procdures Avantage optimiser rpartition charge Limite trafic rseau Inconvnient C & S doivent l'avance connatre et implmenter procdures accomplir
Page 23
Bases de donnes distribues

Variante du C/S de donnes dans laquelle une partie des donnes est prise en charge par le client Intressant si
lappli doit grer de gros volumes de donnes On souhaite disposer de temps daccs rapide Contraintes de confidentialit
Donnes et traitements distribus

Tire partie de la notion de composants rutilisables et distribuables pour rpartir au mieux la charge entre C/S Architecture complexe MEV
Anas ABOU EL KALAM
Page 24
Ne correspondent pas vraiment des applis C/S
Archi 2-tiers
Anas ABOU EL KALAM
Page 25
L'architecture deux tiers : Prsentation

le poste client se contente de dlguer la gestion des donnes un service spcialis.
E.g., appli de gestion fonctionnant sous Windows et exploitant SGBD centralis
Ce type d'application permet de tirer partie de

Interface riche des ordis dploys en rseau, Cohrence des donnes, qui restent gres de faon centralise.
Gestion des donnes prise en charge par SGBD centralis, s'excutant le plus souvent sur un serveur ddi
Client envoie requte (langage de requte e.g., SQL) au serveur Dialogue C/S
envoi de requtes et retour des donnes correspondant aux requtes.
Anas ABOU EL KALAM
Page 26
Exemple de C/S en architecture deux tiers

client
Provoque/initie l'tablissement d'une conversation afin d'obtenir des donnes ou un rsultat de la part du serveur. met des requtes
serveur
Programme qui rpond au client ==> rend le service demand
Lchange de messages
transite travers le rseau reliant les deux machines. met en uvre des mcanismes relativement complexes qui sont, en gnral, pris en charge par un middleware.
Page 27
Plan
Introduction / Notions gnrales De linformation centralise au client-serveur Les Middlewares
Les architectures distribues Application : architectures internet
Anas ABOU EL KALAM
Page 28
Le Middleware : dfinition (1/2)

Quoi ?
lment du milieu = interface de comm universelle entre processus Lensemble des couches rseau et services logiciel qui permettent le dialogue entre les diffrents composants d'une application rpartie.
Pourquoi ?
Assurer changes donnes entre C et S en masquant les diffrents problmes potentiels lis : rpartition des donnes et traitements (accs distant, baisse performances) htrognit des matriels et des logiciels en opration. ...
Anas ABOU EL KALAM
Page 29
Le Middleware : dfinition (2/2)

envoyer des requtes d'accs des donnes (type SQL) d'un client vers un serveur et recevoir les rsultats Ouvrir une connexion entre entits Envoi de requtes SQL vers le serveur Conversion des formats de requtes Envoi des rsultats Conversion des rsultats (Gestion des erreurs) Fermeture de connexion.
Anas ABOU EL KALAM
Page 30
Le Middleware : services
Comment raliser les fonctions classiques des systmes centraliss que l'on rencontre maintenant en univers rparti ?
Conversion : Service utilis pour la communication entre machines mettant en oeuvre des formats de donnes diffrents, elle est prise en charge par la FAP Adressage : Permet d'identifier la machine serveur sur laquelle est localis le service demand afin d'en dduire le chemin d'accs. Annuaire Scurit : Permet de garantir la confidentialit et la scurit des donnes l'aide de mcanismes d'authentification et de chiffrement des informations. Communication : Permet la transmission des messages entre les deux systmes sans altration. connexion au serveur prparation de l'excution des requtes rcupration des rsultats d-connexion.
Page 31
Le Middleware : services
Anas ABOU EL KALAM
Page 32
Le Middleware : exemples
SQL*Net : Interface permettant de faire dialoguer une application cliente avec une base de donnes Oracle. Passage requte SQL, Appel procdures indpendance vis vis du rseau (topologie, protocole) et des OS multi-thread = plusieurs connexions dans un seul process Oracle Serveur journalisation et traage, gestion des connexions avortes, ... EDA (Enterprise Data Access)-SQL Htrognit : interface commune pour clients s'excutant sur +35 platformes requtes (simultanes) sur +80 BD Vue uniforme indpendante du type plateforme, forme stockage, .... ODBC: Interface standardise isolant le client du serveur de donnes. ODBC C'est l'implmentation par Microsoft du CLI (Call Level Interface) du SQL Access Group Elle se compose de : gestionnaire de driver standardis, API s'interfaant avec l'application cliente driver correspondant au SGBD utilis
Page 33
Le Middleware : exemples
DCE (Distributed Computing Environment) / RPC Permet processus tournant sur ++ ordis de communiquer comme s'il sont en local Dans prog client, fonction locale qui a le mme nom que fonction distante et qui, en ralit, appelle fonctions de la bibliothque RPC grent connexions rseaux, passage params, retour rsultats De mme, ct serveur, fonction/processus qui attend connexions clientes, appelle votre fonction avec bons param, renvoyer les rsultats. Fonctions qui prennent en charge les connexions rseaux sont des "stub" Il faut donc crire stub C & stub S, en plus du prog C et fctn distante
Moniteur transactionnel (Transaction Processing Monitor) Sorte de "scheduler sophistiqu" pour partager ressources limites
(BD, mmoire) entre un grand nombre d'utilisateurs simultans et plusieurs serveurs planification de l'excution des transactions, synchronisation ... e.g., BEA Tuxedo pour Unix/windows, Top End de NCR pour Unix, IBM TPF, Bull TP8, ...
Anas ABOU EL KALAM
Page 34
Le Middleware : Remarques
Le choix d'un middleware est dterminant en matire d'architecture,

il joue un grand rle dans la structuration du systme d'information
Pour certaines applis devant accder des services htrognes, il est parfois ncessaire de combiner plusieurs middlewares.
poste client doit connatre et mettre en uvre plusieurs IPC (Inter Process
Communication)
Mcanismes : queues de messages, mmoire commune, smaphores
client lourd
Anas ABOU EL KALAM
Page 35
C/S deux tiers : Avantages
permet l'utilisation d'une interface utilisateur riche, Permet l'appropriation des applications par l'utilisateur, Introduit la notion d'interoprabilit.
Anas ABOU EL KALAM
Page 36
C/S deux tiers : Limites

Poste client supporte la grande majorit des traitements applicatifs
Client lourd ou fat client

le poste client est : fortement sollicit, devient de plus en plus complexe doit tre mis jour rgulirement pour rpondre aux besoins des utilisateurs, cots et la complexit de sa maintenance. la conversation entre client et serveur est assez bruyante et s'adapte mal des bandes passantes troites les applications se prtent assez mal aux fortes montes en charge car il est difficile de modifier l'architecture initiale,
Anas ABOU EL KALAM
Page 37
C/S deux tiers : Solution ?
But
Rsoudre limitations du C/S 2-tiers tout en conservant des avantages
Solution ?
Architecture plus volue, facilitant les forts dploiements moindre cot
architectures
distribues.
Anas ABOU EL KALAM
Page 38
Plan
Introduction / Notions gnrales De
linformation centralise au client-serveur
Anas ABOU EL KALAM
Page 39
L'architecture trois tiers : objectifs

Principe
utilisation d'un poste client simple communicant avec le serveur par le biais d'un protocole standard. standard Donnes prsentation toujours gres de faon centralise, toujours prise en charge par le poste client,
logique applicative prise en charge par un serveur intermdiaire
Archi 3- tiers
Force des archi 3-tiers ==> dploiement immdiat, ==> volutions peuvent tre transparentes pour l'utilisateur ==>caractristiques du poste client sont libres
Page 40
L'architecture trois tiers : rpartition des traitements

premier niveau affichage et traitements locaux (contrles saisie, mise en forme) pris en charge par client, deuxime niveau traitements applicatifs globaux pris en charge par service applicatif troisime niveau services de base de donnes pris en charge par un SGBD.
Anas ABOU EL KALAM
Page 41
L'architecture trois tiers : premires tentatives

Serveur dapplication centralis Communication C/S utilisant dialogue RPC Mcanismes pour dialogue RPC Unix intgr au systme NFS Microsoft NetDDE puis DCOM ==> rendu obselte par .Net Solutions propitaires (ForT ou Implicite) permettent lexploitation dun serveur dapplication par des clients simplement quips dun environnement dexcution (runtime)
Mais Absence de standards Mise en place Coteuse
Anas ABOU EL KALAM
Page 42
Exemple darchi trois tiers : serveur de transactions
Moniteur transactionnel : mise en relation Client avec Serveurs de donnes Atomicit : La transaction ne peut tre partiellement effectue, Cohrence : transaction fait passer la base d'un tat cohrent un autre , Isolation : transaction n'est pas affecte par le rsultat des autres Dure : modifications dues une transaction sont durablement garanties.
Soit transaction a dfinitivement eu lieu, soit elle na jamais exist
API : masque complexit de lorganisation des serveurs de donnes

Page 43
L'architecture trois tiers : la rvolution Internet

World Wide Web (1989) : permet de publier des informations richement mises en forme affichage & traitements locaux (contrles saisie, mise en forme) pris en charge par client ARPANET ==> CERN fut l'acteur principal du WWW ==> W3C Caractre universel, rendu possible par l'utilisation de standards reconnus HTML, pour la description des pages disponibles sur le Web, HTTP, pour la communication entre navigateur et serveur Web, TCP/IP, le protocole rseau largement utilis par les systmes Unix, CGI, l'interface qui permet de dclencher des traitements sur les serveurs Web excution dun processus (sur Serveur) pour chaque invocation (par Client) prfrer extensions comme ISAPI, NSAPI ou Servlets java, Intranet Principes dinternet + technologies dployes dans entreprise on utilise rseau local de lentreprise donnes gres par un SGBD
Page 44
L'architecture trois tiers : rpartition des traitements

Niveaux indpendants
peuvent tre implants sur machines diffrentes
poste client ne supporte plus traitements moins sollicit, moins volu, moins coteux, ressources prsentes sur rseau sont mieux exploites
puisque les traitements applicatifs peuvent tre partags ou regroups
Fiabilit/performances certains traitements se trouvent amliores par centralisation relativement simple de faire face une forte monte en charge, en renforant le service applicatif
Page 45
L'architecture trois tiers : exemple en Intranet

poste client prend la forme d'un simple navigateur Web, service applicatif assur par un serveur HTTP communication avec le SGBD met en oeuvre les mcanismes bien connus des applications client-serveur de la premire gnration.
distinction entre deux tronons de comm indpendants et dlimits par serveur HTTP : circuit froid : relie client au serveur Web pour permettre l'interaction avec l'utilisateur et la visualisation des rsultats. circuit chaud : permet collecte donnes ; peut voluer sans impacter la configuration des postes clients
Page 46
Architecture trois tiers : Le client lger (Thin Client)

Ne prend en charge que prsentation de l'application avec, ventuellement une partie de logique applicative permettant une vrification immdiate de la saisie et la mise en forme des donnes souvent constitu d'un simple navigateur Internet Client ne communique qu'avec la faade HTTP de l'application et ne dispose d'aucune connaissance des traitements applicatifs ou de la structure des donnes exploites. Les volutions de l'application sont donc possibles sans ncessiter de modification de la partie cliente. Exemple de clients lgers poste Windows quip d'un navigateur HTML station rseau du type NC (Oracle, Sun et IBM ) terminal NetPC (windows)
Page 47
Architecture trois tiers : Le client

Limites ...
Les pages HTML, mme avec l'aide de langages de script, sont loin d'atteindre les possibilits offertes par l'environnement du client : les pages affiches sont relativement statiques, le dveloppement multi-plateforme peut tre contraignant l'ergonomie de l'application est limite aux possibilits du navigateur. le multi-fentrage n'est pas facile mettre en uvre, le droulement de l'application doit se faire squentiellement, Il est possible d'aller au del des possibilits offertes par le langage HTML en y introduisant des applets Java ou des contrles ActiveX. Java Orient objet, multi-plateforme se prte bien une utilisation sur Internet JVM, Applet, API, JDBC, RMI, CORBA.
Page 48
Architecture trois tiers : Les activeX

rponse devant le phnomne Java (multi-plateforme) adaptation Internet des composants OCX constituant clef de vote de l'archi DNA peuvent tre intgrs une page HTML mais, la diffrence des applets Java, ils persistent sur le poste client aprs utilisation. permet d'optimiser les transferts de composants sur le rseau mais alourdissement du poste client, problmes de scurit, Les composants ActiveX peuvent communiquer entre eux en utilisant la technologie DCOM ou avec des bases de donnes, en utilisant ODBC Profite de la richesse de windows mais rend les applications dpendantes de cette plateforme ActiveX dans application Intranet vs intrt de cette architecture ==> rappelle fortement le client-serveur deux tiers.
Anas ABOU EL KALAM
Page 49
Architecture trois tiers : Le service applicatif

architecture trois tiers logique applicative prise en charge par le serveur HTTP. (se retrouve dans la position du poste client d'une application deux tiers) Serveur HTTP peuvent mettre en uvre technos bases sur : CGI : mcanisme standard, mais grand consommateur de ressources, NSAPI ou ISAPI : API de Netscape et Microsoft permettant l'criture d'applications multi-thread intgres au serveur HTTP, scripts serveur comme ASP (Active Server Page pour IIS) ou PHP (pour
Apache) sont interprts par le serveur pour gnrer des pages

dynamiquement, servlets Java ou JSP : qui appliquent le mcanisme des applets aux traitements raliss sur le serveur.
Anas ABOU EL KALAM
Page 50
Architecture trois tiers : Limitations

L'architecture trois tiers a corrig les excs du client lourd en centralisant une grande partie de la logique applicative sur un serveur Le poste client, qui ne prend sa charge que la prsentation et les contrles de saisie, s'est trouv soulag et plus simple grer. Par contre, le serveur constitue la pierre angulaire de l'architecture et se trouve
souvent fortement sollicit

il est difficile de rpartir la charge entre client et serveur. On se retrouve confront aux problmes de dimensionnement serveur et de gestion de la monte en charge. Les contraintes semblent inverses par rapport celles rencontres avec les architectures deux tiers!! client est soulag, mais serveur fortement sollicit Apparition des architectures n-tiers.
Page 51
Les architectures n-tiers : prsentation
pallier limitations architectures trois tiers & concevoir applis puissantes et simples maintenir.
distribuer plus librement la logique applicative, applicative faciliter la rpartition de la charge entre tous les niveaux.
Mettre en uvre une approche objet pour offrir plus grande souplesse d'implmentation faciliter la rutilisation des dveloppements. Capacits d'extension
permettre l'utilisation d'interfaces utilisateurs riches, sparer nettement tous les niveaux de l'application,
Anas ABOU EL KALAM
Page 52

L'appellation n-tiers pourrait faire penser que cette architecture met en uvre un nombre indtermin de niveaux de service, alors que ces derniers sont au maximum trois.
La distribution d'application entre de multiples services et non la multiplication des niveaux de service.
composants mtiers spcialiss et indpendants, introduits par les concepts orients objets
composants mtiers rutilisables rendent service gnrique/rutilisable et clairement identifi. sont capables de communiquer entre eux et peuvent donc cooprer en tant implants sur des machines distinctes.
Anas ABOU EL KALAM
Page 53

Distribution des services applicatifs sur plusieurs serveurs
facilite l'intgration de traitements existants dans les nouvelles applications.... Ex : connecter un programme de prise de commande existant sur le site de l'entreprise une application distribue en utilisant un middleware
Objectif gnral
volutivit Maintenabilit Performances
Quantit de donnes stocke Disponibilit du serveur Nombre dutilisateurs
Anas ABOU EL KALAM
Page 54
Les architectures n-tiers : Le rle de l'approche objet

Les volutions de l'informatique permettent de masquer la complexit des mcanismes mis en uvre derrire une approche de plus en plus conceptuelle.
Programmation : langage machine OO (e.g., Java) Protocoles rseau : couche physique ORB Object Request Broker ensemble de fonctions (classes Java, bibliothques C++...) qui implmentent un bus logiciel par lequel des objets envoient et reoivent des requtes et des rponses, de manire transparente et portable
permet une totale transparence des appels distants permet de manipuler un objet distant comme s'il tait local
flux d'infos : octets messages
Anas ABOU EL KALAM
Page 55
Plan
Introduction / Notions gnrales De
linformation centralise au client-serveur
Anas ABOU EL KALAM
Page 56
Architectures n-tiers pour le Web
Rappels modle OSI Les architectures 3-tiers classiques les architectures Web Le tiers client Le tiers Web Le tiers du milieu Le tiers ressource (EIS)
Anas ABOU EL KALAM
Page 57
Couches OSI
Applications TCP/IP directes 7. Application EXEM PLES SM T P "Sim ple M ail T ransfer Protocol" FT P: "File T ransfer Protocol" Applications pile SUN/OS NFS: "Network File System " XDR:"E xternal Data Representation" RPC:"Rem ote Procedure Call" T CP: T ransm ission Control Protocol (connect) UDP: User Datagram Protocol (non connect) IP: Internet Protocol E ncapsulation IP (sur L AN ou liaisons SL IP,PPP) Pratiquem ent tout support de transm ission Rseaux Publics L ignes spcialises Point Point Rseaux L ocaux Rseau tlphonique RNIS, AT M
6. Prsentation
5. Session
4. T ransport
3. Rseau
2. L iaison
1. Physique
Anas ABOU EL KALAM
Page 58
Couches OSI : niveau transport

1er des niveaux utilisable par user pour dvelopper des applis C/S Ralise un service de transmission entre processus (transmission de bout en bout, "end to end"). Selon les options de conception il assure: Gestion des connexions. protocoles en mode connect protocoles en mode non connect. Ngociation de qualit de service. Multiplexage/clatement Contrle d'erreur. Contrle de flux. Contrle de squence. Segmentation.
Page 59
Couches OSI ==> niveau transport ==> TCP

Orient connexion permet deux machines qui communiquent de contrler l'tat de la transmission. Remettre en ordre datagrammes en provenance du protocole IP Vrifier le flot de donnes afin d'viter une saturation du rseau Formater les donnes en segments de longueur variable afin de les "remettre" au protocole IP Multiplexer les donnes faire circuler simultanment des informations provenant de sources distinctes sur une mme ligne Initialisation et fin d'une communication
Page 60
Couches OSI ==> niveau transport ==> UDP

transmission de donnes de manire trs simple entre deux entits dfinies par @IP + N port Mode non-connect: pas de moyen de vrifier si tous datagrammes envoys sont bien arrivs destination et ni dans quel ordre Non fiable : aucun contrle de flux ni de congestion
En revanche, pour un paquet UDP donn, l'exactitude du contenu des donnes est assure grce un checksum
Anas ABOU EL KALAM
Page 61
Couches OSI ==> niveau session

structure et synchronise les dialogues point point en mode message Synchronisation qui peut mettre tel moment gestion des transactions mcanisme de correction des erreurs de traitement par restauration d'un tat antrieur connu. Remarques Une seule session peut ouvrir et fermer plusieurs connexions Pour travail : appel ami qui demande infos supplmentaires Plusieurs sessions peuvent se succder sur la mme connexion
Coup de fil (avec votre pouse) un de vos amis (avec sa femme)
Page 62
Couches OSI ==> niveau session ==> RPC

Le mode de communication du transport tant le mode message asynchrone, la session est dfinie pour offrir l'usager un mode de dialogue de type synchrone. => Permettre un usager d'excuter une procdure ou une fonction sur un autre site: Problme dlicat : Assurer en environnement rparti une smantique pour l'appel de procdure distante voisine de celle connue en univers centralis. Exemples : Systmes d'objets rpartis JAVA RMI :"Remote Method Invocation" CORBA :"Common Object Request Broker Architecture" WS-SOAP :"Web Services - Simple Object Access Protocol"
Page 63
Couches OSI ==> niveau prsentation

Traite du codage des donnes changes diffrents sites ayant des reprsentations diffrentes peuvent utiliser les donnes Exemple "mots" = suite d'octets (mot de 32 bits=collection de 4 octets) Intel ==> octets numrots de droite gauche Motorola ==> de gauche droite Si machine base Intel <==> machine base Motorola ? ==> Les conversions de types : caractres, numriques, construits Syntaxe abstraite analogue de syntaxe dfinition de types dans langage volu Syntaxe de transfert Reprsentation unique dans le rseau des valeurs changes pour transfrer les donnes
Page 64
Couches OSI ==> niveau prsentation ==> standards de conversion

Rseaux publics
Syntaxe abstraite ASN1: X208 Syntaxe de transfert :X209
SUN-OS/ Internet XDR : "eXternal Data Representation". Systmes d'objets rpartis CORBA IDL : "Interface Definition Language". CDR : Common Data representation. Web services WSDL : "Web Services Definition Language". RPC/Encoded : "Syntaxe de transfert XML"
Anas ABOU EL KALAM
Page 65
Couches OSI ==> niveau prsentation
Compression des donnes Transferts avec application d'algorithmes de compression e.g., son, l'image ou la vido... Dans OSI, ces algos sont fournis par couche prsentation Scurit Cryptographie, ... ...
Page 66
Couches OSI ==> niveau application
cette couche propose galement des services fournir l'utilisateur des fonctions dont il a besoin couramment Principalement des services de transfert de fichiers, (FTP), de messagerie (SMTP) de documentation hypertexte (HTTP) etc.
Anas ABOU EL KALAM
Page 67
Accs aux informations distantes : le WWW

Objectif Permettre l'accs des donnes distantes pour des personnes. Bases Systmes de dsignation URL ("Uniform Resource Locator"), Protocole de communication HTTP (Hyper Text Transfer Protocol"), Initialement format HTML=> format MIME Extension ==> format XML Extension : permettre communications entre programmes: notion de services web SOAP Simple Object Access Protocol, WSDL Web Services Definition language UDDI 'Universal Description Discovery and Integration'
Page 68
Architectures n-tiers pour le Web
Rappels modle OSI Les architectures 3-tiers classiques les architectures Web Le tiers client Le tiers Web Le tiers du milieu Le tiers ressource (EIS)
Anas ABOU EL KALAM
Page 69
Rappel : architectures 3-tiers classiques
Anas ABOU EL KALAM
Page 70
Les architectures web
Anas ABOU EL KALAM
Page 71
Les architectures web : le tiers client

web browser
PDA client lourd (fat client), applets, apps Web-service
Anas ABOU EL KALAM
Page 72
Les architectures web : le web tiers

reois les requtes HTTP des clients et renvois les rponses permet la sparation entre prsentation et business logic gnre du contenu dynamiquement transforme des requtes HTTP dans un format compris par lapplication contient la logique du flot de prsentation identifie la session de lutilisateur supporte plusieurs types de clients
Anas ABOU EL KALAM
Page 73
Le tiers web : Technoligies & architecture

CGI/FastCGI ASP Java Servlets JSP PHP, Python JavaScript
Anas ABOU EL KALAM
Page 74
Les architectures web : le tiers du milieu

Gestion de composants Tolrance de fautes, haute disponibilit Passage l'chelle Balance de charge Ressources spooling Transaction Management Console de management Scurit
Anas ABOU EL KALAM
Page 75
Les architectures web : le tiers ressource

Base de donnes (databases) JDO, SQL/J, JDBC, ADO.NET ERP (Enterprise Resource Planning) & EAI (Enterprise Application Integration) J2EE Connector, protocoles propritaires
Anas ABOU EL KALAM
Page 76
Plate-formes
Deux mondes/logique .
Anas ABOU EL KALAM
Page 77
Plan
De linformation centralise au client-serveur
Les architectures distribues Application : architectures web Plate-forme .NET Plate-Forme J2EE Les services Web
Anas ABOU EL KALAM
Page 78
. NET
Technologie/spcification Microsoft
Prsentation : IE Serveur HTTP / FTP : IIS Communication : COM, MSMQ, COM+ Composants : COM, MTS Business <-> Data : ActiveX Data Object, ODBC Accs aux donnes : OLEDB Persistance : SQL Server, Exchange, Active Directory et NTFS
Page 79
. NET
Rponse de Microsoft J2EE pour Dvpt d'applis d'entreprises multi-niveaux, bases sur des composants correspond un ensemble Microsoft qui comporte un framework, des langages de dveloppement, des spcifications techniques et des systmes (Systmes d'exploitation, Logiciels serveurs...)
3 parties
CLR BCL ASP.NET
CLS CTS MSIL

Page 80
Framework .NET
environnement d'excution CLR : moteur d'excution, compiler le code source en MSIL (MS Intermediate Language) 1re excution, code MSIL est compil la vole en code spcifique au systme grce au compilateur JIT (Just In Time). ASP .NET : environnement d'excution d'applications et de services web WinForms : environnement d'excution d'applications lourdes. Services FCL : (Framework Class Library) : librairie Library OO SDK (Software Development Kit) : implmentation de ces classes
Page 81
ASP.NET / WebForms
ASP.NET est une abstraction de HTTP Pages compiles et excutes dans le CLR Modle de dveloppement bas sur les WebForms Sparer traitements et prsentations formulaire reprsente la page web Traitements contenus dans 2de page appele code behind Cette page peut tre code dans nimporte quel langage du Framework .Net et implmente vnements Page finale (gnre au client) intgre prsentation et Code Behind
Anas ABOU EL KALAM
Page 82
Plan
De linformation centralise au client-serveur Les architectures distribues Application : architectures web Plate-forme .NET Plate-Forme J2EE Les services Web
Anas ABOU EL KALAM
Page 83
J2EE
Standard international Une appli J2EE assemble des composants Composants client : appelts Composants Web : Servlets, JSP Composants Business : EJB Notion de ByteCode API : EJB, JDBC, Java Servlet Technology, JSP Technology, JMS, JTA, JavaMail Technology, JAF, JAXP, JAAS, .
Anas ABOU EL KALAM
Page 84
Architecture n-tiers : Les Java Beans

Les Java Beans
composant logiciel rutilisable. notion large englobe aussi bien un simple bouton qu'une appli complte. Concrtement, les Java Beans sont des classes Java utilisant des interfaces particulires. peut tre utilis indpendamment, sous la forme d'une simple applet, ou intgr un dveloppement Java Les beans sont prvus pour pouvoir inter-agir avec d'autres beans au point de pouvoir dvelopper une application simplement en assemblant des beans avec un outil graphique ddi. Sun fournit gratuitement un tel outil : B.D.K. (Bean Development Kit)
Anas ABOU EL KALAM
Page 85
Architecture n-tiers : Les Java Beans

caractristiques : persistance : elle permet grce au mcanisme de srialisation de sauvegarder l'tat d'un bean pour le restaurer ainsi si on assemble plusieurs beans pour former une application, on peut la sauvegarder. communication grce des vnements qui utilise le modle des couteurs peut dvoiler son comportement ses futurs utilisateurs l'aide : proprits qu'il expose et rend accessible l'aide d'accesseurs, des mthodes qu'il permet d'invoquer, comme tout objet Java, des vnements qu'il peut gnrer pour avertir d'autres composants. introspection : ce mcanisme permet de dcouvrir de faon dynamique l'ensemble des lments qui compose le bean (attributs, mthodes et vnements) sans avoir le source. possibilit de paramtrer le composant : les donnes du paramtrage sont conserves dans des proprits. sont livrs sous forme de fichiers JAR
Page 86
Architecture n-tiers : Les EJB

but : faciliter la cration d'applications distribues pour les entreprises. Les EJB sont des composants et en tant que tel, ils possdent certaines caractristiques comme la rutilisabilit, la possibilit de s'assembler pour construire une application, etc ... Les EJB et les beans n'ont en commun que d'tre des composants. Les java beans sont des composants qui peuvent tre utiliss dans toutes les circonstances. Les EJB doivent obligatoirement s'excuter dans un environnement serveur ddi. Les EJB ne comportent pas forcment de partie visible, Les EJB permettent aux dveloppeurs de se concentrer sur traitements orients mtiers Les EJB et l'environnement dans lequel ils s'excutent prennent en charge certain traitements : gestion des transactions, persistance des donnes, ... peuvent communiquer avec des Java Beans ct client de faon indpendante du protocole (IIOP, RMI, DCOM),
Page 87
Architecture n-tiers : Les EJB

Les EJB sont adapts pour tre intgrs dans une architecture 3-tiers ou n-tiers. Les EJB s'excutent dans un environnement particulier: le serveur d'EJB fournit des fonctionnalits utilises par un ou ++ conteneurs d'EJB qui constituent le serveur d'EJB.
serveurs d'EJB commerciaux

BEA Weblogic, IBM Webpshere, Sun IPlanet, Macromedia JRun, Borland AppServer,... JBoss, Jonas
Anas ABOU EL KALAM
serveurs d'EJB open source :

Page 88
Architecture n-tiers : Les Microsoft Transaction Server : (MTS)

COM : Components Objects Model
mcanisme au niveau du systme dexploitation dans lequel il est possible dinstaller des composants serveurs afin de fournir des services varis des logiciels clients dveloppement de logiciel est facilit, puisquil est possible dcrire un programme en faisant appel des traitements effectus par un serveur COM dvelopp par un tiers.
MTS
Serveur destine simplifier la gestion et le suivi des composants distribues (COM) Fonctionnalits associes aux composants : prise en charge automatique des transactions pour protger l'intgrit des donnes, scurit base de rles, accs aux bases de donnes, aux logiciels de mise en file d'attente des messages. optimisation des performances telles que les pools de connexion.
Anas ABOU EL KALAM
Page 89
Communication entre objets : les RMI
mettre en uvre facilement des objets distribus permettre l'appel, l'excution et le renvoi du rsultat d'une mthode excute dans une machine virtuelle diffrente de celle de l'objet l'appelant. Serveur : machine sur laquelle s'excute la mthode distante Client : appel mthode obtenir une rfrence sur l'objet distant appeler la mthode partir de cette rfrence. Stub: reprsentation locale de l'interface de l'objet serveur (Skeleton) Un objet distribu se caractrise par son interface et son adresse (URL).
Anas ABOU EL KALAM
Page 90
Communication entre objets : CORBA

Standard dfini par l'OMG pour faire communiquer des objets, au sens logiciel du terme, quels que soient le langage de programmation utilis et la machine sur laquelle s'excute le programme. Une application accde un objet distant en utilisant une tlcommande locale, appele proxy. Ce proxy lui permet de dclencher les mthodes de l'objet distant l'aide de primitives dcrites avec le langage IDL. L'OMG effectue toute une srie de recommandations connues sous le nom de CORBA services visant proposer des interfaces gnriques pour chaque type de service usuel (nommage, transaction, cycle de vie, ...).
Anas ABOU EL KALAM
Page 91
Comparaison J2EE et .NET
Anas ABOU EL KALAM
Page 92
Anas ABOU EL KALAM
Page 93
Anas ABOU EL KALAM
Page 94
Comparaisons
JSP
Langage Java
PHP
PHP
ASP
VBScript ou JScript
Asp.Net
Tous les langages supports par .Net (C#, VB.Net, Delphi, ...)
mode d'excution principaux avantages
Compil en pseudo code (byte code) Repose sur la plate-forme Java dont elle hrite des avantages
Interprt
Interprt
Compil en pseudo code (MSIL)
Open source Nombreuses bibliothques et sources d'applications libres disponibles Facile MEV
Facile mettre en oeuvre
Repose sur la plate-forme .Net dont elle hrite des avantages Wysiwyg et evnementiel Code behind pour sparation affichage / traitements
principaux inconvnient s
Dbogage assez fastdieux
Dbogage assez fastdieux
Dbogage fastdieux
Fonctionne
essentiellement sur plateBeaucoup de code ABOU EL KALAM Anas formes Windows. ( Voir le
Page 95

Architecture n-tiers base dobjets est le grand GAGNANT ! De nos jours, limportant nest pas de matriser Java, VB, ou C#, mais de comprendre en quoi ces langages sont utiles pour implmenter des archi solides, volutives et maintenables. Intgration l'existant : 1 point partout, la balle au centre
Choisir .NET quand tout le systme informatique repose sur un environnement Microsoft - et inversement - cest possible
J2EE connecteur universel (JCA) . NET Web services

Page 96

Le pragmatisme de Microsoft face l'ouverture de J2EE
Un dveloppeur Visual Basic passera sans difficult .Net. Mais plus difficilement Java, linverse tant galement vrai chez Microsoft, tout est packag : un problme correspond une solution sur J2EE, souvent solutions, parfois sous forme de briques assembler Lapproche .Net est donc plus simple et adapte la PME. Mais la plate-forme manque de maturit, Microsoft ne couvre pas tous les besoins dune PME faire le choix .Net, cest accepter de dpendre de Microsoft l o avec J2EE on a le choix entre diffrents diteurs et mmes des solutions gratuites ou quasiment gratuites en Open Source". argument avant tout marketing : .Net accepte certes plus de 25 langages de dveloppement l o J2EE naccepte que Java
Mais je vois mal un dveloppeur Cobol dvelopper pour .Net. Ce nest pas impossible, mais la culture, les architectures, les applications... tout est diffrent avec .Net ou J2EE
Page 97

.Net moins cher sur le court terme, mais aprs ? Microsoft : solutions tant plus packages, elles ncessitent moins de dveloppements, moins de ressources humaines la phase dacquisition des comptences est plus courte, la mise en oeuvre est plus rapide et tout cela cote forcment moins cher que lassemblage de briques de J2EE. Le retour sur investissement est donc plus rapide sur le court terme. Avec le temps, les choses squilibrent et cest mme plus dlicat sur le long terme, car il nest pas impossible que la phase initiale de J2EE, certes plus fastidieuse, savre plus avantageuse sur le long terme".
Anas ABOU EL KALAM
Page 98
Architecture cohrente
Architecture n-tiers
vision cohrente du systme d'information. Tous les services sont reprsents sous la forme d'objets interchangeables qu'il est possible d'implanter librement, en fonction des besoins. potentiel trs important et permettrait utilisation objets mtiers rutilisables moindre cot et volution en fonction des besoins voir comment il sera utilis, quel cot comment sera gre la transition depuis les environnements actuels.
Anas ABOU EL KALAM
Page 99
Rcapitulatif & exemples

Architecture 1-tiers
Application mainframe
C/S avec SGBDR et middleware orient message, transactionnel ou objet
Clients lgers, serveurs web, serveurs dapplication et middleware
Architecture n-tiers
Rpartition de charge sur diffrents serveurs, mise en uvre de fermes de serveurs,
Page 100
Plan
De linformation centralise au client-serveur
Les architectures distribues Application : architectures web Plate-forme .NET Plate-Forme J2EE Les services Web
Anas ABOU EL KALAM
Page 101
Services web
Pourquoi ?
Lintgration de modules distribus est trs difficile cause de lhtrognits des systmes dialoguer distance via Internet, indpendamment des plates-formes et des langages sur lesquelles elles reposent CORBA tait une solution mais sa complexit a frein son dveloppement
Quoi ?
composant logiciel reprsentant une fonction applicative. peut tre accessible depuis une autre application
client, serveur ou autre service Web
Utilise rseaux Internet & protocoles de transports disponibles. peut tre implment comme une application autonome ou comme un ensemble d'applications Bass sur XML Protocoles simples et standards
Page 102
Services web
Comment ?
protocoles standardisant les modes d'invocation mutuels de composants applicatifs
Couche de transport
HTTP, FTP ou SMTP, SOAP WSDL UDDI
Messages XML Description des services Recherche de service
Scnario
Anas ABOU EL KALAM
Page 103
Exemple
Anas ABOU EL KALAM
Page 104
Exemple
Client
Demande service
Fait recherche smantique dans annuaire UDDI qui donne la liste des prestataires habilits rpondre la requte Rception rponse (en XML) Recherche interface du composant rfrenc dans annuaire Interface WSDL
Dcrit lensemble des services implments par lobjet distribu et il est possible de vrifier si linterface correspond la demande
Proxy SOAP
invocation service
Page 105
Larchitecture Web Services .NET
Anas ABOU EL KALAM
Page 106
Larchitecture Web Services J2EE
Anas ABOU EL KALAM
Page 107
C/C
Avantages
Simple, prsent sur toutes plates-formes / langages Dployable partout Couche lgre sur systmes existants
Problmes
Nouveau Applis indpendantes et contrles par organisations diffrentes Fiabilit non garantie
Anas ABOU EL KALAM
Page 108
BIBLIO
Micromax Information ServicesLtd. 1999. N-Tiers Background Articles. www.n-tiers.com, Octobre 1999 FrdricNAJMAN CdricNICOLAS, ChristopheAVARE. Java client-serveur. Eyrolles, 1998. ThierryRUIZ EmmanuelLIGNE. Corba : Objectifs et architecture. www.etu.info.unicaen.fr/cliquet/dess/corba/doc-fr/node3.html, Avril 1997. PhilippeUSCLADE Jean-FranoisGOGLIN. Du client-serveur au web-serveur. Herms Sciences, 1999. Daniel MARTIN. Architecture des applications rparties. http://worldserver2.oleane.com/, Octobre 1999. /dmartin/Architecture applications reparties.htm.
Page 109

Arc Hi

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Arc Hi

Încărcat de

Drepturi de autor:

Formate disponibile

Technologie des applications client-serveur UE RSX 102 Support de cours Tome 1 Anas ABOU EL KALAM

Technos pour les applis C/S : Introduction

Anas ABOU EL KALAM

Les "middlewares Les architectures distribues Application : architectures internet

Technos pour les applis C/S : Introduction

Anas ABOU EL KALAM

Les architectures distribues Les "middlewares Application : architectures internet

Technos pour les applis C/S : Introduction

Anas ABOU EL KALAM

Introduction : situation actuelle

Technos pour les applis C/S : Introduction

Anas ABOU EL KALAM

Introduction : systmes disponibles

Standardisation, C/S, ...

Introduction : Modes de comm entre progs

Communication asynchrone par messages : avantages

Le C/S : dfinition (basique)

Le C/S en mode message : Architecture gnrale

Architecture Rponse de communication Rseau "Middleware"

Technos pour les applis C/S : Introduction

Anas ABOU EL KALAM

Le C/S : applications (1/2) informatique de gestion algorithmique rpartie, informatique industrielle,

Applications internet ....

Technos pour les applis C/S : Introduction

Anas ABOU EL KALAM

C/S : applications (2/2)

Le C/S en mode message : Architecture gnrale

Les "middlewares Les architectures distribues Application : architectures internet

Technos pour les applis C/S : Introduction

Anas ABOU EL KALAM

Niveaux d'abstraction d'une application

Couche prsentation (IHM)

Logique applicative, traitements

mcanismes permettant la gestion des informations stockes par l'application

Technos pour les applis C/S : Introduction

Anas ABOU EL KALAM

Niveaux d'abstraction d'une application

Technos pour les applis C/S : Introduction

Anas ABOU EL KALAM

Niveaux d'abstraction d'une application

Le noyau de l'application est compos de

Le dcoupage et la rpartition de ce noyau permettent de distinguer les architectures applicatives suivantes :

L'architecture un-tiers : dfinition

L'architecture un tiers : exemple du mainframe (1/2)

esclaves. qui prend en charge l'intgralit des traitements,

Les applis sont excutes sur Serveur central (mainframe)

Technos pour les applis C/S : Introduction

Anas ABOU EL KALAM

L'architecture un tiers : mainframe (2/2) Avantages

Technos pour les applis C/S : Introduction

Anas ABOU EL KALAM

L'architecture un tiers : Limitations

Solution doit concilier

Ainsi est n le concept du client-serveur ...

Modles de rpartitions : schma du Gartner Group (1/5)

Technos pour les applis C/S : Introduction

Anas ABOU EL KALAM

Le schma du Gartner Group (2/5)

Technos pour les applis C/S : Introduction

Le schma du Gartner Group (3/5)

Le schma du Gartner Group (4/5)

Bases de donnes distribues

Donnes et traitements distribus

Technos pour les applis C/S : Introduction