Apache Tomcat6 Server Guide Administration

8/12/2019 Apache Tomcat6 Server Guide Administration

1/232


2/232

Ce livre sur Apache Tomcat 6 sadresse toute personne appele mettre en oeuvre ce serveur sous Windows ou Linux , que ce soitpour des besoins de test, de dveloppement, ou des besoins de production dans un environnement dentreprise.Aprs quelques rappels essentiels sur les technologies Internet et Java/Java EE , massivement utilises par Tomcat, le livre dtaille lesconcepts fondamentaux de la mise en oeuvre de Tomcat 6 et approfondit la mise en place d une vritable infrastructure dentreprisescurise et performante .Si le lecteur est familier dune version prcdente de Tomcat, il pourra approfondir ses connaissances en trouvant dans ces pages uneinformation prcise pour une mise en application immdiate .

Ce livre numrique a t conu et est diffus dans le respect des droits dauteur. Toutes les marques cites ont t dposes par leur diteur respectif. La loi du 11Mars 1957 nautorisant aux termes des alinas 2 et 3 de larticle 41, dune part, que les copies ou reproductions strictement rserves lusage priv du copiste et nondestines une utilisation collective , et, dautre part, que les analyses et les courtes citations dans un but dexemple et dillustration, toute reprsentation oureproduction intgrale, ou partielle, faite sans le consentement de lauteur ou de ses ayants droit ou ayant cause, est illicite (alina 1er de larticle 40). Cettereprsentation ou reproduction, par quelque procd que ce soit, constituerait donc une contrefaon sanctionne par les articles 425 et suivants du Code Pnal.

Copyright Editions ENI

Apache Tomcat 6Guide d'administration du serveur Java EE sous Windows et Linux

tienne LANGLET

Rsum

L'auteur

Etienne Langlet est formateur, consultant et dveloppeur sur les technologies Java/Java EE mais galement spcialiste des produitsOpenSource. Dans ce contexte, il a eu l occasion de mettre en oeuvre des serveurs Tomcat en environnement d'entreprise et proposeainsi au lecteur un ouvrage rellement oprationnel sur le sujet.

ENI Editions - All rigths reserved


3/232

Rappel sur les architectures Internet/Intranet/Extranet

Plus qu un simple moyen pour diffuser l information, l Internet permet aujourd hui de rendre accessible des applicationscompltes aux utilisateurs. L utilisation des technologies Internet dans un rseau d entreprise, l Intranet , permettant auxemploys d avoir accs aux applications, ou bien dans un rseau d entreprise partiellement ouvert destination departenaires, l Extranet .

Les architectures Internet, Intranet, et Extranet ont en commun d utiliser des technologies et protocoles decommunications communs, mais avec une ouverture diffrente. Ainsi, l Internet dsignant le rseau des rseaux, lesapplications sont diffuses un trs vaste public, au contraire, l Intranet qualifiant un rseau priv d entreprise, cestechnologies et protocoles sont utiliss pour servir les employs. Entre les deux, l Extranet, est une ouverture d un

Intranet d entreprise destination de partenaires bien dfinis.Parmi les technologies communes utilises, on trouve le langage HTML (HyperText Markup Language ) utilis pour concevoirles pages diffusant le contenu, et le protocole HTTP (HyperText Transfer Protocol ), ou encore HTTPS dans sa versionscurise, pour faire transiter l information entre le client, qui est en gnral un navigateur Web, et un serveur Web ouautre serveur capable de communiquer sur HTTP.

1. Le protocole HTTP

L change d informations sur Internet se fait principalement en utilisant le protocole HTTP , il permet la communicationentre le navigateur Web de l internaute et un serveur dans un format spcifique orient requte/rponse.

Une requte HTTP est une demande de ressource (une page HTML par exemple), mise par le client via son navigateur,en cliquant sur un lien, ou bien en saisissant l adresse d un site Web. La rponse HTTP cette demande contient laressource demande, ou bien une page d erreur dans le cas o cette ressource n existe pas, ou si son accs estprotg par exemple. Ces ressources sont accompagnes d un code d tat HTTP, permettant de savoir si la demande aabouti correctement, ou bien, dans le cas contraire, les raisons de l erreur.

Exemple : informations transmises dans la requte HTTP lors de la connexion d un navigateur l adresse

http://www.editions-eni.fr

GET / HTTP/1.1 Host: www.editions-eni.fr

Donnes reues par le navigateur :

HTTP/1.1 200 OK Date: Fri, 5 Oct 2007 22:03:31 GMT Server: Microsoft-IIS/6.0 Cache-Control: no-cache Pragma: no-cache Expires: -1 Content-Type: text/html; charset=utf-8

Content-Length: 81254

Editions ENI - Accueil ../..

Il y a trois parties dans cette rponse fournie par le serveur Web. D abord le code d tat HTTP retourn par ce serveursuite la requte, 200 OK dans l exemple ci -dessus, une section contenant ensuite les en - ttes HTTP, et enfin lesdonnes de la ressource demande (en gras).



4/232

La premire version pleinement exploitable du protocole HTTP fut la version 0.9, elle permettait un transfert de donnessimples. Puis par l ajout de la notion d en - tte, la version 1.0 peut ensuite permettre le transfert de donnesextrmement varies.

La version actuelle, la 1.1, a apport de nombreuses amliorations, notamment :

les connexions permanentes,

le support d un mcanisme de cryptage des connexions (via SSL ou TLS),

des mcanismes pour l identification des utilisateurs d un site,

des mthodes de transfert d informations supplmentaires,

l hbergement de multiples sites Web la mme adresse IP.

HTTP utilise la notion d URL (Uniform Resource Locator ) pour permettre la localisation d une ressource sur un serveurWeb. Les URL en HTTP ont la syntaxe suivante :

http://://

Dans cette URL, le port du serveur est facultatif s il vaut 80, de plus le chemin et le nom de la ressource doivent tresaisis en respectant la distinction majuscule/minuscule.

a. Les mthodes HTTP

Le protocole HTTP offre plusieurs possibilits pour grer le transfert des informations entre le client et le serveur,appeles mthodes HTTP . Les mthodes HTTP les plus communment utilises sont par exemple la mthode GET pour mettre une demande de ressource telle une page HTML, ou encore la mthode PUT pour transmettre desdonnes destination du serveur en utilisant un formulaire HTML.

Voici un rsum des diffrentes mthodes HTTP :

Toutes ces mthodes HTTP ne sont pas autorises dans la configuration par dfaut d un serveur Web, et ce pour desraisons videntes de scurit, de plus, la navigation sur Internet ne requiert rarement plus que les mthodes GET et

Mthode Description

GET

Demande d une ressource au serveur. C est lamthode utilise lorsqu un utilisateur clique sur le lien

d une page Web, ou bien entre l adresse d un siteWeb dans son navigateur.

POST

Envoi de donnes vers le serveur, plus prcisment,vers un programme hberg par ce serveur, et quisera capable de comprendre ces donnes pour lestraiter.

HEAD

Comme pour GET, elle permet de demander uneressource, mais la ressource n est pas envoye dansla rponse, cette mthode est utilise pour faire desvrifications d existence d une ressource, pour destests

PUT Permet d envoyer une ressource vers le serveur.

OPTIONSPermet de connatre toutes les options decommunication pour obtenir une ressourceparticulire.

DELETE Suppression d une ressource sur le serveur.

TRACE Mthode de contrle, elle demande au serveur derenvoyer la requte telle qu elle a t reue.

2 - ENI Editions - All rigths reserved


5/232

POST . Les mthodes PUT et DELETE sont quant elle trs pratiques pour un webmaster qui veut mettre son siteWeb jour.

b. Les codes d tat HTTP

Lorsqu un serveur rpond une requte HTTP, il renvoie, en plus des ressources de type page HTML et images, uncode d tat et des informations de contrle. Ces codes d tat permettent de connatre l issue de la conversation entrele client navigateur Web et le serveur.

Les codes de la plage 1xx sont des informations communiques au client concernant l tat d une requte. Ils sontrarement utiliss.

Les codes de la plage 2xx indiquent que la requte a t reue, comprise et accepte par le serveur.

Les codes de la plage 3xx indiquent que la ressource existe mais un emplacement diffrent de celui demand.

Les codes de la plage 4xx indiquent une erreur de la part du client. Par exemple, ci ce dernier demande une ressourcequi n existe pas sur le serveur, le code 404 lui sera renvoy.

Enfin, les codes de la plage 5xx indiquent une erreur de la part du serveur. Dans le cas o un programme tel qu unCGI, par exemple, rencontre une erreur lors de son excution.

Rsum des codes HTTP les plus courants :

c. Les en-ttes HTTP

Code Message Description

200 OK

La requte a t reue et traitecorrectement par le serveur, larponse est envoye dans lasuite.

301 Moved

La ressource demande a tdplace. La nouvelle adresse dela ressource est transmise auclient pour qu il puisse faire unenouvelle demande.

304 Not ModifiedLa ressource demande n a past modifie et peut donc treobtenue partir du cache.

304 Bad RequestLa syntaxe de la requte estincorrecte, ou cette requte nepeut pas tre satisfaite.

401 Unauthorized

La ressource demande ncessiteune autorisation pour treobtenue, le client doit reformulersa requte en incluant lesautorisations ncessaires.

403 Forbidden Le ressource demande n est pasautorise pour ce client.

404 Not Found La ressource ne peut pas tretrouve sur ce serveur.

500 Server ErrorLe serveur a rencontr une erreurpendant le traitement de cetterequte.

503 Service UnavailableLe serveur ne peut pas rpondre,c est le cas par exemple quand ilest trop sollicit.



6/232

