Architectures Web Et Reseaux PDF

INSTITUT SUPERIEUR DES ETUDES TECHNOLOGIQUES
DE SILIANA
ARCHITECTURES
WEB
ET
RESEAUX
2éme RSI
Iset Siliana
nizar.chaabani@gmail.com
http://www.academiepro.com/enseignants-104-Chaabani.Nizar.html
ARCH WEB & RX RSI21 Mr Nizar Chaabani
Objectifs
2
 Objectifs Généraux
 Faire acquérir à l’apprenant les connaissances de base relatives à
l’évolution de l’architecture web
 - Fournir à l’auditeur les éléments théoriques de la construction et le
déploiement des applications web sécurisées et évolutives.
 Objectifs Spécifiques
 Comprendre la notion d’architecture web.
 Connaître les architectures N-tiers, SOA de développement web.
 Connaître les concepts du modèle MVC
 Se familiariser avec l’architecture des systèmes mobiles
 Maitriser l’évolution des réseaux pour la mise en ouvre de ses
architectures.
PRE-REQUIS UE : Développement Web et multimédia 1 & 2

Eléments de Contenu
3
 Client/Serveur Web : Client léger et client riche.
 Architectures n-tiers : 2, 3, n, SOA, etc.
 Modèle MVC
 Architecture Logicielle J2EE
 Architecture des systèmes mobiles
 Web sémantique : architecture et concepts

BIBLIOGRAPHIE CONSEILLÉE
4
1) Service-Oriented Architecture Compass - Business Value,

Planning and Enterprise Roadmap IBM Press Books by
Pearons plc. ISBN 0-13-187002-5
2) Berg (Martin van den), Bieberstein (Norbert),Ommeren
(Erik van), SOA for Profit : guide du manager pour une
SOA réussie, Sogeti et IBM, 2007
3) Manager avec les ERP, Architecture Orientée Services
(SOA), de Jean-Louis Lequeux, Editions d'organisation,
Paris, Avril 2008.ISBN 978-2-212-54094-9
4) Birol Berkem, Why SOA services need to be based on the
Business Motivation Model (BMM) ?, June 2008
5) SOA, Le guide de l'architecte d'un SI agile, 3e édition,
Xavier Fournier-Morel, Pascal Grojean, Guillaume Plouin,
Cyril Rognon, Collection InfoPro, Dunod, 2011

Introduction :
5
 L'objectif premier d'un système d'information,

quel qu'il soit, est de permettre à plusieurs
utilisateurs d'accéder aux mêmes informations :
 Tout système d'information nécessite la

réalisation de trois groupes de fonctions:
 le stockage des données,
 la logique applicative et
 la présentation.

6
 Stockage et accès aux données :

Le système de stockage des données a pour but de conserver une
quantité plus ou moins importantes de données de façon
structurée.
On peut utiliser pour cette partie des systèmes (très variés) qui
peuvent être :
 des systèmes de fichiers,
 des mainframes,
 des systèmes de bases de données relationnelles,
 etc...

7
 Logique applicative :
La logique applicative est la réalisation informatique
du mode de fonctionnement de l'entreprise.
Cette logique constitue les traitements nécessaires sur
l'information afin de la rendre exploitable par chaque
utilisateur.
 Présentation :
La présentation est la partie la plus
immédiatement visible pour l'utilisateur.

8
 Le web c'est un ensemble de machines en réseau

communiquant à l'aide d'un langage commun.
 Le web fonctionne en mode client/serveur

Architectures client/serveur
CONSTITUENT UNE ÉTAPE

IMPORTANTE DANS L'ÉVOLUTION
DES SYSTÈMES D'INFORMATIONS…
Serveur web ou httpd
10
 Capable d'interpréter les requêtes http arrivant sur le port

associé au protocole HTTP
 Récupération des données d’un formulaire
REQUEST_METHOD :
POST ou GET
CONTENT_LENGTH :
Taille en octets du corps de la requête
QUERY_STRING :
Données transmises après le ? dans l'URL

11

Principaux serveurs Web
12
 Apache (Unix / Linux)

 MIIS (Windows)
 Microsoft Internet Information Server Java Web
Server (versions pour Unix/ Linux / Windows) et
Jakarta-Tomcat (qui cohabite avec Apache)
Choix de la technologie
 Le choix de la technologie serveur dépend :
 du système d’exploitation de la machine serveur
 du type de bases de données à interroger
 de la charge que doit supporter le serveur

