Depuis son apparition dans les années 1990 jusqu’à l’aube des années 2000, le web était principalement utilisé pour publier et consulter des documents, généralement statiques et chargées de manière atomique. Au début des années 2000, de nombreux sites ont mis en oeuvre des comportements dits dynamiques : les pages, toujours chargées de manière atomique, sont alimentées en contenu par des requêtes transactionnelles vers des bases de données. Aujourd’hui, les sites sont devenus de véritables applications web à comportement très sophistiqué. Notamment les pages ne sont plus chargées de manière atomique mais de manière parcellaire. C’est le cas par exemple de GMail, Twitter ou encore 280slides. Ces applications ont en effet besoin de charger des informations situées dans des parcelles de la page. Par exemple, lorsqu’un utilisateur de GMail reçoit un nouveau message, la page se met à jour automatiquement sans avoir à recharger la page.

280 Slides, une application web riche

Pour réaliser ce chargement régulier d’informations, la méthode la plus répandue aujourd’hui est l’attente active, ou « polling ». À intervalles de temps réguliers, un appel AJAX, sous forme de requête HTTP est envoyé au serveur pour lui demander si de nouvelles informations existent.

Les inconvénients de l’attente active

L’attente active exploite le comportement standard du protocole HTTP. Le client envoie une requête au serveur, le serveur répond et une fois la réponse reçue la connexion est fermée. A priori, le protocole HTTP n’intègre pas nativement le push.

Cependant, l’attente active présente deux inconvénients majeurs :

• Gaspillage de ressources. Le client ne sachant pas si des informations plus à jour existent sur le serveur ou non, il est obligé de faire des requêtes répétées même quand il n’y a rien de nouveau sur le serveur. Cela entraîne une activité réseau inutile, ainsi qu’un traitement inutile des requêtes et des réponses côté client comme côté serveur. C’est d’autant plus problématique en environnement mobile où les ressources sont plus précieuses : mémoire et processeur sont plus limités, et l’utilisateur est susceptible de payer sa connexion à la quantité de données échangée.
• Un délai de latence. Les requêtes pour recevoir des nouvelles du serveur étant forcément espacées, l’utilisateur recevra les mises à jour avec du retard. Là ou un délai de quelques minutes est acceptable pour le courrier électronique, pour une application de discussion instantanée il est nécessaire de recevoir les messages dans l’instant, en temps réel.

En mode polling, un choix judicieux de la largeur de l’intervalle entre deux requêtes permet de trouver le bon compromis entre  le gaspillage des ressources et le délai de latence, en fonction des applications. Avec un délai court les informations sont fraîches mais la consommation en ressources est importante. Avec un délai plus long la consommation en ressources reste maîtrisée mais les informations arrivent en retard.

Attente Active (Polling)

Comet : Le Push avec les Navigateurs Actuels

Bien que le push ne soit pas prévu par le protocole HTTP, il est possible de l’implémenter en utilisant des caractéristiques naturelles dudit protocole. L’idée est que le serveur ne répond pas tout de suite mais attend d’avoir de nouvelles informations avant d’envoyer la réponse, ou une partie de la réponse. Ces techniques sont regroupées sous le terme de Comet et nécessitent de configurer le serveur web pour accepter un délai long avant la réponse de la requête, et ne pas couper les connexions en cas de délai écoulé.

Comet : Le Push dès Aujourd'hui

iframe cachée

Cette technique consiste à utiliser une iframe cachée, et y charger une URL que le serveur utilisera pour pousser les nouvelles informations. Le contenu de cette iframe invisible sera chargé par blocs. Du point de vue du protocole, tout se passe comme si le serveur ou le réseau mettait plus de temps que d’habitude pour charger la page - sauf que dans ce cas, il ne s’agit nullement de limitations du serveur ou du réseau : le serveur attend d’avoir de nouvelles informations pour les pousser immédiatement vers l’iframe.

Cette technique fonctionne dans tous les navigateurs, cependant la gestion des erreurs est difficile.

Requête XMLHttpRequest gardée ouverte

XMLHttpRequest est le type de requête que les applications Ajax utilisent pour charger des données depuis le serveur sans avoir à recharger la page complète. Dans certains navigateurs, il est possible de l’utiliser en mode multipart, c’est-à-dire que la réponse sera chargée par blocs ; c’est ce qui est utilisé ici pour du push. Là encore, le serveur poussera un nouveau bloc dès qu’il sera nécessaire d’envoyer des nouvelles informations au client.

Le principal problème de cette approche est qu’elle ne fonctionne que dans les navigateurs basés sur Gecko, c’est-à-dire Firefox et ceux qui partagent son moteur de rendu. Internet Explorer étant basé sur Trident, Chrome et Safari sur Webkit et Opera sur Presto.

Attente active prolongée (long polling)

Il s’agit toujours d’une requête XMLHttpRequest, mais cette fois-ci elle est utilisée classiquement, et la réponse arrive en un seul bloc. Par contre, le serveur ne répondra pas avant d’avoir de nouvelles informations. Dès qu’il reçoit une réponse, le client soumet une nouvelle requête au serveur pour que celui-ci puisse à nouveau lui communiquer de nouvelles informations.

Un exemple d’application de discussion en temps réel utilisant l’attente active prolongée se trouve dans la distribution du framework Play. Il s’agit de “chat“, une application simple de discussion en temps réel.

Cette approche fonctionne dans tous les navigateurs, et c’est souvent la méthode la plus adaptée.

Et demain ? L’Apparition des WebSockets

Bien que les approches Comet fonctionnent, elles restent une forme de « bricolage » sur le protocole HTTP. Pour fournir un façon plus simple et standard de réaliser du push dans les applications web, Google à introduit les Web Sockets. Celles-ci sont implémentées dans les versions les plus récentes du navigateur Google Chrome, et sont en cours de standardisation au sein du WHATWG, le groupe de travail à l’origine du HTML5. Mozilla Firefox le supportera dans sa version 3.7.

Les Websockets : un lien bi-directionnel

Les websockets fournissent une connexion bi-directionnelle, full-duplex entre le client et le serveur. Il est possible de faire transiter des données textuelles comme des données binaires, si nécessaires dans les deux directions à la fois.

Il faudra du temps avant que les navigateurs supportant les WebSockets soient suffisamment répandues pour pouvoir envisager leur utilisation sur un site public ; cependant Il est déjà possible de les utiliser en milieu fermé, tel qu’un intranet dont on contrôle le poste de travail.