Les en - ttes HTTP sont des informations de contrle transmises lors de la communication entre un navigateur Web etun serveur Web. Ils servent, par exemple, distinguer la langue prfre d un navigateur Web pour que le serveursoit en mesure de servir la page dans la langue adquate. Il convient de distinguer les en - ttes de requtes HTTP desen - ttes de rponses HTTP.

Pendant ces changes, il est courant que des serveurs ajoutent leurs propres en - ttes, c est notamment le cas desserveurs proxy, mais les en - ttes sont suffisamment paramtrables pour qu ils puissent tre galement modifis parles dveloppeurs d applications Web.

En - ttes de requte :

En - ttes de rponse :

En -tte HTTP Description

Accept Type de contenu accept par le navigateur (parexemple text/html ).

Accept -Encoding Codage de donnes accept par le navigateur.

Accept -Langua ge Langage attendu par le navigateur Web.

Content -Encoding Type de codage des donnes dans le corps de larequte.

Content -Type Type de contenu du corps de la requte (par exempletext/html).

Content -Length Taille des donnes transmises.

Cookie Utilis par le navigateur pour envoyer, dans larequte, un cookie vers le serveur.

Date Date de dbut de transfert des donnes, au formatGMT.

Referrer URL du lien partir duquel la requte a t effectue.

User -AgentChane donnant des informations sur le client, commele nom et la version du navigateur, du systmed exploitation.

En -tte HTTP Description

Content -Encoding Type de codage du corps de la rponse.

Content -Type Type de contenu du corps de la rponse (par exempletext/html).

Content -Length Taille des donnes transmises.

Date Date de dbut de transfert des donnes au format

GMT.

Expires Date limite de validit des donnes.

Location Redirection vers une nouvelle URL.

Server Caractristiques du serveur ayant envoy la rponse.

Set -Cookie Utilis par le serveur, dans la rponse, pour envoyerun cookie sur le navigateur.



7/232

d. Gestion des sessions utilisateurs : les cookies HTTP

Le protocole HTTP est qualifi de protocole sans tat , c est - -dire qu il est absolument incapable de permettre lemaintien d une conversation entre un client et un serveur, de ce fait, chaque couple requte/rponse est totalementindpendant du prcdent et du suivant.

Cette caractristique est assez gnante puisqu il n est pas possible de conserver des informations pour un client lorsde sa navigation.

Ainsi, un utilisateur naviguant sur un site de commerce lectronique, pourrait choisir d acheter un livre sur une page dusite Web, puis en cliquant sur un lien, c est - -dire en formulant une nouvelle requte, dcider d acheter un disque surcette nouvelle page. Le fonctionnement par dfaut du protocole HTTP, ferait que ce stade de la navigation, leserveur aurait dj oubli le livre !

Le protocole HTTP utilise donc un mcanisme supplmentaire pour rgler ce problme : il s agit des cookies HTTP . Lescookies HTTP, ou plus simplement cookies , sont des informations sur la navigation d un utilisateur, qu un serveur Webpeut ajouter dans la rponse qu il fournit, toutes les requtes suivantes de cet utilisateur vers ce serveur incluront lescookies que le navigateur dj reu.

Illustration du fonctionnement des cookies :

Les serveurs Web et autres serveurs d applications tels Tomcat 5, utilisent massivement cette technologie pourconserver des informations sur la navigation d un utilisateur sur un site ou une application.

2. Les serveurs Web

Sur Internet, le rle d un serveur Web est de rendre disponibles les diffrentes pages HTML qui composent un site, ainsique les ressources qu elles peuvent contenir comme par exemple des images, du son, de la vido.

Aujourd hui les serveurs Web les plus utiliss sont :

Apache HTTP Server de la fondation Apache,

Internet Information Server de Microsoft,

Sun ONE de Sun Microsystems, anciennement iPlanet de Netscape Corp.

Chacun de ces serveurs propose de nombreuses options de configuration et permettent d hberger de multiples siteset applications. De plus, les considrations de scurit tant d actualit, ils proposent galement des fonctionnalits descurit, notamment le support du protocole HTTP scuris : HTTPS.

3. Les technologies ct client

Les technologies ct client sont les technologies de dveloppement d application ou bien de sites Web utilises pour

concevoir l interface utilisateur et prendre en charge les diffrents vnements dclenchs par les utilisateurs.Trois types d applications clientes sont majoritairement utiliss :

Les clients lourds,

Les clients lgers,

Les clients riches.

Les clients lourds



8/232

Ce sont des clients proposant une interface graphique fentre telle qu une application de traitement de texte parexemple.

Les technologies utiliss sont variables et dpendent du langage de programmation dans lequel l application a tprogramme. Ce type d application prsente, en gnral, une interface riche en contrle et composants visuelles offrantune ergonomie maximale l utilisateur.

En plus de la partie interface utilisateur, ces applications intgrent galement une partie non ngligeable de la logiquede traitement, et peuvent s intgrer des ressources d un systme d information, tel qu un serveur de base dedonnes, par exemple.

Les technologies utilises sont, par exemple :

Les bibliothques de composants graphiques AWT et Swing en Java, MFC et ATL en langage C++ sousWindows,

Les bibliothques d accs aux bases de donnes JDBC pour Java, ADO et ODBC pour les technologies Microsoft.

Il s agit majoritairement de navigateurs Web utilisant les technologies Internet pour proposer une interface graphique l utilisateur. Ces applications sont en principe dveloppes en utilisant les langages de programmation comprhensiblespar un navigateur Web, mais galement d autres technologies moyennant l installation d extensions.

Ces diffrentes ressources sont rendues disponibles au client par un serveur Web avec lequel elles communiquentgrce au protocole HTTP. Les technologies de dveloppement de clients lgers sont aujourd hui trs souvent utilisesconjointement avec des technologies ct serveur permettant une gnration dynamique des interfaces utilisateurs.

Les clients lgers tirent leur nom du fait qu ils ne sont responsables que de la partie interface utilisateur, tous lestraitements de l application sont dports sur un serveur spcifique : un serveur Web, ou un serveur d application.

Ces applications utilisent les mmes technologies que pour le dveloppement des sites Internet :

HTML : le langage de prsentation des donnes.

JavaScript : pour ajouter de l interactivit et du dynamisme l interface.

CSS : pour crer des styles de prsentation rutilisables.

De plus, ces technologies nativement comprhensibles par un navigateur Web peuvent tre enrichies par d autres, quincessitent souvent des extensions sur le navigateur Web :

Applets Java : programmes graphiques Java embarqus dans les pages HTML, cette technologie requiert unenvironnement d excution Java sur le poste client.

ActiveX : technologie Microsoft semblable aux Applets, mais uniquement util isable avec le navigateur WebInternet Explorer.

Les clients riches sont un compromis entre les clients lourds et les clients lgers. L interface graphique de ce typed application est dveloppe en utilisant un langage de programmation spcifique qui leur confre une ergonomie aussiagrable que les clients lourds, quelques traitements basiques sont galement intgrs ces interfaces, mais lamajorit des traitements se font sur un serveur d application, comme pour les clients lgers. Ce nouveau typed application offre des perspectives intressantes, comme par exemple la possibilit d utiliser l interface client en modeconnect ou dconnect du serveur d application, trs pratique pour les utilisateurs nomades.

Ce type de dveloppement d application tant relativement rcent, les technologies permettant de les dvelopper sontassez peu nombreuses :

La plate -forme Microsoft .NET propose des solutions pour ce type d application,

L environnement Eclipse RCP (Rich Client Platform ), est une plate -forme Open Source utilisant les technologiesJava.

4. Les technologies ct serveur

Les clients lgers

Les clients riches



9/232

Les technologies ct serveur permettent le dveloppement des parties d une application qui vont raliser le plus grosdes traitements pour cette application. Les composants logiciels ainsi dvelopps, ont besoins d tre hbergs dans unenvironnement spcifique, permettant la connectivit avec les parties clientes de ces applications : c est le serveurd applications.

Ces technologies sont galement utilises pour dvelopper des composants capables de gnrer dynamiquement lesinterfaces graphiques des applications. Par opposition aux ressources statiques, telles que les pages HTML, cesressources sont dynamiques, puisque le contenu gnr l est dynamiquement, en fonction de l utilisateur par exemple.

Aujourd hui trois grandes technologies sortent du lot pour le dveloppement ct serveur :

La plate - forme Microsoft .NET qui permet le dveloppement de ressources dynamiques avec la technologieASP.NET , et les composants mtier en COM , DCOM , ou plus rcemment .NET remoting .

La technologie PHP , une plate - forme Open Source en pleine volution, notamment avec l apport dans ladernire version de l orient objet.

La plate -forme JEE , base sur le langage Java, qui propose les composants Servlet et JSP ( Java Server Pages )en tant que ressources dynamiques, et la technologie EJB (Enterprise JavaBeans ) et JavaBean pour lescomposants mtier. Une prsentation plus prcise de ces composants est propose dans le chapitre La Plate -forme JEE 5 de cet ouvrage, dans la mesure o certains d entre eux sont utiliss avec Tomcat.

5. Les architectures n/tiers

Les architectures de dveloppement ont normment volu avec le temps. La tendance actuelle du dveloppementd application met l accent sur la sparation des traitements afin de mieux matriser la complexit grandissante de cesapplications, et de permettre une volution plus facile.

Les architectures client/serveur proposaient des applications intgrant la totalit de la logique mtier et utilisant desserveurs de ressources et de donnes. La puissance du poste de travail de l utilisateur tait alors utilise.

Les architectures 3/tiers ont ensuite propos un modle de structuration permettant une sparation de l interfacegraphique utilisateur, de la logique de traitement de l application, et des serveurs hbergeant les donnes etressources utilises par ces applications.

Les avantages de ce type d architectures sont notables, notamment par rapport l ancien modle client serveur :

Les interfaces graphiques fonctionnant sur le poste client peuvent tre allges.

