Architecture J2EE support de cours complet de A à Z
Aspect programmation
Architecture J2EE
Volonté de SUN
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.
De plus, l'architecture J2EE repose sur des composants distincts, interchangeables et distribués, ce qui signifie notamment :
Les API de J2EE
Les API de J2EE peuvent se répartir en trois grandes catégories :
o Les composants web : Servlets et JSP (Java Server Pages). Il s'agit de la partie chargée de l'interface avec l'utilisateur (on parle de logique de présentation).
o Les composants métier : EJB (Enterprise Java Beans). Il s'agit de composants spécifiques chargés des traitements des données propres à un secteur d'activité (on parle de logique métier ou de logique applicative) et de l'interfaçage avec les bases de données.
o Les services d'infrastructures : il en existe un grand nombre, définis ci-dessous :
JDBC (Java DataBase Connectivity) est une API d'accès aux bases de données relationnelles.
JNDI (Java Naming and Directory Interface) est une API d'accès aux services de nommage et aux annuaires d'entreprises tels que DNS, NIS, LDAP, etc.
JTA/JTS (Java Transaction API/Java Transaction Services) est un API définissant des interfaces standard avec un gestionnaire de transactions.
JCA (J2EE Connector Architecture) est une API de connexion au système d'information de l'entreprise, notamment aux systèmes dits «Legacy» tels que les ERP.
JMX (Java Management Extension) fournit des extensions permettant de développer des applications web de supervision d'applications.
o Les services de communication :
JAAS (Java Authentication and Authorization Service) est une API de gestion de l'authentification et des droits d'accès.
JavaMail est une API permettant l'envoi de courrier électronique.
JMS (Java Message Service) fournit des fonctionnalités de communication asynchrone (appelées MOM pour Middleware Object Message) entre applications.
RMI-IIOP est une API permettant la communication synchrone entre objets.
L'architecture J2EE permet ainsi de séparer la couche présentation, correspondant à l'interface homme-machine (IHM), la couche métier contenant l'essentiel des traitements de données en se basant dans la mesure du possible sur des API existantes, et enfin la couche de données correspondant aux informations de l'entreprise stockées dans des fichiers, dans des bases de données relationnelles ou XML, dans des annuaires d'entreprise ou encore dans des systèmes d'information complexes.
La plateforme Java™ 2 Platform, Enterprise Edition (J2EE) fournit un standard pour le développement d'applications d'entreprise multiniveaux.
L'économie et la technologie d'aujourd'hui ont intensifié la nécessité de disposer de solutions de gestion des informations plus rapides, plus efficaces et à plus grande échelle. La spécification J2EE répond à ces défis en offrant un modèle de programmation qui améliore la productivité de développement, qui standardise la plateforme d'hébergement des applications d'entreprise et qui garantit la portabilité des applications développées grâce à une vaste suite de tests.
L'architecture J2EE prend en charge le développement à base de composants d'applications d'entreprise multiniveaux. Un système d'application J2EE comprend en général les niveaux suivants :
Niveau client
Au niveau client, les composants Web (servlets ou fichiers JavaServer Pages (JSP), par exemple) ou les applications Java autonomes offrent une interface dynamique vers le niveau intermédiaire.
Niveau intermédiaire
Au niveau serveur, ou niveau intermédiaire, les beans enterprise et les services Web encapsulent une logique applicative réutilisable et distribuable pour l'application. Ces composants de niveau serveur sont contenus dans un serveur d'applications J2EE qui offre une plateforme permettant à ces composants d'exécuter des actions et de stocker des données.
Niveau données d'entreprise
C'est à ce niveau que les données de l'entreprise sont stockées et conservées, en général dans une base de données relationnelle.
Les applications J2EE se composent de composants, de conteneurs et de services. Les composants sont des composants de niveau application. Les composants Web tels que les servlets et les JSP, fournissent des réponses dynamiques aux requêtes des pages Web. Les composants EJB contiennent une logique applicative côté serveur pour les applications d'entreprise. Les conteneurs de composants Web et EJB hébergent des services prenant en charge les modules Web et EJB.
. L’architecture J2EE
J2EE (Java 2 Entreprise Edition) est une plate-forme de développement d’application s’appuyant sur le langage Java. Les architectures J2EE sont utilisées essentiellement pour l’élaboration d’applications présentant une architecture complexe. Ainsi, la mise en place de ce type d’application nécessite l’intervention de plusieurs acteurs et l’utilisation de plusieurs composants. D’où une exigence accrue en matière d’interopérabilité et l’interconnexion qui s’avère souvent difficile à mettre en place. Ce type d’applications nécessite également des données hétérogènes (souvent de différents formats) pouvant provenir de différentes applications externes.
Le développement d’une telle application doit tenir compte des composants logiciels préexistants mais également des évolutions futures envisageables (changement de base de données, autres types de clients, changement de logique métier, etc).
Les applications J2EE sont typiquement utilisées dans le cadre des architectures distantes (type client/serveur). Nous étudierons dans ce qui suit l’architecture des applications J2EE réparties et leurs différents composants.
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.
La figure suivante illustre une telle architecture dite « n-tiers » ou multi-couches :
Figure 2 : Architecture de type n-tiers
1.2. Utilisation des couches : avantages et inconvénients
Les principaux avantages que procure l’élaboration d’une architecture « multi-couches » sont :
- Structure de l’application adaptée à l’architecture de déploiement ciblée,
- Modularité de l’application, - Evolution facilitée de l’application,
- Factorisation du code avec possibilité d’exploiter un framework ou des composants
génériques (gain de temps et de performances).
Les inconvénients majeurs sont :
- L’augmentation de la complexité lors de rajout de plusieurs services,
- Nécessité des connaissances tant technique que théorique.
Le schéma ci-dessous est un exemple type d’architecture J2EE destinée à servir un client léger.
Dans ce type d’architecture, nous distinguons ainsi les couches suivantes :
Figure 3 : Exemple type d’une architecture J2EE
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
2.1. Couche présentation
La couche présentation correspond à la partie de l’application visible et interactive avec les utilisateurs. Elle relaie les requêtes de l’utilisateur à destination de la couche métier, et en retour, lui présente les informations renvoyées par les traitements de cette couche. Il s’agit donc ici d’un assemblage de services métiers et applicatifs offerts par la couche métier.
2.2. Couche métier
La couche métier correspond à la partie fonctionnelle de l’application, qui est responsable de l’implémentation de la « logique », décrivant les opérations que l’application opère sur les données en fonction des requêtes des utilisateurs, effectuées au travers de la couche présentation.
Les différentes règles de gestion et de contrôle du système sont mises en œuvre dans cette couche.
La couche métier offre des services applicatifs et métiers à la couche présentation. Pour fournir ces services, elle s’appuie sur les données du système, accessibles au travers des services de la couche d’accès aux données. En retour, elle renvoie à la couche présentation les résultats qu’elle a calculés.
2.3. Couche d’accès aux données
Elle consiste en la partie gérant l’accès aux de données du système. Ces données peuvent être propres au système, ou gérées par un autre système. La couche métier n’a pas à s’adapter à ces deux cas, ils sont transparents pour elle, et elle accède aux données de manière uniforme.
2.4. Couche application
La couche application sert de médiateur entre la couche présentation et la couche métier et contrôle l’enchaînement des tâches.
L'architecture MVC est fortement recommandé comme modèle pour la plate-forme J2EE.
Le modèle MVC est un modèle de conception logicielle largement répandu, fort et utile. Néanmoins il faut retenir que c’est un modèle de conception, et il est donc indépendant du langage de programmation.
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 :
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.
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
Dans ce modèle, le cycle de vie d'une requête est le suivant :