Quelques notions de base
13
 ** Notion 1 : Serveur de données

 Plate-forme gérant des bases de données à l’aide d’un SGBD
 ** Notion 2 : Serveur d’application

 Plate-forme gérant des composants applicatifs (EJB, ActiveX, Web
Services) et de publication Web (Servelet, JSP, ASP, …)
 ** Notion 3 : Client [lourd, léger, riche]
 Poste de travail avec logiciel de présentation associé gérant l’IHM
 Client lourd : code applicatif complet

 Client léger : pas de code applicatif, présentation en browser
 Client riche : le code applicatif qu’il faut et des outils de
présentation sophistiqués (intelligent, smart client)

web 1.0 vs web 2.0 vs web 3.0
14

Rappels Web 1.0
15
 Web 1.0 = Service Internet permettant de naviguer à

travers des pages HTML statiques via HTTP
Transmission de la requête HTTP
Serveur Web

Poste client
Navigateur
 Pages statiques
Transmission de la réponse HTTP
par le serveur Web
HTML et DHTML (côté client)
16
 HTML 4.01
 Dernière version de HTML, les nouveaux développements
portant sur XML (langage à tags ouverts)
 ** Notion 4 : DHTML (Dynamic HyperText Markup

Language)
 Ensemble de spécifications complémentaires au HTML
permettant de rendre une page web dynamique côté client:
 Jscript
 DOM
 CSS

Web
Web 2.0 : Des techniques nouvelles
17
 Ajax: XML sur HTTP en mode

asynchrone via Javascript
 REST: Style d’architecture de
services avec appels HTTP
 XForms: Saisie déclarative
contrôlée en XML
 XUL/XAML: Présentation
déclarative en XML
 RDF (Resource Description Framework):
Langage d’annotation de
ressource en XML
 …

Web 2.0 : Quelques notions
18
 ** Notion : Web Service

 composant logiciel dont l’interface est décrite en XML (WSDL)
et invoquée en XML (SOAP)
 ** Notion : Ajax
 technique pour échanger et manipuler les données de manière
asynchrone avec le serveur Web

Une évolution : le Web dynamique
19
Serveur Web

Traitement de la requête et sélection du
fichier contenant le programme
Requête http
 
 
Logiciel Dossier Serveur
serveur contenant les d'application Base
Poste client pages de
données
Navigateur
 Application
métier
Réponse HTTP

We
Client lourd :
20
 Le terme « client lourd », en anglais « fat

client » ou « heavy client »par opposition au
client léger, désigne une application cliente
graphique exécutée sur le système d'exploitation
de l'utilisateur.

Client léger :
21
Le terme « client léger », parfois « client pauvre », en

anglais « thin client » par opposition au client lourd,
désigne une application accessible via une interface web
(en HTML) consultable à l'aide d'un navigateur web, où
la totalité de la logique métier est traitée du côté du
serveur. Pour ces raisons, le navigateur est parfois
appelé client universel.

Client riche :
22
 Un « client riche » est un compromis entre le client léger et le

client lourd.
 L'objectif du client riche est donc de :
 proposer une interface graphique, basée sur la syntaxe XML,
 obtenir des fonctionnalités similaires à celles d'un client lourd
(glisser déposer, onglets, multi fenêtrage, menus déroulants, …).
 Il existe des standards permettant de définir une application riche :

 XAML (eXtensible Application Markup Language), prononcez
« zammel », un standard XML proposé par Microsoft ;
 XUL, prononcez « zoul », un standard XML proposé par la
fondation Mozilla ;
 Flex, un standard XML proposé par la société Macromedia

Architectures n-tiers : 2, 3, n,
SOA,
23

24
I. Niveau d’abstraction d’une application

II. Architecture 1-tiers
III. Architecture 2-tiers
IV. Architecture 3-tiers
V. Architecture n-tiers
VI. Architecture SOA

I. Niveau d’abstraction d’une application
25
Application
La couche de présentation
La logique applicative
Les données

II. Architecture 1-tiers
26
Les trois couches applicatives sont intimement liées et s'exécutent sur le

même ordinateur
- Les utilisateurs se connectent aux applications exécutées par le serveur
central (le mainframe) à l'aide de terminaux passifs
Tout est sur

présentation applicative données la même
machine
27
- Le poste client se contente de déléguer la gestion des données à un service