Le gros des traitements est ralis sur un serveur d application, et non plus sur le poste client;

La mise jour d un composant de traitement se fait sur le serveur et n impose aucune mise jour ct client.

Cependant, si la partie cliente est un client lourd, il faut installer cette application sur chacun des postes utilisateurs.

Exemple d architecture 3/tiers :



10/232

Les tendances du dveloppement d application se sont donc orientes vers un modle encore plus souple, utilisantmassivement les clients lgers et donc les technologies de l Internet : les architectures n/tiers .

Dans ces architectures, le bnfice apport par l inclusion d un serveur d applications pour les traitements est conserv,des serveurs Web sont ajouts pour prendre en charge les ressources Web statiques telles que les pages HTML et lesimages. Les serveurs d application vont galement hberger les ressources dynamiques.

Ce type d architecture permet une utilisation des traitements hbergs sur le serveur d application, aussi bien par lesclients lourds que par les clients lgers.

Exemple d architecture n/tiers :

Les technologies JEE abordes dans cet ouvrage et sur lesquelles reposent le serveur Tomcat prconisent l utilisationde ce type d architecture.



11/232

Tomcat et Java

1. La fondation Apache

Dvelopp dans les laboratoires du NCSA (National Center for Supercomputer Applications) par Rob McCool, le serveur Webhttpd est l un des tous premiers voir le jour. Aprs le dpart de Rob McCool du NCSA en 1994, le code source originaldu serveur httpd est repris par un groupe de dveloppeurs qui en corrigent les bugs. La premire version de cenouveau serveur Web est rendue disponible en Avril 1995 sous le nom d Apache. Aujourd hui Apache est disponiblepour un trs grand nombre de systmes d exploitation et c est le serveur Web le plus utilis au monde.

En 1999, les dveloppeurs l origine du serveur Apache fondent l Apache Software Foundation (ASF) . L ASF est uneorganisation but non - lucratif cre dans l objectif de promouvoir les logiciels libres, en aidant et sponsorisant denombreux projets. La liste de ces projets est disponible l adresse http://www.apache.org .

2. Le projet Jakarta

Un des projets de la fondation Apache est le projet Jakarta . Ce projet fdre un ensemble de sous -projets lis auxtechnologies Java. Jakarta divise ces projets en trois catgories :

Les serveurs d applications.

Les bibliothques, outils et API de dveloppement.

Les frameworks.

Tomcat appartient la premire de ces catgories.

Parmi les autres sous -projets de Jakarta, on peut galement citer :

JMeter : outil de test et de mesure des performances des applications Web.

Log4j : bibliothque de gestion des fichiers journaux (Fichiers logs).

Jetspeed : portail Internet/Intranet utilisant les technologies Java.

Struts : probablement le framework de dveloppement Web en Java le plus clbre.

POI : une API de programmation pour gnrer des documents Microsoft Excel en Java.

ANT : un outil pour automatiser la construction des applications Java.

Axis : une bibliothque pour le dveloppement de Web Services.

Geronimo : une implmentation complte de serveur d applications compatible JEE

Commons : un ensemble de bibliothques de programmation Java commune aux diffrents projets Jakarta.

3. Les volutions de Tomcat

Le projet Jakarta Tomcat trouve ses origines au tout dbut de l apparition des technologies Servlet et JSP ( JavaServerPages ), dont les concepts fondamentaux sont prsents au Chapitre La plate -forme JEE 5. Les Servlets et JSP sont descomposants logiciels crits en Java qui fonctionnent dans des serveurs Web spcifiques appels Conteneur Web oubien Moteur de Servlet. Le premier Conteneur Web, Java Web Server, a t cr par Sun Microsystems, l inventeur deces technologies. Paralllement, la fondation Apache, a de son ct cr JServ, un autre Conteneur Web utilis commeextension du serveur Web Apache.

En 1999, Sun Microsystems dcide de donner le code du Java Web Server la fondation Apache, ce dernier et le projet



12/232

JServ vont fusionner pour donner naissance au serveur Tomcat. Aujourd hui, Tomcat est, pour Sun Microsystems,l implmentation de rfrence des technologies Servlet et JSP.

En tant qu implmentation de rfrence de ces technologies, un des objectifs majeurs du serveur Tomcat estd tre compltement compatible avec les spcifications technologiques Servlet et JSP dites par Sun.

La premire version du serveur Tomcat est la version 3.x qui est l implmentation de rfrence des technologies Servlet2.2 et JSP 1.1. Cette version a t conue partir du code donn par Sun, et du moteur JServ.

En 2001, une refonte complte de la structure du serveur Tomcat donne naissance la version 4.x. Avec un nouveaumoteur de Servlet baptis Catalina, cette version est l implmentation de rfrence Servlet 2.3 et JSP 1.2.

La version 5 de Tomcat est l implmentation de rfrence Servlet 2.4 et JSP 2.0. Cette version a apport beaucoup denouveauts par rapport la prcdente, notamment au niveau du support de JMX ( Java Management Extension ) pour lemonitoring, ainsi que des optimisations diverses. La version particulire 5.5 intgre le support des nouveautsapparues avec la plate -forme Java 5.0.

La dernire version majeure de Tomcat (la version 6) est, quant elle, une implmentation des technologies Servlet 2.5et JSP 2.1, depuis ces versions, l implmentation de rfrence est le serveur Open -Source GlassFish dvelopp par Sun.

4. La plate-forme Java

a. Historique

En 1991, la socit Sun Microsystems dmarre un projet d informatique embarque : le projet, baptis Star 7 , vise permettre l utilisation de terminaux mobiles avec un systme d exploitation. Ces terminaux taient les anctres desactuelles PDA et PocketPC !

Les ingnieurs de Sun Microsystems sont habitus utiliser le langage C++ pour le dveloppement, et c est donc toutnaturellement vers ce langage qu ils vont s orienter pour le dveloppement du logiciel des terminaux.Malheureusement, l utilisation de ce langage se rvle inadapte pour ce type de projet, notamment cause de lagestion mmoire trs contraignante.

Dans le but de mener bien leur projet, les ingnieurs de Sun vont crer leur propre langage de programmation en sebasant sur C++, et en lui retirant tous ses aspects qu ils considrent comme gnant. Ainsi est n le langage Java, quis appellera dans un premier temps C++-- (un nom de laboratoire !), puis OAK , avant d tre baptis de son nomactuel.

En 1995, la premire version du kit de dveloppement logiciel en Java : le JDK ( Java Development Kit ), est renduedisponible. Cette premire version permet la ralisation d applications graphiques, d applications client/serveur, etd applets, ces dernires tant des programmes, en gnral graphiques, embarqus dans les pages HTML des sitesInternet, leur apportant des possibilits d ergonomie et d animation supplmentaires.

Une des principales caractristiques du langage Java, est de permettre la ralisation d applications portables entre lesarchitectures matrielles et logicielles, et ceci sans recompilation du code source Java.

La compilation du code source Java ne donne pas, comme c est le cas avec beaucoup d autres langages, unexcutable natif, mais un format de fichier spcifique, appel byte - code , et uniquement interprtable par une machinevirtuelle Java. Quelle que soit la plate - forme sur laquelle le code source a t compil, le byte - code gnr est lemme, il suffit simplement ensuite, d avoir une machine virtuelle Java dans son architecture pour pouvoir lancer leprogramme.

Cycle de conception d un programme Java :



13/232

b. Java aujourd hui

Aujourd hui la plate - forme Java est une des plates -formes de dveloppement logiciel les plus adoptes par lesentreprises, au vu de sa robustesse, de sa scurit trs prsente en natif, et de ses performances toujours plusintressantes.

La plate - forme Java se dcompose aujourd hui en trois plates - formes distinctes selon le type d application dvelopper.

La plate - forme JSE (Java Standard Edition) , offre une plate - forme de base pour le dveloppement d applicationsclient/serveur, applications graphiques fentres et applet. La plate - forme JSE est disponible sous deux formes,d abord le kit de dveloppement, le JDK, ncessaire pour tout dveloppement Java, et ensuite, le JRE (Java RuntimeEnvironment) , indispensable pour faire s excuter les applications Java.

Cette plate - forme constitue le noyau dur de Java, elle est constitue des lments suivants :

La Machine Virtuelle Java (JVM : Java Virtual Machine) : c est l environnement d excution des applicationsJava, elle constitue une passerelle entre les applications Java qui sont portables entre les architecturesmatrielles et logicielles, et les systmes d exploitation. Il existe des versions de machines virtuelles pour lamajorit des architectures matrielles et logicielles. Cette machine virtuelle est notamment responsable de lagestion mmoire des applications de sorte que le programmeur n ait pas s en occuper.

La bibliothque de classe Java : un ensemble de composants logiciels prts l emploi. Ces composants

permettent de couvrir les besoins de base du dveloppement Java comme par exemple la gestion des chanesde caractres, les fonctions mathmatiques, les composants d interfaces graphique, la communication rseau,etc.

Les outils de dveloppement (uniquement dans le JDK) : un compilateur de code source Java (javac) , uninterprteur (java) , un gnrateur de documentation (javadoc) .

Historiquement, la version 1.2 de cette plate - forme a marqu un tournant dans l utilisation du langage, avec l apportde nouvelles fonctionnalits, cette version, sortie en 1998, marque le dbut de Java 2 .

La version 1.5, publie en fin d anne 2004 a apport normment de nouvelles fonctionnalits, si bien qu elle estgalement appele Java 5.0, pour distinguer un peu plus cette nouvelle version.

La dernire version en date (sortie en dcembre 2006) est la version 1.6 ou Java 6.0 pour continuer la numrotation



14/232

de version dmarre avec Java 5. Elle apporte quelques nouveauts concernant le dveloppement des applications debureau. C est galement partir de cette version que le chiffre 2 disparat de l acronyme J2SE (Java 2 Standard Edition) ,utilis jusque - l.

