Yoopi.NET est un projet que nous (désolé mais j'ai du mal avec le "je") avons mené en quelques jours dès la sortie officielle de J#. L'idée que tout programme Java respectant la norme 1.1.4 du JDK pouvait potentiellement prétendre à une migration vers la plate-forme .NET nous a réellement emballé (à ce propos, nous vous invitons à lire l'article précédent sur le langage J#, pierre angulaire de ce projet). Dès les premiers tests effectués sur le compilateur de Microsoft, l'idée de migrer un moteur de servlet Java en J# n'a cessé de hanter notre esprit (zavé vu, j'essaie d'imiter le style Harry Potter, bon d'accord c'est pas terrible). A partir de ce moment, seul l'aboutissement de ce projet aurait pu satisfaire notre curiosité. Pourquoi un tel engouement autour de cette migration ? Et bien pour plusieurs raisons : Tout d'abord, pour être capable de démontrer que J# supporte entièrement le JDK 1.1.4, il doit être en mesure de compiler n'importe quelle application conforme à cette version sans aucune modification. Quoi de plus complexe qu'un moteur de servlet pour mettre à profit ces tests (réseaux, threads, ...) ?
Par ailleurs, si aujourd'hui les ASP.NET proposent une alternative intéressante aux Servlets/JSP, ils peineront indéniablement à convaincre là où l'existant Java représente une quantité de code non négligeable. Les entreprises ne sont pas disposées à l'heure actuelle à reconstruire entièrement leur SI sous prétexte qu'une nouvelle architecture a fait son apparition. En revanche, si une stratégie de migration leur est proposée prenant en compte leur existant avec la possibilité de faire communiquer dans le même processus une application Java/JSP et une page ASP.NET, elles y réfléchiront peut-être à deux fois. L'idéal étant de pouvoir partager les objets Session, Application entre servlet et ASP.NET sans dégrader la disponibilité de l'application.
Bien entendu, dans la pratique, la réalité est beaucoup plus complexe. En fonction du type d'application, la migration sera plus ou moins aisée et nous ne sommes pas prêt aujourd'hui de faire fonctionner une telle architecture. C'est pourquoi notre objectif consiste avant tout à démontrer la faisabilité d'un tel projet plus qu'à fournir une réelle implémentation de référence. Nous tenons particulièrement à cette philosophie de "proof-of-concept" car il ne faut pas se faire d'illusion, Yoopi n'est pas un outil magique vous permettant de convertir toutes vos applications Java vers .NET d'un simple click, Yoopi est juste une avancée technologique ouvrant la voie à d'éventuelles implémentations futures ...
A l'origine du projet, la motivation et la ferveur aidant, nous nous sommes intéressés à Jakarta Tomcat du projet Apache. En théorie, Tomcat 3.2 est compatible avec le JDK1.1. En pratique, la réalité est quelque peu différente. Voyons pourquoi ...
La manipulation consiste à récupérer les fichiers .java et à les insérer directement sous Visual Studio dans un projet J#. Un simple drag & drop du répertoire /src de Tomcat est suffisant. Reste ensuite à actionner dans l'environnement le fameux bouton -Build-.
Si Tomcat nous a posé énormément de problèmes, c'est en partie dû à la complexité de son architecture. Voici une liste non exhaustive des différents soucis auxquels nous avons été confrontés :
Le challenge consistant à recompiler entièrement les sources de Tomcat 3.2 en J# est réussi non sans mal. Quant à l'exécution, quelques tests ont rapidement mis en lumière l'énorme chemin qu'il restait à parcourir afin de faire fonctionner l'application de bout en bout. Nous arrêtons ici l'expérience Tomcat mais vous pourrez trouver à la fin de l'article les sources compilée au cas où vous trouveriez la motivation pour continuer cette entreprise.
Abattus mais non résignés, nous nous attelons à rechercher un adversaire de plus petite taille. L'idéal serait de trouver un moteur de servlet suffisamment compact pour devenir un noyau de référence. Une recherche rapide sur le Web nous amène à nous intéresser à shttp, un projet sur le site sourceforge en version 0.1 complètement abandonné par son auteur, un certain Mattias Larsson. Après un rapide coup d'oeil sur les sources, il s'avère que nous tenons enfin notre fameux noyau, et pour cause, ce serveur contient en tout et pour tout une trentaine de classes chargées de traiter les requêtes, les réponses et l'instanciation des WebApp. C'est décidé, shttp deviendra notre noyau J# !
La première étape consiste à compiler les spécifications servlets et JSP contenues dans le fichier servlet.jar, nécessaire au développement de nos applications. Si vous avez lu l'article précédent sur J#, vous verrez que cette étape importante est aussi la plus simple. N'oubliez pas de spécifier au compilateur que vous souhaitez générer une Assembly (DLL) : servlet.dll
Aucune modification de code n'est nécessaire, la compilation passe du premier coup. Jugez-en par vous même, faites le test.
Une fois l'archive servlet.jar compilée, il ne reste plus qu'à créer le projet relatif au noyau shttp. Nous décidons de l'appeler Yoopi car c'est tout simplement le premier mot que nous avons prononcé après avoir fait fonctionner notre moteur de servlet (bon je vous l'accorde, c'est pas très original ;-))
Il est très important de comprendre que Yoopi n'est pas une implémentation complète des spécifications de Sun. Il subsiste énormément de fonctionnalités absentes dans cet outil, notamment :
- La gestion des pages JSP : Une fois les servlets implémentées dans le moteur, mettre en place la gestion des JSP ne constitue pas en soi une réelle difficulté.
- La gestion de la session : Suite à un léger problème avec les cookies, nous n'avons pas jugé cette fonctionnalité prioritaire
- La gestion de la sécurité
- La configuration des WebApp via le fichier web.xml
Une fois le cahier des charges bien défini, nous nous attelons à la migration. Il se trouve que l'outil est assez austère et ne permet pas de saisir à partir d'une interface graphique les différents paramètres de lancement (port, docRoot, WebApps, ...).
Nous décidons donc de concevoir une IHM WinForm minimale telle qu'illustrée sur la copie d'écran suivante :
Pour compiler l'ensemble des sources de Yoopi, il est bien entendu obligatoire de référencer dans votre projet le fichier servlet.dll contenant les spécifications Servlets et JSP. Remarquez au passage que notre moteur fait bien appel à l'Assembly servlet.dll mais n'est pas contraint d'implémenter l'ensemble des classes de la spec. Cela tombe bien car nous ne l'avions franchement pas prévu au planning ;-).
Toujours est-il que le projet est créé, l'interface d'administration aussi. Après quelques heures passées sur de légères modifications du serveur, notamment concernant la gestion d'erreur, le chargement dynamique de classe et l'implémentation d'un browser de répertoires (bon d'accord, pompé dans les sources de Tomcat). Nous décidons de tenter notre chance.
Après quelques build infructueux, la compilation daigne fonctionner et l'exécution de Yoopi nous laisse sans voix ... Juste le temps de verser une larme (euh, j'en fais peut-être un peu trop là) et c'est reparti, il nous faut créer des servlets d'exemple. Pour ce faire, rien de plus simple, il suffit d'importer une servlet existante ou d'en créer une soi-même. L'important étant de la compiler et de l'insérer dans l'outil d'administration via le bouton "Add Servlet Class". N'oubliez surtout pas de mentionner les éventuels packages utilisés.
Pour vous démontrer que Yoopi supporte réellement les classes HttpServlet, le source suivant a été testé. Cette servlet lit un fichier situé sur le serveur et le renvoie tel quel dans la réponse HTTP en binaire avec au passage une modification du type mime.
import
javax.servlet.*;
import
javax.servlet.http.* ;
import java.io.* ;
* This is an example of a simple Servlet.
*/
public class
Yoopi extends HttpServlet
{
public void
service(HttpServletRequest req, HttpServletResponse res)
throws
ServletException, IOException
{
File f = new
File("DNG.gif");
FileInputStream in = new
FileInputStream(f);
int
size = (int)f.length();
res.setContentLength(size);
byte []
buffer = new byte[size];
in.read(buffer);
res.getOutputStream().write(buffer);
res.getOutputStream().close();
}
public
String getServletInfo() {
return
"A simple servlet";
}
}
Pour exécuter Yoopi, il suffit soit de faire un Run sous Visual Studio ou de lancer l'exécutable en ligne de commande. L'interface d'administration vous propose un "Start Servlet Engine" s'appuyant sur une Console Dos pour tracer la communication HTTP entre navigateur et serveur web.
Le moment le plus agréable est celui-ci. Le test de votre première servlet. Pour ce faire, rien de plus simple, lancez un navigateur quelconque et tapez : http://localhost:port/<nomClasseServlet> ou par exemple http://localhost:8080/Yoopi , vous devriez voir apparaître une image créée pour l'occasion.
N'hésitez pas à créer vos propres servlets mais gardez à l'esprit que Yoopi n'est pas un outil finalisé, il se peut que des exceptions soient levées ici ou là (y aura qu'a dire que c'est la faute à Microsoft, ils ont l'habitude ;-)).
Pour implémenter un moteur de JSP, il suffit de générer dynamiquement le code des servlets dans une Assembly. Le noyau de Yoopi pourrait être amélioré afin de supporter le chargement dynamique de classe sans interruption de service. Fonctionnalité non supportée aujourd'hui dans la version actuelle de l'outil. Pour ce faire, nous vous conseillons de jeter un oeil aux sources de Tomcat. Par ailleurs, la compilation des pages JSP aujourd'hui prise en charge par le compilateur javac de Sun pourrait être délégué au compilateur vjc.exe de Microsoft comme indiqué dans la figure ci-dessous. Il existe à la manière de C# une API permettant de faire appel au compilateur J#.
Enfin, gardez à l'esprit que les JSP qui référencent des Frameworks
techniques basés sur J2EE ne pourront pas fonctionner sur Yoopi. 
Oui, Yoopi est en licence OpenSource, tout comme son noyau d'origine : shttp. Le but est de promouvoir cet outil afin d'en faire profiter la communauté des développeurs, et qui sait, peut-être réveillerons nous quelques heureuses initiatives afin d'en faire un vrai serveur de référence à part entière.. (rêvons un peu ;-)). Sachez que nous n'assurons aucune garantie quant à la stabilité de ce mini-noyau ni n'assurons de support sur cette version. La documentation est totalement inexistante (quoi, les sources ça suffit pas ? ;-)) mais vous ne devriez pas rencontrer de réels problème pour le configurer.
Nous réfléchissons à l'avenir à une solution d'hébergement du projet sur le site SourceForge, meilleur moyen de poursuivre l'aventure.
Yoopi est-ce qu'il convient d'appeler un proof-of-concept destiné à démontrer la faisabilité d'une implémentation servlets en environnement .NET. Lors de la mise en oeuvre de ce projet, il n'y a eu aucune arrière pensées ou velléité malsaine de notre part. Le but n'est pas d'inciter les développeurs Java à implémenter leurs servlets en .NET ou de promettre l'impossible à ceux ayant déjà un existant complexe, mais d'entrevoir des possibilité futures pour une cohabitation Java/.NET. Nous savons pertinemment que seuls certains types d'application bien spécifiques (non EJB) seront concernés par Yoopi et ses principes. Les autres liront sûrement cet article avec un léger sourire au coin des lèvres ;-).
Enfin, il faut noter que notre intervention dans le cadre de ce portage se résume à quelques modifications sommaires de code sources et à une compilation en du projet en J#. Il convient donc de raison garder. Sans fausse modestie, personne ne peut prétendre avoir développé un noyau en ayant simplement porté une implémentation existante. DotNetGuru n'a donc aucun mérite dans la réalisation de cette migration. La vrai star de ce projet reste avant tout Mattias Larsson qui est loin de se douter que son projet inachevé de conteneur de servlet aurait pu dériver vers une telle implémentation (merci de ne surtout pas le prévenir, il m'en voudrait à vie ;-))
Auteur : Sami JABER
Copyright : DotNetGuru Juillet 2002 ©
Téléchargez les projets
Projet Yoopi .NET v0.2 (sources + binaires)
Projet Tomcat.NET (sources + binaires) : les sources comprennent le noyau Tomcat ainsi que les parseurs XML
Remerciements
Merci infiniment à Christopher Lauer (il souhaite rester anonyme ;-)) pour avoir joué les debuggers .NET