spécialisé
- L’ensemble des traitements applicatifs par le poste client : client lourd
- La gestion des données est prise en charge par un SGBD centralisé,
s'exécutant le plus souvent sur un serveur dédié
- Ce dernier est interrogé en utilisant un langage de requête qui, le plus
souvent, est SQL

28
GET
Ressources
OUT

29
L'architecture à deux niveaux (aussi appelée

architecture 2-tier),
« tier » signifiant rangée en anglais,
caractérise les systèmes clients/serveurs pour

lesquels :
 le client demande une ressource (GET), et
 le serveur la lui fournit directement (OUT), en utilisant
ses propres ressources.

30
 Client : présentation + applicatif

présentation applicative données
Client Serveur
 Serveur : applicatif + gestion données
données applicative présentation
Serveur Client

31
- Les données sont toujours gérées de façon centralisée
- La présentation est toujours prise en charge par le poste client
- La logique applicative est prise en charge par un serveur intermédiaire
Tier 1 Tier 2 Tier 3
Serveur
Client BDD
applicatif
Présentation Logique métier Données

32
GET
GET
Ressources
OUT OUT

33
Dans l'architecture à 3 niveaux, appelée architecture 3-tiers,

il existe un niveau intermédiaire, c'est une architecture
partagée entre :
1. Un client, c'est-à-dire l'ordinateur demandeur de ressources, équipée

d'une interface utilisateur (généralement un navigateur web);
2. Le serveur d'application (ou middleware), chargé de fournir les
ressources mais faisant appel à un autre serveur;
3. Le serveur de données (ou database server) qui va fournir au
serveur d'application les données dont il a besoin.

34
Tiers Client Tiers Milieu Tiers Backend
Appareil
mobile Serveur SGBD
WAP
Browser
Serveur Serveur
Web
Web d’application Application
ERP
Client
Java Parefeu
Client Application
VB/C++ … … mainframe

35
 Les 3 principaux tiers s'exécutent chacun sur une

machine différente
présentation applicative données
Couche présentation
Navigateur web sur machine cliente
Client léger
Couche applicative / métier
Serveur d'applications , Serveur HTTP exécutant des composants /
éléments logiciels qui génèrent dynamiquement du contenu HTML Via des
requêtes à des BDD distantes
Couche persistance
Serveur(s) de BDD de données
36

 dans l'architecture à 3 niveaux, chaque serveur (niveaux 2
et 3) effectue une tâche (un service) spécialisée :
 Un serveur peut donc utiliser les services d'un ou plusieurs autres
serveurs afin de fournir son propre service.
ARCH WEB & RX RSI21 Mr Nizar Chaabani 37

38

VI. Les Architectures orientées services (SOA)
39
Les applications au sein d’une entreprise : plusieurs

technologies
Portail WEB Application Java Application .NET 2
Application Java 2 Application .NET Portail WEB 2

40
Client 1 Client 2 Client 3
Service Service Service

Métier 1 Métier 2 Métier 3
Sans couche de médiation

41
Client 1 Client 2 Client 3
Couche de Médiation
Service Service Service

Métier 1 Métier 2 Métier 3
Avec couche de médiation

42
L’architecture orientée service constitue un style

d’architecture basée sur le principe de séparation
de l’activité métier en une série de services. »
Processus métier
Métier
Fonctionnel
Use cases
Vue logique
Applicatif
Applications & logiciels
Technique
Physique
Infrastructure

Web Services, l’interopérabilité sans adhérence !
43
 Permet à des systèmes hétérogènes

d’interopérer
 A travers les langages, les plateformes, les applications
 D’ordinateur à ordinateur
 A l’intérieur ou à l’extérieur d’un firewall
 Fondé sur des standards internet
 XML, SOAP, WSDL, UDDI
 Technologie universellement adoptée
 Consensus des acteurs clés

44
SOA et Web Service ->fonctionnement
Le fonctionnement des services web repose sur un modèle en couches, dont les
trois couches fondamentales sont les suivantes :
•Échange , visant à décrire la structure des messages échangés par les
applications.
•Découverte, pour permettre de rechercher et de localiser un service web
particulier
•Description, dont l'objectif est la description des interfaces des services web
45

46
Qu’est ce que SOA-> Principes
Les 4 grands principes du SOA
 La définition des services
 Les services sont autonomes
 Les clients et les services ne partagent que des contrats
 La compatibilité est basée sur les règles
