Spring annonce en ce moment à JavaOne Spring Application Plateform (ce qui donne SAP en acronyme, finalement on en est plus très loin). En résumé, S2AP (oui le "2" c'est justement pour se différencier de l'ERP éponyme) est une sorte de Framework d'entreprise s'appuyant sur OSGI pour fournir un noyau basé sur un système de dépendances configurables dynamiquement.

Dans cet amas de briques technologiques aux allures bling bling, un nouveau format de fichier fait son apparition : le PAR (Plateform Archive), une collection de bundles OSGI groupé dans un JAR classique. Côté noyau, Spring annonce DMK (Dynamic Module Kernel), encore un module OSGI configurable dynamiquement. Je vous passe les détails des profiles, personality et autres SSI (Single System Image) pour le Clustering (qui n'existait pas jusqu'à présent). Ce billet de Rob Harrop nous en dit plus sur le "nouveau" positionnement de SpringSource.

Et j'oubliais. Au passage, Spring offrira deux mode de licences : GPLv3 ou commerciale payante (tient tout cela me rappelle quelque chose).

Pour faire court, Spring prend une tournure que je trouve complètement burlesque. Voilà un Framework qui a été créé pour être indépendant des Frameworks (EJB, JMS, JCA, Remoting avec Corba/RMI/WS) et qui aujourd'hui, après s'être rendu compte qu'un Framework sans services techniques n'est que coquille vide, propose désormais toute une ribambelle d'API complètement propriétaires. L'idéal de Spring a toujours été pour moi l'abstraction procurée par l'injection de dépendances. Lorsqu'on compare S2AP à un conteneur EJB 3 de base, il n'y a plus rien qui démarque Spring. Tous font de l'OSGI, tous proposent du POJO-like, tous se déployent en mode embedded dans un Tomcat et ce que Spring appelle DMK n'est rien de plus qu'un micro-noyau de serveur d'application avec des services techniques (admin, clustering, etc...)

Spring Framework lui (dont la licence reste en Apache 2.0) est toujours un projet actif et fonctionne aussi très bien sans S2AP.

A quand un projet qui permettra de créer une abstraction au dessus de S2AP et EJB3 ? On pourrait l'appeler MetaSpring par exemple ...

Cela fait plusieurs mois que je cherchais à renouveler mes outils de travail. C'est bien beau de mettre en place des Frameworks, des patterns et des bonnes pratiques pour être plus productif, mais encore faut-il avoir une machine et des outils qui supportent la charge.

J'ai toujours été un avide supporter des machines virtuelles.

Lire la suite »

J'avoue avoir découvert cette bibliothèque JavaScript lors d'un récent billet de Sanjiv Jivan (développeur de GWT Ext) lorsqu'il parla en ces termes de Smart Client :

There are several other excellent Javascript libraries like SmartClient that haven't gained the recognition they deserve and community support only because they were honest and consistent in their licensing model

Ce projet au nom peu évocateur est d'une richesse incommensurable comparée à ses concurrents (même si d'un point de vue graphique, il y a encore un peu de travail).

Lire la suite »

J'ai toujours pointé du doigt les déficits de Flex/AIR en terme d'homogénéité. L'intégration et l'homogénéité d'une plateforme sont les points essentiels qui lui permettent d'être productive. Aujourd'hui, AIR c'est plus de quatre ou cinq technologies et plateformes différentes.  On développe en ActionScript, on génère du byte code Flash et on s'interface avec le serveur avec Java, Php ou des services REST. Il suffit qu'on souhaite mettre en oeuvre du messaging asynchrone, des EJB 3 et là surgisse les autres BlazeDS AMF ou FDS.

Bref, tout cela est loin de l'atelier Eclipse ou VS.NET tout intégré permettant d'utiliser le même langage et le déboggueur côté client et côté serveur. Voilà pourquoi, même si je considère aujourd'hui Silverlight encore en retard par rapport à Flex, je lui confère une marge de progression supérieure. A terme, Silverlight a plus de chance de percer chez les développeurs là où Flex restera l'apanage des graphistes. Si on observe la culture de Microsoft et celle d'Adobe, tout cela reste finalement cohérent.

Dans ce paysage, plusieurs acteurs ont compris qu'aujourd'hui le choix du langage et de la plateforme était important (plus que celui de la VM ou du moteur de rendu) avec notamment JSeamless qui, pour résumer très grossièrement, est une sorte de GWT qui génère du Flash. Il faut dire que la démo est assez convaincante. Un projet à suivre, surtout si la licence reste en BSD..

Jusqu'à présent j'expliquais simplement de manière théorique en quoi le mode "convention over configuration" et la gestion de la persistance dans Rails étaient des points qui me semblaient peu "scalables". Notamment ActiveRecord, qui me semble être un pattern très dangereux, surtout lorsqu'on s'appuie sur une base de données au schéma complexe.

De la théorie à la pratique, il n'y avait finalement qu'un pas. Voici que le plus gros "client" RoR au monde vient de lâcher prise après des années d'efforts pour stabiliser les serveurs en production. 3 jours d'indisponibilité de Twitter, mais aussi d'une application FaceBook très importante auront eu raison de RoR.

A noter que le langage Ruby n'est bien entendu pas la cause du problème.

A qui le tour ?

update : Comme toute info un peu sensible, il y a des versions contradictoires et personne ne veut prendre la responsabilité d'une annonce officielle. Mais il semble quand même que Rails ne soit plus en odeur de sainteté.