Développement logiciel

Technologies d’applications WEB

Baidy THIONGANE,
Reine Marie Ndéla MARONE
 Pré-requis et Objectif général
Pré-requis :
• Avoir maitrisé les langages de base du Web (HTML, CSS, Javascript )
• Avoir une expérience en programmation Web côté serveur avec l’un des langages suivants: PHP,
Python, dotnet, Java EE…

Objectifs généraux :
• Comprendre les différentes architectures d’applications WEB.
• Etre capable de mettre en œuvre les différentes technologies pour réaliser une application web.
 Présentation cours
Découpage du cours

• Séquence 1: Introduction
Objectifs spécifiques : A la suite de cette séquence, l’étudiant doit être capable de:
1. Décrire les enjeux et les défis d’une application web
2. Comprendre les architectures logiques d’une application web
3. Identifier les différentes couches de l’architecture logicielle d’une application web.
 Présentation cours
Découpage du cours

• Séquence 2: Client tier

Objectifs spécifiques : A la suite de cette séquence, l’étudiant doit être capable de:
1. Décrire les sous parties de la couche CLIENT.
2. Classifier les différentes sous parties de la couche CLIENT.
3. Mettre en œuvre chaque sous partie avec les technologies qu’il faut.
 Présentation cours
Découpage du cours

• Séquence 3: Middle Tier

Objectifs spécifiques : A la suite de cette séquence, l’étudiant doit être capable de :
1. Décrire les sous parties de la couche MIDDLE Tier.
2. Classifier les différentes sous parties de la couche MIDDLE Tier.
3. Mettre en œuvre chaque sous partie avec les technologies qu’il faut.
 Présentation cours
Découpage du cours

• Séquence 4: Backend
Objectifs spécifiques : A la suite de cette séquence, l’étudiant doit être capable de :
1. Décrire les sous parties de la couche Backend.
2. Classifier les différentes sous parties de la couche Backend .
3. Mettre en œuvre chaque sous partie avec les technologies qu’il faut.
 Présentation cours
Découpage du cours

• Séquence 5: Conception et Développement d’une application web.

Objectifs spécifiques : A la suite de cette séquence, l’étudiant doit être capable de :

1. Assembler les différentes composants technologiques d’une application web.
2. Créer une application web qui fonctionne.
Consigne de travail

Consignes :

• Lire et comprendre les séquences du cours

• Reprendre les exemples du cours
• Faire les tests de connaissances
• Faire les travaux dirigés
Introduction
 Historique et enjeux
• Applications web désormais utilisées pour presque
toutes les activités sur le net:
 shopping (boutique en ligne, grand site de vente
en ligne comme Amazon),
 réseau social (Facebook),
 facturation, comptabilité en ligne,
 gestion de contenus, moteur de recherche
(Google)…
• Développement applications web rapide et pas prêt de
s’épuiser.
• Part de plus en plus importante sur les logiciels.
Applications web au coeur de nos activités
 Historique et enjeux

• Avantages des applications web:

 accessibilité de partout et à toute heure
à partir ordinateur ou terminal mobile de
l’utilisateur,
 mises à jour automatiques,
 sauvegarde et centralisation des
Applications responsive ou adaptative design données,
 coût moins élevé qu’un logiciel…
Historique et enjeux
• Croissance vertigineuse des applications web.
 Début d’internet: sites web proposant du
contenu identique pour tous les utilisateurs.
 Années 1990: 1ères applications web bien
moins performantes et maniables que les
logiciels à installer.
Yahoo en 1999  Dès 2002: « Rich Internet Application »
aussi efficaces que les logiciels avec capacités
qui ne cessent de s’accroître. Différentes
technologies permettant d’enrichir le contenu
proposé à l’internaute.

Yahoo en 2018
Historique et enjeux
• 2007: sortie du 1er Iphone. Utilisation des applications sur les smartphones:
tournant radical, nouvelle ère des applications web.
• Les sites et applications web doivent désormais s’adapter à:
 nouveaux usages,
 tous les nouveaux supports existants (tablettes, smartphones, objets
connectés….):responsive ou adaptative design.

Applications responsive ou adaptative design

Historique et enjeux
• Nouvelles exigences des applications web pour les prochaines années:
 Simplicité d’usage, design, ergonomie.
 Plus d’interactivité, d’intuitivité, expériences agréables aux internautes.
 Applications toujours plus rapides et riches.
 Garantir la sécurité des données des usagers. Ex: sécurisation transfert d’argent,