Besoin de standardisation et la mise en commun des protocoles ( SOAP, XML,….)
La pensé orientée services
SOAP (Simple Object Access Protocol) est un protocole d'échange
Service
Application 1 Message à traiter
Contrat Implémentation
Application 2
Message traité
Service 1
Service 2

47
Cycle de vie des services

Identifier les services à mettre en place ;
Pour cela il doit répondre à quelque critère suivant :
 la réutilisation
 l’interopérabilité, offerte via Internet à d’autre SI
 autorise son emploi dans une composition.

Processus
48
Modèle orienté
objets
(POO)
Modèle orienté
services (SOA)

Processus
49
Il s’agit de centraliser la logique d’un processus dans un

composant dédié, qui prend en charge l’enchaînement et les
règles de gestion

Architectures Orientées Services
Administration des services
50
•Disponibilité, Versioning, Monitoring, Déploiement
•Routage dynamique des requêtes et des réponses
•Audit, log
•Usage, facturation…
•Sécurité: authentification, autorisation, cryptage, signature
 Timestamp
 Statistics Transform service, Physical
request Connection
 Performance
 Intrusion
 Switch Service
 Attack Monitoring  Switch Implementation
 Prioritization
Connector Service
Implementations
XML Access State Aggregate

Firewall Security Logging SLA Mngmt Transform Route
Control Composite
Other
Web
 Identity  State Aggregate or Services
Accounting
 Authentication  Billing Composite
 Recovery
services
 Encryption  Royalties  Queuing
 Access control

Architectures Orientées Services
Synthèse 51
 Les architectures SOA permettent aux

applications de communiquer avec les
différentes ressources (données,
infrastructure, processus) par
l’échange de messages entre interfaces
réseaux
 SOA est permet de définir d’ interfaces

stables et cohérentes offertes sur des
implémentations volatiles
Design Pattern MVC
52

53
 Architecture web  Architecture web MVC
standard

Models, Views, and Controllers
 SQL
View Model
Database
Controller
Web Server HTTP
Browser
MVC
55
• Le Modèle-Vue-Contrôleur organise l'interface

Homme-machine d'une application logicielle en
– un modèle (objet métier, modèle de
données)
– une vue (présentation, interface utilisateur)
– un contrôleur (logique de contrôle, gestion

des événements, traitement)

MVC - objectifs
56
• séparation entre
– les données
– la présentation
– les traitements
• Meilleur réutilisabilité du code
– Facilite la maintenance

MVC Frameworks
57
 J2EE:
 Struts
 Spring MVC
 PHP
 CakePHP
 Strusts4php
 C#.NET
 Girders
 Ruby on Rails

MVC58- web
• La logique applicative est constituée des
scripts réalisant les demandes de
l'utilisateur (contrôleur), des classes
métiers et des classes d'accès aux
données (modèle).
• L'interface utilisateur sera gérée la
plupart du temps par un navigateur
web, elle peut éventuellement être
un autre site web communiquant via
des webservices.

MVC en image
59
•couche ihm: c'est l'interface utilisateur encore appelé

interface homme machine
•couche métier : c'est le coeur de l'application où réside les
objets traités par l'application
•couche dao : couche d'accès aux données (data access object).
Cette couche permet une indépendance de la logique métier et
du stockage des données associées
MVC en action
60
1. le client fait une demande au contrôleur. Ce contrôleur voit passer

toutes les demandes des clients
2. le contrôleur doit traiter la demande. Pour ce faire, il peut avoir
besoin de la couche métier, cette dernière peut éventuellement
accéder aux données (via la couche dao)
3. le contrôleur effectue les traitements nécessaires sur / avec les
objets renvoyés par la couche métier
4. le contrôleur sélectionne et nourrit la (les) vue(s) pour présenter
les résultats du traitement qui vient d'être effectuée
5. la vue est enfin envoyée au client par le contrôleur
Le modèle
61
• décrit et contient les données manipulées par

l'application, ainsi que des traitements propres à ces
données
• les résultats renvoyés par le modèle sont dénués de
toute présentation
• le modèle contient toute la logique métier de
l'application
Le modèle - DAO
62
• Data Access Object

