I. Définition▲

Le terme serveur Web désigne un ensemble de serveurs permettant à une application Web de fonctionner.

Les serveurs d'applications JEE sont composés d'un serveur HTTP, d'un conteneur de Servlets (dans la notion de Servlet nous incluons également les pages JSP qui sont transformées en Servlets à la compilation) et d'un conteneur EJB. Ils fournissent également un certain nombre de services JEE comme JMS, JNDI, JDBC, etc.

Tous ces composants ne sont pas utiles dans tous les contextes. C'est pourquoi il existe un grand nombre de serveurs sur le marché proposant chaque composant de manière séparée ou combinant certains d'entre eux. Toutes ces combinaisons correspondent à des besoins bien précis.

Les serveurs Web lourds sont utiles pour absorber une charge importante ou pour fournir des services complexes. Les serveurs Web légers sont une bonne alternative pour des projets qui ne requièrent pas ces critères : l'utilisation la plus courante de ces serveurs est probablement le contexte de développement. Un développeur a besoin de pouvoir tester ses briques logicielles, de manière rapide, intégrée et sans connaissance particulière en administration. Les serveurs Web légers sont une solution efficace à cette problématique. C'est ce que nous allons étudier dans le cadre des tests Serveur d'applications JEE

II. Principes▲

Les serveurs Web légers n'ont pas besoin d'être installés. Ils nécessitent un minimum de configuration. Ils ont également l'avantage d'être rapides à lancer, à arrêter et sont moins gourmands en ressources pour fonctionner. Ils se présentent sous forme d'un fichier Jar. Si l'on souhaite les faire fonctionner de manière indépendante à notre code de test, il est possible de les lancer en ligne de commande. Mais il est encore plus intéressant de les piloter directement dans notre code de test afin qu'ils y soient complètement intégrés.

C'est là qu'est le plus grand intérêt du serveur Web léger : être utilisé en mode embarqué dans le code Java en notant que l'utilisation en mode autonome reste toujours possible. Les serveurs que nous étudierons un peu plus loin sont basés sur la simplicité d'utilisation en mode embarqué. Quelques lignes de code Java suffisent pour les piloter. L'utilisation des serveurs Web légers embarqués dans du hardware est également possible grâce à leur petite taille.

III. Ce qui est disponible sur le marché▲

Voici un tableau qui montre une vue d'ensemble des différents types de serveur Web JEE :

  Type Mode embarqué Licence Support commercial Poids
Apache Tomcat conteneur de servlets oui open-source non moyen
Jetty conteneur de servlets oui open-source non léger
TJWS (Tiny Java Web Server and Servlet Container) conteneur de servlets oui open-source non léger
Winstone conteneur de servlets oui open-source non léger
LWS (LiteWebServer) conteneur de servlets oui, mais peu de documentation propriétaire payant léger
OpenEJB conteneur EJB oui open-source non moyen
Weblogic serveur d'applications non propriétaire payant lourd
Websphere serveur d'applications non propriétaire payant lourd
Glassfish serveur d'applications oui open-source payant lourd
JBoss Application Server serveur d'applications oui open-source payant lourd
Apache Geronimo serveur d'applications non open-source non léger

Les conteneurs de Servlets, comme les serveurs d'applications, embarquent des serveurs HTTP afin de les rendre autonomes.

Les serveurs Web issus de logiciels libres bénéficient des retours d'expériences d'une large communauté d'utilisateurs et sont disponibles gratuitement. Les serveurs Web propriétaires, quant à eux, ont l'avantage de bénéficier d'un support payant qui peut être intéressant pour les entreprises. Certaines sociétés supportent des serveurs Web open source et proposent donc également un support payant aux entreprises.

La colonne "poids" montre les serveurs selon leur empreinte mémoire. Les serveurs de la catégorie léger font une taille maximale de 5 mégaoctets. Ceux de la catégorie lourd font plus de 50 mégaoctets. Tomcat et OpenEJB font une quinzaine de mégaoctet, nous les avons regroupés dans une catégorie moyenne car ils sont un bon compromis entre robustesse et légèreté.

Remarquez que rien n'empêche un serveur Web léger embarqué d'être utilisé comme serveur autonome.

IV. Tester des applications Java▲

L'automatisation des tests unitaires fait partie de l'industrialisation des projets informatiques. Elle permet de garantir un bon niveau de détection des anomalies. Il est possible de réaliser plusieurs types de tests qui seront déroulés de manière automatisée dans plusieurs environnements. Voyons quelques types de tests qu'il est possible d'améliorer grâce aux serveurs Web légers.

IV-A. Tests de composants Java▲

