Centralise et modularise les actions et la gestion des vues. Il définit à la fois un mapping des URLs ou URIs, c’est à dire associer un nom logique à une page JSP ou une Servlet et un mécanismes de re-direction des vues.

Avantages :

• Contrôle centralisé : La re-direction ou le renvoi des vues est effectué via des noms logiques, ceci permet de pour pouvoir changer le chemin ou le noms des vues sans modifier le code des actions.
  

CONTEXTE

Un environnement distribué et multi-tiers nécessite des appels à des méthodes distantes afin d’échanger des données. Ces données envoyés ou reçus sont transportés via les tiers.
Les clients sont exposés à la complexité de la gestion des composants distribués.

SOLUTION

Le pattern BusinessDelegate offre une abstraction de l’implémentation des services métier et réduit le couplage entre le tiers Présentation et le tiers Métier.
Ce pattern réduit aussi l’importance des modifications qui peuvent impacter le Tiers de Présentation.

AVANTAGES DU PATTERN

L’utilisation du pattern Business Delegate permet de :

• Faciliter la séparation des rôles de développement,
  
• Découpler le client et les EJBs (ou destinations JMS),
  
• De regrouper en un seul endroit tous les appels distants. Transformer les Exceptions génériques en exceptions propres à l’application ou au framework développé.
  
• De maximiser la reutilisabilité des services distants en proposant un point d’entrée pour chaque service.
  

CONTEXTE

Pour accéder à un service Business, un client (Servlet ou simple POJO) doit d’abord localiser le service puis « l’instancier » ou le créer. Ces services sont typiquement des EJBs, des Datasources ou des composants JMS.
Par exemple dans une architecture basique, un EJB doit d’abord récupérer une référence (localiser) sur une Home d’EJB, puis créer l’EJB correspondant. De la même façon, une servlet doit localiser une fabrique de connexion JMS et créer une connexion ou session JMS.

Cependant pour utiliser les composants de service, le client passe par un annuaire JNDI.
Il est nécessaire de signaler que le code client est toujours le même ce qui signifie une duplication de code très significative.

La création d’un contexte initial JNDI et la localisation des composants de service nécessite une utilisation très intensive des ressources qui peuvent impacter sur la performance de l’application et la plate-forme hébergeant le serveur d’application. Par exemple si un nombre très conséquent des clients demandent le même service correspondant à un EJB, on trouveras plusieurs copies dupliquées du même objet dans la JVM.

L’implémentation de la fabrique du contexte initial dépend du vendeur, ce qui introduit une dépendance vis-à-vis du code client.

Si nous récapitulons La localisation des services engendre :

• Opération réseau intensive.
  
• Des interfaces complexes,
  
• Du code dupliqué, donc redondance,
  
• Dépendance vis-à-vis du vendeur du serveur d’application.
  

SOLUTION

Le pattern ServiceLocator introduit une abstraction des de l’utilisation du service de nommage JNDI tout en cachant la récupération du contexte initial. Il permet aussi l’abstraction de la création des composants de service (EJB, Factory JMS, DataSource).

Le fait de centraliser la création des composants de service facilitera le cache de ces derniers.

Ceci va permettre:

• Une reutilisabilité très conséquente du code.
  
• Tous les clients vont passer par le même objet pour les opérations de localisation et de création.
  
• Augmenter les performances de l’application en minimisant les appels distants avec le système du cache.
  
• Ce pattern est bon candidat pour été utilisé par le pattern BusinessDelegate.
  
• Le client se contente de l’exécution du traitement proposé par le composant de service sans se soucier du vendeur du serveur d’application ni d nom JNDI alloué à ce composant.
  

TYPAGE DU SERVICELOCATOR

Le serviceLocator doit prendre en compte les différents par exemple :

• Les ejbs distants et locaux,
  
• Les fabriques de connexions JMS,
  
• Les source de données.
  

Le Front Controller résout le problème de décentralisation des systèmes de Servlet par exemple en canalisant toutes les requêtes via un seul contrôleur. Le contrôleur lui-même est généralement implémenté en deux parties : un gestionnaire (Récupération des requêtes) d'une part et une hiérarchie de commandes (exécution puis aiguillage) d'autre part.

Avantages :

• Contrôle centralisé. Le Front Controller coordonne toutes les requêtes passées auprès de l'application Web. Le contrôleur unique est dans un emplacement parfait pour appliquer les stratégies de l'application dans son ensemble, telles que la sécurité et le suivi d'utilisation.
  