– Le Dao a pour but de transformer chaque enregistrement
contenu dans une bases de données en objets et
inversement
• Correspondance bijective (SGBD / paradigme
objet)
– une table (appelée aussi relation)  une liste d’objets
– une ligne d’une table (appelée aussi tuple ou
enregistrement)  un objet
– un champs de base de données  un attribut d’objet
– une valeur d’un champs  une valeur d’attribut d’un
objet
• L’objet est capable de se sauver / détruire en base
Le modèle - la couche métier
63
• Idéalement la couche métier utilise une ORM et un

DAO, qui utilisent eux-mêmes la DAL
– Dans ce cas là les méthodes CRUD (Create Read Update
Delete) ainsi que les dépendances entre objets sont gérées par
les couches supérieures
• La couche métier ne contient alors que les traitements métiers
(propre à l’objet)

Le modèle
64

vue
65
• interface avec laquelle l'utilisateur interagit

• présentation des résultats renvoyés par la
couche modèle, après le traitement du
contrôleur
• recevoir toutes les actions de l'utilisateur (clic
de souris, sélection d'une entrée, boutons,
soumission de formulaire …)
– événements envoyés au contrôleur
• La vue n'effectue aucun traitement

contrôleur
66
• Détermine l'action à réaliser (analyse de la

requête HTTP)
• gestion des événements de synchronisation
entre modèle et vue
• Si une action nécessite un changement des
données
– demande la modification des données au
modèle
– avertit ensuite la vue que les données ont
changé pour qu'elle se mette à jour
Contrôleur et actions
67
• Le contrôleur analyse la requête HTTP (et

notamment les variables)
– pour déterminer l’action à exécuter
• Le contrôleur doit déterminer les vues
associées (les templates HTML, mais aussi les
css et js à embarquer)
• Multitude d’action = contrôleur lourd
– Modèle MVC2
• Un contrôleur principal redirige vers des contrôleurs
spécialisés (méthode dispatch)
• Les contrôleurs spécialisés exécutent effectivement l’action

Séquence typique de traitement
MVC2
68
1. la requête est analysée par le front contrôler

2. Le contrôleur spécialisé adéquat est appelé avec
la requête en paramètre
3. Le contrôleur spécialisé demande, via l’action
adéquat, au(x) modèle(s) approprié(s)
d'effectuer les traitements
4. le contrôleur spécialisé sélectionne la (les)
vue(s) adaptée(s)
5. le contrôleur spécialisé remplit la vue adaptée
avec le résultats des traitements
6. le contrôleur spécialisé renvoie la vue adaptée.
69
B O NNES P RA T I Q U ES P O U R
L ’ A D M I NI ST RA T IO N D ES SI T ES
WEB

70
 Application utilisant le protocole HTTP (80) ou

HTTPS (443) pour être pilotée par un utilisateur
 L’utilisateur a besoin d’un simple navigateur Web ou

d’une application propriétaire utilisant le protocole
HTTP/HTTPS pour travailler sur l’applicatif

Architecture d’une application Web
71
Serveur Web App. Web DB

Application
Server XML
HTTP / HTTPS Apache RMI
Port 80 / 443 IIS SQL
IIOP
Iplanet XML
XML
JDBC
XML, Soap, HTML, Zeus Soap
Etc. etc.
etc. etc. CGI,
PHP
Etc.
App. Web DB
Client Web Firewall

Classique

Les attaques web
72

SQL Injection
73
technique qui permet aux attaquants d’injecter des

requêtes SQL directement sur la base de données qui se
trouve derrière un serveur Web, en manipulant l’entrée «
INPUT » à une application.
Exemple : sur une page d’authentification « login.asp »,

l’utilisateur est amené à saisir un Nom d’utilisateur «
User1 » et un mot de passe « pass2012 », cette opération
se traduit sous forme d’un requête SQL :
SELECT * FROM Utilisateur WHERE nom= ‘User1'

and mot_passe=‘pass2012’

74
Dans le cas de SQL Server, « -- » est utilisé pour mettre un

commentaire jusqu’à la fin de la ligne, la requête serait alors
SELECT * FROM Utilisateur WHERE username= or 1=1
Cette requête recherche dans la base de données les champs dont le

nom d’utilisateur est vide en réponse à la condition. La requête
va retourner tous les champs de la table utilisateur et l’attaquant
serait authentifié.
L’attaquant a réussi ainsi à s’authentifier sans avoir pour

autant utilisé de nom d’utilisateur ni de mot de passe.

75

