Architectures Logicielles des SI

Framework de dveloppement JEE

Pr. Imade BENELALLAM

Chapitre 1: Introduction aux

Architectures des SI

Un SI orient Web Application!

Application Web:
q Accessible par Internet travers un navigateur Web en utilisant un
protocole sans tat stateless (HTTP, HTTPS).
q Fonctionne indpendamment du systme d'exploitation utilis.
q Utilise pour fournir des services tels que la messagerie, les blogs,
les forums en ligne ...etc
!

Les critres tels que la performance, la scurit, la vitesse de traitement et la

haute disponibilit qui sont importants pour assurer les services dentreprise
ne sont pas garantis par une application Web.
3

Architecture des applications Web

q Systmes monolithique : gros, lents et inadaptables
q Mlange entre la Prsentation , la logique mtier (Business logic) et les donnes
q Souvent isol de l'extrieur : non volutif et difficilement maintenable.

Application

DB

Autre

Code source nostalgique

// application logic
if (!empty($_POST["userId"])) {
// database access
$conn = DB::Connect("mysql://user:passwd@host/db");
$res = $conn->Query(
"SELECT * FROM user WHERE id = '"
+ $_POST["userId"] + "'");
$row = $res->FetchRow(DB_FETCHMODE_ASSOC);
// business logic
$userName = $row["display_name"];

// presentation
echo "Hello " . $userName . "!";

Limites des Applications Web

Les applications Web prsentent certaines limites qui les rendent
inappropri dans un contexte dutilisation par les entreprises.
Limites

Description

Qualit

Les applications Web utilisent des protocoles de transport tels que HTTP, qui sont
stateless, par consquent, ces protocoles ne garantissent pas le succs d'une
transaction. donc, la qualit des donnes ne peut tre garantie.

Vitesse

Le temps de rponse une requte par les applications web est lev. Mais, les
requtes concurrentes les unes avec les autres sur les mmes ressources
dentreprise rduisent la vitesse globale dexcution des requtes.

Complexit

Ces applications impliquent de nombreuses lignes de code pour grer les

transactions, les sessions (tats), le multithreading et la mutualisation des
ressourcesetc

Scurit

La technologie de base des applications Web ne prend pas en charge les

fonctionnalits ncessaires pour appliquer des politiques de scurit.

Problmatiques
Les entreprises sont en mutation permanente:

Fusions-acquistions, changements internes, mise en place des processus

collaboratifs,

et le patrimoine des SI nest pas naturellement prpar une telle

flexibilit :

Grandes applications hrites de lpoque des sites centraux (main frame) ou du

mode Client/Serveur
Petites applications inter fonctionnant presque miraculeusement, avec une
multitude dinterfaces bricoles et Redondance de donnes de rfrence

La ncessit de surmonter :

les incohrences,
La mauvaise communication
Lhtrognit de certains sous systmes, rsultant dune longue histoire.

Quelle Solution ?
Produire des Applications Entreprises
= Urbanisme + Architecture

Ensemble des moyens permettant de faire voluer

le Systme dinformation aux mmes rythmes que la
stratgie et lorganisation. Elle consiste dcrire la
structuration du systme cible et la faon de
latteindre .

LUrbanisme et lArchitecture
Lurbanisme du Systme dinformation dfinit les rgles dchanges et
dinteraction entre les blocs (ne dfinit pas la structure interne des
blocs).
Larchitecture est lart de construire ces blocs. Larchitecture respecte
les rgles de lurbanisme qui aura dfini la finalit du btiment et les
contraintes de construction, mais dispose dans ce cadre dune grande
libert.

Urbaniste et Architecte
Urbaniste: conoit le SI dun point de vue global et labore
larchitecture densemble : Vision globale et gnrale;
Architecte: labore les plans dun difice et travaille dans le cadre fix
avec une Vision dtaille.
Cette diffrence tant faite, la confusion persiste parfois
essentiellement du fait de la pnurie durbaniste des SI

10

Architecture des SI
Un SYSTME peut tre dfini comme "un ensemble d'lments en
interaction et formant un tout".
Le SYSTME D INFORMATION peut tre dfini comme lensemble des
moyens mis en uvre pour stocker, traiter, gnrer et restituer les
informations ncessaires au bon fonctionnement de lentreprise ou
de lorganisme.
Ainsi, l'tude de l'ARCHITECTURE d'un SYSTME DINFORMATION
consiste examiner la structure d'un ensemble de composants
fonctionnels, applicatifs, matriels et logiciels ainsi que le mode de
relation qu'entretiennent ces composants.
11

Dmarche pour larchitecture des SI

12

Dmarche et vision informatique

La vision mtier: dcrit lensemble des processus mtier et des
activits de lentreprise que le SI doit supporter. Il sagit de la
structuration du SI par les activits de lentreprise.
La vision fonctionnelle: offrant un cadre de structuration cible des
informations et traitements ncessaires aux processus mtiers. Il
sagit donc de la structuration du SI en blocs fonctionnels
communicants.
La vision informatique: La vision informatique recouvrant des
applications qui automatisent les fonctions, et linfrastructure
technique permettant leur exploitation.
13

Dmarche et vision informatique

14

Typologies des architectures selon la vision

informatique
Architecture Applicative:

elle structure le SI en blocs applicatifs communicants

elle dcrit sous langle technique, les applications, les flux et les messages changs
entre applications

Architecture Logicielle

elle structure et dcompose de faon logique chaque application en couches

elle introduit les notions et concepts de dcoupage en couches, composants,
framework et design patterns

Architecture Technique (Physique)

Il sagit de la structuration et de dimensionnement des moyens dinfrastructure

technique mettre en uvre pour informatiser lactivit de lentreprise.
Moyens matriels, logiciels de base, rseau, infrastructure
OS, SGBDR,
Load-balancing, Fail-over, Scalabilit, Qualit de Service (QoS), Scurit, Performance

15

Historique des Architectures des SI

16

Les trois niveaux d'abstraction d'une

application
Application = Prsentation + Traitements + Donnes;
Noyau de l'application = logique de l'affichage + la logique des
traitements;
Le dcoupage et la rpartition de ce noyau permettent de distinguer
les architectures applicatives:

l'architecture 1-tiers,
l'architecture 2-tiers,
l'architecture 3-tiers,
les architectures n-tiers.

17

L'architecture 1-tier
Aven les PC en rseau, il est devenu
possible de dployer une application un
tier sur plusieurs ordinateurs
indpendants.
Plusieurs utilisateurs se partagent des
fichiers de donnes stocks sur un serveur
commun.
La gestion des conflits d'accs aux donnes
est prise en charge par chaque programme
de faon indpendante.
18

Client / Serveur
Apparition
dbut des annes 1990.

Raisons :
Le cot lev du temps CPU des gros systmes qui
a pouss les utilisateurs demander des moyens
pour dporter les traitements sur les postes de
travail,
La volont de vouloir utiliser opportunits offertes
par les nouvelles interfaces graphiques
L'mergence d'un standard interfaces graphiques
et d'un standard OS de fait pour la station de
travail : Microsoft Windows.
19

Client / Serveur
L'architecture client/serveur est une des modalit des architectures
informatiques distribu.
Au sein de cette architecture, on trouve :
Des offreurs de services (serveurs)
Des consommateurs de services (client).
Les clients et les serveurs sont des modules fonctionnels dont la logique est
encapsule dans leurs interfaces respectives.

Les clients et les serveurs peuvent tre localiss sur des machines
ddies.

20

Client / Serveur
Classification des architectures Client/Server selon le Gartner Group

21

L'architecture 2-tiers
Architecture 2-Tiers appele client-serveur de premire gnration ou
client-serveur de donnes.
Le poste client se contente de dlguer la gestion des donnes un
service spcialis.
Les changes entre le client et le serveur seffectue travers rseau
reliant les deux machines grce des mcanismes relativement
complexes pris en charge par un middleware.

22

Le Middleware
Cest l'ensemble des couches rseau et services logiciel qui
permettent le dialogue entre les diffrents composants d'une
application rpartie. Ce dialogue se base sur un protocole applicatif
commun, dfini par l'API du middleware.
Le middleware est dfini par le Gartner Group comme une interface
de communication universelle entre processus. Il reprsente
vritablement la clef de vote de toute application client-serveur.
L'objectif principal du middleware est d'unifier, pour les applications,
l'accs et la manipulation de l'ensemble des services disponibles sur
le rseau, afin de rendre l'utilisation de ces derniers presque
transparente.
23

Le Middleware
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 applications devant accder des services
htrognes, il est parfois ncessaire de combiner plusieurs
middlewares. Dans ce cas, le poste client doit connatre et mettre en
oeuvre plusieurs IPC, on en vient la notion de client lourd.

24

Limites des architecture 2-Tiers

le poste client est fortement sollicit, il devient de plus en plus lourd
et complexe, et doit tre mis jour rgulirement pour rpondre aux
besoins des utilisateurs,
Ce type d'application est souvent cantonn au rseau local de
l'entreprise,
Des difficults rencontres pour assurer des fortes montes en charge
car il est difficile de modifier l'architecture initiale,
la relation troite qui existe entre le programme client et
l'organisation de la partie serveur complique les volutions de cette
dernire,
25

L'architecture 3-tiers
Larchitecture 3-Tiers remdie aux lacunes des architectures 2-tiers. La
solution rsiderait dans l'utilisation d'un poste client simple d'un
poste client simple communicant avec le serveur par le biais d'un
protocole standard.
Dans ce but, l'architecture trois tiers applique les principes suivants :
les donnes sont toujours gres de faon centralise,
la prsentation est toujours prise en charge par le poste client,
la logique applicative est prise en charge par un serveur intermdiaire.

L'architecture trois tiers, encore appele client-serveur de deuxime

gnration ou client-serveur distribu, spare l'application en trois
niveaux de service distincts
26

L'architecture 3-tiers
Ces trois niveaux tant indpendants, ils peuvent tre implants sur
des machines diffrentes, de ce fait :
le poste client ne supporte plus l'ensemble des traitements, il est moins
sollicit et peut tre moins volu, donc moins coteux,
les ressources prsentes sur le rseau sont mieux exploites, puisque les
traitements applicatifs peuvent tre partags ou regroups (le serveur
d'application peut s'excuter sur la mme machine que le SGBD),
la fiabilit et les performances de certains traitements se trouvent amliores
par leur centralisation,
il est relativement simple de faire face une forte monte en charge, en
renforant le service applicatif.
27

L'architecture 3-tiers: Avantages

Le poste 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.
Le dploiement est immdiat, les volutions peuvent tre
transparentes pour l'utilisateur et les caractristiques du poste client
sont libres.
Linternaute peut se connecter au serveur en utilisant tout type de
poste client disposant d'un navigateur compatible HTML (PC sous
Windows, Macintosh, Station Unix, WebPhone... ).
28