paiement en ligne.
 S’adapter à tous les nouveaux supports (tablettes, smartphones…): responsive
ou adaptative design.
• Développer des applications web convaincantes sera de plus en plus complexe !
• Faire appel à des professionnels devient réellement indispensable.
Architecture des applications web

• Une application web peut être découpée en 3 niveaux d'abstraction distincts :

 La couche de présentation ou IHM: gère
l'interaction entre l'application et l'utilisateur.
 La logique applicative: gère les traitements
représentant les travaux à réaliser par
l'application.
 Les données, ou plutot l'accès aux données:
regroupe l'ensemble des mécanismes
permettant la gestion des informations stockées
par l'application.
• Ces trois niveaux peuvent être imbriqués ou répartis de différentes manières entre plusieurs
machines physiques.
Architecture des applications web
• Noyau de l'application composé de la logique de présentation et de la logique
applicative.
• Découpage et répartition de ce noyau permettant de distinguer les architectures
applicatives suivantes :
 l'architecture 1-tiers,
 l'architecture 2-tiers,
 l'architecture 3-tiers,
 les architectures n-tiers.
• Nb: tiers = couches= niveaux (de l’anglais tiers : étage).
 Architecture 1tiers
• Années 90, application 1tiers: les 3
couches intimement liées et s'exécutant sur
la mê me machine (informatique
centralisée).
• Dans un contexte multi-utilisateurs: 2 types
d'architecture mettant en oeuvre des
applications 1tiers :
Mainframe: ordinateur central dans lequel  des applications sur site central,
tous les programmes sont déployés
 des applications réparties sur des
machines indépendantes communiquant
par partage de fichiers.
Architecture 1tiers

Interface utilisateur en mode caractère

Architecture d'une application sur site central
Architecture 2tiers
• A partir des années 90:explosion de la
volumétrie des données entraine séparation
applications et données.
• Données stockées dans des bases de
données sur d’autres machines.
• Architecture 2tiers(client-serveur de 1ère
génération ou client-serveur de données) utilise
puissance des ordinateurs sur le réseau et
fournit à l’utilisateur une interface riche.
• Gestion des données par un SGBD centralisé
sur un serveur dédié et interrogé via un langage
de requê te, exemple: SQL.
Architecture 2tiers
• Dialogue entre client et serveur se résumant à l’envoi de
requêtes et aux données en réponse.
• Echange de messages transitant à travers le réseau reliant les
2machines.
• Mise en oeuvre de mécanismes relativement complexes pour
gérer les échanges de message.
• Mécanismes généralement pris en charge par un middleware.
Architecture 2tiers
• Middleware, littéralement « élément du milieu »: ensemble des couches
réseau et services logiciel permettant le dialogue entre les différents
composants d'une application répartie.
• Dialogue basé sur un protocole applicatif commun, défini par l'API du
middleware.

Middleware
Architecture 2tiers
• Inconvénients architecture 2tiers:
 Le client supporte tous les traitements applicatifs: client lourd, ou fat client;
 Le poste client fortement sollicité, devient de plus en plus complexe et nécessite
des mises à jour régulières;
 Difficulté à modifier l'architecture initiale: fortes montées en charge mal
supportés par les applications ;
 La relation forte et étroite entre le programme du client et l'organisation de la
partie serveur complique les évolutions de cette dernière ;
 Architecture grandement rigidifié par les coûts et la complexité de maintenance.
• Conclusion: Architecture 2tiers souvent cantonné au réseau local de l'entreprise.
Architecture 3 tiers

• Dans l’architecture 3tiers: séparation entre la couche présentation et la couche

applicative (aussi appelée couche métiers).
Architecture 3-tiers : Couche Présentation ou Tiers client

• La couche présentation correspond à la partie de l’application visible et

interactive avec les utilisateurs(IHM).
• Peut être réalisée par une application graphique ou textuelle, en HTML, en
WML (clients légers).
• Interface pouvant prendre de multiples facettes sans changer la finalité de
l'application.
Architecture 3-tiers : Couche Présentation

• Par exemple: système de distributeurs de billets, l'automate peut être