Les années 1980 ont vu un changement de paradigme dans l’informatique : l’élément de base de l’interaction homme-machine qu’était la « ligne de commande » s’est effacé au profit de la « fenêtre ». À cette occasion les applications, principalement exécutées sur un serveur distant, se déplacent vers le poste de l’utilisateur qui a gagné en puissance. Au cours des années 2000 un nouveau changement s’est amorcé, et la « fenêtre » laisse maintenant la place à la « page ». Ce changement s’accompagne d’un retour des applications sur un serveur distant, mais sans perdre la richesse qui avait été gagnée lorsque les applications étaient arrivées sur le poste de travail.

Le navigateur web, qui à son apparition dans les années 1990 n’était qu’une application parmi d’autres, est maintenant la plate-forme d’exécution privilégiée pour les applications utilisateur. Google va plus loin : avec Google Chrome OS (annoncé en 2009), le navigateur devient le système d’exploitation, et ainsi les seules applications admises sur la plate-forme sont les applications web.

Le Web en 1997 : Documents Seulements

Le navigateur comme plate-forme d’execution : un rêve ancien

Ce sont les nombreux avantages des applications web sur les applications desktop qui ont mené le navigateur web a prendre cette place.

• Accès universel : une application web tourne sous toutes les machines, tous les systèmes d’exploitation équipés d’un navigateur moderne. Cela inclut des appareils qu’on ne considère pas forcément comme des ordinateurs : les téléphones mobiles, les consoles de jeux, les magnétoscopes numériques…
• Déploiement et mise à jour : il suffit d’accéder à l’URL de l’application pour utiliser la version la plus à jour, sans avoir à installer quoi que ce soit sur le poste client.
• Indépendance du poste de travail physique : un utilisateur peut retrouver ses données depuis n’importe quel poste, y compris une machine d’emprunt.

Face à ces avantages, il n’est pas surprenant de constater que l’industrie du logiciel s’est intéressée au web très tôt… Peut-être même trop tôt. En 1995, Sun publie Java 1.0 qui très vite permet d’exécuter des applications distantes dans un navigateur web, les applets Java. Vers la fin des années 1990, de nombreuses entreprises imaginent un « ordinateur réseau », sans espace de stockage dont toutes les applications seraient distantes. Le Network Computer d’Oracle et Acorn, NetStation de NetProducts, JavaStation de Sun Microsystem… Aucun n’a vraiment percé car il était trop tôt : le réseau n’était pas pervasif comme il est aujourd’hui, et les outils n’étaient pas prêts. Les pages web étaient principalement statiques, et les applets Java restaient limitées dans leurs fonctionnalités et leurs performances.

La situation est aujourd’hui différente : une part croissante de la population a un accès haut débit et permanent à Internet, et le navigateur web a muté en une plate-forme d’exécution qui rivalise avec les systèmes fenêtrés. Les entreprises web grand public, à commencer par Google, ont su tirer parti de cette plate-forme avec des applications telles que GMail, Google Docs et Google Calendar. Elles ont ensuite été suivies par les éditeur de logiciels « classiques » qui sont de plus en plus nombreux à migrer leurs offres vers le web.

Le Web En 2009 : Applications Riches

Les Applications Web en 2010

Cette tendance s’accompagne de nouveaux défis qu’il convient de régler pour pouvoir progresser. Ceux-ci sont principalement :

• Sécurité : la communication étant constante entre le serveur et le poste client, il est primordial de s’assurer (1) que personne ne peut intercepter les données (2) que personne ne peut se faire passer pour le client auprès du serveur et (3) que personne ne peut se faire passer pour le serveur auprès du client. Il est également important de protéger l’utilisateur des sites web malveillants qui peuvent exister.
• Performances : l’application doit être réactive, rapide même quand la connexion est mauvaise ou aux heures d’affluence.
• Intégration au bureau : pour des raisons de sécurité, les applications web sont restreintes dans leur communication avec la machine locale. Cela ajoute des limites aux applications web auxquelles ne sont pas soumises les applications natives.
• Compatibilité : une des caractéristiques clé des applications web étant de pouvoir être utilisées dans n’importe quel navigateur moderne, sur n’importe quelle machine, il convient de maintenir cette universalité dans le développement web et les évolutions de la plate-forme.

Pour y répondre, des experts des entreprises concernées (Mozilla, Apple, Google, Yahoo et bien d’autres) ainsi que des experts indépendants réfléchissent aux évolutions possibles et souhaitables de la plate-forme web pour lever les limitations des applications web sans impacter la sécurité, les performances ou la compatibilité.

Ces évolutions se concrétisent à travers des organismes de standardisation tels que le W3C pour HTML ou ECMA pour Javascript.

• Le stockage local (local storage) peut être utilisé comme une forme de cache, et ainsi réduire considérablement le temps de latence avec lequel l’utilisateur interagit avec ses données.
• La géolocalisation a été introduite dans Firefox 3.5.
• L’orientation de l’appareil a été introduite dans Firefox 3.6 (particulièrement utile sur les téléphones mobiles, que l’on peut tourner en portrait ou paysage).
• ECMAScript 5 (la norme correspondant à Javascript) va apporter de la robustesse au langage à travers le mode strict, et ajouter des fonctionnalités permettant d’écrire des applications plus complexes plus simplement.

En 2010, le Web comme plate-forme unique (Chrome OS)

Ces évolutions ont amené Google à introduire un système d’exploitation complètement basé leur navigateur, Chrome. Ce système, baptisé Google Chrome OS mais pas encore disponible, ne permet d’utiliser que des applications web et abandonne définitivement les applications locales. De plus, ce système destiné aux ordinateurs sans disque dur est stateless, c’est-à-dire qu’aucune information n’est stockée localement et tout est sur le réseau. L’utilisateur peut facilement passer d’une machine à une autre sans avoir à faire quelque migration que ce soit.

Intranet : Profiter dès Aujourd’hui du Web de Demain

Sur le web ouvert, l’utilité de ces avancées est souvent retardée par l’inertie dans le renouvellement des navigateurs. Si un grand nombre d’utilisateur a gardé un navigateur ancien, il est nécessaire de rester à des technologies supportées par ces navigateurs.

Sur un intranet en revanche, la maîtrise du navigateur ouvre de nombreuses portes. D’une part, il suffit de faire le choix d’un navigateur récent pour profiter de leurs fonctionnalités avancées. Ainsi, choisir Firefox 3.5 ou Chrome 3.0 permet d’utiliser le stockage local, et de profiter des performances d’une machine virtuelle Javascript à compilation « juste à temps ». Cela permet de faire des applications plus riches, plus performantes à moindre coût.