• Sécurité des threads. Comme chaque requête implique la création d'un nouvel objet de commande, les threads des objets de commande eux-mêmes ne doivent pas nécessairement être sécurisés. Ceci signifie qu’on évite les problèmes de sécurisation des threads dans les classes de commande.
  
• Possibilités de configuration. Un seul contrôleur de premier plan doit être configuré sur le serveur Web ; le gestionnaire s'occupe du reste de la distribution.
  

Ce modèle décrit une alternative pour implémenter une fonctionnalité récurrente dans une application Web. Le Filtre d’interception fonctionne en transmettant chaque requête dans une chaîne de filtres configurable avant de donner la main au contrôleur. Les filtres traitent généralement les fonctions de bas niveau telles que le décodage, l'octroi d'autorisation, l'authentification et la gestion des sessions alors que le modèle Front Controller gère les fonctionnalités au niveau de l'application. Autre aspect des filtres : ils sont généralement sans état. Lorsqu'un utilisateur obtient une autorisation, par exemple, le serveur Web doit authentifier la session. Si l'utilisateur est authentifié, le traitement se poursuit. Dans le cas contraire, l'utilisateur est redirigé ailleurs. L'un des avantages du Filtre d’interception est que dans la majorité des implémentations, il est inutile de modifier les pages elles-mêmes pour ajouter une fonctionnalité complémentaire.

Avantages :

• Séparation des problèmes. La logique que contiennent les filtres est dissociée de la logique d'application. Le code d'application n'est donc pas affecté par les modifications des fonctions de bas niveau.


• Flexibilité. Les filtres sont indépendants les uns des autres. Par conséquent, vous pouvez former une chaîne en combinant tous les filtres sans avoir à en modifier le code.


• Configuration centrale. Du fait de la nature composite des filtres, il est possible d’utiliser un simple fichier de configuration pour charger la chaîne de filtres. Au lieu de travailler sur un grand volume de code source, il suffit alors de modifier un seul fichier de configuration pour déterminer la liste des filtres à insérer dans le traitement de la requête.


• Composition variable au déploiement. Les chaînes de filtres d'interception peuvent être construites au moment de l'exécution à partir de fichiers de configuration. Par conséquent il est possible modifier la séquence des filtres pendant le déploiement sans avoir à modifier le code.


• Réutilisation. Comme les filtres ne dépendent pas de leur environnement d'exploitation, à l'exception du contexte dans lequel ils opèrent, chaque filtre peut être réutilisé individuellement dans d'autres applications Web.

LES DESIGN PATTERNS

Les design patterns sont des éléments d’architecture logicielle réutilisables.
Un design pattern est une solution à un problème en tenant compte d’un contexte.

• Un contexte est un environnement ou une situation ou des pré-conditions.


• Un problème est une question qui nécessite investigation et résolution. Le problème est généralement lié à un contexte.


• Une solution est la réponse au problème étant donné son contexte.

Un pattern correspondant à un problème peut être adaptable à plusieurs contextes, pour cela il faut que ce dernier soit le plus conceptuel et structurel possible. Son implémentation prendra en compte les spécificités du contexte, par exemple plate-forme d’exécution, contraintes techniques du projet …

LES DESIGN PATTERNS J2EE

Les patterns J2EE sont une collection de solutions techniques à des problèmes récurrents liés à l’intégration J2EE dans le processus de développement des applications orientées entreprise.

Ils reflètent l’expertise et le retour d’expérience en terme d’architecture applicative et technique regroupées sous le terme qualité de service (QoS Quality of Service).

Les patterns J2EE viennent répondre aux problématiques et exigences en terme de :

• Performance, Cette exigence désigne la durée attendue des temps de réponse aux requêtes clients,


• Scalabilité, Cette exigence désigne la capacité de maintenance de performances d'accès constantes malgré l'accroissement du volume de données traitées. Elle est une exigence capitale pour des applications à usage intensive de données, telles qu'un SGBD, un serveur WEB.


• Qualité, qualité en terme de code de l’application, un code de bonne qualité assure la pérennité, la diffusion et la maintenabilité du projet.


• Disponibilité, Cette exigence concerne à la fois les applications et les plates-formes les hébergeant.


• Sécurité, en terme d’authentification, d’habilitation et d’autorisation d’accès.


• Flexibilité, L’application est facilement modifiable ou restructurable,


• Réutilisabilité, (Don’t reinvent the Weell) permettent un gain de temps pour des développements


• Fiabilité, L’ utilisateur peut faire confiance à l’application.

Ils font aussi partie des bonnes pratiques et approches J2EE qui accélèrent la construction des architectures et de leur implémentation.