différent d'une banque à l'autre, mais les fonctionnalités offertes sont
similaires et les services identiques (fournir des billets, donner un extrait
de compte, etc.).
• Une même fonctionnalité métier (ex: commande d'un nouveau chéquier) peut
avoir une présentation sur Internet différente de celle sur un distributeur
automatique de billets ou sur l’écran d'un chargé de clientèle en agence.
• Technologies :• Un navigateur Web, Un PDA ou SmartPhone.
Architecture 3-tiers : Couche Présentation
1. La couche présentation relaie les requêtes de l'utilisateur à destination de la couche
métier.
2. La couche métier renvoie ensuite à la couche présentation les résultats qu'elle a
calculés.
3. La couche présentation en retour présente à l’utilisateur les informations
renvoyées par les traitements de la couche métier .
Architecture 3-tiers : Couche applicative

• Couche applicative ou couche métier ou business ou encore serveur d’applications:

contient les traitements représentant les règles métier (créer un compte de facturation,
calculer un amortissement ... )
• Offre des services applicatifs et métiers à la couche présentation.
• Utilise les données accessibles à travers la couche inférieure pour fournir ces services.
• Technologies: • CGI,
• ASP• Java Servlets
• JSP• PHP, Python
•JavaScripts •...
Architecture 3-tiers : Couche données

• Couche de données: partie gérant l'accès aux données du système. Par ex:
peut contenir les usines d'objets métier, c'est à dire les classes chargées de
créer des objets métier de manière totalement transparente, indépendamment
de leur mode de stockage (SGBDR, Objet, Fichiers, ...).
• Ces données peuvent être propres au système, ou gérées par un autre
système.
• La couche métier n'a pas à s'adapter à ces 2 cas: accès aux données de
manière uniforme, on dit qu’il y a un faible couplage.
• On a couplage faible, couplage léger ou couplage lâche si les composants
échangent peu d'information.
 Architecture 3-tiers : Couche données

• Données propres au système :

 Données pérennes: durée de vie plus ou moins longue, voire définitive.
 Données pouvant être stockées indifféremment dans de simples fichiers texte,
fichiers XML, ou SGBD.
 Accès aux données identique: quel que soit le support de stockage choisi, l'accès aux
données doit être le même.
 Exemples:
DATA ACCESS OBJET (DAO) consiste à représenter les données du système
sous la forme d'un modèle objet. Par exemple un objet pourrait représenter un
contact ou un rendez-vous.
La représentation du modèle de données objet en base de données (appelée
persistance) peut être effectuée à l’aide d’outils tel que HIBERNATE.
Architecture 3-tiers : Couche données

• Données gérées par un autre système:

 Données gérées de manière externe par un autre système.
 Ex: application de pilotage de l'entreprise qui ne stocke pas des données
comptables dont elle a besoin, mais les demande à une application de
comptabilité.
 Ce système externe est indépendant et on ne se préoccupe pas de savoir
comment il obtient les données ou si elle les sauvegarde, on utilise simplement sa
capacité à fournir des données à jour.
• Technologies: Base de données via SQL, JDBC, .NET, JavaEE, ERP (Enterprise
Resource Planning), EAI (Enterprise Application Integration)
 Architecture 3-tiers : Couche données

Avantages architecture 3 tiers Inconvenients architecture 3 tiers

• Correction des excès du client lourd • Serveur HTTP fortement sollicité et difficulté de répartir la charge entre
en centralisant une grande partie de client et serveur.
la logique applicative sur un serveur • Problèmes de dimensionnement serveur et de gestion de la montée en
HTTP. charge rappelant l'époque des mainframes.
• Poste soulagé et plus simple à gérer • Solutions mises en œuvre relativement complexes à maintenir et
car il ne prend à sa charge que la gestion des sessions compliquée.
présentation et les contrôles de • Contraintes inversées par rapport à l’architecture 2 tiers : le client est
saisie. soulagé, mais le serveur est fortement sollicité.

• Le juste équilibrage de la charge entre client et serveur semble etre atteint avec la génération suivante : les
architectures n-tiers.
Architecture Multi-tiers

• Architecture multi-tiers appelée aussi architecture distribuée ou

architecture n-tiers: pensée pour pallier aux limitations des architectures 3
tiers et concevoir des applications puissantes et simples à maintenir.
• Permet de distribuer plus librement la logique applicative, facilite ainsi la
répartition de la charge entre tous les niveaux.
• Qualifie la distribution d'applications entre de multiples services et non
la multiplication des niveaux de service.
Architecture Multi-tiers

• Utilisation de composants métiers, spécialisés et indépendants, introduits

par les concepts orientés objets pour faciliter la distribution.
• Permet de tirer pleinement partie de la notion de composants métiers
réutilisables et modulables.
• Un composant est une «boîte noire», créé par un développeur, qu’il va
réutiliser et que d’autres développeurs vont utiliser.
• Le développeur utilisateur connaît seulement les points d’entrée et le type
des informations retournées. Ex: Les composants JavaEE sont les EJB.
Architecture Multi-tiers

• Ces composants rendent un service, si possible, générique et clairement

identifié.
• Ils sont capables de communiquer entre eux et peuvent donc coopérer en
étant implantés sur des machines distinctes et hétérogènes.
Architecture Multi-tiers: Exemple de l’architecture SOA
Motivations architecture SOA
• Jusqu’à fin années 1990:
 Utilisation de mainframes s’occupant de toutes les opérations du SI de l’entreprise.
 Programmes tous déployés dans le mainframe avec les mêmes technologies.
• Début des années 2000:
 Procédés dans les entreprises de plus en plus informatisés,
 De plus en plus de logiciels externes à forte valeur ajoutée intégrés au SI. Par exemple,
l’entreprise peut souhaiter:
 Intégrer un ERP de gestion du service après vente (SAV),
 Intégrer un e-commerce grâce à un CMS pour vendre les
produits en ligne et profiter de l'essor de ce secteur,
 Automatiser la gestion des commandes des clients
professionnels pour faire face à la concurrence.
Architecture Multi-tiers

• Problème: Besoin d’un environnement adapté pour chacun de ces systèmes à

ajouter : système d’exploitation, capacité de stockage et de calcul, configuration
spécifique (ports, pare-feu, etc.).
• Solution: remplacer le mainframe par plusieurs ordinateurs (serveurs) munis
d'environnements adaptés à chaque système.
• Ainsi les entreprises exploitaient plusieurs serveurs. Par ex:
 un serveur pour gérer la boutique en ligne,
 un serveur pour l’ERP du SAV(Service Après Vente),
 un serveur pour les grossistes et la gestion des commandes,
 un serveur pour un ERP de comptabilité.
Architecture Multi-tiers
• Problème : comment faire communiquer
tous ces différents systèmes ?
• Solution: faire appel à chaque système dans
le format qu’il comprend.
• Ex: ERP écrit en COBOL appelle la boutique
en ligne écrite en PHP pour obtenir la dernière
commande d’un client, la requête doit être
envoyée dans un format X compatible PHP.
• Réponse de l'ERP envoyée à la boutique dans un format Y à transformer en
un format compatible avec COBOL pour être exploité.
• Transformations réalisées par des adaptateurs.
• Besoin d’un adaptateur pour chaque logiciel dans le SI afin qu’il puisse
communiquer avec un autre logiciel.
Architecture Multi-tiers

• Avec l’agrandissement du système apparaissent les problèmes suivants :

 Complexité du système : gestion de dizaines d’adaptateurs par chaque
logiciel afin de communiquer avec des dizaines d’autres logiciels.
 Flexibilité limitée : changement d’une fonctionnalité dans un logiciel du SI
impliquant des changements en cascade dans tout le SI : mise à jour d’adaptateurs,
redéploiement de l’ensemble, etc.
 Scalabilité difficile.
 Coût de maintenance trop élevé dû à la complexité du système et à
l'interdépendance forte entre les composants du SI.
Architecture Multi-tiers

• Idée de l’architecture SOA: organiser les SI en briques indépendantes appelées

services.
• Chaque service ayant un nombre de fonctionnalités cohérentes et indépendant des
autres services.
• Services communiquant entre eux grâce à un protocole standard, connu et compris de
tous.
• Protocole SOAP basé sur le XML s’est largement imposé.
Architecture Multi-tiers

• Pour bien comprendre le concept, analysons une implémentation de la SOA sous forme
d’un web service.
• Ex: Développement d’un web service pour gérer les clients d’une banque.
• Ce web service va avoir les fonctionnalités suivantes :
 Récupérer un client grâce à son ID.
 Mettre à jour les informations d’un client.
 Récupérer ses mouvements de compte.
Architecture Multi-tiers

• Possibilité de développer le service en Java qui va interagir avec les bases de

données de la banque pour accomplir ces fonctions.
• Une fois mis en production, ce service peut être appelé par un autre service qui s’occupe
de l’application mobile.
• Objectif: obtenir informations proposés par votre service afin d’afficher une page de
compte à l’utilisateur final.
Architecture Multi-tiers

• 1er problème: Comment indiquer au service mobile où trouver votre service, les
fonctionnalités qu'il propose et comment les appeler ?
• Solution: Etablir un “contrat” entre les services expliquant le fonctionnement de chaque
service.
• Contrat souvent au format d’un document XML appelé WSDL.
• Structure du contrat standard et connue de tous les services.
• Rédiger donc un document WSDL dans lequel on décrit l’URL du service, fonctions
proposés et paramètres requis pour chaque fonction.
• Le service mobile n’a plus qu’à consulter ce document pour pouvoir faire appel à votre
service.
Architecture Multi-tiers
• 2e problème: Comment les autres services
peuvent-ils trouver votre document WSDL
pour consultation ?
• Solution: centraliser tous les documents
WSDL dans un serveur qui tient un annuaire
de ceux-ci.
• Annuaire appelé UDDI (Universal Description
Discovery and Integration).

• Les différents services connaissent l’URL de cet annuaire. Ils le consultent pour découvrir les
nouveaux services et lire les WSDL afin de communiquer ensemble. Ils ont ainsi l’URL du
service, ses fonctions et le type de réponse qu’il va renvoyer.
Architecture Multi-tiers

• 3e problème: Comment faire communiquer des services écrits dans des langages
différents et utilisant des technologies variées ?
• Solution: XML, un langage standardisé, extrêmement flexible et personnalisable.
Protocole SOAP : fixe les règles et les bonnes pratiques pour l’utilisation du XML
dans les échanges de messages entre services.
• Le service mobile dans notre exemple enverra alors un fichier XML grâce à une requête
POST via HTTP vers le service de gestion des clients.
• Fichier XML contenant des instructions conformes au contrat WSDL.
• Le service de gestion des clients parse le fichier XML et renvoit une réponse SOAP.
Architecture Multi-tiers

• 4e problème : Comment créer des messages SOAP conformes pour appeler des
services ou y répondre ?
• En pratique pas besoin de créer des fichiers XML qui répondent aux normes SOAP.
• En effet, la plupart des langages disposent de leurs propres librairies pour épargner la
peine de formater des fichiers XML complexes à la main.
• En Java, la librairie par défaut est JAX-WS.
Architecture Multi-tiers

• JAX-WS permet de :
 Générer les WSDL : décrire les classes spécifiées dans votre service dans un fichier
WSDL à publier dans un serveur UDDI.
 Invoquer un service : récupérer les fichiers WSDL et en générer des Class “proxy”
que l’on appellera depuis un code comme n’importe quelle Class. JAX-WS générera
ensuite les messages SOAP et gérera le parsing des réponses.
Architecture Multi-tiers
Architecture Multi-tiers: architecture WOA

• La principale différence entre le SOA et le WOA est que le WOA repose sur une
technologie REST (REpresentational State Transfer) alors le SOA utilise le protocole
SOAP (Simple Object Access Protocol).
• L’avantage de REST est qu’il n’est pas un protocole mais un style d’architecture.
• Par conséquent, l’architecture REST ne subit pas les contrainte d’un protocole particulier
comme SOAP, qui est bâti sur XML, ce qui le rend flexible et adaptable à tout projet de
type Saas (par exemple pour connecter des objets ou des machines).
• On parle de système « RESTful » pour qualifier les systèmes qui reposent sur les
principes de l’architecture REST.
Architecture Multi-tiers

• Le web de demain n’utilisera plus seulement le protocole HTTP (autorisant la

diffusion de documents au format HTML ou XHTML), mais tout type de « Saas »
(« Software as a Service » ou logiciel en tant que service).
• Logiciels en tant que service, tels que ASP, existaient déjà avant mais n’étaient pas
nativement conçues pour des transmissions vers un serveur distant.
• Cela est entrain de changer: les Saas d’aujourd’hui permettent d’étendre l’architecture
orientée services (SOA) vers une architecture orientée web (WOA).
• On peut alors parler de « solution web », qui est un point de convergence entre le web
HTTP et le SOA.