Mais le contrôle du poste client permet d’aller encore plus loin : en utilisant des extensions, il est possible d’aller d’étendre le navigateur pour donner accès à des fonctionnalités normalement accessibles uniquement aux applications desktop. Par exemple, certaines extensions permettent d’initier un appel téléphonique depuis une page web. C’est aussi avec cette approche que Google a proposé Google Gears dès Mai 2007 afin d’offrir un mode déconnecté pour les applications web. Il convient toutefois de garder à l’esprit que l’usage d’extension comporte un risque de dépendance au navigateur choisi. Il est donc recommandé (1) de se limiter à des extensions de petite taille, pour faciliter la maintenance et la portabilité (2) de rester tant que possible proche des recommandations du w3c. Ainsi, lorsqu’une version plus récente du navigateur choisi supportera la norme, la migration depuis l’extension sera facilitée.

Conclusion

Le navigateur est aujourd’hui un élément stratégique du poste de travail : c’est la plate-forme d’exécution d’applications par excellence, en passe de supplanter complètement les applications locales. Par conséquent, il convient de lui consacrer beaucoup d’attention. Le choix d’un navigateur adapté vous permettra de développer des applications intranet puissantes à moindre coût, tandis qu’un navigateur plus limité peut être un véritable frein dans le développement des outils d’accès à votre système d’information. De plus, des développements trop dépendant d’un navigateur peuvent rendre une migration future très coûteuse et potentiellement empêcher une modernisation pourtant nécessaire.

Zenexity possède une expertise des technologies web allant des solutions serveur au fonctionnement même des navigateurs majeurs. N’hésitez pas à nous contacter si vous avez besoin de conseils dans le choix stratégique du navigateur, ou pour connaître les solutions permettant de limiter les coûts et les risques liés à la migration vers un navigateur moderne.

L’ouverture au public du site de démarches en ligne du Conseil Général de Seine et Marne recueille un brillant succès.

Le premier service ouvert aux citoyens est la « Demande de bourse Mobil’Etudes ». Il va permettre aux étudiants d’obtenir des bourses dont le montant varie en fonction de la distance séparant le lieu d’habitation du lieu d’études. Vingt minutes à peine après l’ouverture dudit service, cinq demandes étaient déjà créées. Une semaine après la date d’inauguration, on dénombrait déjà plus de 1000 comptes créés, 500 demandes de bourse enregistrées, sans compter des centaines de visiteurs quotidiens.

Il s’agit d’une première étape d’une stratégie globale du CG 77 de positionner le citoyen au centre des actions de la collectivité et de donner aux agents des outils performants, simples et conviviaux pour gérer la relation citoyen au quotidien à travers Internet en cohérence totale avec le courrier, le courriel et le téléphone.

Afin de maximiser les chances de réussite rapide du projet, le CG 77 a entrepris de baser ses travaux sur la toute nouvelle version 4.0 de la plate-forme CapDémat. Cette nouvelle version, développée pour le Conseil Général du Val d’Oise, repose sur des fondations techniques et ergonomiques entièrement conçues et réalisées par les laboratoires de Zenexity, au profit de la communauté Open Source CapDémat.

CapDémat 4.0 apporte des performances accrues, une sécurité renforcée et surtout une nouvelle interface innovante, fluide, ergonomique, fiable et facile à utiliser, aussi bien par les citoyens pour s’enregistrer, saisir et suivre les demandes, que par les agents pour gérer lesdites demandes.

Les solutions technologiques et ergonomiques dont bénéficie CapDémat 4.0 représentent l’état de l’art en e-administration et ont été toutes déjà éprouvées sur des grands projets menés par Zenexity auprès de milliers d’utilisateurs (citoyens, agents, salariés, internautes, etc.), de collectivités telles que le CG 95, CG 77, CDA La Rochelle, Saint Germain en Laye ou d’entreprises privées telles que JC Decaux, Carrefour, Intermarché ou Leclerc.

En collaboration avec les équipes du Conseil Général, Zenexity a conçu et réalisé la première passerelle entre une téléprocédure, en l’occurrence la « Demande de bourse Mobil’Etudes » et le logiciel de gestion financière Grand Angle de la société Logica.

Logica (ex. Unilog), éditeur de la solution Grand Angle, progiciel financier, a collaboré avec les architectes Zenexity afin de réaliser cette solution de communication. L’agent de la collectivité peut ainsi se concentrer sur le suivi, l’analyse et le traitement des demandes en temps réel ou en différé, interagir avec le citoyen demandeur, planifier les tâches et actions sans avoir à ressaisir la moindre des informations et en étant certain à tout moment du respect des procédures légales, administratives et financières.

Zenexity accompagne le Conseil Général de Seine et Marne dans la construction d’une plate-forme e-administration performante, à faibles couts d’évolution et de maintenance, alignée sur les standards du Web, du Web 2.0 et de la SOA, totalement conforme aux standards d’interopérabilité (RGI) et d’accessibilité (RGAA) et répondant aux dernières recommandations de sécurisation et du respect de la réglementation de la CNIL.

Une plateforme de démonstration de ces nouvelles interfaces est accessible librement.

Introduction au SaaS

Le SaaS constitue une nouvelle approche d’édition et de commercialisation des logiciels. Le SaaS apporte de nouvelles possibilités pour les entreprises. Au delà de l’acronyme SaaS, “Software as a Service”, il est intéressant de définir le contenu de ces offres. Concrètement, il s’agit souvent de solutions logicielles clef en main, hébergées et administrées par l’éditeur qui les fournit. Un point important: une application SaaS est articulée autour de la plate-forme Web/HTTP ce qui la différencie d’une offre en mode ASP pour laquelle le logiciel n’est pas toujours full-web et nécessite parfois l’installation de composants sur les postes utilisateurs.  Souvent associé au cloud-computing, le SaaS suit strictement la même démarche: externaliser l’exploitation informatique en se basant sur Internet et les standards d’interopérabilité du Web.

Buzz or not Buzz ?

Une étude Evans Data [1] parue en janvier dernier présente quelques chiffres sur le sujet: un sondage montre qu’un tiers des développeurs américains travaillent actuellement sur un projet SaaS, tandis que plus de la moitié des développeurs, au niveau mondial cette fois, ont l’intention de se lancer sur ce créneau en 2009. On peut malgré tout relativiser ces chiffres. Une autre étude [2] réalisée par Pingdom sur les statistiques de recherches de Google semble démontrer que le mot “SaaS” est un buzzword, tout comme le Cloud computing et le “Web 2.0″ à leur époque, buzzwords qui ont rapidement déclinés durant l’année 2008.

Mais est-ce que la mesure de popularité d’un mot clef par Google Trends est suffisante pour annoncer un déclin réel des concepts qui se “cachent” derrière un mot ?  Nous ne le pensons pas. Nous l’analysons  plutôt comme le pattern d’un thème devenu mature et connu du grand public. Les recherches portent alors sur des mots plus ciblés, au fur et à mesure que s’élabore une nouvelle terminologie autour de ces concepts.