La plate - forme JEE (Java Enterprise Edition) est une extension de la plate - forme JSE. Elle permet le dveloppementd applications d entreprise, c est - -dire des applications qui vont s excuter dans un contexte de serveurd applications . Les applications JEE peuvent tre exploites par des clients lgers, comme les navigateurs Web, oubien par des clients lourds, comme des applications graphiques fentres.

La dernire version de cette plate - forme est la version 5, et celle qui est supporte par la version 6 du serveur JakartaTomcat. Ici galement, le chiffre 2 disparat de l acronyme J2EE (Java 2 Enterprise Edition) utilis depuis le dbut del existence de cette plate -forme.

Le chapitre La plate -forme JEE 5 de cet ouvrage prsente plus en dtail les diffrents aspects de cette plate -forme.

La plate - forme JME ( Java Micro Edition ) permet le dveloppement d applications mobiles. Ces applications peuventfonctionner sur des priphriques de type tlphones mobiles, Pocket PC, Palm Pilot, etc. Un trs grand nombre defabricants de tlphones mobiles ont dj adopt cette technologie, et proposent une large gamme de produitscompatibles JME.

c. Java et Tomcat

Le serveur Jakarta Tomcat est, depuis ses premires versions, dvelopp en Java, cette plate - forme lui apportant tousses avantages en termes de robustesse, de performance, et de scurit. De plus, les applications hberges parTomcat sont elles -mmes crites en Java, l intgration est donc complte.

Les diffrentes versions de Tomcat ont su s adapter aux volutions apportes au langage, et toutes les versions de ceserveur sont encore disponibles au tlchargement, c est le cas notamment des anciennes versions 3.x qui sont les

seules compatibles avec les versions de Java antrieurs Java 2 . Aujourd hui, la version 6 de Tomcat sait tirer profit des amliorations apportes la plate - forme JSE, notamment enterme de performance.



15/232

La plate-forme Java Enterprise Edition (Java EE)

La plate -forme Java offre de trs nombreuses possibilits de dveloppement d applications. La plate -forme Java EE (JEE)est probablement la plus riche des plates -formes Java, en offrant un environnement standard de dveloppement etd excution d applications d entreprise multitiers.

La complexit des architectures informatiques d entreprise tant grandissante, les plate -formes de dveloppement desystmes informatiques ont d prendre en compte cette complexit pour l intgrer.

La plate -forme JEE fait partie de celles qui ont le mieux russi cette intgration, en offrant des possibilitsd interconnexion entre les systmes et les applications, auparavant inexistantes.

En tirant parti des avantages de Java, tels que l indpendance de la plate -forme, ou bien son orientation objet qui luiconfre une trs grande rutilisabilit, JEE simplifie la conception de systmes d entreprise, en fournissant :

Une infrastructure d excution pour hberger les applications ;

Des modles de composants pour dvelopper les applications, livrs sous forme de bibl iothques deprogrammation ;

Une plate -forme de service intgre par les infrastructures d excution, et utilise par les composants.

Un autre avantage non ngligeable de JEE, est que cette plate -forme est un standard, ce qui signifie que, bien que lesproduits estampills compatible JEE soient relativement nombreux, ils respectent tous les standards de cette plate -forme, et peuvent donc tre utiliss pour hberger les applications qui, elles aussi, ont t dveloppes en respectantces standards.

Cet ouvrage ne traite pas du dveloppement d applications JEE, mais il est ncessaire de prsenter les fondements decette plate -forme dans la mesure o Tomcat 6 repose entirement sur cette plate -forme, et que les applicationshberges par ce serveur sont dveloppes avec les bibliothques JEE.

1. Le Java Community Process (JCP)

Le fait que la plate -forme Java soit une plate -forme standard a contribu son adoption par de trs nombreux diteursde logiciels. En plus de l adoption de ces standards, certains d entre eux participent galement l laboration de cestechnologies. Ces diteurs associs Sun Microsystems font partie du JCP : Le Java Community Process .

Le Java Community Process regroupe des entreprises du monde informatique aussi prestigieuses que Sun , IBM ,Oracle , Borland , BEA , Nokia , Sony , mais galement des acteurs du logiciel libre comme la fondation Apache ou leconsortium ObjectWeb . Son objectif est de dfinir les spcifications des nouvelles technologies autour de Java, cesnouveauts peuvent concerner toutes les plates -formes Java.

Les demandes de modification ou de cration de nouvelles spcifications sont appeles JSR ( Java Specification Request ),et sont numrotes avant d tre baptises. Ainsi, la nouvelle API JavaServer Faces s est d abord appele JSR 127 .

Le processus d tablissement d une JSR se droule de la faon suivante :

D abord, pendant l initialisation du projet, sont dfinis les membres participant cette nouvelle spcification,une description et une justification du projet, ainsi qu un planning prvisionnel.

Ensuite, un groupe d experts chargs de faire une premire bauche de la spcification ( Early Draft ), estconstitu. Ces experts sont des spcialistes employs par les socits membres du JCP. La premire version dela spcification est soumise la communaut Java et au comit de validation du JCP, le JCP Executive Comitee .

L accueil fait la spcification dtermine les modifications apporter au travail des experts, pour finalementconduire sa version finale ( Final Release ). La spcification est rendue publique, de mme qu uneimplmentation de rfrence fournie par le groupe d experts.

Enfin, un expert est nomm, il est charg de la maintenance de la spcification ( Maintenance Release ).

Les informations sur le travail en cours du JCP et l tat d avancement des nouvelles spcifications sont consultables surhttp://www.jcp.org.

2. Une forte dpendance : Java 5 et les annotations



16/232

La version 5 de la plate -forme JSE (et donc du langage Java) a introduit beaucoup de nouveauts dans la manire deprogrammer avec ce langage. Parmi toutes ces innovations, l une d elles a laiss sceptique plus d un dveloppeur Java,il s agit des annotations.

Les annotations sont des mta -donnes introduites dans le code, ces mta -donnes doivent tre interprtes par unprogramme Java spcifique pour pouvoir donner un rsultat concret. Dans la plate -forme Java 5, les annotationsfournies tait trs peu nombreuses, il est clair que Sun Microsystems cherchait, ce moment -l, prparer le terrainpour JEE 5.

Les annotations rvolutionnent compltement le dveloppement d applications d entreprise Java, et plusparticulirement le dveloppement d applications EJB et de Web Services. En effet, le reproche assez frquemment fait ce type d applications est que le dveloppeur devait fournit beaucoup d informations techniques n ayant aucune

valeur ajoute pour son application. Les annotations vont permettre de gnrer automatiquement ces donnestechniques au moment du dploiement des applications dans le serveur, puisque ces serveurs intgrent lesprogrammes capables d interprter ces annotations.

Avec JEE 5, les annotations sont principalement utilises pour :

Les applications bases sur JPA.

Les applications EJB.

Les applications de Services Web.

Elles peuvent galement tre utilises dans des applications clientes (Web ou client lourd Java), qui ont desdpendances avec ces types d applications.

Exemple d utilisation d une annotation pour crer un Service Web :

package fr.eni.editions.jee5.ws;

import javax.jws.WebMethod; import javax.jws.WebService;

@WebService public class MonServiceWeb {

@WebMethod(name="addition") public int op_Addition(int a, int b) {

return a + b;

}

}

Dans l exemple ci -dessus, l annotation @WebService est utilise pour dclarer que cette classe Java doit tre dclarecomme un Service Web, et l annotation @WebMethod pour dclarer que la fonction op_Addition() de cette classe doit treexpose sous le nom addition .

Cette syntaxe vite l criture de fichiers de configuration trs complexes, comme c tait le cas dans les versionsprcdentes de la plate -forme JEE.



17/232

Les composants Java EE

Le modle de dveloppement d applications JEE prconis par Sun Microsystems fait intervenir trois types de composantslogiciels. L objectif est de mieux sparer les traitements et donc les responsabilits de chacun de ces composants dansl application. Avec un tel dcoupage, l quipe de dveloppement peut mieux structurer et modliser son application avecde commencer le codage, de plus, l application est plus facilement maintenable.

1. Servlet

Les servlets sont des composants logiciels entirement crits en Java, ce ne sont pas des programmes autonomes, etelles doivent tre hberges dans un serveur d application pour pouvoir tre appeles.

Les servlets sont des composants orients requte/rponse, c est - -dire qu une servlet s excute suite une requte,en gnral http, et fournit une rponse cette requte, ce fonctionnement est donc trs proche de celui d un serveurWeb.

Une servlet possde des caractristiques intressantes, comme elle est crite en Java, elle est portable et volutive,mais elle est galement trs performante car elle est charge en mmoire lors de son premier appel, et en seradcharge l arrt de l application ou du serveur d applications. De plus, il n y a toujours qu une seule instance d uneservlet en mmoire, le serveur d applications utilisant un thread pour traiter chaque requte mise par les clients.

Une servlet tant avant toute chose une classe Java, cette classe doit tre charge puis interprte par une machine

virtuelle Java, en l occurrence ici, celle du serveur d application. Ensuite, le serveur va initialiser la servlet pour lui fairecharger des informations de configuration, par exemple, la servlet est maintenant prte recevoir des requtes et renvoyer des rponses. Lorsque l application ou le serveur s arrte, la servlet est dtruite, puis son instance estnettoye par la machine virtuelle Java.

Cycle de vie d une servlet :

Le rle d une servlet dans une application JEE, est de recevoir les requtes des clients, ainsi que d en extraire lesinformations, ces informations une fois ventuellement formates, pourront tre utilises pour appeler les traitements.La servlet est aussi responsable de la prparation des donnes ncessaires la gnration de la rponse, sansncessairement fournir cette rponse au client.

