Professeur : Christophe Fessard

Développement d’applications
distribuées en java ee

Chapitre - Introduction

Architecture distribuées
 Principe de conception
= séparation des responsabilités

3 types de responsabilités = 3 couches (tiers) principales

Couches applicatives détaillés

Vue plus fine des responsabilités

2
 Modèle Client-Serveur
Modèle Client-Serveur = 2 programmes + 1 protocole
 Programme « serveur » = offre un service à des clients
 Programme « client » = utilise un service fourni par un serveur
 Protocole = moyen de communication

Indépendant de la notion de « machine »

 Client et serveur sur la même machine
 Client et serveur sur des machines différentes

Où placer les couches applicatives ?

 Distribution des couches
 Typologies multiples (Gartner)

3
 Architecture 1-tiers (mainframe)

 Tiers terme anglais, traduction niveaux

 L’application est sur un serveur (éventuellement distant)
 Le client est une application « légère » de visualisation

Architecture 1-tiers (client autonome)

 L’application est sur le client
 Les données sont sur un serveur (éventuellement
distant)

4
 Architecture 2-tiers (client lourd)
 Le cœur de l’application est sur un serveur (éventuellement distant)
 La couche présentation (IHM) de l’application est sur le client

Architecture 3-tiers (client

léger)

 Le client est une application « légère » de

visualisation (ex : navigateur web)
 Le cœur de l'application est sur un serveur
 Les données sont sur un autre serveur

5
 Architecture n-tiers
Généralisation des modèles précédents
remarque : un serveur peut être un client pour un autre serveur !
Distribution des responsabilités en 4 ou + tiers

Architecture type :

6
 Exemple avec serveur d’application Java EE
 Architecture 3 ou 4 tiers :
 Client léger
 Serveur de présentation (pouvant être fusionné avec le serveur de traitement dans le cas de Java EE)
 Serveur d'application
 Serveur de données

7
Comment « découper » une application en tiers
(niveaux) ?

Architecture par composant

8
 Composants
 Application = assemblage de composants
Composant = unité logique de traitement  Rend un service (fonction)
 Vue boîte noire
Propriétés
 Identification : nom unique, référencé dans un annuaire
 Indépendance : utilisable tout seul
 Réutilisation : utilisable dans différents contextes
 Intégration : combinable avec d’autres composants

Composants distribués  Le client peut se trouver sur un Serveur (distant)

Principales catégories de composants java ee

 Web - partie présentation
 JSP (Java Server Page) – page qui permet de générer dynamiquement du code HTML.
 Servlet - classe Java qui permet de traiter une requête venant d’un client.
 Métiers – logique applicative (fonctionnelle)
 EJB (Entreprise JavaBean) - composants chargés d’implémenter mettre en œuvre la logique applicative
indépendamment de l’environnement technique.
 Accés aux données – persistance
 EJB entité – composant permettant la persistance de données

9
 Problématiques
Applications n-tiers à base de composants = composants distribués avec responsabilités distribuées

Complexité
 Conception des composants et des applications
 Développement des composants et des applications
 Gestion des aspects transverses : sécurité, disponibilité, communication, persistance, transactions…
 Interopérabilité des composants
 Administration des composants et des applications
 Sécurisation de bout en bout des applications
 Transaction traversant plusieurs composants
 …

Notion de cycle de vie des composants

Tous types de composant est gérer par un conteneur (conteneur web ou d’EJB).
Durant sa vie (instanciation à désallocation mémoire) chaque composant passe par différents états, définis dans les
standards.
Ces états, les transitions qui permettent de passer de l'un à l'autre, et les conditions qui permettent d'activer ces
transitions forment un ensemble que l'on appelle le cycle de vie d'un composant.
À chaque changement d'état d'un composant, l'application qui possède ce composant peut être notifiée par le
serveur d'application.

10
 Système réparti (Interoperabilité)
Système réparti/architecture distribuées :
Système formé de composants matériels ou logiciels localisés sur des ordinateurs en réseau qui communiquent et
coordonnent leurs actions uniquement par l’envoi de messages.
Permettre une adaptation permanente entre les problèmes et les applications informatiques.