Des économies et de la flexibilité

Les responsables financiers des entreprises apprécieront le budget nécessaire tandis que les équipes opérationnels seront satisfaites de la rapidité de mise en service (Time To Market). Effectivement, les coûts du logiciel sont allégés: le coût d’aquisition est nul et remplacé par une facturation à  l’usage (pay as you go). Les coûts de maintenance sont également réduits, le client n’ayant plus à faire l’acquisition des serveurs. Ensuite, il s’agit de solutions qui apportent une forte capacité à monter en charge et une certaine flexibilité au niveau des fonctionnalités. Enfin, les applications SaaS sont dors et déja déployée et prête à l’utilisation: le temps de mise en oeuvre des projets est réduit de manière drastique.

Evaluer et anticiper les risques

Début 2009, nous avons assisté à une polémique après que Saleforce.com ait connu une interruption de service de 40 minutes à la suite d’une panne matériel. Le tableau de bord des clients n’était plus accessible et l’activité commerciale de ceux qui n’avaient pas de solutions de secours est restée au point mort durant tout ce temps. Le même jour Bill McDermott, de l’éditeur allemand SAP expliquait au magazine Information Week que les grandes entreprises ne devraient jamais reposer sur des plateformes SaaS pour l’exécution des opérations qui font leur coeur de métier. Comme Microsoft, celui-ci met en valeur une stratégie fondée sur des modules SaaS qui viennent compléter leurs produits: le Software-Plus-Service.

Face à ces problèmes, des opposants au SaaS émergent. On retrouve ainsi dans la blogosphère des articles très critiques sur les changements que le SaaS impose. Il est important de prendre conscience des inconvénients afin de mieux évaluer les risques et de mettre en place une stratégie d’anticipation. Examinons quelques-uns des thèmes récurrents de l’argumentaire anti-SaaS.

• “Il est nécessaire d’avoir une connexion internet” Oui, mais aujourd’hui nous sommes constamment connecté : au bureau, via son mobile, dans les gares etc. De plus, les éditeurs SaaS travaillent sur l’intégration du mode hors ligne permettant de continuer à utiliser l’application même sans connectivité, en s’appuyant sur différentes technologies. Cette affirmation est donc de moins en moins vraie. Ainsi Google propose la majorité de ses services en mode hors ligne (emails, agenda…).

• “Vos données sensibles seront stockées sur des serveurs qui ne vous appartiennent pas” Oui, mais une part non négligeable de l’espionnage industriel a des origines internes, fuites volontaires ou non, obligeant les entreprises à prendre des mesures. La gestion de la sécurité représente un poste de coût, et peut s’avérer défaillante dans certaines entreprises. Le simple acte de jeter des documents ou de vieux disques à la poubelle est une “faille de sécurité”. Les éditeurs SaaS, à partir du moment ou ils ont industrialisé leurs processus d’hébergement, maîtrisent mieux la protection de l’information que l’entreprise Lambda.

• “Vous perdez le contrôle de la version du logiciel sur laquelle vous travaillez” Une des fonctionnalités principales du SaaS est de proposer des logiciels fréquemment mis à jour. La mise en place de nouvelles versions, prise en charge par l’éditeur, est transparente pour l’utilisateur final. Le gain de confort, notamment pour ceux qui ont connu la saga des grandes  migrations applicatives et particulièrement les redoutables mises à jour du système d’exploitation, est indéniable.

• “En mode SaaS, vous payez continuellement. Il est préférable de payer une licence et d’être libre par la suite. Que se passe-t-il si l’éditeur SaaS change sa politique de prix ?” Le prix des applications en mode SaaS est en général modique mais inclut les frais de mise à jour. Mais ne s’agit-il pas de prix d’appel visant à verrouiller le client avant de l’assommer par des augmentations ? La question est légitime. Toutefois ce problème existe déjà sur des logiciels acheté chez un éditeur de “solutions classiques”. Il sera nécessaire de payer les mise à jours. Si malgré tout l’éditeur change sa politique de prix de façon brutale, sachez que vous êtes libre de partir à tout moment, rien n’engage le client: le plus petit comme le plus grand. Les éditeurs SaaS le savent et font le nécessaire pour conserver leurs clients. Pourquoi prendraient ils le risque de perdre des clients alors qu’ils ont entre les mains un modèle économique qui fonctionne ?

L’avenir du SaaS

Le SaaS évolue et devient de plus en plus mature. Il est probable qu’émergent dans les prochaines années de nouveaux standards liés aux problématiques spécifiques du Sofware as a Service. Il y a fort à parier que ces standards imprimeront leur marque comme le trio HTTP/HTML/URL en son temps. Les thèmes potentiels de standardisations peuvent être aussi large que la qualité de service, la sécurité et la stabilité du fournisseur. Pour le moment, on peut s’appuyer sur des SLA et exiger des fournisseurs des fonctionnalités d’interopérabilité, notamment en terme d’exports / imports des données.

Tous les éditeurs SaaS devraient fournir une copie des données aux clients. Une bonne approche consisterait à exposer des services XML ou JSON permettant à l’entreprise de mettre en place son propre système de sauvegarde ou de synchronization. On peut citer l’exemple de l’API Google Apps qui permet notamment aux utilisateurs de Gmail dans sa version entreprise d’accéder aussi bien à la configuration qu’aux données des utilisateurs de manière sécurisée.

Comment évaluer la qualité d’un éditeur SaaS

• Choisissez les meilleurs: Pourquoi aller vers un éditeur qui propose une offre classique et commune ? Profitez du meilleur du SaaS en choisissant un fournisseur offrant des solutions innovantes dont la valeur ajoutée est validée par des exemples concrets. Héberger un outil de CRM sur vos serveurs vous coûte cher ? N’hésitez pas à étudier l’alternative offerte par quelques-unes des solutions CRM en mode SaaS.

• Vérifiez la disponibilité des services: La disponibilité du service est un facteur primordial. Une bonne pratique consiste à vérifier ce que propose l’éditeur en terme de monitoring et de transparence, notamment par le biais des outils de communication qu’il met en oeuvre: blog et forums par exemple. Contractuellement, il faut privilégier les solutions offrant des critères précis de disponibilité, supérieure à 99,9% par exemple. Un bon taux de disponibilité contractuel constitue le gage d’une équipe technique compétente. Pensez également à vérifier l’historique de la société dans les domaines métiers et techniques.