Limitations
le serveur HTTP constitue la pierre angulaire de l'architecture et se trouve
souvent fortement sollicit et il est difficile de rpartir la charge entre client
et serveur.
On se retrouve confront aux pineux problmes de dimensionnement
serveur et de gestion de la monte en charge rappelant l'poque des
mainframes.
De plus, les solutions mises en uvre sont relativement complexes
maintenir et la gestion des sessions est complique.
Les contraintes semblent inverses par rapport celles rencontres avec
les architectures deux tiers : le client est soulag, mais le serveur est
fortement sollicit. Le phnomne fait penser un retour de balancier.
Le juste quilibrage de la charge entre client et serveur semble atteint avec
la gnration suivante : les architectures n-tiers.
29

Les architectures n-tiers

Thoriquement, ce type
d'architecture supprime tous les
inconvnients des architectures
prcdentes :
elle permet l'utilisation d'interfaces
utilisateurs riches,
elle spare nettement tous les niveaux
de l'application,
elle offre de grandes capacits
d'extension,
elle facilite la gestion des sessions.
30

Les architectures n-tiers

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. En fait, l'architecture n-tiers
qualifie la distribution d'application entre de multiples services et non
la multiplication des niveaux de service.
Cette distribution est facilit par l'utilisation de composants ``mtier'',
spcialiss, indpendants et rutilisables.
Ces composants rendent un service si possible gnrique et
clairement identifi. Ils sont capables de communiquer entre eux et
peuvent donc cooprer en tant implants sur des machines
distinctes.
31