Les défis à relevrer

 La communication - Transmettre l’information entre les composants logiciels.
 L’hétérogénéité - gérer la diversité des matériels et logiciels en interaction.
 L’intégration / transparence - Le système comme un tout et non un aggrégat.
 L’interopérabilité - Echanger des données entre applications distribuées.
 L’ouverture - Découvrir et intégrer d’autres systèmes.
 Le passage à l’échelle (scalability ) - Conserver l’efficacité une fois étendue (cf. internet).
 La sécurité - Confidentialité, intégrité et disponibilité.
 Gestion des défaillances - Défaillances partielles

11
 L’intergiciel (middleware)
Couche logiciel intermédiaire (répartie) entre les niveaux bas (systémes et communication) et haut (applications).

L’intergiciel a quatre fonctions principales

 Fournir une interface ou API (Applications Programming Interface) de haut niveau aux applications
 Masquer l’hétérogénéité des systèmes matériels et logiciels sous-jacents
 Rendre la répartition aussi invisible (”transparente”) que possible
 Fournir des services répartis d’usage courant (Interoperabilité d’applications hétérogénes)

12
 The Open Groupe
Consortiums de fournisseurs de solutions logicielles ouvertes
 L’Open Groupe : http://www.opengroup.org/
 consortium de constructeurs et d’utilisateurs promouvant les systèmes ouverts « inter-opérables ».

L’Open Groupe propose des certifications :

 Wap : http://www.opengroup.org/wap/cert/index.html
 UNIX® : http://www.unix-systems.org/
 CORBA® : http://www.opengroup.org/procurement/corba_tools.htm
 LDAP® : http://www.opengroup.org/directory/

13
 Echanges d'informations
Flux = données qui passent d’un point A à un point B
 D’une application à une autre,
 D’un module applicatif à un autre
 D'un utilisateur à un autre
 D’une base de données à une autre
 D’une entreprise à une autre
…
Dans des modes différents
 Échanges synchrones, asynchrones, pseudo-synchrone
 Échanges unitaires ou en masse
 Cadencés ou au fil de l’eau
 Transactionnels ou non
 (…)

Périmètre

Exemples de flux
 Transfert de fichier
 Partage de fichier
 Appel de procédure distant
 Requête sur une base de données
…

14
Granularité / Fréquence

15
Modalité

16
 Architectures d'échange
Architecture point-à-point
Analyse des solutions point-à-point
 Simplicité de mise en œuvre si le nombre
d'applications à intégrer est faible
 Architecture « intuitive »
 Efficacité des échanges directs

Problème de passage à l'échelle

 Si N applications, N(N-1)/2 liens…
 Effet « plat de spaghettis »
Evolutivité très réduite
 Intégration d'une nouvelle application
= ajout de nombreux nouveaux liens
 Couplage fort entre les applications
 fort impact des évolutions (notamment interfaces)
Exploitation et administration complexes
 Manque de visibilité sur les échanges

17
Architecture bus

18
 Exemple de solution de type bus : le MOM
Middleware Orienté Message (MOM) = bus logiciel de transport qui permet à des applications de recevoir des
messages émis par d’autres
 Connectivité : supporte différents protocoles de communication
 Transport :
 Garantit l'acheminement (intégrité, gestion des erreurs)
 Gère différentes modalités : synchrone/asynchrone, publication/abonnement…
 Gère les transactions

Existe aujourd'hui sur la plupart des serveurs d'applications

19
 Analyse des solutions de type bus
Avantages
 Passage à l'échelle facilité
 Si N applications, au plus N liens bidirectionnels
 Meilleure évolutivité
 Intégration d’une nouvelle application = un seul connecteur
 Couplage faible entre les applications
 Services de transport
 Acheminement garanti des données (reprise sur erreur, gestion des doublons)
 Intégrité des données

Inconvénients
 Adhérence forte entre les applications et le bus
 Couplage fort entre les formats des données
 fort impact des évolutions du format d'échange
 Plate-forme centralisée
 hautement critique
 goulot d'étranglement

20