2. Java Server Pages : JSP

La technologie Java Server Pages permet le dveloppement de pages Web dynamiques. D un point de vue de sastructure, une page JSP est trs proche d une page PHP ou bien ASP, si ce n est que le langage utilis pour la partiedynamique n est pas le mme. Une page JSP est un fichier qui porte l extension .jsp .

Une page JSP est constitue d un squelette de code HTML pour la partie statique, et de code Java pour permettrel intgration de donnes obtenues en rsultat des traitements. La structure d une JSP est donc htrogne, et elledevra tre traite par le serveur d application avant d tre envoye dans la rponse au client.

Ce traitement est ralis par le serveur d applications au premier appel de la page et chaque fois que cette page estmodifie par un programmeur. Un serveur d applications transforme une JSP en classe Java, puis la compile en servlet,

Cycle de vie dune servlet



18/232

c est ensuite l excution de cette servlet particulire qui provoquera la gnration de la rponse. Chaque autre requtevers cette JSP est en fait directement prise en charge par la servlet gnre.

C est cette tape particulire du cycle de vie d une JSP qui fait qu un serveur d applications JEE a besoin d uncompilateur Java, et que par consquent, une grande majorit d entre eux ncessite une installation de Java fournie parun JDK plutt que par un JRE.

Cycle de vie d une JSP :

La transformation est assure par un outil interne du serveur d applications, la compilation par un compilateur Java, commecelui du JDK : javac .

Le rle d une JSP dans une application JEE est de prendre en charge la partie visuelle de cette application en prsentantles donnes au client.

3. Enterprise JavaBeans : EJB

Les composants Enterprise JavaBeans sont des composants mtier distribus, c est - -dire qu ils sont invocables par lerseau. Les EJB sont trs grande valeur ajoute car ils prennent en charge les transactions, la scurit, et sontnaturellement amens tre rparti sur des fermes de serveurs.

Il existe deux types d EJB :

Les EJB session : ils encapsulent l ensemble des fonctionnalits mtier ncessaires l application, ils peuvent,selon leurs configurations, maintenir ou non des informations sur les clients et les traitements qu ils ralisent (ilssont dit avec ou sans tat).

Les EJB pilot par message : appel galement MDB (Message Driven -Bean ), ils sont comparables aux EJBsessions, mais sont invoqus diffremment. Les EJB session sont directement exploits par des appels defonctionnalits sur ces composants. Par contre, pour dclencher un traitement sur un EJB MDB, il faut aucontraire, lui envoyer un message applicatif en utilisant l API JMS (Java Message Service), prsente plus loin.

Cette nouvelle version de la plate - forme JEE a vu disparatre les EJB entit . Un EJB entit est un composant persistant,c est - -dire que son tat est sauvegard et restaur dans une base de donnes. Ils matrialisent les donnesncessaires l application, et sont en gnral appels par les EJB sessions. Les EJB entit sont aujourd hui remplacs

par la nouvelle API de persistance Java : Java Persistence API (JPA).Le rle d un EJB dans une application JEE est donc variable en fonction de son type. Les diffrents types d EJB sont engnral utiliss conjointement dans une mme application.

Les EJB sont hbergs dans une partie spcifique d un serveur d application JEE. Le serveur Tomcat 6 ne dispose pas decet environnement spcifique, il est donc impossible d utiliser des EJB avec Tomcat 6. Cependant, les technologies Javaproposent de trs nombreuses alternatives aux EJB qui sont d ailleurs moins coteuses en temps de dveloppement, etsurtout moins complexes, que les EJB.

4. Les entits Java

Les entits Java sont des objets persistants, c est - -dire que leur tat est sauvegard dans une base de donnes



19/232

relationnelle. Les entits Java sont cres avec l API de persistance Java JPA . Cette nouvelle API apporte plus desouplesse que les EJB entits prcdemment utilises, car elle est exploitable dans des applications non -JEE. Lesentits Java n ont pas besoin d tre installes dans un serveur d applications.

L API JPA utilise les annotations pour indiquer les caractristiques de persistance des objets, notamment l associationclasse vers table et les associations entre les proprits de la classe et les colonnes de la table, c est du mappageObjet/Relationnel .

Une caractristique intressante de JPA est de fournir une abstraction par rapport la base de donnes utilise, parconfiguration, le dveloppeur prcise les donnes de connectivit cette base sans que ses caractristiques propressoient utilises dans le code.

JPA est dfinie par Sun Microsystems sous forme d une spcification technique que des diteurs peuvent utiliser pourfournir des implmentations de cette API. Les principales implmentations actuelles sont :

Hibernate : initialement un projet Open Source, aujourd hui rattach la socit JBoss,

TopLink : un produit de l diteur Oracle,

OpenJPA : projet Open Source de la fondation Apache.



20/232

La plate-forme de service

Les applications JEE ont des besoins d accs aux diffrents lments du systme d information, c est notamment le casdes composants EJB entit prcdemment prsents, qui doivent accder une base de donnes pour y enregistrerleurs informations. Un trs grand nombre de services sont proposs par la plate -forme JEE, ces services permettentl intgration aux sources de donnes, et sont rendus accessibles aux applications par le serveur d applications.

1. JDBC : Java DataBase Connectivity

JDBC permet aux programmes Java d accder aux bases de donnes. Cette API de programmation possde laparticularit de permettre un dveloppement sans se soucier du type de la base de donnes utilise : elle utilise poura, un pilote d accs la base de donnes.

JDBC est disponible pour la plate-forme de base Java : JSE. JEE rajoute une extension JDBC pour l intgration de cetteAPI en tant que service d un serveur d applications.

La Java Persistence API utilise JDBC de manire transparente pour crire l tat des entits persistantes dans une basede donnes.

2. JNDI : Java Naming & Directory Interface

Le rle de l API JNDI dans JEE est double.

D abord, elle permet l accs aux services d annuaire d entreprise utilis, par exemple, pour authentifier les utilisateurs.Elle utilise pour cette tche, un mcanisme de pilote semblable JDBC, lui permettant ainsi d utiliser les diffrents typesd annuaire.

JNDI permet galement d implmenter un service de nommage. L ensemble des ressources que le serveur d applicationmet disposition via ces API de services, doit tre enregistr avec un nom logique, permettant aux applications derechercher cette ressource dans le serveur : c est le deuxime rle de JNDI.

3. JMS : Java Message Service

Lors de l appel d une fonctionnalit sur un composant par un autre, le composant qui a appel cette fonction est bloquet en attente d une rponse de la part du composant appel : ce type d invocation est dit synchrone. Pour viter cesinter -blocages, il est possible d utiliser un mcanisme d invocation asynchrone , par l envoi de messages applicatifs entreles composants : c est le rle de JMS.Le composant appelant poste un message destination d une file d attente de messages, hberge par le serveurd applications, puis continue son traitement, sans attendre. Le composant appel est abonn cette file d attente, ettraite le message qui ordonne un traitement particulier.

4. JavaMail

JavaMail permet la cration et l envoi de message lectronique via Java. Cette API permet d utiliser les protocolesstandards de messagerie Internet : POP3, IMAP4, SMTP. Un serveur d application JEE peut exposer une configurationd accs un serveur de messagerie lectronique, pour qu une application utilisant JavaMail puisse envoyer un message.

5. JTA : Java Transaction API

Lors de l accs une base de donnes, une application peut avoir besoin d utiliser une transaction . Le principe consiste considrer un ensemble d oprations comme une seule.

Par exemple, une application bancaire qui ralise un virement entre deux comptes va d abord dbiter le premier compte,puis crditer le deuxime. Il est indispensable de raliser ces deux oprations dans une transaction, ainsi si le dbitpuis le crdit aboutissent tous les deux sans problme, alors la transaction est valide, dans le cas contraire, on annuletout, et les comptes reprennent leur solde initial.

partir du moment o la mme base de donne est utilise pour stocker toutes les informations utilises dans unetransaction, l API JDBC prsente prcdemment, permet de grer la transaction, mais si les donnes sont rparties, ilfaudra alors utiliser les transactions de JTA.



21/232

JTA permet de grer les transactions dites distribues, c est - -dire qu elles font intervenir des bases de donnesdiffrentes, ou des composants EJB diffrents.

L utilisation de JTA ncessite un environnement d excution pour les EJB.

6. RMI/IIOP : Remote Method Invocation/Internet InterORB Protocol

RMI est une API Java qui permet l appel de fonctionnalit distance, en utilisant une communication rseau. RMI faitpartie de la plate -forme JSE. RMI/IIOP est une extension utilise pour la construction des EJB sessions et entits,compatible avec d autres mcanismes comparables dans d autres technologies.

7. JCA : JEE Connector Architecture

Un connecteur JEE permet d utiliser une ressource du systme d information qui ne possde pas d interface nativeJava/JEE. Les gros systmes informatiques tels les mainframes, sont utilisables par les applications JEE en ayant recours un connecteur spcifique ces systmes.

8. XML

XML n est pas une API de service JEE, mais son utilisation dans cette plate -forme est de plus en plus importante.D abord utilis pour crire les diffrents fichiers de configuration, XML est la base d un nouveau mode de

communication entre les applications : les Web Services.Les Web Services sont des composants logiciels qui sont invocables par d autres composants mme si ces derniers ontt dvelopp en utilisant un langage de programmation diffrent, ou s ils fonctionnent sur un systme d exploitationdiffrent.

La version 5 de Java EE apporte un support standard des Web Services avec une nouvelle API : JAX-WS ( Java API for XML Web Services ).

Un grand nombre d API pour le traitement XML sont prsentes dans JEE, par exemple JAXP ( Java API for XML Parsing ),pour l analyse des fichiers XML, etJAXB ( Java Architecture for XML Binding ) pour associer des donnes XML des classesJava, et ainsi faciliter la manipulation de ces donnes.