Architectures n-tiers

32

Les architectures n-tiers

Une architecture n-tiers est compose de:
q Une couche prsentation (la vue)
q Une couche logique mtier ou
traitement (couches logicielles ou
services),
q Une couche daccs aux donnes (le
modle),
q Un intgrateur (point de dmarrage) ou
un environnement dexcution (serveur
dapplications).

Vue

Intgrateur

Mtier

donnes

33

Exemple: Les architectures n-tiers

E

B
A

SGBD

34

Reprsentation de donnes: classes de

valeurs
Objectif : reprsenter les donnes manipules par lapplication sans faire rfrence aux
traitements.
q La dfinition des classes de valeurs peut tre obtenue par une phase de conception UML
(Diagramme de classes) ou par une mthode danalyse des donnes (Modle conceptuel des
donnes).
q Lcriture de ces classes peut tre prise en charge par des outils automatiques ( partir de
schmas UML, relationnels ou XML).
q En Java, les classes de valeurs sont reprsentes par des JavaBeans. Un JavaBean est une classe
qui respecte un ensemble de contraintes :
q Chaque instance dcrit une entit particulire;
q Une entit particulire est entirement dcrite par les proprits de la classe;
q Deux mthodes publiques sont associes chaque proprit : getter, setter;
q Il existe un constructeur publique sans argument;

35

Reprsentation de donnes: classes de

valeurs
Classes de valeurs : JavaBeans

B
A

SGBD

36

Reprsentation de donnes: Exemple de

classes de valeurs

37

Reprsentation de donnes: Types de classes

de valeurs
Suivant le contexte, nous pouvons avoir plusieurs types de classes valeurs pour reprsenter une
donne:

38

Besoin de traitements
Un exemple : comment implanter une mthode de sauvegarde pour le Bean Person?