• Vérifiez les conditions de résiliation et les moyens mis à disposition du client utilisateur dans l’hypothèse d’une terminaison de contrat. Dans quels formats et sous quelles conditions les données applicatives peuvent être rapatriées ? Dans quels délais ? Peut-on récupérer les informations de provisionning (comptes utilisateurs et profils d’accès associés)…

• Une activité en forte croissance: Assurez vous que la société éditrice est en forte croissance. Le secteur du SaaS suit une évolution a deux chiffres. Il n’y a pas de raison pour que votre éditeur ne s’inscrive pas dans cette tendance.

• N’oubliez pas le reste: Comme dans toute démarche client/fournisseur, n’hésitez pas à vous informer sur la satisfation des clients, sur la qualité des employés et la prospérité de l’entreprise.

Conclusion

En tant que société de conseil en architecture web et en urbanisation du Système d’Information, nous travaillons avec nos clients à l’élaboration d’applications innovantes. Ces applications ont la capacité à monter en charge et apportent une simplicité d’usage qui garantit une utilisation pertinente et efficace dans les différents contextes professionnels de nos clients. Nous avons fait le choix d’écrire un billet sur ce thème afin de nous positionner et de vous proposer le point de vue d’une équipe d’experts du web. Le SaaS est prometteur, il n’y a pas de raison pour ne pas se lancer. De la même manière que le client léger a effacé l’architecture clients / serveurs au tournant des années 2000, nous pensons que le SaaS deviendra incontournable dans les années à venir.

[1] Half of All Developers Expect to Develop SAAS Software in the Next 12 Months, Evans Data, 12/02/2009
[2] Current trends for Web terminology and buzzwords, Pingdom, 08/01/2009

Dans la jungle des frameworks Web disponibles aujourd’hui il peut être difficile de s’y retrouver. Comment choisir le bon ? Celui qui va vous permettre enfin d’augmenter votre productivité dans le développement d’applications Web ?

Mais surtout, un framework Web moderne, c’est quoi ?

A la base, la technologie

Evidemment le choix de votre framework va tout d’abord dépendre de votre technologie de prédilection; RubyOnRails pour ruby, Django pour python, Grails pour groovy, Symfony pour PHP, Play! pour Java … peu importe la technologie en fait : chaque technologie propose un ou plusieurs frameworks. Si vous regardez un peu plus en détail ces différents frameworks vous remarquerez qu’au délà du langage de programmation utilisé, ils partagent les mêmes composants et les mêmes concepts fondamentaux.

Cependant le choix de la technologie n’est pas anodin. Vous devez impérativement choisir un framework qui s’appuie sur la technologie qui vous convient; celle où vous et vos équipes êtes à l’aise. Chaque technologie a sa propre philosophie; et celle-ci a forcément déteint sur la manière dont est conçue le framework. Si vous venez d’un langage statique et très structuré comme Java, vous pourriez bien vous trouver un peu perdu face à l’approche des problématiques adopté par Django par exemple… Choisir un framework qui s’appuie sur une technologie qui vous est totalement étrangère a de nombreuses conséquences, et si vous cherchiez à augmenter votre productivité vous pourriez bien au contraire vous retrouver à passer un temps précieux à faire les choses les plus simples.

Un framework impose son style d’architecture

Globalement il y a deux façons d’appréhender le développement d’applications Web.

Soit on considère que l’architecture du Web est importante. Le Web s’appuie sur le protocole HTTP qui est un protocole sans état. Rien n’existe dans HTTP au dèla du simple couple requête-réponse. On doit donc concevoir l’application Web comme un ensemble de jeux requête-réponse indépendants les uns des autres. Reste à gèrer un minimum d’état global, souvent simplement pour gérer l’authentification, et là quelques patterns simples existent qui permettent de gérer ces cas aux limites sans remettre en cause l’architecture fondamentale (utilisation de session, cookies, …).

Sinon on peut également considérer que le coté “sans état” du Web est une aberration et vouloir s’appuyer sur un framework qui le masque et utilise HTTP comme un simple protocole de communication. De nombreux frameworks proposent une implémentation basée sur cette approche; dans ce type d’applications, les composants (pages, boutons, formulaires) existent sur le serveur en dehors de toute requête HTTP. Les frameworks de type JSF en Java s’appuient sur ce principe qui a l’avantage certain de proposer aux développeurs non familiers du Web un cadre de développement rassurant en première approche: les pages sont construites en glissant-déposant des composants graphiques et en leur associant des traitements.

Cependant en reniant l’aspect sans état du Web on va généralement à la rencontre de problèmes assez complexes à gérer; gestion des boutons suivant/précédent/rafraichir des navigateurs, gestion des bookmarks, des points d’entrée dans l’application non prévus, distribution de l’application sur plusieurs serveurs, …

Le Web a une architecture, respectons la ! Les frameworks que nous avons cité plus hauts (RoR, Django, Symfony, Grails, Play!, …) s’appuient tous au maximum sur l’architecture originale du Web. Et ce n’est pas un hasard si ce sont de ces frameworks dont tout le monde parle aujourd’hui.

Les composants indispensables

Tous les frameworks cités plus haut sont ce que l’on appelle des frameworks MVC. Ils partagent tous la même architecture qui décompose l’application en 3 parties. La couche Controller qui est notifiée des évenements HTTP et qui contient la logique permettant de générer la réponse. Le couche Vue, chargée de générer la réponse proprement dite et qui s’appuie généralement sur un moteur de template. Enfin la couche Modèle qui représente les fonctionnalités de l’application, son modèle objet et ses traitements métiers.

Le “Router” connecte le Web à l’application

Quel type d’évènement HTTP est capable de recevoir l’application et comment sont-ils “traduits” par le framework ? C’est généralement ce composant (que j’appelle ici le “Router”) qui est chargé de faire ce mapping.

Un bon framework est capable de prendre en charge l’ensemble des requêtes HTTP disponibles, doit faire attention au sens du verbe HTTP utilisé dans la requête (GET, POST, …) et ne doit pas imposer de limites dans les schémas d’URL utilisés. D’une manière générale on retrouve souvent les objets requêtes et réponses au niveau du framework et ceux ci doivent se rapprocher au maximum de la logique portée par les requêtes et les réponses HTTP.

Un bon framework Web est également capable de transformer automatiquement les données transportées par la requête HTTP en objets directement exploitables par la technologie de l’application.

Le système de template

Générer les pages HTML affichées à l’utilisateur est une grosse partie du travail que doit réaliser une application Web. Un bon système de template est nécessaire pour faciliter ce rendu. Typiquement on attend d’un système de template qu’il soit capable de naviguer dans le modèle objet de l’application afin d’en extraire l’information intéressante mais aussi qu’il permette d’effectuer les opérations algorithmiques élémentaires (itérations, parties conditionnelles). On utilise alors un langage d’expression simple.