SQL INJECTION – Comment se protéger
76
Les fondamentaux défenses:

Règle 1:Utilisation Prepared Statements(requêtes
paramétrées)
Règle 2:Utilisation de procédures stockées.
Règle 3: Valider toutes les entrées utilisateur Fourni de
coté serveur
Les défenses additionnel:

Exécuter avec le moindre des privilèges.
White List Input Validation.

Protection contre les injections
77

78

79

80

Protection contre le vol de session
81

82

83

Bonnes pratiques pour l’administration
des sites web
84
1)Sécurisation de la plateforme d’hébergement:

 Mise à jour et hardening du serveur.
 Détection d’intrusion réseau.
 Détection d’intrusion au niveau de l’hôte (HIDS).
 Détection antivirale
 Filtrage applicatif

Bonnes pratiques pour l’administration des
sites web
85
2)Suivi et audit des logs enregistrés au niveau de la

plateforme de connexion :
 log d’administration,
 log d’accès public,
3.Sauvegarde des données sensible :

 Applicatif
 base de données

sites web
86
SECURISATION DU BD
 Mettre à jour le SGBD avec les derniers correctifs
stables
 Utiliser des algorithmes de hachage/cryptage pour
stocker les données critiques
 Sécuriser le serveur de base de données derrière un
firewall et utiliser un IDS pour détecter toute tentative
d’intrusion
 Le serveur de base de données ne devrait pas avoir une
adresse IP accessible au public
 L'accès à la base de données ne devrait être autorisé
qu'à partir du serveur web sur un port bien particulier

sites web
87
 Protéger contre les attaques de brute force

 Utiliser l'authentification forte, si possible (one time password,
certificat numérique, etc.)
 Verrouiller un compte après un nombre déterminé de tentatives de
connexion a échoué
 Identifier l'emplacement dans le réseau:
 Serveur web est situé dans une DMZ
 Évaluer la configuration du firewall:

 Serveur web est protégé par un pare-feu de couche d'application
 Firewall contrôle tout le trafic entre l'Internet et le serveur web
 Pare-feu bloque tout le trafic entrant vers le serveur web, sauf les
ports TCP 80 (HTTP) et / ou 443 (HTTPS)

sites web
88
 Évaluer les commutateurs réseau

 Les commutateurs sont utilisés pour protéger contre
les écoutes réseau
 Évaluer les répartiteurs de charge (Load
balancers)
 Les répartiteurs de charge sont utilisés pour
augmenter la disponibilité du serveur web
 Les équilibreurs de charge sont complétés par les
caches web
 Evaluer le reverse proxy
 Le reverse proxy est utilisé comme une passerelle de
sécurité pour accroître la disponibilité du serveur web

Architecture Logicielle J2EE
89

Qu’est ce que le Java EE (ou J2EE)
90
 La Plateforme JEE désigne les technologies Java

utilisées pour le développement d'applications
«d’entreprise » distribuées (Répartie, multi-
couches, n-tiers)
 JEE est une plate-forme fortement orientée

serveur.

Répartition des fonctions
91
1. sur la couche présentation, une application cliente est chargée

de l’affichage et de la saisie des données
 Client web léger, Application java client ou applets (RMI),
2. sur la couche application, un serveur d’application maintient
des composants métiers utilisés pour modéliser sous forme
d’objet les processus de l’application Serveurs de:
 présentation, outils métiers, servlets,JSP , EJB
3. sur la couche données, les serveurs du système d’information
d’entreprise stockent les composants métiers
 bases de données relationnelles ou objets, intégrés (ERP),
annuaires d’entreprise LDAP,…

Serveurs d'applications JEE
92
 Architecture Web

Architecture: schéma de principe
93

Principes de JEE
94
 L’architecture JEE est une architecture d’application distribuée à base de

composants. Ces composants sont mis en œuvre par l’intermédiaire des
conteneurs Tiers Tiers
Tiers Interface Tiers Métier
Services Web Données
Navigateur Serveur
Serveur Web d’application
Conteneur
Conteneur Conteneur
Applet Internet
Web EJB Serveur de
Composant Client
bases de
Composant Web Composant données
Applet/ Métier
Servlet/JSP
Html/wml Bean

Composants J2EE
95
 Un composant est une unité logicielle de niveau

applicatif.
 JEE supporte les types de composants suivants :

 applets,
 application clientes,
 JavaBeans
 composants Enterprise JavaBeans (EJB),
 composants Web,
 composants adaptateurs de ressource
 etc

