Application en Couche : Comprendre sa Définition et son Évolution Essentielle

L'architecture en couches est un style architectural populaire qui organise les composants d'une application en couches horizontales, chaque couche ayant un rôle spécifique. Cet article explore en détail le concept d'application en couche, son évolution, ses avantages, ses inconvénients et les alternatives modernes.

Introduction à l'Architecture en Couches

Depuis les années 60, l’architecture en couche a évolué, tout comme sa stratégie de déploiement. The idea behind Layered Architecture is that modules or components with similar functionalities are organized into horizontal layers. Dans le style d’architecture en couches, les composants sont organisés en couches techniques (en opposition au domain-partitioned architecture), chaque couche jouant un rôle spécifique au sein de l’application.

Les Principes Fondamentaux

L’architecture en couches respecte le principe de Separation of Concern en rendant chaque couche responsable. Pour garantir ce principe, les couches doivent être fermées (closed), c’est-à-dire que lorsqu’une requête se déplace de haut en bas d’une couche à l’autre, elle ne peut sauter aucune couche. En ayant des couches indépendantes, si on souhaite remplacer une technologie sur une couche par une autre (e.g.

Architecture OSI (Open Systems Interconnection)

Le modèle OSI est un modèle conceptuel qui permet une communication à la fois physique et virtuelle sur un réseau. Il est composé de sept couches, chacune ayant une fonction spécifique :

Couche Physique: Responsable de la transmission des données brutes sur le support physique.
Couche Liaison de Données: Transforme les paquets reçus de la couche réseau en trames. Cette couche est l'un des aspects de la transmission réseau où les normes sont essentielles.
Couche Réseau: Assure le routage des paquets entre les différents réseaux.
Couche Transport: Divise les données en segments plus petits pour des transferts plus efficaces et plus rapides. Par exemple, si 10 Mo de données sont transférés et que seuls 5 Mo sont complets, la couche session s'assure que seuls 5 Mo sont retransmis.
Couche Session: Ouvre et ferme les sessions de communication. La session doit être ouverte suffisamment longtemps pour que les données soient transférées, mais elle doit être fermée une fois le transfert terminé.
Couche Présentation: Assure la conversion des données entre les différents formats. Par exemple, la communication avec un serveur Web via HTTPS utilise des informations chiffrées.
Couche Application: C'est le niveau le plus proche de l'utilisateur final. Par exemple, un client de messagerie qui transfère des messages entre le client et le serveur fonctionne sur la couche 7. La couche application ne désigne pas l'application elle-même qui effectue la communication. Elle s'assure que la partie tierce est identifiée et accessible. Le cas échéant, elle authentifie soit le destinataire, soit l'expéditeur du message, soit les deux. Elle s'assure que les ressources de communication nécessaires existent (par exemple, la présence d'un modem sur l'ordinateur de l'expéditeur). Elle garantit un accord aux deux extrémités de la communication quant aux procédures de reprise en cas d'erreur, à l'intégrité des données et à la confidentialité. Elle détermine un protocole et des règles de syntaxe des données au niveau application.

Services SASE et CASE

Par contraste, les services SASE correspondent à des fonctions axées sur les utilisateurs, spécifiques à l’application et, dans de nombreux cas, fondées sur CASE. Ils peuvent, entre autres, concerner des répertoires centrés sur l’utilisateur, des terminaux virtuels, le transfert de données, la messagerie ou le transfert d’éléments graphiques et de médias. Si ces deux types de solutions ont d’abord fait l’objet d’une séparation claire dans la planification, il est avéré qu’ils se chevauchent très souvent en pratique, car les services SASE et CASE interagissent entre eux et dépendent même les uns des autres. Ils sont donc souvent définis ensemble en tant qu’éléments de service de contrôle d’association (ACSE, Association Control Service Elements).

Les Couches Typiques d'une Application

Dans une application typique, on retrouve généralement les couches suivantes :

Couche Présentation (IHM - Interface Homme-Machine): Responsable des interactions avec l'utilisateur. C'est l'interaction Homme-machine. Elle ne contient ni donnée ni traitement car elle doit être facilement modifiable. Elle adapte les données aux besoins de l'utilisateur sans avoir à modifier les données applicatives. On souhaite par exemple pouvoir changer de station cliente aisément. Cette couche peut être implémentée de différentes manières : client léger, applications client-serveur, etc. Pour les plateformes Web, c'est le navigateur qui a été choisi. Le rôle de cette couche est essentielle à l'architecture et au dialogue entre le navigateur et le serveur web. Des technologies comme PHP, ASP-activeX peuvent s'effectuer côté serveur. Elle ne demande aucun travail du client.
Couche Métier (Applicatif): Contient la logique métier de l'application, c'est-à-dire les règles de gestion de l'application. C'est le niveau "applicatif" de gestion de l'application, on parle aussi de processus métier. Elle représente l'interface entre l'IHM et les données pérennes de l'entreprise.
Couche Données (Persistance): Responsable de l'accès aux données, qu'elles soient stockées dans une base de données ou dans des fichiers. C'est le niveau des données.

Variantes de Déploiement

La première variante combine les couches de présentation, métier et de persistance en une seule unité de déploiement.

Avantages de l'Architecture en Couches

Isolation et Séparation des Préoccupations: Each layer is isolated from the others, accessible via a well-defined interface. The primary advantages of this architecture are isolation and separation of concerns. Chaque couche est responsable d'une tâche spécifique, ce qui facilite la maintenance et la compréhension du code.
Remplaçabilité des Technologies: Il est possible de remplacer une technologie sur une couche par une autre sans impacter les autres couches.
Réutilisabilité: Les couches peuvent être réutilisées dans différentes applications. Les objets persistants sont plus facilement réutilisables.
Testabilité: Chaque couche peut être testée indépendamment.

Inconvénients de l'Architecture en Couches

Complexité Accrue: L'architecture en couches peut augmenter la complexité du code, surtout si le nombre de couches est élevé.
Performance: Le passage d'une couche à l'autre peut engendrer une surcharge et impacter les performances.
Rigidité: L'architecture en couches peut être rigide et difficile à adapter aux changements.
Couplage Fort: Bien que chaque couche soit isolée, il peut y avoir un couplage fort entre les couches, ce qui rend les modifications difficiles.
Gonflement de la Couche Service: À moyen terme, un effet de bord récurrent de l'architecture en couches apparaît avec le "gonflement" de la couche de service. Une des conséquences les plus visibles est l'évolution de certaines classes de services en "GOD objects" possédant trop de responsabilités à gérer. Ceci entraîne une difficulté à se retrouver dans le code et à terme un problème de maintenabilité. Une autre conséquence de ces "GOD objects" dans la couche service est la difficulté accrue à travailler à plusieurs d'une même équipe en même temps sur le même projet.
Choix Techniques Précoces: L'architecture en couches ne permet pas de repousser à plus tard les choix techniques et ainsi garder les options ouvertes. À court terme, dès la création du projet, nous allons de par l'orientation des dépendances avoir tendance à démarrer par la couche de persistance. Le sens des dépendances à une importance primordiale (cf. Dépendances Et Valeur Métier Au Cœur De L'Architecture) et la fondation de l'architecture en couches se trouve être celle de persistance. Ce simple sens de dépendance entraîne des questionnements survenant trop tôt dans la vie d'un projet, tel que le moyen de persistance ainsi que son modèle de données. Il s'agit du type de décision qui doit pouvoir être repoussé afin de laisser les options ouvertes et ainsi connaître au mieux les enjeux fonctionnels et non fonctionnels lors du choix.

Alternatives à l'Architecture en Couches

Architecture Hexagonale (Ports et Adaptateurs): Cette architecture met l'accent sur l'isolation du cœur de métier de l'application. Elle permet de connecter différents types d'interfaces (utilisateurs, bases de données, etc.) au cœur de métier via des ports et des adaptateurs.
Architecture Orientée Domaine (DDD - Domain-Driven Design): Cette architecture met l'accent sur la modélisation du domaine métier de l'application. Elle permet de créer des applications qui sont plus proches des besoins des utilisateurs.
Microservices: Cette architecture décompose une application en petits services indépendants qui communiquent entre eux via des API.
Clean Architecture: Après la parution par Robert C.Martin de la "clean architecture" dans son blog en 2012 (The Clean Architecture), puis dans dans son livre éponyme en 2017, on aurait pu penser qu'un changement de dominance allait survenir. Ce n'est pour l'instant pas le cas, la faute peut être dû au fait que la "clean architecture" reste abstraite pour beaucoup et pas facilement implémentable.

L'Inversion de Dépendances

Grâce à l'inversion de dépendance, nous avons résolu les deux premiers problèmes. La couche service ne dépend plus d'aucune autre couche, c'est notre nouvelle fondation qui met le métier au centre des préoccupations de l'équipe de développement.

Amélioration du Travail en Parallèle

Afin de "dégonfler" cette couche et de répartir sa charge, nous allons utiliser une couche additionnelle. Pour arriver à responsabiliser au mieux les différents objets, nous allons dédier cette nouvelle couche au domaine métier. Dernière problématique à résoudre, améliorer le travail en parallèle. Avec notre architecture v2 nous avons déjà amélioré ce travers de l'architecture, mais nous pouvons faire mieux. Ce que l'on souhaite, c'est de pouvoir développer en parallèle différents "use cases" avec le moins de friction possible. Nous allons utiliser dans les principes SOLID le principe de "Single Responsability”, qui je le rappelle ne signifie pas être responsable d'une seule "chose" mais que la classe n'a en théorie qu'une seule raison de changer. Nous venons, à la suite de plusieurs itérations, d'obtenir une architecture qui comble les problématiques de l'architecture en couches.

Pourquoi l'Architecture en Couches Est-Elle Encore Utilisée?

Ces architectures règlent les problèmes de l'architecture en couches, mais alors pourquoi ne sont-elles pas plus utilisées ? Est-ce la peur du changement ? En ce qui concerne la peur du changement, c'est en effet un facteur qui peut exister. Dans des entreprises possédant des bases de codes conséquentes utilisant l'architecture en couches, la tentation est grande de justifier de garder cette architecture afin de garantir une homogénéité entre les projets et ainsi "faciliter” l'adaptation de futurs développeurs venant d'autres projets. Est-ce trop complexe ? Après 3 ans de pratique quotidienne de l'architecture hexagonale sur plusieurs microservices, je peux dire qu'elle n'est ni plus complexe ni plus coûteuse. Il y a cependant un temps de montée en compétences plus important pour de nouveaux venus du fait que ce ne sont pas des architectures communément utilisées.

Architectures Distribuées

Les architectures distribuées n'étaient pas nées.

CORBA (Common Object Request Broker Architecture)

CORBA est une architecture pour les applications distribuées. Le moteur pour faire tourner les applications au dessus des OS et du matériel. Elle permet aux applications en services d'interagir entre eux car les composants peuvent être de nature différentes, sur des OS différents, dans des langages différents. CORBA permet de construire des composants objets qui sont complémentaires et interopérable, represantant le spectre le plus large de l'industrie informatique. CORBA permet de localiser des services, de gérer la sécurité et les exception, sur des machines, des environnements et des langages différents. Elle permet de construire une application distribuée et les appels à des services normalisés sur un bus appellé ORB ( comme Object Request Broker ). L'ORB est l'élément central de cette architecture. Il permet aux objets d'invoquer des méthodes sur des objets locaux ou distant, et d'en recevoir les réponses. CORBA offre un ensemble de service très riche.

IDL (Interface Definition Langage): Permet de définir les interfaces des objets.
IIOP (Internet Inter-ORB Protocole): Protocole de communication entre les ORB.

DCOM (Distributed Component Object Model)

DCOM est une technologie développée par Microsoft. de l'OMG, bien avant que le Web ne représente l'enjeu économique qu'il est aujourd'hui. avaient pour DCOM de COM : "Distributed" COM. DCOM permet de créer des applications sous forme d'objets distribués, permettant les applications Windows d'interagir entre elles. Il gère les problèmes du réseau. La couche de communication est nécessaire à toute architecture distribuée. Cependant, DCOM présente toutes les contraintes de COM et ses lacunes de conception. Le mécanisme d'identification des objets n'existe pas. Il est basé sur des interfaces particulières et non à des instances. Il existe différents niveaux d'abstraction. Les ActiveX sont des objets DCOM. Cependant, l'architecture distribuée paraît faible. DCOM est 100% compatibles Microsoft. On peut dire que de DCOM se dégage une impression de non globalité des concepts. Il traîne le boulet COM. Microsoft fera tout pour faire durer son produit. sont encore là pour longtemps.

RMI (Remote Method Invocation)

RMI est une technologie Java qui permet à un objet de faire appel aux services offerts par les objets persistants. Elle permet la mise en oeuvre de services transactionnels pour assurer la cohérence des bases de données. RMI permet l'accès a ces serveurs d'infrastrcture a des services techniques, sur RMI (Remote Method Invocation). Elle utilise la machine virtuelle (JVM) de la machine locale. Elle permet à un client d'invoquer des méthodes à distance sur un objet qu'il instancie, dans n'importe quel langage, généralement vers RMI.

RMI-IIOP: Développé par le OMG (Object Management Group) et utilisé dans l'architecture CORBA. L'avantage de RMI-IIOP est qu'il utilise IIOP comme protocole de communication. Cela permet de créer des objets distribués qui ne sont pas forcément écrits en Java. Les interfaces des objets distribués sont à décrire en Java. Cela permet d'assurer la compatibilité avec CORBA. Les stubs sont donc exploitables par toute plate-forme CORBA. Ils sont générés automatiquement par le compilateur idlj. RMI-IIOP fonctionne sur toutes plate-formes. RMI était uniquement disponible pour quelques plates-formes, car écrit en code natif. RMI-IIOP est simple d'utilisation, parfaitement intégré à Java et ouvert, car compatible CORBA.

Objets Persistants et Objets Métiers

Les objets persistants sont des ressources et ils font partie des données de l'entreprise. Ils ne sont pas liées à la session d'un client. Les objets métiers ou "session" correspondent à des taches et des processus. Ils sont liés à un client particulier ( dans le sens client serveur ) et sont éphémères. Ils sont en général non persistants. Ils peuvent faire appel aux services offerts par les objets persistants. Ils sont plus facilement réutilisables.

Middleware

Le middleware fournit des tuyaux fiables et performants. Pour rendre le middleware transparent aux utilisateurs ont utilise un middleware. Le middleware permet la communication entre un client et un serveur au moyen de file d'attente de messages. Il gère des files d'attentes et facilite la communication. Il permet la communication asynchrone et n'impose pas de connexions entre elles. Les messages peuvent être routés pour des raisons de sécurités ou d'efficacité.

Publish/Subscribe: Un sujet est associé a chaque message. Le client envoie le message à un agent intermediare. Les clients s'enregistrent auprés de cet agent en fonction des sujets qui les intéresse. L'agent transmette les messages à des destinations, qui sont des files d'attente.
Transactions: Les transactions sont des noms des application qui changent l'état de manière controllé. Il n'y a pas de demi-mesure, soit le travail a été effectué soit non. En cas de problème, le système revient dans son état de départ. Il faut que toutes les modifactions soient validées. Une transaction est une unité de travail indivisible. Elle permet de passer d'un état cohérent à un nouvel état cohérent. Les transactions assurent le bon fonctionnement en intégrant des mécanismes transactionnels. Elles permettent de gérer les cas de défaillance du système, de ruptures de connexions.

tags: #application #en #couche #définition

Application en Couche : Définition et Évolution