Explorer les Livres électroniques
Catégories
Explorer les Livres audio
Catégories
Explorer les Magazines
Catégories
Explorer les Documents
Catégories
Serveurs d'applications
Tout comme les bibliothques d'interfaces graphiques comme
Swing fournissent les services ncessaires au dveloppement
d'application graphiques, les serveurs d'applications mettent
disposition les fonctionnalits permettant de raliser des
applications d'entreprise : communication entre ordinateurs, mis
en place de protocole adapts, gestion des connexions avec une
base de donnes, prsentation de pages Web, gestion des
transactions, etc.
J2EE propose justement un ensemble de bibliothques avec des
objets de trs haut niveau pour mettre en oeuvre facilement ses
serveurs d'applications. Chacun de ces objets est adapte la
situation en correspondant parfaitement au canevas de
l'ensemble du processus. Ainsi, les dveloppeurs n'ont pas partir
d'une feuille blanche et surtout J2EE permet d'avoir une dmarche
standardise.
Architecture multitiers
Un des thmes rcurrent du dveloppement d'applications J2EE est la
dcomposition de celles-ci en plusieurs niveaux, ou tiers. Gnralement,
une application d'entreprise est compose de trois couches fondamentales
(d'o le terme dcomposition en trois tiers) :
La premire a pour rle d'afficher les donnes pour l'utilisateur et de collecter
les informations qu'il saisit. Cette interface est souvent appele couche de
prsentation car sa fonction consiste prsenter les donnes l'utilisateur
et lui permettre de fournir des informations au systme. La couche
prsentation est la partie de l'application responsable de la cration et du
contrle de l'interface prsente l'utilisateur et de la validation de ses
actions.
Sous cette couche de prsentation, on trouve la logique mtier qui permet
l'application de fonctionner et de traiter les donnes. Dans une application
de paye, par exemple, la logique mtier multiplie les heures travailles par
le salaire horaire pour dterminer combien chaque employ doit toucher.
La logique mtier est mise en oeuvre partir des rgles mtier. Cette
partie de l'application constitue l'essentiel du tiers mdian.
Toutes les applications d'entreprise ont besoin d'crire et de lire des donnes.
Architecture client-serveur
Les applications plus complexes peuvent tirer parti d'une
base de donnes et accder aux informations qu'elle
contient en envoyant des commandes SQL un serveur
pour lire et crire les donnes. Dans ce cas, la base de
donnes fonctionne dans un processus indpendant de
celui de l'application, et parfois sur une machine diffrente.
Les composants permettant l'accs aux donnes sont
spars du reste de l'application.
Architecture clientserveur
La raison de cette approche est de centraliser les donnes
afin de permettre plusieurs utilisateurs d'y accder
simultanment. Les donnes peuvent ainsi tre partages
entre plusieurs utilisateurs de l'application. Cette
architecture est communment appele client-serveur, qui
dans notre approche peut tre reprsente en deux tiers.
Architecture clientserveur
Un des inconvnient de l'architecture deux-tiers est que la
logique charge de la manipulation des donnes et de
l'application des rgles mtiers affrentes est incluse
dans l'application elle-mme. Cela pose problme
lorsque plusieurs applications doivent partager l'accs
une base de donnes. Il peut y avoir, par exemple, une
rgle stipulant qu'un client affichant un retard de
paiement de plus de 90 jours verra son compte
suspendu. Il n'est pas compliqu d'implmenter cette
rgle dans chaque application accdant aux donnes
client. Toutefois, si la rgle change et qu'un dlai de 60
jours est appliqu, il faudra mettre jour toutes les
applications, ce qui peut tre contraignant.
Architecture trois-tiers
Pour viter cette pagaille, la solution consiste sparer
physiquement les rgles mtier en les plaant sur un
serveur o elles n'auront tre remise jour qu'une seule
fois, et non autant de fois qu'il y a d'applications qui y
accde. Cette solution ajoute un troisime tiers
l'architecture client-serveur.
Architecture trois-tiers
Selon ce modle, toute la logique mtier est extraite de
l'application cliente. Celle-ci n'est plus responsable que de
la prsentation de l'interface l'utilisateur et de la
communication avec le tiers mdian. Elle n'est plus
responsable de l'application des rgles. Son rle est rduit
la couche prsentation.
Architecture trois-tiers
Un des avantages essentiel de cette architecture est qu'elle
rend possible la cration d'applications dans lesquelles les
classes dfinies au niveau de la logique mtier sont
directement tires du domaine de l'application. Le code
de cette couche peut utiliser des classes modlisant les
objets du monde rel (par exemple des clients) au lieu de
manipuler des requtes SQL complexes.
En plaant les dtails de l'implmentation dans les couches
appropries
et
en
concervant
des
applications
fonctionnant avec des classes modlisant les objets du
monde rel, les applications sont plus faciles maintenir
et faire voluer.
Les conteneurs
Les conteneurs sont les lments fondamentaux de
l'architecture J2EE. Les conteneurs fournis par J2EE sont de
mme type. Ils fournissent une interface parfaitement
dfinie ainsi qu'un ensemble de services permettant aux
dveloppeurs d'applications de se concentrer sur la logique
mtier mettre en uvre pour rsoudre le problme qu'ils
ont traiter, sans qu'ils aient se proccuper de toute
l'infrastructure interne.
Les conteneurs s'occupent de toutes les tches fastidieuses
lies au dmarrage des services sur le serveur,
l'activation de la logique applicative, la gestion des
protocoles de communication intrinsque ainsi qu' la
libration des ressources utilises.
Les conteneurs
Les conteneurs
J2EE et la plate-forme Java disposent
de conteneurs pour les composants
Web et les composants mtiers. Ces
conteneurs possdent des interfaces
leur permettant de communiquer
avec
les
composants
qu'ils
hbergent.
Les
principaux
conteneurs J2EE sont notamment
ceux ddies aux EJB, aux JSP, aux
servlets et aux clients J2EE.
Exemple de servlet