Android
96

97
 Première plateforme ouverte pour appareils

mobiles.Les applications natives et tierces utilisent
les mêmes API.
 Un système d’exploitation open source libre pour

appareils mobiles;
 Un environnement de développement ouvert

construit sur un noyau Linux open source;

Concurrents
98
 iOS(iphone OS): Un système mobile développé par

Apple;
 Windows mobile: C’est le nom générique donné à

différentes versions de Microsoft Windows

Pourquoi développer une application mobile?
99
Pour les professionnels
✔ L’application augmente l’accessibilité au site

✔ L’application permet de générer du trafic
✔ Le marché est en pleine croissance
✔ Une application contribue à l’image de marque

Versions disponibles
100

Plateforme de téléchargement
101

Google Play : anciennement dénommée Android
Market
Boutique en ligne
Client mail (Gmail)

Gestion des SMS
PIM (Google Calendar, gestion des contacts, etc.)
Google Maps
Navigateur Web basé sur WebKit
Messagerie instantanée (Google Chat, MSN, etc.)
Android Market Place
etc.
Architecture générale
102

Architecture - Kernel Linux
103
 Basé sur Linux (version du noyau : 2.6) mais ce n'est pas Linux ! (pas
de support de la glibc, X non présent)
 Le kernel Linux offre :
 Une couche d'abstraction matérielle
 Gestion de la mémoire
 Gestion des processus
 Gestion de la couche réseau
 Il est possible d'accéder à la console (le shell)
depuis la commande adb

Architecture - Application Framework
Core Plateform Services
104
 Activity Manager
 Gère le cycle de vie des applications
 Maintient une « pile de navigation » permettant de switcher d'une application à une
autre et de restaurer son état précédent
 Package Manager
 Utilisé par l'Activity Manager pour charger les informations des fichiers .apk
(Android package file)
 Window Manager
 Gestionnaire de fenêtres des applications
 Resource Manager
 Gère tout ce qui ne relève pas du code (ressources statiques, images, audio, etc.)
 Content Provider
 Gère le partage des données entre applications
 View System
 Fournit l'ensemble des composants graphiques

Architecture - Application Framework
Hardware Services
105
 Permettent d'accéder aux APIs matérielles de bas niveau

 Telephony Service
 Permet l'accès aux interfaces "téléphonique" (GSM, 3G, etc.)
 Location Service
 Permet d'accéder au GPS
 Bluetooth Service
 Permet d'accéder à l'interface bluetooth
 Wifi Service
 Permet d'accéder à l'interface Wifi
 USB Service
 Permet d'accéder aux interfaces USB du terminal
 Sensor Service
 Permet d'accéder aux détecteurs (détecteurs de luminosité, etc.)

Le moteur d'exécution d'Android
106
 Un moteur d'exécution (« runtime system » en

anglais) est un programme qui permet l’exécution
d'autres programmes.
 pour utiliser des applications développées en Java
sur votre ordinateur vous avez besoin du JRE (« Java
Runtime Environment »).
 Pour Android Elle contient certaines bibliothèques
de base du Java accompagnées de bibliothèques
spécifiques à Android et la machine virtuelle «
Dalvik ».

la compilation et à l'exécution d'un programme
Java standard.
107

la compilation et à l’exécution d'un programme
Android standard
108

Arborescence d’un projet Android
109
Arborescence d’un projet Dossiers crées

automatiquement lors de la création d’un projet :
 bin : binaires generés
 libs : bibliothèques
 res : fichiers de ressources (icones, layout, . . . )
 src : fichiers sources (code Java)

Installation d’une application
110
 Liste des périphériques avec ADB

 ADB (Android Debug Bridge) outls d'une
communication entre le smartphone et pc.
adb devices
 Installation Une application est installée sur un AVD
ou sur un matériel a l’aide de la commande :
adb install NomApk.apk

Boîte à outils
111

SDK Android
112
 Le kit de développement Android(SDK) fournit

l’environnement de travail pour développer, tester et
déboguer des applications Android.
 Dans le SDK on trouve:

1. Les API Android qui sont le coeur du SDK. Composés
de bibliothéques d’API Android, ils donnent au
développeur accès à la pile Android.
2. Des outils de développement qui permettent de
compiler et déboguer vos applications.
3. Le virtual Device Manager et l’Emulateur qui
fournit un meilleur environnement de test

