Blog ENI : Toute la veille numérique !
En raison d'une opération de maintenance, le site Editions ENI sera inaccessible le mardi 10 décembre, en début de journée. Nous vous invitons à anticiper vos achats. Nous nous excusons pour la gêne occasionnée
En raison d'une opération de maintenance, le site Editions ENI sera inaccessible le mardi 10 décembre, en début de journée. Nous vous invitons à anticiper vos achats. Nous nous excusons pour la gêne occasionnée
  1. Livres et vidéos
  2. Architecture logicielle
  3. Architectures d’application
Extrait - Architecture logicielle Pour une approche organisationnelle, fonctionnelle et technique (2e édition)
Extraits du livre
Architecture logicielle Pour une approche organisationnelle, fonctionnelle et technique (2e édition) Revenir à la page d'achat du livre

Architectures d’application

Principes d’architecture

L’architecture se réfère à la représentation abstraite du comportement d’un système et de ses composants. Il y a deux principes fondamentaux qui imposent la décomposition d’un système en sous-parties plus petites. D’une part, les systèmes modernes sont devenus trop complexes pour qu’on puisse les appréhender dans leur totalité. D’autre part, il y a autant de niveaux de lecture que de catégories de lecteurs d’un modèle.

L’objectif de ce chapitre est de décrire les techniques de décomposition d’un système en utilisant les concepts de couches et de niveaux (on utilisera les termes plus parlants de layers et tier). Nous faisons référence aux architectures centrées sur l’application, dans leur acception atomique, circonscrites à un périmètre technologique précis et en opposition aux architectures distribuées des solutions d’entreprise qui sont, elles, orientées service et que nous aborderons dans un autre chapitre.

Couches

Les couches (ou layers) d’un système sont des sous-systèmes à part entière qui consomment des informations provenant de leur environnement et lui en fournissent. L’objectif de l’empilement des couches logiques est d’isoler les responsabilités au sein de packages d’une même catégorie.

On parlera de layer strict ou unidirectionnel dès le moment où les dépendances se font du bas vers le haut, c’est-à-dire qu’on a besoin de la couche inférieure pour compiler la couche supérieure (et que la couche inférieure ne connaît rien des couches supérieures). Procéder de la sorte est efficace car cela limite l’effet spaghetti dans le code, interdit quasiment les dépendances cycliques entre packages (et donc, minimise les impacts d’un changement dans une couche) et limite le temps de compilation ou d’interprétation.

Enfin, si on veut rendre les couches interchangeables, il est nécessaire de définir ou d’utiliser un protocole de communication.

Une couche (un layer) est une unité de composants logiques, tandis qu’un niveau (tier) est l’unité physique (machine, serveur d’application) de déploiement des couches.

images/07DP01.png

Figure 7.1 : Architecture multicouche

1. Présentation

La couche de présentation impose la façon...

Tier

La stratification logique offre de nombreux avantages en termes de génie logiciel (modularité, maintenabilité, découplage, parallélisme, réutilisabilité...). Toutefois, si on veut garantir une indépendance forte des couches logiques, il faut que cette stratification opère aussi au niveau de l’environnement d’exécution du code. Ainsi, chaque couche d’architecture correspondra en réalité à un déploiement physique particulier. Nous allons ici expliciter l’évolution historique de la structure monolithique vers le quasi-standard n-tier et nous détaillerons celui-ci.

On fait souvent l’amalgame entre le tier et le layer qu’il contient, alors qu’il y a une très nette différence : le schéma de l’architecture en couches qui sépare la présentation de la logique métier et de l’accès aux données est communément adopté. Outre cette scission logique en strates de composants, on observe aussi une distribution physique de ces composants sur des tiers matériels distincts. Ainsi, on peut déployer physiquement les différentes couches dans un environnement distribué, c’est alors qu’on parlera d’architecture multitier (ou n-tier).

Traditionnellement, les architectures multiniveaux (ou n-tier) sont des applications client/server dans lesquelles la présentation, la logique applicative et les accès aux données s’exécutent dans des couches distinctes.

1. Monolithique

Avant que les architectures n-tier ne deviennent un standard, on bâtissait les systèmes sur un schéma monolithique (aka 1-tier), c’est-à-dire que l’intégralité du code de l’application s’exécutait sur la même machine (mainframe).

Ceci n’est pas un problème en soi pour une application autonome, un utilitaire par exemple, qui n’a pas grand intérêt à exploiter des ressources partagées entre plusieurs utilisateurs ou extérieures à la machine sur laquelle il s’exécute, ou dont le cycle de vie (installation, déploiement) est parfaitement maîtrisé. Ce type de système est autonome et autocentré, il se suffit à lui-même....