Ce langage d’expression n’est pas un langage de programmation. Même si le framework s’appuie sur une technologie à typage statique, un langage d’expression dynamique simple est généralement plus adapté au système de template. Celui-ci doit permettre d’accéder au moins en lecture aux attributs des objets, et de gérer simplement les cas de valeurs non définies.

Un bon système de template permet de créer des fonctions réutilisables sous forme de tags et des helpers permettant d’affiner l’affichage des types de bases (numérique, date, …). L’héritage entre templates est également un gros “plus” : cette technique permet de composer des pages dont certaines parties sont communes (menus, entête et pied de page, …) et de garantir ainsi une cohérence entre les pages de l’application.

Enfin la gestion de l’internationalisation est indispensable. Cela comprend d’une part la possibilité d’externaliser les messages dans des fichiers de traduction, mais également tout simplement d’être capable d’afficher tous les caractères possibles et donc de supporter entièrement UTF-8 !

L’accès aux données

Les langages que nous utilisons pour le développement d’applications Web sont majoritairement des langages orientés objet, tandis que les données sont généralement stockées dans des bases de données relationnelles. Pour résoudre ce problème historique “d’impedance mismatch”, des outils ORM (Object Relationnal Mapping) sont nécessaires.

Pour une efficacité maximum ce composant ORM doit être parfaitement intégré au framework. Les frameworks s’appuyant sur des langages dynamiques sont généralement avantagés sur ce point car ils ont la possibilité d’adapter “dynamiquement” la structure des objets en fonction du schémas de la base de données.

Mais peut importe l’outil final, tant qu’il permet de créer un vrai modèle objet. Fuyez les frameworks ringard qui vous impose de séparer structure de données et traitements. Cet anti-pattern, le bien nommé “Anemic Domain Model” touche plus particulièrement les frameworks Java influencés par une décennie de mauvaises pratiques initiées avec les EJB. N’oubliez pas que le principe même de la théorie des langages objets et de mixer données et traitement … !

Le plus important : la productivité

C’est le point essentiel. C’est même pour nous la principale raison-d’être d’un framework: augmenter la productivité des développements. La première manière d’améliorer la productivité est évidemment de fournir un cadre de développement, une architecture et des fonctions de haut niveau. Mais il y a également des points plus concrets sur lesquels un framework Web moderne se doit d’intervenir :

Une structure de projet “clé en main”

Un bon framework est capable de générer en une commande une structure de projet prête à l’emploi et prête à être exécutée. Outre le fait que le démarrage d’un nouveau projet est notablement accéléré cela a également un effet de bord intéressant: la structure même du projet est imposée encore plus drastiquement aux développeurs qui n’ont alors aucune raison de s’en écarter. Vous remarquerez que rien ne ressemble plus à un projet Ruby On Rails qu’un autre projet Ruby On Rails, alors que ce n’est pas forcément vrai entre deux projets Struts par exemple.

Le rechargement à chaud

Pour être à l’aise un développeur a besoin de voir immédiatement le résultat de ses modifications sans avoir à jouer un cycle long de compilation, déploiement, redémarrage du serveur. C’est vraiment important. Ici les frameworks qui s’appuient sur des langages de scripts sont généralement avantagés puisqu’ils ne connaissent pas de phase de compilation. Cependant il est possible d’obtenir des résultats équivalent même avec des langages compilés. Par exemple le framework Play! bien qu’utilisant Java est capable de détecter une modification du code source et de prendre en charge automatiquement les phases de compilation et le rechargement à chaud.

La qualité des rapports d’erreur

Même avec le meilleur framework et le meilleur développeur des erreurs surviennent inévitablement. Et ce n’est pas grave en soit. Ce qui est important est comment ces erreurs sont rapportées au développeur : de la qualité des informations remontées par le framework dépend la résolution rapide de l’erreur. Un bon framework Web affichera directement les erreurs dans le navigateur de manière lisible et surtout mettra directement en relation l’erreur et le code source de l’application.

Play!, notre framework de développement Web

Toutes ces techniques et beaucoup d’autres sont implémentées dans Play! notre framework de développement Web. Notre vision claire des objectifs d’un framework et notre volonté d’améliorer sans cesse notre productivité fait de Play! notre arme absolue pour le développement Web.

Si vous cherchez un très bon framework Web en Java, n’hésitez pas à le tester !

La problématique portail

Le portail est une interface web qui agrège les services applicatifs du système d’information de l’entreprise. Comme nous allons le voir, il y a différentes approches pour mettre en oeuvre une telle solution. Les contraintes techniques et fonctionnelles entrent en jeu. Il est donc important de bien appréhender le périmètre de son projet pour proposer une solution cohérente qui répondra aux besoins des utilisateurs.

Les portails JSR-168

Historiquement, pour mettre en place un portail  dans un environnement J2EE, l’entreprise dispose d’une infrastructure standardisée par la spécification Java JSR-168. Cette spécification définit le portail comme un ensemble de fenêtres (portlets) librement assemblables dans une même page Web, regroupées dans des   applications portails (portletapps).

Dans un portail JSR-168, toute la richesse de l’écosystème Java est disponible, ce qui permet de répondre à des besoins variés: on peut ainsi  mettre en oeuvre  portails interactifs, transactifs ou encore collaboratifs. En contrepartie, la construction d’une application en portlets JSR-168 est statique et son intégration opérationnelle dans le portail  nécessite un effort de développement important.

Les portails majoritairement implémentés dans le cadre de projet pour les collectivités et  les entreprises sont Liferay, JBoss Portal, Jetspeed ou encore pict.

Le mashup qu’est ce que c’est ?

Le mashup s’articule autour de services multiples qui peuvent être extérieurs au système d’information. Un mashup, ou application composite, consiste à combiner des données en provenance de sources hétérogènes et généralement distribuées : applications web internes, mais également services externes au système d’information.

Le mashup permet de fédérer et de revaloriser les informations en les transformant notamment en données structurées arbitrairement. Pour implémenter ces fonctionnalités, il est légitime de considérer  les langages XML et JSON et l’approche REST comme les pierres angulaires assurant l’interopérabilité entre systèmes hétérogènes. Dans ce contexte, on distingue l’existence de trois types de mashup: consumer, data et business mashup.

Le premier permet de combiner les données provenant de plusieurs sources en une interface unifiée. Le second combine quant à lui des données similaires. Il existe des data mashup orientés entreprise qui fusionnent les données internes avec des données externes. Lorsque l’on parle de portail, c’est généralement le business mashup qui nous intéresse. Les fonctionnalités apportées par ce type d’application composite sont équivalentes à  celles disponibles dans un portail J2EE. Les business mashup regroupent les fonctionnalités des consumer  mashup et des data mashup.