22/232

Les applications JEE

La plate -forme JEE apporte un certain nombre de standards pour le dveloppement des applications Java enenvironnement serveur et apporte d autres services. En plus de fournir un modle de composants, JEE standardisegalement la manire dont ces composants doivent tre assembls avant de pouvoir tre installs dans un serveur JEE.

Les phases dcrites par JEE pendant le cycle de conception d applications sont :

Le dveloppement des composants applicatifs : cette phase correspond la modlisation puis au codage individuel desdiffrents composants logiciels.

L assemblage des composants en modules : les diffrents types de co mposants sont assembls en modules dedploiement spcifiques. Ainsi les servlets et JSP sont assembls dans des modules Web , et les EJB dans des modulesEJB . Des fichiers de configuration sont ajouts.

L assemblage des modules en applications : pour simplifier la livraison d une application, les diffrents modules sontregroups en une seule et unique archive de dploiement.

Le dploiement de l application : en utilisant les outils spcifiques du serveur d applications, l application est installedans le serveur. Ces outils trs diffrents ont en commun de pouvoir lire ces formats d applications et de modulesstandards pour raliser l installation.

1. Le modle de dveloppement MVC

L architecture de dveloppement MVC (Model View Controller ) ou encore modle MVC , trouve ses origines avec lelangage SmallTalk au dbut des annes 1980, ce n est donc pas un concept nouveau spcifiquement li audveloppement JEE. Son objectif principal est d apporter une sparation de la logique mtier et de la logiqued affichage, et pour ce faire, elle divise l application en trois parties distinctes : le modle , la vue et enfin le contrleur .

Appliqu aux technologies JEE, le modle MVC trouve un type de composant par rle remplir : le modle estreprsent par les composants EJB, le contrleur par les servlets, et la vue par les JSP.

Collaboration dans le modle MVC :

1. Le client met une requte HTTP destination de l application, c est en gnral une servlet qui reoit la requte et qui enextrait les informations.

2. Les informations sont utilises pour appeler les traitements mtier.

3. Les composants du modle manipulent les donnes du systme d information (lecture, enregistrement, mise jour, ).

4. Les traitements mtier retournent les donnes rsultats la servlet, qui stocke ces donnes pour les rendre accessible aux JSP.

5. La servlet appelle la JSP adquate.

6. La JSP s excute, inclut les donnes transmises par la servlet, et gnre la rponse au client.

L utilisation du modle MVC pour le dveloppement des applications JEE est une prconisation de Sun Microsystems, etl utiliser apporte un certain nombre d avantages.

D abord, les responsabilits tant clairement dfinies au sein de l application, les composants sont plus nombreux, maisgalement plus simples, leurs spcificits font qu ils peuvent tre dvelopps par des spcialistes, les servlets et EJBpar des dveloppeurs Java, les JSP par des webdesigners.

Ce dcoupage permet galement une maintenance plus aise de l application, ainsi un changement de charte



23/232

graphique, ou encore de logo par l entreprise, n aura un impact que sur la partie vue, le modle et le contrleur nesubiront en rien ces changements.

Pour simplifier et systmatiser l utilisation de MVC dans les architectures JEE, des frameworks de dveloppemententirement bas sur ce modle MVC, tel Apache Struts ou encore la nouvelle API Java Server Faces , ont vu le jour.

2. Les diffrents modules JEE

Les applications JEE sont des applications multitiers qui offrent de multiples possibilits d intgration avec les ressourcesd un systme d information, et de ralisations d interfaces graphiques utilisateurs. Les traitements peuvent tre raliss partir de donnes provenant de base de donnes ou bien de mainframes, et ces mmes donnes peuvent treprsentes sur une interface graphique de type client lourd ou bien un navigateur Web.

Il est donc ncessaire d organiser les diffrents lments de code d une application en fonction de leur rle, desmodules pour les interfaces Web, d autres pour les interfaces graphiques client lourds, etc.

Le regroupement de ces ressources se fait dans des modules appels modules de dploiement JEE . Un module n est niplus ni moins qu une archive au format ZIP incluant les diffrentes ressources, mais avec une extension particulire.

a. Modules Web

Un module web contient les lments d une application JEE qui vont permettre l utilisation de cette application autravers d un navigateur Web et du protocole HTTP.

Les lments intgrs dans un module web sont les servlets et les JSP : ce sont les ressources dynamiques del application, mais il est galement courant d y trouver les ressources statiques telles que les pages HTML, fichiers descripts, les images et autre contenu multimdia. De plus, les ressources dynamiques tant dveloppes en Java, ontrouve galement des bibliothques de classes Java supplmentaire, fournies sous forme de fichier .jar .

Les modules web possdent un descripteur de dploiement : le fichier web.xml , et sont assembls dans un fichierd extension .war , signifiant Web ARchive . C est ce type d archive que Tomcat 6 sera amen manipuler.

b. Modules EJB

Les composants EJB sont constitus d une multitude de fichiers de code Java, mais galement de fichiers deconfiguration. L objectif des modules EJB est de fournir une archive homogne pour la livraison et le dploiement deces composants.

Un module EJB possde la particularit de ne pas tre directement exploitable par le serveur d application. En effet, lescomposants EJB doivent intgrer un certain nombre de fichiers de code Java spcifique au serveur d applications. Dans

l objectif de dvelopper des applications standards JEE, ces fichiers de code spcifiques ne sont pas fournis par ledveloppeur, mais sont gnrs automatiquement par les outils du serveur d applications au moment du dploiement.

Pour permettre cette gnration de code, il est tout de mme ncessaire de fournir des fichiers de configurationsupplmentaires propres au serveur d applications utilis.

Le descripteur de dploiement d un module EJB est le fichier ejb-jar.xml , et ces modules sont assembls en archived extension .jar .

c. Modules Client

Les modules EJB prcdemment prsents permettent l intgration des traitements et des donnes mtier, ceslments peuvent tre exploits par les modules web pour afficher les donnes sur un navigateur, mais il estgalement possible d utiliser les EJB au travers d une interface graphique client lourd dveloppe en utilisant les APIde programmation Java AWT ou SWING . Ces classes devront ensuite tre assembles dans un module JEE pourpouvoir interagir avec le serveur d applications.Un module client permet l assemblage de ce type de classes, et doit fournir un descripteur de dploiement dans lefichier application - client.xml . Un module client est un fichier d archive portant l extension .jar .

d. Modules de connecteurs

Les ressources d un systme d information telles que les bases de donnes ou bien les services d annuaires, sontintgrables dans les applications JEE grce aux API JDBC et JNDI.

L API JCA prsente prcdemment dans ce chapitre permet l intgration de systmes ne disposant pas depasserelles d intgration avec Java, en proposant une API standard pour dvelopper ces passerelles. Les modules deconnecteur permettent ensuite d assembler ces lments de code.



24/232

Le descripteur de dploiement de ce type de module est un fichier nomm ra.xml , le module est un fichier d archive quiporte l extension .rar .

3. Structure et packaging des applications

Chaque module de dploiement JEE inclut un fichier de configuration spcifique au format XML, appel descripteur dedploiement.

Le rle d un descripteur de dploiement est de rfrencer et de configurer les diffrents composants de ce module, parexemple, le descripteur de dploiement web.xml d un module web dcrit toutes les servlets ainsi que la manire dontelles seront appeles par les clients. L application d entreprise JEE, qui contient tous les modules, possde elle aussi undescripteur de dploiement qui rfrence tous les modules de cette application.

Lors de l installation d une application dans le serveur, les outils d installation des applications lisent les descripteurs dedploiement pour savoir comment installer l application et ses modules.

Structure des modules de dploiement et des applications JEE :

Chacun des modules de dploiement est galement installable de manire autonome, sans avoir t intgr dans unfichier .ear d application JEE, un serveur d application JEE peut directement utiliser un fichier .war , par exemple.



25/232

Les applications Web JEE et Tomcat

Parmi tous ces types de modules, les modules web sont les seuls exploitables par un serveur Tomcat 6, les applicationsTomcat 6 sont donc fournies sous forme de fichiers .war autonomes : les applications web .

Ces applications Web peuvent contenir des classes Java pour la gestion des traitements mtiers, ainsi que des classesd entits Java pour la gestion de la persistance.

L ouvrage se contente uniquement de dtailler la structure des modules web dans la mesure o un administrateurde serveur Tomcat 6 a la responsabilit d installer ce type de module. Pour en savoir plus sur les autres modules, il

faut consulter un ouvrage spcifique sur le sujet, ou bien le site web de Sun Microsystems sur les technologies JEE :http://java.sun.com/jee, qui propose un excellent tutoriel sur le sujet.

1. Structure et arborescence d une application Web

L arborescence d une application Web est trs particulire, et doit tre respecte, dans le cas contraire, uneapplication, mme trs bien programme, peut ne pas fonctionner correctement, voire ne pas s installer du tout dans leserveur.

L arborescence d une application Web est constitue d un rpertoire spcifique appel WEB- INF/ et qui contientnotamment les classes Java sous WEB-INF/classes , les librairies de code Java sous WEB- INF/lib , et le descripteur dedploiement web.xml de l application. Ce rpertoire est la partie prive de l application, il n est pas visible d un point devue de l utilisateur final, ainsi un utilisateur ne pourra jamais tlcharger le descripteur de dploiement par exemple.

Tout ce qui se trouve en dehors du rpertoire WEB- INF/ constitue la partie publique de l application, les ressourcessont accessibles. La partie publique contient les diffrentes pages HTML et JSP, mais aussi toutes les ressourcesmultimdia comme les images.

Exemple d arborescence d application Web :

noter que cette arborescence montre une application finalise, et que l emplacement du code source Java n apparat pas ici.