Pour implanter cette mthode nous devons avoir des informations sur la nature (BDR, XML, etc.) et
les paramtres (login, mot de passe, etc.) du systme de persistance.
Ces informations ne peuvent pas tre reprsentes par une proprit du bean Person :
- ce ne sont pas des donnes de lapplication,
- ils seraient dupliques dans chaque instance,
39

Besoin de traitements
Nous devons donc ajouter un paramtre cette mthode :

Cette approche pose dautres problmes :

q La dfinition du bean est pollue par des considrations techniques. Nous nous
loignons de lobjectif des classes de valeurs (prsentation des donnes).
q La mthode de la persistance est duplique dans chaque bean (trs difficile changer).
q Il est dlicat doffrir plusieurs mthodes de sauvegarde. Nous avons cr une
dpendance artificielle entre une donne et sa manipulation.

40

Besoin de traitements
Nouveaux objectifs :
q supprimer les dpendances entre donnes et traitements,
q rassembler les traitements parpills,
Solution : il faut ranger le code technique de sauvegarde dans une classe spcialise qui va se
charger de la sauvegarde de tous les beans :

41

Besoin de traitements
Il peut exister plusieurs versions de cette classe (JDBCStorage, FileStorage,
XmlStorage) qui rendent le mme service mais de manire diffrente.

Ces implantations partagent la mme interface ou peuvent hriter de la mme

classe abstraite.
Le partage dinterfaces est une solution prfrable.
Nous venons de dfinir les classes de service.
42

Les classes de service

Un service logiciel cest :
q Une spcification (en Java elle se traduit par une ou plusieurs
interfaces),
q Une ou plusieurs implantations (ralises par une ou plusieurs
classes de service qui agissent sur les donnes).
q Les utilisateurs dun service travaillent partir de la spcification
(interface) et ignorent les dtails de limplantation sous-jacente.
q Le rle de la couche dintgration est de faire le lien entre les
utilisateurs dune spcification et une implantation particulire.
43

Les classes de service

q Une application doit tre conue comme un ensemble de services construits les uns partir des autres en vue de
rpondre aux spcifications dtailles.

Classes de valeurs : JavaBeans

B
A

SGBD

C
q Les services sont dvelopps indpendamment et la couche dintgration va faire le lien entre A/C, A/D, B/D, C/B et C/D.
q On peut classer les services en fonction de leur rle.
44

Les services daccs aux donnes

Une couche DAO (Data Access Object) offrent plusieurs fonctionnalits:
q Centralisation des accs aux donnes,
q Simplification de laccs aux donnes,
Classes de valeurs : JavaBeans
q Abstraction du support de stockage,
q Travail sur les entits principales,
B
A

DAO

SGBD

45

Les contrleurs

Un contrleur assure :
q limplantation du protocole dentre,
q le traitement et la validation des requtes clientes,
q lappel aux couches internes.

Classes de valeurs : JavaBeans

Contrleur

B
DAO

SGBD

46

Les vues

Les vues assurent :

q Limplantation du protocole de sortie,
q La construction des rsultats partir des donnes,
q Lenvoi de ces rsultats.

Contrleur

Classes de valeurs : JavaBeans

Vue

DAO

SGBD

47

Les services mtiers

Les services mtier assurent les oprations de traitement des donnes.
Caractristiques :
q Ils sont indpendants dune source de donnes.
q Ils sont indpendants de la logique applicative (suite de requtes clientes).
q Ils sont rutilisables.

Contrleur

Classes de valeurs : JavaBeans

Mtier B

Vue

DAO

SGBD

Mtier C

48

Les types de services mtiers

q Offrir des fonctions spcialises (DAO, contrleur, etc.),
(http://java.sun.com/blueprints/patterns/DAO.html)
Abstract and encapsulate data access mechanisms
q Simplifier un service trop complexe (facade),
(http://java.sun.com/blueprints/patterns/SessionFacade.html)
Coordinate operations between multiple business objects in a workflow
q Enrichir les fonctions dun service existant (decorator),
q Rechercher un service (locator),
(http://java.sun.com/blueprints/patterns/ServiceLocator.html)
Simplify client access to enterprise business services
q Se charger de laccs un service (proxy),
q Construire un service particulier (factory).
49

Vers une architecture distribue oriente

service
CORBA
Java RMI
EJB
Web services
SOA

Application
Client

Contrleur

Classes de valeurs : JavaBeans

Objet
CORBA

Application
Client

Mtier B

DAO
Vue

Mtier C

SGBD

Service
Web
50

Bibliographie:
PATTERN-ORIENTED SOFTWARE ARCHITECTURE, A
Pattern Language for Distributed Computing,
By : Frank Buschmann, Kevlin Henney and Douglas C.
Schmidt, 2007

51