Deux philosophies

Fondamentalement, le mashup et les portails sont deux philosophies différentes. Pour la première, l’interface est construite coté client avec notamment l’utilisation du langage Javascript et de méthodes asynchrones. Le résultat est une interface riche, dynamique et réactive qui valorise fortement le design et la présentation des données. A l’inverse, les portails traitent l’information coté serveur ou bien utilisent des artifices tels que l’intégration de contenus externes par des iframes. Ainsi, le mashup va davantage solliciter le navigateur du client et peut dans certains cas poser des problèmes de sécurité si certaines bonnes pratiques ne sont pas respectées.  En revanche, la logique du portail est mieux armée pour permettre une gestion consistante des identités et une  sécurité optimale des informations présentées, parfois au détriment de la capacité à monter en charge.

Au niveau de l’architecture, le portail J2EE repose sur la spécification portlet, une API spécifique qui contraint les développeurs à mettre en place des règles de sécurité et de navigation complexes. De plus, il n’est pas possible de tout implémenter avec cette approche. Par exemple, une application portlet ne peut pas être dans deux états différents à un instant donné. A l’inverse,  l’architecture RESTful, à la base des mashups,  est sans état ce qui permet de mieux gérer ces cas de figure.

Une intégration possible…

Aujourd’hui les portails évoluent et intègrent la notion de mashup. Ces portails peuvent prendre différentes formes. Avec l’arrivée d’applications web 2.0 le portail est rapidement entré dans le domaine du grand public et l’internaute s’est rapidement approprié le web avec une nouvelle génération de portails  : iGoogle, Netvibes ou encore avec la présence de sites monolines de plus en plus nombreux. On pense à Flickr, Digg, Last.fm ou encore Delicious. Ces applications web exploitent le mashup pour dynamiser et valoriser le contenu. Ce phénomène s’étend actuellement aux sites à destination des professionnels, on peut citer l’exemple de  la société de services postaux UPS qui propose une API ouverte. D’autres sites tels que Voyages SNCF ou encore Paypal offrent des widgets et peuvent s’intégrer dans des applications professionnelles.

Les portails revendiquent des fonctionnalités avancées au niveau de la sécurité. Un sujet qui revient souvent, est la problématique d’authentification unifiée. Pour une application mashup, où l’essentiel de la collection  et de l’aggrégation des informations se fait sur le client la problématique est hardue. Il existe cependant des solutions ouvertes tel que OpenID qui tendent  à se généraliser.

Les mashups peuvent jouer un grand rôle dans l’environnement des entreprises. Ils créent de nouveaux services pour les consommateurs et ouvrent un nouveau champ de possibilités. Un utilisateur final crée son portail par assemblage de composants mashup et ce, sans nécessiter  de  compétences techniques si ce n’est la maîtrise de la souris. Le mashup rend l’internet personnalisable. Parallèlement, avec les API disponibles, les entreprises peuvent efficacement construire des applications moins chères, réutilisables et maintenables à moindre coût.

Des solutions sur lesquelles s’appuyer

Nous arrivons à la fin de ce billet et nous n’avons pas abordé les moyens à mettre en oeuvre pour élaborer une application en mashup. Il est donc légitime de se demander quels outils et quels frameworks sont utilisés. La réponse est simple : vous connaissez déja ces outils. En résumé, développer un mashup revient à travailler un document XML depuis du code Javascript. Partant de ce constat, vous pouvez utiliser les frameworks javascript suivant : Mootools, JQuery, Dojo ou encore Yahoo! UI.

La question des standards et des bonnes pratiques méritait de conclure cet article. Globalement, on  peut affirmer que le mashup repose sur les standards du W3C. Typiquement on échangera des données au format XML ou JSON. Coté programmation, le javascript peut être considéré comme un langage standardisé, à quelques exceptions près. Cependant l’interopérabilité entre portail reste à concrétiser. Chaque plateforme dipose de ses propres widgets (CBS, facebook, Netvibes, Skype, NBC…). Dans ce contexte, des solutions émergent afin de définir une façon commune de travailler. Ainsi, il est intéressant de suivre les projets OpenSocial de Google et UWA initié par Netvibes. Le premier se concentre sur l’utilisation des réseaux sociaux en fournissant une API commune pour les principaux  réseaux sociaux. Le second définit un cadre de travail pour développer des widgets universels (iPhone, Netvibes, Windows Vista, MySpace, Apple Dashboard…). A terme, on peut imaginer que l’utilisateur aura la possibilité de déplacer des widgets depuis un site web vers son bureau par drag & drop. Dans ce contexte, il est probable que le Système d’Information des entreprises soient la prochaine cible des applications mashups.

L’avènement du logiciel “complexe” correspond à la montée en puissance des applications conçues par assemblage de composants. Cette tendance a été  parfaitement illustrée - voir favorisée diront les lobbyistes Java-  par la montée en puissance de la plate-forme Java et du paradigme interface-implémentations  : les interfaces définissent de manière la plus précise possible les contrats d’échanges entre les composants, charge aux implémentations de les respecter. Lorsque l’expression technique du contrat (interfaces) n’est pas suffisante, on a recours à une définition formelle; Java Specification Requests pour le monde Java.

Ce découpage de plus en plus fin du logiciel ne présente pas que des avantages :  qui dit multiplication des composants dit augmentation des zones de friction et de faiblesse,  et d’un point de vue organisationnel, une dilution des responsabilités, notamment lorsque l’application fonctionne mal… Chaque point de communication entre composants est potentiellement source de problèmes, chaque mise à jour de versions de l’un d’entre eux remet potentiellement en cause l’équilibre de l’édifice. La fluidité de la communication inter-composants est souvent à l’image de la communication entre les équipes projets en charge de leur conception et de leur réalisation.

Lorsque l’on conçoit et construit une application, l’une des étapes indispensables consiste à qualifier chacun de ses composants selon ses qualités intrinsèques d’une part, mais aussi selon l’excellence de son comportement avec les autres composants : en sciences sociales on parlerait de sociabilité. Force est de constater que cette étape n’est que rarement appréhendée. Choix de solutions obsolètes ou non maintenues, détournement de composants, c’est à dire leur utilisation hors de leur zone de confort, composants malpolis ( c’est à dire ne respectant pas leur contrat) ou encore muets (dont l’absence de traces interdit tout diagnostique) sont quelques-uns des symptômes les plus fréquents que nous constatons sur les applications à base de composants. Les critères de sociabilité sont notoirement critiques, puisque c’est aux frontières des composants que s’accumulent nombre d’erreurs et autres compatibility issues, qui par ailleurs ne sont pas toujours détectés: la pratique des tests d’intégration n’atteint pas le degré d’industrialisation et d’automatisation que l’on peut constater par exemple avec les tests unitaires.