MVC

Il est nécessaire de clarifier les différences qu’entretient ce pattern architectural avec celui des architectures n-tier, car leur proximité conceptuelle est si ténue qu’elle peut induire des confusions. Comme le modèle n-tier, le modèle MVC, ou modèle-vue-contrôleur, sépare le design en trois zones : la présentation, la logique et les données.

1. Bénéfices

L’adhésion au modèle MVC apporte un certain nombre de bénéfices architecturaux :

  • Une séparation des préoccupations de design. L’application devient plus flexible du fait du découplage entre la présentation, le contrôle, le comportement applicatif et les données.

  • Une extensibilité et une maintenance plus aisée. Ce design induit moins de complexité, cloisonne les responsabilités, évite la duplication de code et favorise l’usage des interfaces.

  • Un gain en productivité dû à une collaboration facilitée entre graphistes et développeurs.

Ce pattern, en découplant les modèles des vues, réduit la complexité et augmente la flexibilité du design.

2. Workflow

images/07DP03.png

Figure 7.3 : Modèle MVC

Le flux de contrôle est typiquement de la sorte :

1.

L’utilisateur interagit avec la vue à travers un composant d’interface...

Applications mobiles

L’avènement récent des smartphones et autres tablettes inflige une mutation violente au paysage logiciel. On assiste à une rétroaction technologique, car les terminaux mobiles imposent paradoxalement des contraintes qu’on croyait définitivement enterrées à l’heure des processeurs multicœurs : un espace mémoire limité tant à l’exécution qu’au stockage, des résolutions d’écran minuscules, plus faibles que celles des écrans cathodiques, une vitesse de traitement en deçà des ordinateurs bas de gamme.

Les plateformes mobiles imposent des exigences non fonctionnelles drastiques (bande passante, résolution d’écran, déploiement via les stores d’Apple ou de Google par exemple) qui nécessitent de repenser les architectures traditionnelles. Cet effort d’adaptation technologique se verra largement récompensé par l’accession à un marché colossal : pléthore d’utilisateurs ultra-connectés, avides d’information et autant de cartes de crédit à portée de clic.

Alors, comme on peut dire que les technologies d’entreprise sont stabilisées dans l’arène n-tier où s’affrontent les technologies d’Oracle et de Microsoft jugulées par les règles...

Exemple

Nous allons illustrer les points précédents par une implémentation très simple suivant le modèle MVC sur une architecture 3-tier en Java EE. Il s’agit simplement d’illustrer les interactions entre la vue, le contrôleur et le modèle dans un processus d’achat en ligne via la commande d’un panier.

1. Architecture

a. 3-tier

L’architecture Java EE supporte le développement d’applications multi-tier orientées composants. Un système typique, produit avec cette technologie, inclut les tiers suivants :

  • Tier client (client tier, user interface tier) : dans ce niveau, on trouve des composants web tels que des servlets ou des JavaServer Pages (JSP) ou des applications Java autonomes (Swing) qui fournissent une interface dynamique sur le tier intermédiaire. Ces composants sont contenus dans un containeur web (Tomcat, Galssfish...).

  • Middle-Tier (business tier, middle tier) : dans ce niveau, aussi appelé tier serveur, on trouve des composants métier EJB (Enterprise Java Bean) et des services web qui encapsulent une logique métier réutilisable et distribuable. Ils sont contenus dans un serveur d’application (JBoss, WebSphere, Glassfish...) qui leur fournit les services nécessaires.

  • Tier intégration (enterprise integration tier) : dans ce niveau, on trouve les données de l’entreprise stockées et persistées typiquement dans une base de données relationnelle ou bien dans les applications mainframe.

Les applications Java EE sont faites de composants, de containers et de services. 

b. Modèle MVC

Le pattern MVC peut s’implémenter très simplement en Java EE sur une architecture 3-tier. Il est possible d’utiliser une servlet en tant que contrôleur pour gérer les requêtes entrantes provenant de l’utilisateur. Chaque page web de l’application correspond à une vue implémentée sous forme de page JSP (ou JSF - Java Server Face) vers laquelle le contrôleur redirige l’utilisateur en fonction de l’état de l’application. Les données métier sont sérialisées en base de données via des EJB session et un mappage relationnel JPA (Java Persistence API).

images/07DP04.png

Figure 7.4 : Modèle MVC version Java EE

2. Implémentation

Pour illustrer...