II. Présentation▲
II-A. L'origine des Servlets▲
Suite à l'incroyable essor pris par le développement d'applications Web côté serveur, Sun Microsystems se devait de ne pas rester à l'écart, et a donc produit un kit de développement Web, comprenant le serveur Web java et un ensemble de classes.
Cet ensemble de classe correspond à ce que l'on appelle les Servlets et le serveur Web java, programmé pour une grande partie grâce aux Servlets, fut un des premiers serveurs Web à faire fonctionner les Servlets.
Rapidement, grâce aux qualités intrinsèques au langage Java (que je mettrais en valeur au fur et à mesure de l'ouvrage) et aux spécificités du fonctionnement des Servlets, ces dernières sont parvenues à attirer l'attention des développeurs.
C'est bien entendu Sun Microsystems, avec son département logiciel Java Soft (comme pour le langage Java), qui a écrit la première version de la norme des Servlets, et qui continue à le faire de manière relativement ouverte, acceptant d'étudier toute proposition raisonnable venant de n'importe qui. La dernière version de cette norme est actuellement la 2.2, et n'est pas supportée par tous les serveurs de Servlets.
Bien que les Servlets constituent une extension majeure du langage Java, leur API n'est pas intégrée à la version standard de la plate-forme Java, mais à l'édition entreprise http://java.sun.com/j2ee/.
II-B. Les technologies utilisées▲
La technologie des servlets n'est qu'un ensemble de classes. Elles ont besoin pour fonctionner convenablement, d'une machine virtuelle Java et de l'ensemble des autres classes intégrées à l'API standard du langage Java .Une servlet est une application développée dans un contexte client-serveur, et vient se greffer sur des applications existantes afin de les étendre ou de les implémenter différemment. Une servlet n'existe pas par elle-même, mais étend des applications utilisant des protocoles tels que HTTP, SMTP ou FTP par exemple.
II-C. La place des Servlets▲
II-C-1. À quoi ça sert ?▲
Les servlets permettent théoriquement d'étendre n'importe quel type de serveur. Il est donc théoriquement possible de développer toute sorte d'application susceptible de bénéficier à une application faisant office de serveur. Cependant dans la réalité il n'est pas possible, à ma connaissance, de développer des applications pour autre chose qu'un serveur Web. Ceci est dû au simple fait qu'il est nécessaire de développer une passerelle entre la machine virtuelle Java et le serveur à étendre et que cela constitue un travail difficile et probablement inintéressant pour des raisons que j'évoquerai plus tard. De plus, il n'est pas certain que cet effort soit récompensé par les développeurs.
En pratique, les Servlets permettent donc exclusivement le développement d'applications Web côté serveur, ceci de manière à pouvoir fournir un contenu dynamique aux visiteurs de sites Web.
II-C-2. Public visé▲
La mise en place de cette technologie est gratuite et accessible à tous facilement. Le langage Java n'étant pas réputé pour son austérité, tous les ingrédients sont réunis pour en faire une solution de masse.
En effet, les programmeurs peuvent créer des applications utiles en très peu de temps et ne sont limités en aucune manière par les possibilités très étendues du langage utilisé. De plus, étant donné l'orientation objet de ce dernier, et l'utilisation de celle-ci comme support pour la diffusion d'ateliers de génie logiciel (comme Objectering), les Servlets sont adaptées à la programmation de grandes applications. Ces dernières bénéficient alors de la réutilisabilité des programmes écrits en Java et accélèrent le développement.
D'autres caractéristiques du langage Java favorisent la diffusion des Servlets dans tous les domaines : sa portabilité, sa stabilité et sa grande présence dans les milieux universitaires (chaque année, ce sont environ deux millions de développeurs Java qui sont formés).
Enfin, la gratuité des solutions permettant de faire tourner des Servlets sur une machine de manière performante est également un facteur de diffusion non négligeable.
Pour résumer, les propriétés du langage Java et des solutions de mise en place des Servlets permettent une diffusion de cette technologie dans les milieux professionnels autant que chez les utilisateurs amateurs. C'est d'ailleurs en réponse à cet attrait de la part des programmeurs que de nombreux hébergeurs ont décidé de proposer une offre concernant les Servlets.
II-C-3. Les possibilités▲
Comme je l'ai dit précédemment, l'énorme bibliothèque de classes permet au programmeur de Servlets une grande latitude quant à la fonction que remplira son application.
D'autres caractéristiques comme les possibilités évoluées de connexion aux principaux SGBD du marché1.2, la persistance du processus de chaque Servlet, l'intégration des EJB (pour Enterprise Java Beans) ou encore la gestion de la sécurité permettent aux Servlets de prendre en charge des projets tels que des sites de commerce électronique, des plates-formes bancaires, des sites communautaires ou des outils de configuration de serveurs.
Je ne le répéterai jamais assez, les servlets ne sont pas exclusivement destinées à créer des applications Web, elles peuvent très bien étendre d'autres types de serveurs. On peut donc raisonnablement envisager la création de nouvelles commandes pour un serveur FTP, ou d'une application de filtrage de courriers électroniques directement présente sur le serveur et non sur le client. Ces applications ne sont pas réalisables dès aujourd'hui, mais elles le seront sans doute prochainement lorsque les fournisseurs de serveurs utilisant un autre protocole que HTTP adopteront la plate-forme J2EE.
II-D. Quels sont les acteurs sur le marché ?▲
Depuis leur création en 1996, de plus en plus d'acteurs majeurs de l'industrie de l'informatique ont proposé une offre autour des Servlets.
Tout d'abord en ce qui concerne les serveurs d'applications. Ces solutions sont très fortement liées à tous les domaines d'activité de l'entreprise. De nombreux composants « métiers » sont utilisés (comme les EJB qui sont les Enterprise Java Beans), et des critères comme la fiabilité, le support technique et l'adéquation avec les contraintes professionnelles de l'entreprise sont primordiaux. Il est donc compréhensible que d'importants fournisseurs d'applications aient investi ce secteur. Ces fournisseurs sont IBM (avec WebSphere), BEA (avec WebLogic), Oracle (avec Oracle Application Server) et iPlanet (avec iPlanet Application Server). Ces serveurs utilisent des moteurs de Servlets et des serveurs Web parfois indépendants. Par exemple IBM a développé un serveur Web pour WebSphere qui se base sur le serveur Web Apache.
Ensuite viennent les moteurs de Servlets, qui ne fonctionnent pas tous suivant le même modèle. Ce sont des applications qui implémentent toutes une version de la norme de l'API des Servlets, ils ne se différencient donc pas selon leurs fonctionnalités, mais selon leurs performances. Les principaux moteurs de Servlets sont Tomcat (de la fondation Apache), Resin (de Caucho), JServ (de la fondation Apache également), Allaire avec JRun.
Enfin ces moteurs de Servlets sont souvent rattachés à des serveurs Web (car c'est à un serveur Web que sont destinées les requêtes provenant d'un navigateur dans de nombreux cas). Étant donné qu'un site Web ne se base pas exclusivement sur les Servlets, les serveurs Web les plus utilisés pour fournir d'autres services sont en général choisis. Ces serveurs sont Apache (de la fondation Apache), iPlanet Web Server (de iPlanet) et IIS (de Microsoft).
D'autres entreprises très présentes dans le secteur du développement traditionnel fournissent des outils aux développeurs désirant obtenir une forte intégration avec leur serveur supportant les Servlets. Je pense par exemple à Borland avec JBuilder, Macromedia UltraDev, et à PowerJ de Sybase. Le reste des outils est développé par les acteurs cités ci-dessus (Oracle avec JDeveloper, IBM avec Visual Age, Allaire avec JRun Studio).
On ne peut que constater l'absence de Sun et de Microsoft quant aux outils permettant le développement et le déploiement de Servlets. En ce qui concerne Sun, ce n'est pas tout à fait vrai. En effet, ils fournissent un moteur de Servlets intégré à un serveur Web nommé Java Web Server, mais il constitue plus une solution pionnière qui a permis de disposer d'une première plate-forme que d'une solution destinée à être utilisée en production. Ils proposent également un outil de développement appelé Forté (anciennement Net Beans) qui, dans sa version entreprise, supporte les Servlets. Cet outil n'est pas véritablement utilisé à cause de sa lourdeur, mais fut quand même le premier outil RAD permettant le développement de Servlets. Ils ne proposent donc ces outils que dans un but d'introduction aux concepts qu'ils proposent, ils ont par ailleurs fort à faire à normaliser l'API des Servlets tout en développant son implémentation et ses fonctionnalités.
Quant à Microsoft, il suffit de songer à leur mode de diffusion pour comprendre leur position. Les produits de Microsoft sont diffusés en partie, car ils constituent un standard imposé par le caractère propriétaire de leurs applications. Ils fournissent des applications en étroite relation avec leur système : on choisit le système de Microsoft, car on ne peut se passer de leurs applications et vice-versa. Avec Java, on peut disposer d'une plate-forme pouvant apporter des solutions globales (comme les serveurs d'applications) et ceci de manière portable : l'informaticien et l'utilisateur sont indépendants de l'architecture matérielle et logicielle. On peut donc très bien choisir d'autres produits que ceux de Microsoft. Afin de résister à la déferlante Java, Microsoft a donc annoncé le développement d'une plate-forme similaire : la plate-forme .NET. C'est un ensemble d'outils pour le développement, le déploiement et l'utilisation d'applications distribuées, qui met en valeur l'utilisation des réseaux (locaux ou Internet). Cette solution reprend de nombreuses caractéristiques de Java comme le langage C# dont la syntaxe est étonnamment similaire à celle de Java, la présence d'une machine virtuelle qui interprète un langage intermédiaire, le caractère distribué des applications (un utilisateur peut utiliser une application distante) et d'autres encore. On peut donc voir la plate-forme .NET comme un concurrent à la plate-forme J2EE1.4.
Bien entendu cette situation n'est pas figée et elle sera probablement amenée à changer au fur et à mesure de l'arrivée des nouveaux acteurs et des départs des anciens, qui seront peut être attirés par d'autres plates-formes.
II-E. Les solutions de substitution▲
D'autres solutions que les Servlets permettent de réaliser des applications similaires. En effet, les développeurs n'ont pas attendu l'arrivée de ces dernières pour automatiser le traitement de données côté serveur en vue de les communiquer à des utilisateurs . Voici une liste des principales techniques pouvant se substituer aux Servlets :
- CGI (pour Common Gateway Interface) : c'est un ensemble de règles permettant de faire communiquer un serveur Web avec des applications externes. Cette possibilité a donc été rapidement utilisée pour proposer un contenu dynamique. Les scripts CGI peuvent être écrits dans n'importe quel langage (comme le C, le Perl, le Python, etc.) ;
- PHP (pour Pretty Hypertext Processor) : c'est un langage permettant d'écrire des scripts qui seront ensuite interprétés par un logiciel (on appelle PHP la réunion des deux). C'est un logiciel libre qui en est aujourd'hui à la version 4 et qui est un des plus employés. C'est une technologie très portable ;
- ASP (pour Active Server Pages) : la solution proposée par Microsoft. C'est une norme qui permet le développement d'applications Web côté serveur sur la plate-forme Microsoft (système d'exploitation Windows et serveur Web IIS). Comme la norme CGI, ASP permet de développer des scripts en utilisant le langage de programmation de son choix. Cela n'est que théorique, et malgré le développement anecdotique de support ASP pour le langage Perl en utilisant Apache par exemple, l'indépendance vis à vis du langage, du serveur Web et du système d'exploitation n'est pas une réalité. ASP dans sa version 4 (nommée ASP+) est intégrée à la plateforme .NET (voir plateforme.NET) ;
- Les solutions propriétaires comme Cold Fusion ou WebDev (de PC Soft) qui comprennent tous les outils de la chaîne de développement d'applications Web côté serveur sont assez utilisées, mais possèdent les inconvénients de toute architecture propriétaire. Cela dit ces solutions proposent également leur lot d'avantages, comme la gestion de flux de texte très évoluée pour Cold Fusion et le développement rapide pour WebDev.
Je ne compare pas ces possibilités aux Servlets pour l'instant, car je ne vous ai pas donné assez d'éléments de réflexion, mais sachez que cela sera fait ultérieurement. Je ferai parfois, et tout au long de cet ouvrage, quelques comparaisons ponctuelles sur des points précis entre les Servlets et certaines des solutions sus-citées. Sachez seulement pour l'instant que toutes ces technologies ne sont utilisables que par l'intermédiaire du protocole HTTP, ce qui n'est pas le cas des Servlets, même si c'est cet aspect que je développerai en majorité.