La plate-forme Java EE est elle-même un exemple d’édifice complexe basé sur des composants. Vue sous l’angle de l’architecte, JEE est en effet un ensemble de services détaillés dans le cadre de spécifications (les JSRs) puis implémentés par les éditeurs de plate-formes estampillées JEE. EJB, JDBC, JMS, Servlets sont quelques-unes de ces spécifications qui agissent de concert pour offrir un socle d’exécution pour les procédures complexes : le serveur d’applications.

“Stick to standards”, really ?

“Tenez-vous en aux composants standards” vous diront certains. C’est un message certes séduisant de prime abord, mais qui ne dit pas comment faire lorsque la problématique adressée sort des solutions standards. D’autre part, tous les standards ne sont pas bons à adopter. Corba, EJB, JDO, les fossés de l’histoire de l’informatique d’entreprise sont jonchés de “standards d’avenir” qui n’ont pas tenu leurs promesses! Le framework standard JEE orienté évènements Java Server Faces constitue le dernier avatar du standard “raté”, qui ne tient pas la comparaison face aux alternatives open-sources, plus élégants, simples à mettre en œuvre ou plus évolutifs tels que Wicket.

La force d’un écosystème comme celui de Java est précisément de proposer une multitude de composants ou frameworks alternatifs, utilisables lorsque les solutions standards ne conviennent pas. Le succès remporté par des frameworks comme Hibernate démontre s’il était besoin, la validité des approches concurrentielles.

Quelle démarche pour choisir un composant ?

Bien qu’il n’y ait pas de méthodologie universelle pour qualifier un composant, il y a bien quelques recettes à appliquer. Une veille technologique, dans la durée, est la première étape cruciale, qui permet notamment de discerner les tendances lourdes des simples effets de mode ou de buzz. Lorsque l’alternative subsiste entre telle et telle solutions, des analyses qualitatives complémentaires ou une mise en oeuvre de POC permettent de discriminer les solutions restant en lices, selon une matrice pré-établie de critères portant sur la qualité, la productivité, les performances, l’ouverture. Finalement, le retour d’expérience des early adopters constitue toujours une source précieuse d’enseignements.

Après le premier cycle d’investissement des entreprises qui ont choisi Java comme technologie de base pour la la refonte de leur système d’information en mode “Web”, on peut faire les comptes.

Et les retours d’expériences ne sont pas vraiment glorieux. Outre des problèmes récurrents de performance, ce que nos clients reprochent à Java est avant tout une productivité bien plus faible que celle espérée. Les projets ont du mal à aboutir et lorsqu’ils sortent enfin, leur mise en production est plutôt laborieuse malgré des investissements colossaux dans des solutions JEE “entreprise”.

Alors est t’il temps d’abandonner Java pour une de ces technologies miracles basée sur un langage dynamique ? Le problème n’est pas si simple. Et bien que Java en tant que langage soit loin d’être le meilleur, la majorité des problèmes ne viennent pas du langage proprement dit mais surtout de l’ écosystème qui permet de faire du Web avec Java : aujourd’hui c’est JEE.

Le problème avec JEE

Lorsqu’on veut faire du Web avec Java la méthode “standard” est de s’appuyer sur JEE (Java Enterprise Edition). Cet ensemble de frameworks “entreprise” contient tout ce qu’il faut pour connecter une application Java au Web. En théorie. Parce que JEE n’a jamais rempli sa mission: développer une application Web en s’appuyant uniquement sur ce framework est vraiment trop fastidieux.

L’exemple le plus frappant est la brique fondamentale qui permet de faire du Web en Java : l’API des servlets. Celle ci a été conçu non pas comme une API permettant de créer un service HTTP en Java mais comme une API générique permettant de créer potentiellement n’importe quel service indépendamment du protocole. Et naturellement depuis 10 ans il n’y a toujours qu’une seule implémentation : HTTP. On se retrouve donc à manipuler HTTP grâce à une API pas totalement prévue pour ça et qui ne transpose que vaguement les concepts du Web.

Un autre exemple ? JSF le framework JEE censé faciliter la création des IHMs Web. A peine la spécification terminée et les première implémentations disponibles le “Web 2.0″ change tout dans la manière de créer une application Web : AJAX devient incontournable et on commence à redécouvrir HTTP avec les architecture REST. Pas de chance pour JSF, son modèle purement statefull est incompatible avec REST, les implémentation détournent HTTP pour des raison d’implémentation et la moindre requête AJAX se révèle un enfer à implémenter. Encore une fois on se rend compte un peu tard que JEE n’a pas grand chose à voir avec le Web.

La survie de Java va t’elle passer par l’abandon de JEE ?

Cependant Java ne se limite pas à JEE. Une multitude de framework permettent de créer des applications Web plus simplement. Et bonne nouvelle, ces frameworks se désengagent peu à peu du carcan du “standard JEE”. Ce sont des framework Java qui permettent de créer des applications Web sans servlet, des systèmes de templates qui remplacent efficacement JSP. Ces frameworks souvent inspirés des modèles existants dans d’autres technologies sont une réelle alternative à JEE.

Même les solutions “entreprise” s’y mettent. Ces derniers mois plusieurs solutions majeures ont attirés notre attention.

SpringSource, la société derrière le framework Spring propose un serveur d’application Java non JEE, “SpringSource application platform” ! Les technologies spring sont déjà énormément utilisées dans les applications JEE, mais finalement on peut considérer que l’adhérence à JEE et aux spécifications standard n’apporte aucune valeur ajoutée réelle : les même technologies simplifiées et packagées ensemble dans un véritable “application server” offre une alternative tout aussi sérieuse et surtout plus simple et plus agile.

Même IBM sort son Websphere non JEE ! Websphere Smash est le nouveau serveur d’application prévu pour créer les applications Web de manière agile. Tout en continuant à s’appuyer sur la plate forme Java il s’ouvre a d’autres langages tels que groovy et PHP. Mais surtout plus question de Servlet de JSP de JSF ou même de WAR …

Au final Java peut trés bien offrir un socle de développement productif et efficace pour le Web, capable de s’affirmer face aux autres technologies. Java a certe de nombreuses faiblesses par rapport aux langages dynamiques concurrent (Python, Ruby, PHP) mais offre également de nombreuses facilités qui sont une vraie force dans certains contextes : erreurs de code detectées à la compilation, facilitées pour le refactoring grâce au typage statique, excellent outillage, IDE, Debugger, hautes performances …

A condition de revoir complétement les frameworks !