Chaque application Web dploye dans un serveur d applications est accessible via une URL unique. Cette URL estconstitue du nom d hte et du numro de port du serveur d applications, ainsi que d une partie faisant rfrence une application web particulire : c est le chemin du contexte d application web . Lors du dploiement d une applicationdans un serveur, le dployeur d application est responsable de l attribution d un chemin de contexte unique pourchaque module Web.



26/232

Le contexte d application Web reprsente la vue complte de l application web commune tous les clients, cette vueglobale permet de faire rfrence des donnes de configuration communes tous les utilisateurs, par exemple.

Format des URL d accs aux applications Web :

http://:/ c o n t e x t e

2. Le descripteur de dploiement : web.xml

Le descripteur de dploiement d une application Web contient plusieurs types d informations, son objectif est d orienterle serveur d application sur l installation de l application.

Les principales informations que l on y trouve sont :

Des paramtres d initialisation pour l application et/ou les servlets : ce sont des informations de type texte que lesservlets et JSP de l application peuvent consulter. Ces informations peuvent, par exemple, permettre de spcifierl adresse email de l administrateur du site ou de l application, sans avoir l crire en dur dans le code, permettant ainsiune modification plus aise de cette adresse.

La dfinition des servlets et des JSP : chaque servlet d une application Web JEE doit tre dclare dans le fichierweb.xml pour tre accessible. Il est galement possible de dclarer les pages JSP si elles ont besoin de paramtresd initialisation particuliers.

La mise en correspondance des servlets avec des URL : les classes Java de servlets tant stockes dans la partieprive de l application web ( WEB-INF/classes ), il est indispensable que le serveur d application associe des URLentrantes chacune des servlets de l application. Cette association se fait aprs avoir dfini chaque servlet (voir ci -

dessus).Les pages d accueil et d erreur de l application : lorsqu un utilisateur fait rfrence la racine de l application, ildemande la page d accueil, cette page peut tre dfinie par une directive du fichier web.xml . De plus, il est possibled associer les diffrents codes d tat HTTP et erreurs applicatives, des pages spcifiques, comme le code d erreurHTTP 404 par exemple.

Des contraintes de scurit : certaines parties d une application Web JEE peuvent tre restreintes certainsutilisateurs. Les directives de configuration utilises dans le descripteur de dploiement, permettent de spcifier quels utilisateurs ces ressources sont rserves, et comment ces utilisateurs particuliers vont s identifier surl application. Le chapitre sur la scurit expose plus en dtail ces mcanismes.

Exemple de fichier web.xml :

Demo

auteur Etienne LANGLET

FormulaireServlet

fr.eni.editions.demo.servlet.FormulaireServlet

configuration DEV

AutreServlet

fr.eni.editions.demo.servlet.AutreServlet



27/232

FormulaireServlet /form

AutreServlet /autre

formulaire.html

Voici en dtail, l explication des diffrentes parties de ce fichier.

Un descripteur de dploiement est un fichier XML qui est valid par rapport une grammaire particulire. Cettegrammaire peut tre dfinie dans deux types de fichiers pour la validation, les DTD (Document Type Definition) et lesSchmas XML (Fichier .xsd ), les schmas XML permettent une validation plus fine et sont utiliss depuis J2EE 1.4. L en -tte de ce fichier contient donc la rfrence au schma XML utilis, crit dans le premier lment de configuration XML :l lment racine .

Il y a ensuite un lment permettant de donner un titre l application.

Demo

Des paramtres d initialisation peuvent tre spcifis et rcuprs par programmation dans toutes les servlets et JSPde l application. Le programmeur utilise le nom du paramtre pour rcuprer la valeur associe.

auteur Etienne LANGLET

Chaque servlet doit ensuite tre dclare en mettant en correspondance un nom logique avec la classe Java de cetteservlet. Cette dclaration peut galement faire mention de paramtres d initialisation spcifiques chaque servlet.

FormulaireServlet

fr.eni.editions.demo.servlet.FormulaireServlet

configuration

DEV

AutreServlet

fr.eni.editions.demo.servlet.AutreServlet

Pour tre accessible, chaque servlet prcdemment dclare doit tre associe une URL.



28/232

FormulaireServlet /form

AutreServlet /autre

Enfin, la page d accueil par dfaut de l application est rfrence, et le document se termine par la balise de fin del lment racine.

formulaire.html

Lors du dmarrage d une application par Tomcat 6, le serveur analyse le fichier web.xml et le valide partir du schmaXML, si la syntaxe du fichier ne correspond pas au schma, alors l application ne sera pas dmarre et ne sera doncpas disponible.

3. Les sessions HTTP

Une des problmatiques voques dans le chapitre Prambule, est l incapacit du protocole HTTP grer lui -mme lesuivi de la navigation d un client sur un site ou une application Web. Ainsi chaque requte mise par un client, estcompltement indpendante de la suivante et de la prcdente. Pour combler ce manque, le protocole HTTP peuts appuyer sur le mcanisme des cookies, qui consiste envoyer des informations vers le navigateur client, en lesinsrant dans la rponse.

Cependant, cette solution prsente de nombreux inconvnients lis la structure mme des cookies :

Les informations transmises sont de type texte : Il est impossible d envoyer une structure de donnes, tel unpanier d achat, vers le client.

Les cookies sont limits en quantits : 20 cookies maximum par site, 300 en tout dans le navigateur.

Les cookies sont limits en taille : 4 kilo -octets de donnes maximum.

De plus, le client peut compltement interdire les cookies sur son navigateur Web.Il existe une alternative aux cookies utilisable dans les applications Web JEE, il s agit des sessions HTTP .

Le principe des sessions HTTP est extrmement sduisant car les informations relatives un client sont cette fois -cistockes sur le serveur, ainsi, pour reprendre l exemple du panier d achat sur un site marchand, le contenu de cepanier peut tre facilement reprsent par une structure de donnes complexe stocke sur le serveur d application.

Mais alors, comment le serveur fait - il la correspondance entre ces donnes de session qu il conserve, et le client auquelelles sont rattaches ? Grce l identifiant de session de cet utilisateur. Chaque session HTTP est associe unidentifiant unique gnr par le serveur et renvoy par le serveur au client. Lorsqu un client met une requte vers leserveur, cette requte contient l identifiant de session, et le serveur peut associer le client ses donnes.

Pour transmettre cet identifiant au client, le serveur gnre un cookie dont le nom est jsessionid , et dont la valeur estl identifiant de session qu il a gnr pour ce client, le client transmet ce cookie avec chaque requte mise vers ceserveur, jusqu expiration du cookie.

Ceci ne rsout pas le fait que si le navigateur client n accepte pas les cookies, ce mcanisme ne fonctionne pas. Unesolution ce problme existe : la rcriture dURL .

La rcriture dURL consiste inclure dans chaque requte de l utilisateur, un paramtre permettant de transmettrel identifiant de session. Pour ce faire, le serveur doit rcrire toutes les URL des pages qu il transmet au client enrponse, cette rcriture se fait par des instructions de code Java ajouter dans les pages JSP des applications, lecode doit donc tre prvu pour supporter ce mcanisme.

Une URL non rcrite :

http://localhost:8080/demo/identification

Une URL rcrite :



29/232

http://localhost:8080/demo/login;jsessionid=EA337E2DFE9465EAADC0...

L URL rcrite contient l identifiant de session en tant que paramtre, lorsque le client clique sur un lien qui contient ceparamtre, il transmet automatiquement son identifiant de session au serveur.

Mcanisme de rcriture d URL :

Une session HTTP expire partir du moment o le navigateur Web est ferm, ou bien explicitement par une action telun clic sur un lien, qui provoque, ct serveur, la destruction de la session. La session peut galement expirer touteseule, si aucune requte de la part de l utilisateur n est mise pendant 30 minutes, ce qui est la valeur par dfaut desspcifications JEE. Cette valeur peut, bien entendu, tre modifie.

Le mcanisme sur lequel repose le suivi de session HTTP peut donc tre, soit les cookies, soit la rcriture d URL, lesspcifications JEE prconisent d utiliser en priorit les cookies s ils sont supports par le navigateur, la rcriture d URLuniquement dans le cas contraire, et ce pour des raisons de performance et de scurit. En effet, chaquetransformation d URL ncessite un travail supplmentaire du serveur, de plus, l identifiant de session apparaissant en

clair dans la barre d adresse du navigateur, il peut facilement tre vu et utilis par un tiers.



30/232

Les serveurs d applications JEE

Les applications JEE sont ncessairement lies un environnement d excution spcifique dans la mesure o ellesutilisent des bibliothques de programmation particulires. De plus, ces applications ont besoin d un certain nombre deservices qui seront rendus disponibles par cet environnement d excution. Un serveur d applications JEE fournit un telenvironnement.

Le march des serveurs d applications JEE est trs riche, mais tous ces produits implmentent les mmes standardsimposs par la plate -forme, de sorte que les applications sont compltement indpendantes du serveur utilis.

la sortie de chaque nouvelle version des spcifications JEE, les diteurs de serveurs d applications redoublent d efforts

pour fournir des produits compatibles avec ces nouvelles normes.

1. Rles d un serveur d applications

Le rle d un serveur d applications est de mettre en oeuvre des applications distribues, conues base decomposants Java (Servlet, JSP, EJB) et de les rendre accessibles des clients Web (navigateurs) et des applicationsd entreprise (clients lourds) crites en Java. Le serveur doit prendre en charge le cycle de vie complet des diffrentscomposants, et la gestion d une file d attente pour satisfaire aux requtes des clients.

De plus, pour satisfaire aux exigences des applications d entreprise, le serveur d applications doit tre le plusperformant et le plus fiable possible. Il est donc capable de grer la disponibilit des applications en proposant unservice de gestion de la monte en charge et une solution de tolrance de panne en mettant en place des fermes(clusters) de serveurs.

