Archive for the 'web' Category

Les frameworks Ajax

Les frameworks de développement Web reposant sur JSP on l’inconvénient majeur de nécessiter une bonne connaissance de JavaScript pour pouvoir développer un site en Ajax. Pendant longtemps, ces frameworks ne prennaient pas en compte cette dimension du développement Web. Mais un nouveau type de frameworks spécialement conçu autour de la technologie Ajax a fait son apparition depuis environ un an. Leur particularité est de permettre à un développeur Java d’écrire une application Ajax sans aucune connaissance de JavaScript.

Il existe deux frameworks plus ou moins équivalents que sont GWT (Google Web Toolkit) et Echo2. L’un comme l’autre permet de concevoir une application Ajax sans écrire une seule ligne de code en JavaScript. Leur principe est de proposer une librairie Java et un compilateur qui converti le code de cette librairie en JavaScript. Mais bien que reposant sur le même principe général, ces deux frameworks sont en fait très différents.

GWT distingue de façon très nette les parties cliente et serveur. La première est intégralement compilée en JavaScript et peut être exportée vers n’importe quel serveur Web tel que Apache, tandis que la partie serveur est destinée à tourner sur un conteneur de Servlet tel Tomcat. Bien sûr, il est possible de faire tourner le tout sur Tomcat, mais seules les librairies pouvant être compilées en JavaScript peuvent être inclues dans le code de la partie cliente.

En revanche, Echo2 n’offre pas de cadre pour distinguer le côté serveur et le côté client, il appartient au développeur de s’en tenir au design pattern adéquate. Et à la différence de GWT, Echo2 génère une véritable application Java dont le code est intégralement délivré par des Servlets. Il n’est donc pas possible d’exporter une application Echo2 vers un simple serveur Web.

Quel que soit le choix de la technologie, les frameworks Ajax ont l’avantage, pour un développeur Java, de pouvoir se lancer dans l’écriture de Services Web complexes. On signalera enfin l’existence d’une librairie Ajax conçue spécifiquement pour le framework JSF et qui s’appelle Ajax4Jsf, nous aurons l’occasion d’y revenir.

Le tour du Web en 333 secondes

Attention les yeux :

Les frameworks de développement Web et le pattern MVC

Le langage Java s’est principalement imposé côté serveur, cela s’entend dans une architecture client/serveur. C’est pourtant dans les applications autonomes que Java a tout d’abord mis en oeuvre l’architecture qui allait faire sa popularité, à savoir le pattern MVC. La philosophie sous-jacente à MVC est de supprimer les couplages inutiles, c’est-à-dire de décomposer l’application en modules indépendants les uns des autres. C’est déjà ce que permet de faire la programmation orientée objet en théorie, mais la réalité est que les développeurs, cherchant la facilité au premier abord, établissent souvent à des redondances inutiles qui sont à l’origine d’enchevêtrements abscons. Les designs patterns sont là pour rappeler les bonnes pratiques en matière de programmation et, de ce fait, faciliter tant la collaboration des équipes que la mise à jour ultérieure du code. Cette approche de la programmation a été adoptée dans la librairie swing qui est la librairie graphique de Java pour les application autonomes.

Parallèlement à son succès auprès des développeurs, Java s’est progressivement imposé côté serveur jusqu’à devenir un acteur incontournable du Web au même titre que le langage PHP. Mais cette progression c’est faite laborieusement comme nous avons pu le voir dans un billet précédent. Face à la complexité croissante des applications Web, la nécessité d’en revenir aux meilleurs pratiques de développement s’est rapidement fait sentir. C’est pour répondre à la détresse des architectes logiciels que la fondation Apache a crée le framework Struts. Un framework dont l’objectif avoué est d’inviter les développeurs à de meilleures pratiques, et notamment à recourir au fameux pattern MVC qui consiste à séparer une application en trois couches que sont la couche de présentation, la couche métier et la couche de contrôle, celle qui fait le pont entre les deux premières.

La couche de présentation (Vue) est celle qui a la responsabilité de générer ce qui est affiché à l’écran, c’est-à-dire le positionnement des composants graphiques ainsi que les détails de leur aspect comme la couleur. La couche métier (Model) est celle qui met en oeuvre la logique de l’application, elle a pour responsabilité de représenter les données du problème et de les résoudre. Enfin, le controleur (Controler) établit la relation entre la Vue et le Model, elle gère la dynamique de l’application.

