Architectures orientées

services
Chapitre 1: Introduction
Dr.Ghada Besbes
Définition Architecture
• … la structure des composants d’un programme/système, leurs
interrelations et les principes et lignes directrices gouvernant leur
conception et leur évolution au fil du temps.” [Garlan, 1995]
La définition de l’architecture logicielle consiste à:
• Décrire l’organisation générale d’un système et sa décomposition en
sous-systèmes ou composants
• Déterminer les interfaces entre les sous-systèmes
• Décrire les interactions et le contrôle entre les sous systèmes
• Décrire les composants utilisés pour implanter les fonctionnalités
des sous-systèmes
• Les propriétés de ces composants
• Leur contenu (e.g., classes, autres composants)
• Les machines ou dispositifs matériels sur lesquels ces modules seront 2
déployés
Définition Architecture
• Pourquoi développer une architecture logicielle ?
• Pour permettre à tous de mieux comprendre le système
• Pour permettre aux développeurs de travailler sur des parties
individuelles du système en isolation
• Pour préparer les extensions du système
• Pour faciliter la réutilisation

3
Introduction

• Traditionnellement une application informatique est un

programme exécutable sur une machine qui représente la
logique de traitement des données manipulées par
l’application.
• Ces données peuvent être saisies interactivement via
l’interface ou lues depuis un disque.
• L’application émet un résultat sous forme de données qui
sont, soit affichées, soit enregistrées sur un disque.

• Dans ce schéma, les traitements, les données d’entrées, les 4

données de sortie sont sur une seule machine.
Introduction
• On peut alors séparer l’application en différentes parties ou
niveaux ou couches :
1. La couche interface homme machine (IHM) ou présentation:
permet l'interaction de l'application avec l'utilisateur. Cette
couche gère les saisies au clavier, à la souris et la
présentation des informations à l'écran. Dans la mesure du
possible, elle doit être conviviale et ergonomique.
2. La couche de traitement ou la logique applicative: décrit les
travaux à réaliser par l'application.
3. La couche de gestion des données ou plus exactement
l'accès aux données, regroupant l'ensemble des
mécanismes permettant la gestion des informations 5
stockées par l'application.
Vision : historique des
architectures
• Architecture 1 tiers
• Architectures Client-Serveur
• 2- tiers
• 3- tiers
• N-tiers
• Architectures à Base de Composants
• Architectures Orientées Services

6
Architecture 1 tiers
• Jusqu’au années 90, ces trois couches étaient la plupart du
temps sur la même machine.
• Dans une application un tiers, les trois couches applicatives
sont intimement liées et s'exécutent sur le même ordinateur.
• L’application utilisait les disques de la machine pour lire les
données a traiter et stocker les données résultantes du
traitement .
• Avantages:
• Grande facilité d'administration
• Haute disponibilité.
• La centralisation de la puissance sur une seule et même machine
permet une utilisation optimale des ressources 7
Architecture 1 tiers
• Inconvénients
• L’explosion de la volumétrie des données rend leur gestion
difficile
• En regroupant tous les traitements on groupe également toutes
les sources d'erreur
• Problème liés à une utilisation dans un contexte multi-utilisateur:
• L’augmentation du nombre d’utilisateurs pose des problèmes de
gestion des conflits d'accès aux données ou la modification
simultanée d'un même enregistrement par plusieurs utilisateurs. Ces
conflits peuvent altérer l'intégrité des données
• Il est difficile d'assurer la confidentialité des données
• Ce type de solution est donc à réserver à des applications non
critiques exploitées par de petits groupes de travail (une 8
dizaine de personnes au maximum).
Architecture client-serveur

• Dans le cas d'un système reparti, l'application est divisée en

plusieurs morceaux où chaque morceau joue un rôle différent
pour les traitements du SI.

• L'environnement client-serveur désigne un mode de

communication à travers un réseau entre
plusieurs programmes ou logiciels : l'un, qualifié de client,
envoie des requêtes ; l'autre ou les autres, qualifiés
de serveurs, attendent les requêtes des clients et y répondent.

9
Architecture client-serveur
• Le modèle client-serveur met en oeuvre une conversation
entre deux programmes.
• On distingue donc les deux parties suivantes :
• Le client, c'est le programme qui provoque le dialogue,
• Le serveur, c'est le programme qui se contente de répondre au
client.

