Академический Документы
Профессиональный Документы
Культура Документы
Introduction à J2EE
J2EE (Java 2 Enterprise Edition) est une norme proposée par la société Sun, portée par un
consortium de sociétés internationales, visant à définir un standard de développement
d'applications d'entreprises multi-niveaux, basées sur des composants.
On parle généralement de «plate-forme J2EE» pour désigner l'ensemble constitué des services
(API) offerts et de l'infrastructure d'exécution. J2EE comprend notamment :
Dans la mesure où J2EE s'appuie entièrement sur le Java, il bénéficie des avantages et
inconvénients de ce langage, en particulier une bonne portabilité et une maintenabilité du
code.
1. Architecture multicouche
1.1. Présentation et organisation d’une architecture multicouche
Les applications J2EE actuelles possèdent une architecture complexe où plusieurs
composantes applicatives interviennent. Une telle application est organisée sous forme de
plusieurs couches interconnectées que l’on appelle « tiers ».
Ce type d’architecture met en place des interconnexions entre des entités différentes
génériques et/ou spécialisées dans un traitement particulier réparties, une nouvelle contrainte
est à prendre en considération : il s’agit de la composante communication (réseaux et
protocoles d’échange).
La figure suivante présente l’architecture J2EE d’une application Web avec la vue « tiers » :
Figure 1 : Architecture J2EE d’une application Web
L’exemple d’architecture décrit au dessus représente une architecture de type 3-tiers. Celle-ci
est la plus utilisée dans les petits et moyens projets. Elle permet de séparer le client, le serveur
d’application et le réservoir de données.
Dans le cas d’une application plus complexe (applications d’intégration, gestion métier
poussée, communication entre différentes applications existantes, etc), l’architecture 3-tiers
peut s’avérer insuffisante. Ceci est du à une évolution difficile de ce type d’application à
cause de la concentration des services au niveau d’un seul tiers.
Pour pallier aux divers problèmes cités ci-dessus, une architecture dotée d’une granularité
plus fine s’avère plus appropriée.
L’architecture présentée dans la figure ci-dessus est un exemple type composée de plusieurs
couches. Elle nécessite un travail de personnalisation en fonction du projet à développer avant
de permettre la mise en œuvre de l’applicatif à mettre en place. Les couches de base qui la
composent sont les suivantes :
- Couche présentation
- Couche application
- Couche métier
- Couche accès aux données
Le MVC est un modèle d’architecture qui repose sur la volonté de séparer les données, les
traitements et la présentation. Ainsi l'application se retrouve segmentée en trois composants
essentiels :
• La vue correspond à l'IHM. Elle présente les données et interagit avec l'utilisateur.
Dans le cadre des applications Web, il peut s'agir d'une interface HTML/JSP, mais
n'importe quel composant graphique peut jouer ce rôle.
• Le modèle représente les données et les règles métiers. C'est dans ce composant que
s'effectuent les traitements liés au cœur du métier. Les données peuvent être liées à
une base de données, des EJBs, des services Web, etc.
Figure 4 : Modèle MVC
Il est important de noter que les données sont indépendantes de la présentation. En
d'autres termes, le modèle ne réalise aucune mise en forme. Ces données pourront être
affichées par plusieurs vues. De ce fait le code du modèle est factorisé : il est écrit une seule et
unique fois puis réutilisé par chaque vue.
2. Le modèle MVC2
Le MVC très pratique, peut se révéler lourd à mettre en place. Ceci à cause de la multitude de
contrôleurs à implémenter, car comme nous l’avons expliqué précédemment, chaque vue
possède son propre contrôleur.
Dans l'organisation logicielle MVC2, le Servlet est unique, en classe et en instance. Il garantit
l'unicité du point d'entrée de l'application. Il prend en charge une partie du contrôle de
l'application.
Les contrôleurs MVC se retrouvent alors partiellement déportés dans l'entité "dynamique de
l'application" qui assure le contrôle de la dynamique de l'application et qui gère les relations
entre les objets métier et la présentation. Les contrôleurs deviennent essentiellement des
contrôleurs du dialogue entre l'utilisateur et les objets métiers.
Figure 5 : Modèle MVC2
1. Le client envoie une requête à l'application. La requête est prise en charge par le
Servlet d'entrée.
5. Le contrôleur encapsule les données métiers dans des JavaBeans, sélectionne la JSP
qui sera en charge de la construction de la réponse et lui transmet les JavaBean
contenant les données métier.
6. La JSP construit la réponse en faisant appel aux JavaBeans qui lui ont été transmis
et l'envoie au navigateur.