Il s occupe galement de la fourniture des diffrents services utiles aux composants et au fonctionnement desapplications :

Service HTTP : pour permettre l accs aux applications via un navigateur Web.

Service de nommage : les ressources exposes telles que l accessibilit aux bases de donnes, sontenregistres avec un nom, ce service met en oeuvre l API JNDI.

Service de gestion des transactions : le service transactionnel est mis en oeuvre grce JTA.

Service de gestion de la disponibilit des applications (monte en charge et tolrance de panne) : ce n estpas un service dfini par les spcifications JEE, mais tout serveur d applications doit permettre la mise enoeuvre d une solution de haute disponibilit des applications pour garantir leur accessibilit et desperformances maximales.

Service de scurit : l API JAAS permet de grer l authentification et les droits d accs aux applications.

Service d administration : la configuration des services, le dploiement des applications, la supervision del ensemble des ressources doit idalement pouvoir se faire avec une interface de gestion du serveur. Cesinterfaces ont des ergonomies trs variables selon les produits, du simple fichier de configuration texte, laconsole graphique d administration.

Service d accs aux donnes : les services les plus utiliss par les applications car ils permettent l intgrationau systme d information, via JDBC et JCA notamment.

Service de gestion des messages : la messagerie applicative mise en oeuvre grce JMS.

2. Architecture d un serveur d applications

Les applications JEE sont constitues de modules contenant des composants logiciels diffrents. Le cycle de vie de cescomposants, et leur besoins pour fonctionner sont assez diffrents. Un serveur d application JEE est constitu deplusieurs environnements d excution, chacun tant adapt un type de composant JEE. Ces environnementsd excution sont appels Conteneurs JEE .

Un conteneur repose sur une infrastructure Java et utilise donc une machine virtuelle Java.

Les conteneurs d un serveur d applications JEE sont :



31/232

Le conteneur Web : il hberge les modules Web constitus de servlets et de JSP. L accs ce conteneur se fait via leprotocole HTTP.

Le conteneur EJB : il hberge les modules EJB. L accs un conteneur EJB par un autre conteneur, ou par uncomposant d application se fait en utilisant le protocole RMI/IIOP.

Le conteneur d applets : les applets Java embarques dans les pages HTML peuvent communiquer en HTTP avec lescomposants Web servlet et JSP. Le conteneur d applet est en fait le navigateur web associ au plug - in Java permettantd excuter les applets.

Le conteneur d applications clientes : il hberge les modules clients contenant des applications client lourds Java. Ceconteneur peut communiquer avec le conteneur Web et le conteneur EJB pour s interfacer avec les composantsprsents dans ces conteneurs. Ce conteneur doit tre install sur la machine cliente sur laquelle s excute la partie del application qui communique avec le serveur.Structure d un serveur d application JEE :

3. Les produits du march

Les serveurs d applications JEE peuvent tre classs en deux catgories, les implmentations compltes desspcifications JEE, et les implmentations partielles.

Les implmentations compltes contiennent tous les types de conteneurs de composants et offrent un accs l ensemble des services JEE. Les implmentations partielles quant elles ne fournissent qu une partie des conteneurs(souvent un seul) et les services JEE ne sont pas tous disponibles.

BEA WebLogic Server 10.0 BEA est l un des plus anciens diteurs de solutions JEE. Son produit, WebLogic Server , fut pendant trs longtemps leserveur d application JEE le plus utilis, c est aujourd hui avec le produit d IBM, l un des produits phare du monde JEE.

Sun Java System Application Server 9

Le produit de l inventeur de la technologie JEE est conu partir d une implmentation Open Source de serveur JEE 5appele GlassFish . Le projet GlassFish, initi par Sun, est l implmentation de rfrence des technologies JEE 5. C estvidement le premier serveur proposer une implmentation lors de la sortie d une nouvelle version des spcificationsJEE.

Apache Geronimo 2.0

Implmentations compltes



32/232

Implmentation Open Source de la fondation Apache, le serveur Geronimo utilise Tomcat 6 comme conteneur Web, etOpenEJB comme conteneur d EJB. En plus de ces deux projets Open Source, de trs nombreux autres produits OpenSource sont intgrs Geronimo, comme par exemple la base de donnes Apache Derby , ou encore la bibliothque deWeb Services , Apache AXIS .

noter galement qu IBM fournit une version Open Source d un serveur d applications JEE 5 bas sur l implmentationApache Geronimo : c est WebSphere Application Server Community Edition 2.0 .

JBoss Application Server 5.0

Au moment de l criture de ces lignes, la version 5 de JBoss est encore en cours de dveloppement. L implmentation

de conteneur web utilise par JBoss n est ni plus ni moins que Tomcat 6. La socit JBoss Inc. cre par l inventeur duserveur, Marc Fleury , diffuse galement le framework JEE Hibernate , ainsi que la solution de portail d entreprise JBossPortal .

Caucho Resin

Il y a deux versions du conteneur Web Resin , la version professionnelle et la version Open Source qui est disponible enlibre tlchargement. La version professionnelle ajoute notamment des fonctionnalits de supervision et de clusteringncessaire dans un environnement de production, alors que la version Open Source est oriente dveloppement ettests.

OpenEJB

OpenEJB est un conteneur EJB sous licence Apache. L objectif de ce projet est de fournir un conteneur pourcomposants EJB facilement intgrable avec d autres conteneurs JEE, notamment des conteneurs Web.

4. Le cas Apache Tomcat 6

Le serveur Tomcat 6 de la fondation Apache est le conteneur Web le plus utilis sur le march, notamment du fait qu ila t pendant longtemps l implmentation de rfrence des technologies servlets et JSP. De plus, Tomcat est utilisdans d autres projets de serveurs d applications commerciaux ou Open Source, comme Apache Geronimo , ou encoreJBoss Application Server .

a. Tomcat est un moteur de Servlet

Tomcat 6 est une implmentation partielle de serveur d applications JEE car il ne fournit pas tous les services de laplate -forme JEE, ce n est qu un conteneur Web, ou encore moteur de servlets/JSP.

D un point de vue de la plate -forme de services JEE, Tomcat 6 propose une implmentation des API JDBC , JNDI ,JAAS et JavaMail , les autres services ne sont pas fournis en standard, mais peuvent tre apports par d autresproduits complmentaires.

Implmentations partielles



33/232

Pour conclure

1. Les nouveauts de Java EE 5

Les lecteurs dj familiers de la plate -forme Java Enterprise ne souhaitent peut -tre s attarder que sur les nouveautsde cette version implmente par Tomcat 6, dans ce cas, cette partie du chapitre est pour eux.

Cette dernire version de JEE apporte des nouveauts vraiment trs consquentes, ce qui explique en partie le retardpris par les diteurs de serveurs d applications pour fournir des implmentations compatibles. Plus qu une mise jour,il s agit d une refonte majeure de la plate -forme.

Premire grande nouveaut, l introduction de la programmation par annotation , ceci permet notamment de pouvoirgnrer une grosse partie du code par le serveur d applications au moment du dploiement, et de s affranchir desfichiers de configuration.

De ce fait, les API existant dans les versions antrieures de JEE ont d tre adaptes ce nouveau modle deprogrammation, c est le cas par exemple de l API de Service Web JAX-RPC ( Java API for XML -RPC ) qui laisse sa place JAX-WS (Java API for XML Web Services) .

La nouvelle API de persistance Java JPA (Java Persistence API) fait son apparition dans JEE 5 ainsi que dans la plate -forme standard JSE 6. Elle facilite grandement la persistance des donnes en base sans avoir recours un frameworktierce partie.

Du ct du dveloppement Web, certaines annotations sont utilisables dans les servlets et les JSP pour tablir desrfrences des EJB, des Services Web, ou des ressources du serveur d applications.

Enfin, l API JavaServer Faces (JSF) est officiellement intgre dans la plate -forme. JSF permet de faciliter ledveloppement d applications Web en utilisant le modle de conception MVC.

2. Le futur

Au moment de l criture de ces lignes, Sun Microsystems prvoit dj de sortir une nouvelle version de la plate -formeJava EE (JEE 6), et ce moins de 2 ans aprs la sortie officielle de JEE 5, alors que certains diteurs n ont toujours paslivr de version compatible JEE 5 de leur produit !

Une version de la plate -forme standard est galement en prvision, mais les amliorations de la futur plate -forme JSE 7ne devrait principalement concerner que les applications de type client lourd.



34/232

Les diffrentes versions de Tomcat

Comme indiqu dans le premier chapitre de cet ouvrage, il existe plusieurs versions du serveur Apache Tomcat. Il estimportant de bien choisir la version de son serveur en fonction des applications qui y seront installes. En effet, lesversions majeures de Tomcat correspondent toutes une implmentation de rfrence des technologies Servlet et JSP.

Voici un rappel sur les relations entre les versions des technologies JEE et les versions de Tomcat :

Ainsi, une application dveloppe en utilisant l API Servlet 2.5 par exemple, devra ncessairement tre installe dans unserveur Tomcat en version 6.

Spcifications Java EE API Servlet API JSP Apache Tomcat

J2EE 1.2 2.2 1.1 3.x

J2EE 1.3 2.3 1.2 4.x

J2EE 1.4 2.4 2.0 5.x

JEE 5 2.5 2.1 6.x



35/232

Distribution de Tomcat

Le serveur Tomcat 6 est disponible en libre tlchargement sur son site Internet, l adresse http://tomcat.apache.org .Plusieurs formats de fichiers sont proposs au tlchargement. D abord, Tomcat 6 est tlchargeable soit sous forme decode source qu il faudra compiler, ou bien sous forme de binaires Java. La version code source est trs intressante pourp

Documents

Apache Tomcat6 Server Guide Administration