Les tests d'intégration permettent de valider le fonctionnement d'une méthode qui se connecte à un serveur afin de récupérer une ressource dynamique. Avec ce type de test, l'utilisation d'un serveur Web léger embarqué au code aura l'avantage de le rendre indépendant d'une plateforme, ce qui diminuera la charge de travail à fournir pour installer la plateforme de test. Cela permet également de réduire les erreurs liées à l'environnement.

Ainsi, avec l'utilisation d'un serveur Web léger dans un code de test JUnit en général, ces erreurs diminuent et sont plus facilement détectables. En effet, si le serveur embarqué rencontre un problème au démarrage, nous le détecterons grâce aux logs du test qui a échoué, puisque c'est le test qui le pilote.

IV-B. Tests de composants graphiques▲

Certains projets ont pour but de fournir des composants graphiques, formatés aux couleurs d'une entreprise et permettent surtout de réaliser des applications finales avec peu de connaissances techniques. Ils portent généralement le nom de "Frameworks d'entreprise" et peuvent voir leurs tests unitaires améliorés grâce aux serveurs Web légers. Il est possible de déployer un WAR en définissant un contexte d'exécution avec les serveurs Web légers cités plus haut dans cet article.

Une fois le serveur lancé avec la webapp dans son contexte d'exécution, nous pouvons utiliser un parser XML pour valider les pages avec les DTD XHTML, ou utiliser un framework de test comme Selenium afin de tester fonctionnellement l'application. Concrètement, avec Jetty, il faut utiliser une classe XmlConfiguration que l'on initialise avec un fichier XML. Sa méthode newInstance() récupère le serveur Jetty configuré avec le WAR que nous avons indiqué dans le fichier XML. Voici à quoi doit ressembler le fichier de configuration XML de Jetty dans le but de déployer un WAR :

Exemple de fichier de configuration de Jetty
Sélectionnez

<Configure class="org.mortbay.jetty.Server">
    <Call name="addWebApplication">
        <Arg>/myapplication</Arg>
        <Arg>./chemin/webapp.war</Arg>
    </Call>
</Configure>

Déployer un WAR avec un serveur Web embarqué aux tests est une bonne solution tant que ce WAR est suffisamment léger pour être redéployé à chaque test. Dans le cas contraire, si le WAR est trop lourd pour ce cas d'utilisation, il est préférable d'utiliser un serveur Web léger en mode autonome.

Dans ce cas, il faut définir un port en localhost sur lequel un serveur autonome sera déployé sur chaque environnement de tests. L'utilisation d'un serveur Web léger a l'avantage de diversifier les contextes d'exécution et de faire baisser les coûts du logiciel en utilisant un serveur Web léger issu du logiciel libre. La diversification du contexte d'exécution est un moyen de valider le respect de la norme JEE par l'application.

IV-C. Tests de composants EJB▲

OpenEJB permet de tester des composants EJB en l'utilisant de manière embarquée au code de test.

Il existe également des frameworks à tout faire, comme Spring, qui permettent de bouchonner des composants EJB. Spring permet de remplacer certaines fonctionnalités des EJB.

V. Utilisation en production▲

L'utilisation de serveurs Web légers est possible en production pour certains sites non critiques, qui ne dépassent pas un certain seuil d'utilisateurs connectés en même temps. Cette utilisation peut s'expliquer par des raisons de coûts, de simplicité ou de compétences dans des équipes qui connaissent bien Tomcat par exemple. Il ne faut pas que l'application ait besoin d'EJB ou d'autres services spécifiques aux serveurs d'applications.

En règle générale, il s'agira d'une solution temporaire qui permet de mettre en place le projet très rapidement. Tomcat est néanmoins une exception : suffisamment robuste et prouvé, il est capable d'atteindre des performances souvent tout à fait suffisantes en production.

VI. Vue d'ensemble▲

Voici un tableau, loin d'être exhaustif, qui présente quelques serveurs Web légers dans différents langages, en fonction du langage de script pour lequel il est fait :

Créé avec Serveur JSP / Servlet PHP / Perl / Python ASP.net Ruby on Rails
Java Jetty, ou ceux présentés dans le premier tableau X      
C++ Lighttpd + modules   X   X
.Net WebDev     X  
.Net Mono XSP     X  
Ruby Thin       X
Ruby Webrick       X

Ainsi certains d'entre eux sont multiplateformes, d'autres peuvent être utilisés en mode embarqué plus ou moins facilement. Le monde des serveurs Web est vaste et il est possible de trouver de tout pour toutes les situations, même si nous sommes restés concentrés sur Java dans cet article.

J'espère que cet article vous aura donné une bonne idée des possibilités qu'offrent les serveurs Web légers, et en particulier leur utilisation en mode embarqué.

VI. Références▲

Cet article a été adapté au gabarit de developpez.com par Romain Linsolas (romaintaz).