Comme nous l’avons écrit dans dans un billet précédent, les JSP reposent sur un langage de balises extensible. Cette propriété a été exploitée par les concepteurs de Struts pour créer une librairie de balises permettant de résoudre la majorité des problèmes posés par l’écriture de la couche présentation, cela sans avoir besoin de recourir aux Scriptlets. Cela permet finalement d’unifier le langage utilisé pour la couche présentation généralement écrite par les équipes de design. Le langage Java est ainsi réservé à l’écriture des couches métier et controleur.

C’est donc pour répondre à ce motif que le framework Struts a été développé. Il y est parvenu au prix d’une certaine complexité qui le réserve aux projets de grande envergure.

Le développement Web en Java

La conception de sites Web est possible en Java, elle est basée fondamentalement sur la technologie des Servlets et requière l’installation d’un conteneur comme le serveur Tomcat. C’est ce conteneur qui reçoit et oriente les requêtes http vers les Servlets idoines. En retour, la Servlet doit construire la réponse à la requête, en général au format html ou xml.

Le principe des Servlets est très puissant car il permet de répondre à n’importe quel type de requête http qui est le protocole standard des applications Web. Mais l’inconvénient est que les développeurs partent d’un fichier en langage Java pour produire un document en langage html. Ainsi, la rédaction d’une page Web est malaisée. Le handicap se fait particulièrement ressentir lors de la mise à jour du document. Voyez par vous-même :

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class ExempleDeServlet extends HttpServlet {
    protected void doGet(HttpServletRequest req, HttpServletResponse res)
    throws  ServletException, IOException {
        OutputStream out = res.getOutputStream();
	out.println("<?xml version="1.0" encoding="UTF-8" ?>") ;
        out.println("<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitionnal//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitionnal.dtd\">"
        out.println("<html><head><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\" /><title>Exemple de Servlet</title></head>");
        out.println("<body>Vous ne vous en rendez peut-être pas compte, mais ce n'est vraiment pas pratique</body></html>");
    }
    protected void doPost(HttpServletRequest req, HttpServletResponse res)
    throws  ServletException, IOException {
        doGet(res, req);
    }
}

Les fondements de la technologie n’ont jamais été remis en cause et ils ont maintes prouvé leur pertinence. En revanche, le langage Java a été enrichie d’une nouvelle spécification avec l’arrivé des JSP (Java Server Page) il y a bientôt dix ans. L’inconvénient des Servlets a ainsi été surmonté en inversant les pôles : les JSP sont des documents qui suivent la structure du langage html avec la possibilité d’ajouter du code Java.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Exemple de JSP</title>
</head>
<body>
C'est beaucoup plus pratique à écrire et à mettre à jour
</body>
</html>

Comme on le voit ci-dessus, une JSP ressemble à s’y méprendre à un document html, c’est le conteneur qui se charge de compiler la JSP en Servlet. En fait, une JSP permet de faire bien plus de choses que d’écrire des balises html. Comme nous l’avons dis, il est également possible d’y insérer du code Java grâce aux Scriplets mais aussi de faire référence à une variable avec les Expressions Langage. Enfin, et c’est le plus important, les JSP reposent sur un langage de balises extensible, c’est-à-dire que contrairement au langage html qui définit l’ensemble des balises autorisées, le développeur de JSP peut créer ses propres balises. Ce mécanisme est extrêmement puissant et offre un gain de temps considérable en permettant de créer des composants complexes qui pourront être utilisés par la simple apposition d’une balise.

Malgré tous ces avantages, les JSP ne sont pas pour autant la panacée. Elles ont l’inconvénient de leur avantage, leur souplesse est telle que les JSP deviennent rapidement illisibles si le développeur ne s’astreint pas à une certaine rigueur. C’est à ce niveau qu’intervient le framework. Le rôle qui lui est dévolu est de définir un cadre de travail qui doit permettre de conserver l’avantage premier des JSP, à savoir leur facilité de mise à jour.

Nous reviendrons sur les frameworks dans un prochain billet.

En bref

Au fond, qu’est-ce que le Web ?

Le Web est une application parmis d’autres du réseau Internet, il exploite la possibilité qu’ont machines à communiquer entre elles. Du point de vue des développeurs, le Web repose sur trois piliers que sont le protocole http, le service dns et le langage html (1). Au-dessus de ces trois piliers, le navigateur, sans lequel le Web est impraticable, prend en charge tous ces aspects techniques pour offrir une navigation conviviale, la convivialité étant un de ses aspects les plus importants.

Ce que n’est pas le Web, ou presque pas …

Une autre application très répandue d’Internet est le service de mails. L’e-mail est l’application la plus utilisée d’Internet, elle repose traditionnellement sur les deux protocoles que sont smtp et pop pour, respectivement, l’envoi et la réception du courrier. Le service de messagerie a connu de nombreuses évolutions, notamment avec l’apparition des messageries instantanées. Mais la transformation la plus frappante est l’apparition du webmail. Jusqu’alors, la navigation sur le Web et la consultation de ses messages nécessitaient l’emploi de logiciels distincts dû à la différence entre les protocoles de commnucation. L’apparition de Hotmail a été une véritable révolution. Ce type de service permet de relever sa messagerie depuis n’importe quel ordinateur connecté au réseau public. La révolution ne vient pas tant du service, au fond très classique, que de la possibilité d’y accéder à partir d’un navigateur Web.

Le problème et la solution

Le jalon est posé. Le Web qui, à l’origine, se contentait d’afficher des pages de texte noir sur fond blanc, parsemé ici ou là de mots soulignés en bleu (ah ! la belle époque), devient un vecteur par lequel peut transiter un service tel que la messagerie.

Cette transformation s’est étendue et on observe un nombre croissant d’applications qui basculent sur le Web. S’agissant du webmail, cette transformation consistait à basculer simplement une application Internet depuis un protocole vers un autre. Ou plus exactement, à interfacer les traditionnels protocoles pop et smtp avec le protocole http. Aujourd’hui, les webmails sont d’usage courant, mais en vérité, le mouvement s’est considérablement amplifié après la maturation qu’à apporté l’éclatement de la première bulle spéculative de l’ère Internet.

Avec salesforce.com, on voit cette fois une application de gestion complexe basculer intégralement sur le Web. Ce qui est fascinant, est de voir cette fois une application traditionnellement circonscrite aux réseaux d’entreprise être accessible sur le réseau publique, et cela par le seul biais du navigateur Web. D’abord sujette au scepticisme général, salesforce.com a convaincu de la force de sa technologie et de la pertinence de son modèle économique. Pour l’entreprise, le service proposé permet un moindre coût de formation grâce à l’utilisation d’une interface avec laquelle les gens sont devenus familiers. Il permet également un moindre coût de déploiement puisque celui-ci est pour ainsi dire nul. Mon métier fait que je n’utilise pas Salesforce, mais je ne doute pas que les avantages sont encore nombreux par rapport aux solutions client-lourdingue.

Salesforce.com est la figure de proue du phénomène SaaS, un phénomène dont l’ambition est de faire basculer toutes les applications sur le Web, autrement dit sur le navigateur. Toutes les applications, c’est-à-dire tout ce que vous démarrez sur votre ordinateur ! Il y va donc des logiciels que vous utilisez en entreprise, comme le propose notamment salesforce.com, mais aussi du plus anodins des logiciels. Calcul, traitement de texte, retouche photo … les problèmes dont vous attendez que votre ordinateur les résolve le seront à terme par le biais de votre navigateur. La standardisation (2) de l’interface utilisateur au niveau applicatif, et non plus seulement au niveau système, promet un gain de productivité propre à convaincre une entreprise soucieuse de ses intérêts, j’ai nommé Microsoft.

(1) Plus précisément, le pilier côté client inclus les langages de balises, le CSS et l’ecmascript, dont le fameux javascript, pour ce qui est des standards du Web.

(2) Désolé, mon blog n’est pas conforme aux standards à causes des badges que j’y ai ajouté. Sinon, WordPress a pour réputation de se conformer aux standards.

Le web, cette bulle de savon

Diversité des couleurs, juxtaposition des cultures dont le résultat impressionniste évoque le contour bariolé des bulles de savon.

bulles de savon

Flottement dans les airs qui enivre les esprits du sentiment de liberté, fragilité qui emplit les regards de fascination.

Le web ne laisse voir de lui que son pourtour, vide pour les uns, remplit pour les autres de cet air qui fait la vie ailleurs.