10
Architecture client-serveur
• Par extension, le client désigne également
l'ordinateur sur lequel est exécuté le logiciel client, et le
serveur, l'ordinateur sur lequel est exécuté le logiciel
serveur.
• En général:
• Les serveurs sont des ordinateurs dédiés au logiciel serveur qu'ils
abritent, et dotés de capacités supérieures à celles des
ordinateurs personnels en ce qui concerne la puissance de calcul,
les entrées-sorties et les connexions réseau.
• Les clients sont souvent des ordinateurs personnels ou des
appareils individuels (téléphone, tablette)..
11
Types de clients
• Client lourd (fat client): désigne une application cliente
graphique exécutée sur le système d'exploitation de
l'utilisateur. Un client lourd possède généralement des
capacités de traitement évoluées et peut posséder une
interface graphique sophistiquée. Néanmoins, ceci demande
un effort de développement et tend à mêler la logique de
présentation (l'interface graphique) avec la logique applicative
(les traitements).
• Client leger (thin client): ne prend en charge que la
présentation de l'application avec, éventuellement, une partie
de logique applicative permettant une vérification immédiate
de la saisie et la mise en forme des données. Il est souvent
constitué d'un simple navigateur web. 12
Couplage
• Le couplage est une métrique indiquant le niveau d'interaction
et de dépendance entre deux ou plusieurs composants
logiciels (fonctions, modules, objets ou applications).
• Deux composants sont dits couplés s'ils échangent de
l'information et sont dépendants l’un de l’autre.
• Couplage fort: si les composants échangent beaucoup
d'information.
• On ne peut pas déterminer le qui, le quoi et le comment d’une
modification de données donc ça pose des problèmes lors du
développement et la maintenance. A éviter autant que possible
• Exemple: Architecture « peer-to-peer » (tous les processus ont le
même rôle)
13
Couplage
• Couplage faible: si les composants échangent peu
d'information.
• Pas d’inter-dépendance entre les composants de l’application
• Permet de maîtriser la complexité de l’architecture pour le
développement, le test et la maintenance
• Exemples: Architectures 3-tiers, n-tiers
• Couplage très faible: Les composants sont remplaçables,
conçus en indépendance, avec des technologies diverses
• Un composant est facilement remplaçable par un autre rendant
les mêmes services
• La construction par assemblage permet de faciliter la
maintenance
14
• Exemple: architecture orientée services
Architecture 2 tiers
• Dans une architecture deux tiers, encore appelée client-
serveur de première génération ou client-serveur de données,
le poste client se contente de déléguer la gestion des données
à un service spécialisé.
• Le cas typique de cette architecture est l'application de
gestion fonctionnant sous Ms-Windows et exploitant un SGBD
centralisé s'exécutant le plus souvent sur un serveur dédié
pour la gestion des données

15
Architecture 2 tiers

• Ce dernier est interrogé en utilisant un langage de requête

qui, le plus souvent, est SQL. Le dialogue entre client et
serveur se résume donc à l'envoi de requêtes et au retour des
données correspondant aux requêtes. Ce dialogue nécessite
l'instauration d'une communication entre client et serveur.
• Ce type d'application permet de tirer profit de la puissance
des ordinateurs déployés en réseau pour fournir à l'utilisateur
une interface riche, tout en garantissant la cohérence des
données, qui restent gérées de façon centralisée.

16
Architecture 2 tiers

17
Architecture 2 tiers
• Le client provoque l'établissement d'une conversation afin de
d'obtenir des données ou un résultat de la part du serveur.

• Cet échange de messages transite à travers le réseau reliant

les deux machines. 18
Architecture 2 tiers
Avantages:
• Maintenance et administration du serveur simplifiées
• Souplesse : possibilité d’ajouter/supprimer dynamiquement
des clients sans perturber le fonctionnement de l’application
• Les ressources sont centralisées sur le serveur
• Sécurisation simple des données : un seul point d’entrée
• Pas de problème d’intégrité/cohérence des données
Limitations:
• On ne peut pas soulager la charge du poste client, qui
supporte la grande majorité des traitements applicatifs (client
lourd)
• Coût élevé : le serveur doit être très performant pour honorer
tous les clients 19
Architecture 3-tiers
• Les limites de l'architecture deux tiers proviennent en grande partie
de la nature du client utilisé : le frontal est complexe et non standard
• La solution résiderait donc dans l'utilisation 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 :
• la présentation est toujours prise en charge par le poste client,
• la logique applicative est prise en charge par un serveur
intermédiaire.
• les données sont toujours gérées de façon centralisée,

20
Architecture 3 tiers

21
Architecture 3 tiers
• Présentation:
• De plus en plus mince, i.e., le client
ne fait qu’afficher un contenu
HTML

• La logique métier
• Créer les pages Web à afficher pour
le client
• Gérer les dossiers des clients

• Persistance 22
• Le base de données des clients
Architecture 3 tiers
• Tous ces niveaux étant indépendants, ils peuvent être
implantés sur des machines différentes, de ce fait :
• le poste client ne supporte plus l'ensemble des traitements, il est
moins sollicité et peut être moins évolué, donc moins coûteux,
• le poste client est communément un client léger, par opposition
au client lourd des architectures deux tiers.
• la fiabilité et les performances de certains traitements se
trouvent améliorées par leur centralisation,
• le découplage logique applicative/interface permet de changer ou
d’avoir plusieurs interfaces utilisateur sans toucher à l’application
elle-même.

23
Limitations
• L'architecture trois tiers a corrigé les excès du client lourd en
centralisant une grande partie de la logique applicative sur un
serveur applicatif. Le poste client, qui ne prend à sa charge
que la présentation, s'est trouvé ainsi soulagé et plus simple à
gérer.
• Par contre, le serveur applicatif se trouve souvent fortement
sollicité et il est difficile de répartir la charge entre client et
serveur. On se retrouve confronté aux problèmes de gestion
de la montée en charge rappelant l'époque des mainframes.
• Les contraintes semblent inversées par rapport à celles
rencontrées avec les architectures deux tiers : le client est
soulagé, mais le serveur est fortement sollicité.
• Le juste équilibrage de la charge entre client et serveur semble
atteint avec la génération suivante : les architectures n-tiers. 24
Architecture n-tiers
• L'architecture n-tiers est aussi appelée architecture distribuée
ou architecture multi-tiers.
• Le niveau intermédiaire (traitement) est une collection de
composants qui sont utilisés dans de nombreux traitements
transactionnels.
• Ces composants peuvent être situés sur un ou plusieurs
serveurs physiques.
• De plus, chacun de ces composants effectue une petite tâche
et c'est pourquoi on peut séparer cette partie intermédiaire
en plusieurs parties d'où le terme architecture n-tiers

25
Architecture n-tiers
• Cette distribution est facilitée par l'utilisation de composants
métier, spécialisés ,indépendants et réutilisables.
• 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.
• La distribution des services applicatifs facilite aussi
l'intégration des traitements existants dans les nouvelles
applications.

26
Architecture n-tiers
Au-delà de 3-tiers:

27
Avantages et limitations
Avantages
• Réutilisation de services existants
• Découplage des aspects métiers et des services entre eux : meilleure
modularité
• Facilite l’évolution
• Un couplage faible entre les services
• Permet de faire évoluer les services un par un sans modification du
reste de l'application
Limitations
• En général, les divers services s'appuient sur des technologies très
variées : nécessité de gérer l'hétérogénéité et l'interopérabilité
• Utilisation des outils supplémentaires
• Les services étant plus découpés et distribués, posent plus de
problèmes liés à la coordination 28
Vision: environnement de
développement
• Paradigme procédure
• procédures, fonctions et données structurées
• applications monolithiques ( modulaire)
• Paradigme objet
• classes (fonctions et données structurées)
• lié à un langage de programmation
• applications monolithiques
• Paradigme composant
• composant (groupe d’interfaces)
• Lié à un modèle de composant
• Entité de plus gros grain,
• décrit par ce qu’il offre et ce qu’il requiert,
• utilisation indépendante de l’implémentation
• interaction application-application
• Paradigme service 29
Vision: environnement de
développement

30
Paradigme Composants
• Analogie avec les composants électroniques, legos,
puzzles

31
Paradigme Composants
Un composant
• Une unité regroupant les fonctionnalités concernant une même idée
• Un module logiciel autonome pouvant être installé sur différentes
plates-formes
• qui exporte des attributs et des méthodes
• qui peut être configuré (déploiement semi
automatique) Interface de
• capable de s’auto-décrire configuration
Intérêt
Être des briques de base configurables
pour permettre la construction
Interfaces

d’une application par

fournies

composition
32
 Paradigme Composants
Facturer:
encaisser,
Consommer: rendre Monnaie
payer,
selectionner, en pièces de
prendre
1 dinars
Gerer: Distributeur de
ouvrir, Facturation
remplir, boissons version 1
mettreMonnaie
Réparer:
ouvrirCapot,
fermerCapot

Permet de modifier l'application

sans modification du code Facturation
en manipulant les assemblages Facturer:
version 2
encaisser, 33
rendre Monnaie
en pièces de 100
millimes