-
Tout d'abord, je tiens à vous signaler que ce tutorial date un peu, je vous invite, pour avoir des nouvelles plus récentes à consulter notre blog sur Java et J2EE.
J2EE signifie signifie Java 2 Entreprise Edition et repose donc sur Java, le fameux langage objet conçu pour être "portable" ("Write Once, Run Anywhere").
Dès son origine, java a révolutionné plusieurs domaines de l'informatique, que ça soit la téléphonie, l'internet ou les applications d'entreprise. Aujourd'hui, SUN a réorganisé son offre autour de 3 briques :
- Java 2 Micro Edition (J2ME) qui cible les terminaux portables.
- Java 2 Standard Edition (J2SE) qui vise les postes clients.
- Java 2 Entreprise Edition (J2EE) qui définit le cadre d'un serveur d'applications et d'intégration.
J2EE a pour but de crédibiliser le statut de Java en tant que plateforme pour la programmation en entreprise.
-
Il existe de nombreuses architectures possibles pour les applications d'entreprise, nous allons passer en revue les plus connues et nous verrons à quelle problématique J2EE tente de répondre.
-
Pour simplifier, on peut dire que, dans ce type d'architecture, les traitements sont sur le client et la base de données est sur le serveur. Le plus gros problème est celui de la maintenance : La moindre modification oblige à mettre à niveau chaque poste client. De plus les performances de l'application sont pour beaucoup en fonction des ressources des clients.
-
A cause des problèmes de l'architecture à deux niveaux, on a rajouté un autre niveau. Ainsi une application est divisée en trois niveaux logiques :
- Niveau présentation : l'interface graphique pour l'utilisateur.
- Niveau métier : Recouvre la logique métier ( aussi appelée logique applicative ).
- Niveau données : Les données de l'application ( serveur de base de données, documents XML, serveur LDAP... ).
Le niveau métier contient le code appelé (via le niveau présentation) par l'utilisateur pour extraire et traiter les données de la troisième couche. Cette séparation en couches améliore la souplesse de l'application. Il devient facile de déployer de nombreuses interfaces utilisateur sans devoir modifier la logique applicative.
-
Ce genre d'architecture se compose de différents niveaux que l'on peut subdiviser de la façon suivante :
- Interface utilisateur : Couche chargée de gérer les interactions entre l'utilisateur et l'application ( Application de bureau, navigateur WAP, Browser Internet... )
- Logique de présentation : Elle permet de définir ce que doit afficher l'interface utilisateur et la maniçre dont les requêtes doivent être traitées.
- Logique métier : Modélise les règles métiers de l'entreprise.
- Service d'infrastructure : Fonctionnalités fournies aux composants ( connexions, transactions... ).
- Données : Données de l'entreprise.
Ce genre d'architecture suit le modèle Modèle Vue Contrôleur ( Voir les explications du pattern MVC sur le site de sun ), c'est ce modèle que J2EE suit.
-
En fait, J2EE est une norme qui va spécifier à la fois l'infrastructure de gestion de vos applications et les API des services utilisées pour concevoir ces applications. La plateforme J2EE est essentiellement un environnement fournissant :
- Une infrastructure d'exécution pour faire tourner vos applications.
- Un ensemble de services accessibles via l'API J2EE pour vous aider à concevoir vos applications.
-
Un des avantages majeurs de J2EE est de faire abstraction de l'infrastructure d'exécution. En effet, J2EE spécifie les rôles et les interfaces pour les applications, ainsi que l'environnement d'exécution dans lequel les applications sont déployés. Ceci permet aux développeurs d'application de ne pas avoir a reprogrammé les services d'infrastructure.
-
Le serveur J2EE va fournir à votre application un ensemble de services comme les connexions aux bases de données, la messagerie, les transactions... L'architecture J2EE unifie l'accés à ces services au sein des API de ses services d'entreprise mais plutôt que d'avoir accés à ces services au travers d'interfaces propriétaires ou non standard, les applications J2EE peuvent accéder à ces API via le serveur.
La spécification de la plateforme J2EE pérvoit un ensemble d'extensions Java standard que chaque plate-forme J2EE doit prendre en charge :
- JNDI : JNDI est une extension JAVA standard qui fournit une API uniforme permettant d'accéder à divers services de noms et de répertoires. Derrière un nom JNDI, il peut y avoir un appel à des services CORBA, DNS, NIS, LDAP... En fait, JNDI permet de localiser et d'utiliser des ressources.
- Authentification : J2EE fournit des services d'authentification en se basant sur les concepts d'utilisateur, de domaines et de groupes.
- JDBC : Java Database Connectivity est une API qui permet aux programmes Java d'interagir avec les bases de données SQL.
- Servlet : Un servlet est un composant coté serveur, écrit en Java, dont le rôle est de fournir une trame générale pour l'implémentation de paradigmes " requête-réponse ". Ils remplacent les scripts CGI tout en apportant des performances bien supérieures.
- JSP : La technologie JSP (JavaServer Pages) est une extension de la notion de servlet permettant de simplifier la génération de pages web dynamiques. Elle se sert de balises semblables au XML ainsi que de scriplets Java afin d'incorporer la logique de fabrication directement dans le code HTML. JSP est un concurent direct de l'ASP et du PHP.
- JMS : Java Messaging Service est à la fois une ossature et une API permettant aux développeurs de construire des applications professionnelles qui se servent de messages pour transmettre des données.
- JTA : La spécification JTA (Java Transaction API) définit des interfaces standards entre un gestionnaire de transactions et les éléments impliqués dans celles-ci : L'application, le gestionnaire de ressources et le serveur.
- EJB : Chaque instance d'un EJB se construit dans conteneur EJB, un environnement d'exécution fournissant des services (Sécurité, Communications, Cycle de vie...). Un client n'accède JAMAIS directement à un composant. Il doit pour cela passer par une interface locale et une interface distance. L'interface locale décrit le cycle d'existence du composant en définissant des méthodes permettant de le trouver, de le créer, de le détruire. Et L'interface distante spécifie les méthodes que ce composant présente au monde extêrieur.
-
Un conteneur J2EE est un environnement d'exécution chargé de gérer des composants applicatifs et leur donner accès aux API J2EE.
Dans l'architecture des conteneurs J2EE, vous êtes censés fournir :
- Composants applicatifs : Les servlets, les JSP, les EJB... En somme les composants de votre application.
- Descripteur de déploiement : C'est un fichier XML décrivant vos composants applicatifs et qui fournit des informations au conteneur sur vos composants applicatifs (droit d'accès, transaction...).
L'architecture d'un conteneur, quand à elle, se divise en quatre parties :
- Les interfaces des composants : Ensembles d'interfaces spécifiées par le conteneur et que vos composants applicatifs doivent implémenter.
- API des services du conteneur : Services supplémentaires fournies par le conteneur.
- Services déclaratifs : Services introduits par le conteneur sur vos applications.
- Autres services du conteneur : Il s'agit des services tels que le garbage collector, le pooling des connexions base de données...
-
Une application J2EE commence par la création de composants J2EE. Ces composants sont ensuite regroupés en modules auquel on associe des descripteurs de déploiement. Ces modules J2EE peuvent ensuite $etre déployés comme application à part entière ou être assemblés avec un descripteur de déploiements J2EE et être déployés en tant qu'application J2EE. ( voir la spécification de sun au format PDF )
-
Durant cette phase, nous modélisons les règles métiers sous la forme de composants applicatifs. Ces composants applicatifs seront groupés selon leur type ( Web, EJB.. ) avec un descripteur de déploiement pour donner un module J2EE. Ces modules J2EE composeront l'application J2EE.
Note : un module J2EE peut être déployé seul et être considéré comme une application J2EE valide.
-
Une application J2EE peut être constitué d'un ou plusieurs module J2EE et un descripteur d'application J2EE. L'application J2EE est packagée dans un fichier ayant l'extension .ear ( Entrerpise Archive ).
Note : Un fichier EAR est un ficher JAR sauf qu'il contient un fichier application.xml décrivant l'application.
-
Le déploiement d'applications consiste à installer et à personnaliser des modules empaquetés sur une plateforme J2EE. Ce processus se compose de deux étapes :
- Installation : On installe l'application sur le serveur J2EE.
- Configuration : On paramêtre l'application pour qu'elle s'intègre à l'infrastructure sur laquelle elle vient d'être installée ( mot de passe base de données, factory de connexions, utilisateurs, droits... ).
-
-
-
-
Je vous invite à consulter le site de SUN sur Java ( http://www.javasoft.com ), vous y trouverez toute l'information dont vous avez besoin. Si vous avez des suggestions ou des questions, n'hésitez pas à m'écrire ! ça me fera plaisir :)
Stéphane TRAUMAT
Scub, Java & SOA
Cette introduction n'a aucune prétention, si vous y trouvez des erreurs ou des imprécisions, n'hésitez pas à m'écrire, je serais heureux de rectifier. Cette introduction sera mise à jour régulièrement avec les contributions que je recevrais.
|
|