|
Architecture J2EE - Comment organiser son application J2EE
3.6.Connexion des couches L’utilisation de couches s’avère très utile pour la modularité et l’évolutivité d’une application. Cependant la connexion de ces couches entres-elles n’est pas une mince affaire. En effet, pour rester dans le principe : « évolution, modularité », il faut que les couches soient indépendantes ; c’est donc à ce niveau que les problèmes apparaissent.
3.6.1.Solutions directes 3.6.1.1.Communications inter applications Les couches peuvent se trouver au sein d’une stricte partie d’application mais également au sein de l’application globale.
C’est-à-dire que la couche métiers peut très bien se trouver sur un serveur (un tiers), la couche application sur un autre et la présentation sur un autre également. Ceci est la répartition des couches par tiers.
Le schéma ci-dessous représente les tiers (métiers et application) et montre les types de connexions entre les serveurs.
Au sein d’un tiers précis, l’application doit également être divisée en couches afin de facilité l’évolution et la modularité.
L’interconnexion entre ces couches est plus complexe. C’est donc, ici, que doivent intervenir les patterns.
3.6.1.2.Patterns Les patterns sont des modèles de programmation qui répondent à un problème particulier. Lorsqu’on développe une application complexe qui se veut modulable, on est obligé d’utiliser des « astuces » pour connecter les différentes classes de notre application.
Ces astuces sont, bien entendu, les patterns. Un ensemble très important de pattern existent, vous trouverez très généralement des solutions à des problèmes critiques dans les patterns. Cependant il est impératif de les comprendre afin de ne pas les utiliser dans de mauvaises conditions.
Si vous souhaitez plus d’informations sur les patterns, vous pourrez vous référer au cours « Design Pattern ».
Façade Une façade est un objet frontal constituant le point d’entrée unique des services d’un sous-système. L’implémentation et les autres composants du sous-système sont privés et invisibles des composants externes. La façade assure la protection des variations dans l’implémentation du sous-système.
Ce pattern est très utilisé. En effet, il permet de séparer la définition d’un système et son implémentation. On retrouve ce pattern aussi bien au niveau des drivers (JDBC par exemple), provider JNDI (CORBA, RMI, DNS …) mais également au sein de vos applications. Vous pouvez l’utiliser dans celles-ci pour cacher l’implémentation d’accès aux données, aux services …
Voici un schéma récapitulant ce pattern :
DAO (Data Access Object) L’accès aux données peut se faire de plusieurs manières. Le pattern DAO définit la manière la plus optimale en matière d’évolution et d’architecture objet.
Ce pattern se base sur l’utilisation de classe « Data ». On parle de POJO (Plain Old Java Object) en Java. Le qualificateur « Old » n’est pas du tout négatif, en effet il indique que la compatibilité avec l’ensemble des versions de Java est préservée (donc n’utilise pas d’outils spéciaux en dehors du langage Java).
Votre DAO fournit les méthodes d’ajout d’objet (sauvegarde en base de données), lecture d’objet (récupération de données depuis la base de données), modification d’objet, suppression d’objet. Il cache la connexion à la base de données ou tout autre outil d’accès aux données (XML, réseau …).
Le schéma suivant présente le pattern. Il décrit un DAO utilisant JDBC (DataSource et ResultSet).
MVC (Model View Controller) ou Controller MVC peut être vu comme une structure d’application plus qu’un pattern en lui-même. Le problème est : « Comment bien séparer le traitement de la requête client, le modèle de données et le choix de la vue à retourner au client ? ».
MVC définit, comme son nom l’indique, trois composants :
- Model : modèle de données (accès aux services …)
- Vue : vue retournée à l’utilisateur
- Controller : contrôleur traite la demande client, accède aux modèles et sélectionne la vue à retourner au client.
Vous pouvez retrouver ce pattern dans SWING, Servlet/JSP pour les plus connus. Si vous souhaitez en savoir plus, vous pouvez vous reporter à l’essentiel concernant « Struts » (framework utilisant le concept MVC).
Fabrique (Factory) Un problème s’impose très souvent en terme de création d’objets : « Qui doit être responsable de la création des objets lorsque ceux-ci correspondent à des responsabilités particulières, telle une logique de création complexe ou une volonté de séparer les responsabilités de création pour une meilleure cohésion, etc… ? »
L’utilisation d’une fabrique est sans doute l’une des principales solutions.
Imaginons que vous souhaitiez utiliser des classes de services dans une application web. Comment voulez vous créer l’objet de service tout en gardant une abstraction totale de l’implémentation ?
En java, vous utilisez l’opérateur « new » pour créer une nouvelle instance d’objet en mémoire comme ci-dessous :
MonService service = new MonService();
Cependant cette solution est trop restrictive, si vous souhaitez utiliser une autre classe de service, vous devrez modifier l’ensemble des codes faisant l’appel précédent.
Dans le cadre d’une Fabrique, c’est elle qui s’occupera de choisir la bonne classe de service à instancier (via une variable d’environnement, fichier de properties …). De plus les méthodes de votre fabrique permettant de récupérer un service devront retourner le type d’interface de haut niveau de votre service et NON LE TYPE DE LA CLASSE D’IMPLEMENTATION (cela anéantirait le concept de Fabrique en lui-même !).
IMonService service = MaFabrique.getMonService(); // retourne un objet de type
// IMonService (interface) et non MonService qui serait la classe d’implémentation
Vous pourriez également utiliser une Fabrique dans les cas suivants :
- Une classe ne peut anticiper quel type d’objet elle doit utiliser
- Vous voulez centraliser la connaissance des types de classe qui seront créées
Il existe cependant plusieurs types de fabriques (concrète, abstraite …). Ces différents types ont le point commun de construire des objets, mais la façon dont ils gèrent cette création diffère suivant le type.
Voici un schéma présentant ce pattern (type abstrait) :
Adaptateur (adapter) Ce pattern est né d’un problème simple : « Comment concilier des interfaces incompatibles ou fournir une interface stable à des composants similaires possédant différentes interfaces ? ».
La solution est tout aussi simple : « Convertir l’interface d’origine d’un composant en une autre interface, via un objet adaptateur intermédiaire.
Prenons l’exemple d’un système voulant accéder à des stocks distants de différents fournisseurs. Chaque fournisseur fournit un moyen particulier d’accéder à ses informations. Cependant chaque fournisseur fournit la même information (quantité disponible liée à une référence produit par exemple). Vous pouvez utiliser le pattern adaptateur afin d’uniformiser les accès à ces informations.
Voici un schéma récapitulant ce pattern :
Observateur Lorsque vous connectez deux couches ensembles et que vous voulez qu’une couche de plus bas niveau appelle ou envoie un message à la couche de plus haut niveau il n’est pas toujours évident de trouver une solution qui respecte le principe de séparation Modèle - Vue.
Le principe de Faible couplage indique qu’il doit être possible de remplacer une couche (par exemple : présentation) sans en affecter les autres (par exemple : domaine). Vous ne pouvez pas directement appeler une méthode d’affichage d’une fenêtre à partir de la couche domaine.
La solution est bien entendu l’utilisation du pattern Observateur.
Problème : Différents types d’objets souscripteurs sont concernés par les changements d’état et les événements d’un objet diffuseur (publisher) et veulent réagir à leur manière lorsque le diffuseur génère un évènement. De plus le diffuseur veut maintenir un faible couplage avec les souscripteurs.
Solution : Définit une interface « souscripteur » ou « auditeur ». Les souscripteurs implémentent cette interface. Le diffuseur peut enregistrer dynamiquement les souscripteurs intéressés par un événement et le leur signaler.
Autres patterns intéressant Voici une liste d’autres patterns très intéressant en terme de développement :
- Singleton
- Bridge
- Composite
- Proxy
- Decorator
- Iterator
- Prototype
- State
- Strategy
- …
N’hésitez pas à consulter l’essentiel dédié à ces patterns (Design Pattern) afin d’avoir plus d’informations et de détails.
3.6.1.3.Utilisation de JNDI (Java Naming and Directory Interface) Nous avons pu voir que certains patterns sont particulièrement utiles lorsqu’ils travaillent avec des propriétés externes (valeurs externes, hors du code). C’est le cas pour les Fabriques, Adaptateur et bien d’autres encore. L’une des possibilités est d’utiliser un fichier externe (properties par exemple), ceci est le cas pour les applications clientes, ou utiliser JNDI dans le cas d’application contenue (dans un Container).
Vous pouvez facilement mapper une valeur à une clé et donc spécifier la classe à utiliser pour tel ou tel service sans avoir à l’intégrer à votre code directement.
Voici un exemple de configuration JNDI pour une application web (dans le web.xml) :
<env-entry>
<env-entry-name>contactDaoImpl</env-entry-name>
<env-entry-value>com.society.contactbook.dao.impl.ContactDaoXml</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>
Ces lignes définissent une entrée « contactDaoImpl » dans l’environnement de l’application contenant la valeur « com.society.contactbook.dao.impl.ContactDaoXml », c'est-à-dire le nom absolue de la classe DAO à utiliser pour l’implémentation du DAO lié au Contact.
Vous pouvez alors récupérer facilement la valeur dans votre Fabrique :
Context ctx = new InitialContext();
String contactDaoImpl = (String) ctx.lookup("java:comp/env/contactDaoImpl");
IContactDao dao = (IContactDao) Class.forName(contactDaoImpl).newInstance();
Ces quelques lignes permettent d’instancier de façon dynamiquement la classe indiquée dans l’entrée d’environnement : « contactDaoImpl ».
L’avantage de cette méthode est évidente : on peut changer la classe d’implémentation de « contactDao » sans avoir à recompiler l’ensemble de l’application !
Nous vous avons présenté une utilisation de JNDI, cependant il existe un grand nombre d’autres utilisations (particulièrement intégrer à la connexion entre les composants : EJB / JMS / Datasource …)
3.6.2.Solutions à base de framework 3.6.2.1.Spring Spring est un conteneur léger, c'est-à-dire qu’il « remplace » un conteneur lourd (utilisé par les EJB dans un serveur d’application) au sein d’un simple conteneur web. Bien entendu l’utilisation de Spring est une approche différente comparée à l’utilisation d’un conteneur « lourd ».
Spring est une couche transversale intégrant (liste non exhaustive) :
- La gestion des transactions de façon transversale et centralisé
- Couche d’abstraction à JDBC (réduit le nombre de ligne de code à écrire pour l’accès JDBC, met en place une hiérarchie d’exception plus intuitive …)
- Intégration avec (mapping objet/relationel) :
- Toplink
- iBatis
- Hibernate
- JDO
- AOP (Aspect Oriented Programming)
- Framework MVC (Model View Controller)
De nombreuses fonctionnalités sont disponibles dans ce framework. Même s’il n’est pas toujours évident de comprendre rapidement l’utilisation de Spring, il est souvent plus difficile d’utiliser les standards J2EE …
3.6.2.2.Struts Struts pourrait être assimilé à une surcouche de Servlet/JSP. Ce framework comble une bonne partie des lacunes du Model : Servlet/JSP. Ce framework met a disposition un ensemble d’outil afin d’organiser de façon harmonieuse le modèle MVC au sein d’une application web.
D’une part vous avez les « ACTION » de l’autre la VUE (page jsp). Le framework permet de centraliser la carte de navigation dans votre site.
Contrairement à Spring, ce framework n’est pas transversale à votre application mais se situe principalement dans les couches application et présentation.
|
|
 |