Virtual Device Manager
113
 Le SDK Android et le Virtual Device Manager sont

utilisés pour créer et gérer les AVD(Android Virtual
Devices) et les packages du SDK.

Emulateur
114
 L’emulateur d’Android est un outil de test et de

débogage d’application Android.
 Il fournit une connexion réseau complète, une

simulation d’envoi et de réception d’appels et de
SMS.

Composants d’une application Android
115
 Les applications Android sont constitués de composants

à couplage.
 Les composants sont liés par un manifeste d’application
qui décrit chacun d’eux et comment ils interagissent.

Activity : le cycle de vie
116

Architectures Web Et Reseaux PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Architectures Web Et Reseaux PDF

Загружено:

Авторское право:

Доступные форматы

INSTITUT SUPERIEUR DES ETUDES TECHNOLOGIQUES

ARCH WEB & RX RSI21 Mr Nizar Chaabani

 Client/Serveur Web : Client léger et client riche.

 Architectures n-tiers : 2, 3, n, SOA, etc.

 Architecture Logicielle J2EE

 Architecture des systèmes mobiles

 Web sémantique : architecture et concepts

ARCH WEB & RX RSI21 Mr Nizar Chaabani

1) Service-Oriented Architecture Compass - Business Value,

ARCH WEB & RX RSI21 Mr Nizar Chaabani

 L'objectif premier d'un système d'information,

 Tout système d'information nécessite la

ARCH WEB & RX RSI21 Mr Nizar Chaabani

 Stockage et accès aux données :

ARCH WEB & RX RSI21 Mr Nizar Chaabani

ARCH WEB & RX RSI21 Mr Nizar Chaabani

 Le web c'est un ensemble de machines en réseau

ARCH WEB & RX RSI21 Mr Nizar Chaabani

CONSTITUENT UNE ÉTAPE

 Capable d'interpréter les requêtes http arrivant sur le port

ARCH WEB & RX RSI21 Mr Nizar Chaabani

ARCH WEB & RX RSI21 Mr Nizar Chaabani

 Apache (Unix / Linux)

ARCH WEB & RX RSI21 Mr Nizar Chaabani

 ** Notion 1 : Serveur de données

 ** Notion 2 : Serveur d’application

 Client lourd : code applicatif complet

ARCH WEB & RX RSI21 Mr Nizar Chaabani

ARCH WEB & RX RSI21 Mr Nizar Chaabani

 Web 1.0 = Service Internet permettant de naviguer à

 ** Notion 4 : DHTML (Dynamic HyperText Markup

ARCH WEB & RX RSI21 Mr Nizar Chaabani

 Ajax: XML sur HTTP en mode

ARCH WEB & RX RSI21 Mr Nizar Chaabani

 ** Notion : Web Service

ARCH WEB & RX RSI21 Mr Nizar Chaabani

ARCH WEB & RX RSI21 Mr Nizar Chaabani

 Le terme « client lourd », en anglais « fat

ARCH WEB & RX RSI21 Mr Nizar Chaabani

Le terme « client léger », parfois « client pauvre », en

ARCH WEB & RX RSI21 Mr Nizar Chaabani

 Un « client riche » est un compromis entre le client léger et le

 Il existe des standards permettant de définir une application riche :

ARCH WEB & RX RSI21 Mr Nizar Chaabani

ARCH WEB & RX RSI21 Mr Nizar Chaabani

I. Niveau d’abstraction d’une application

III. Architecture 2-tiers

IV. Architecture 3-tiers

VI. Architecture SOA

ARCH WEB & RX RSI21 Mr Nizar Chaabani

ARCH WEB & RX RSI21 Mr Nizar Chaabani

Les trois couches applicatives sont intimement liées et s'exécutent sur le

Tout est sur

- Le poste client se contente de déléguer la gestion des données à un service

ARCH WEB & RX RSI21 Mr Nizar Chaabani

ARCH WEB & RX RSI21 Mr Nizar Chaabani

L'architecture à deux niveaux (aussi appelée

caractérise les systèmes clients/serveurs pour

ARCH WEB & RX RSI21 Mr Nizar Chaabani

 Client : présentation + applicatif

 Serveur : applicatif + gestion données

données applicative présentation

ARCH WEB & RX RSI21 Mr Nizar Chaabani