insideIT.fr : le blog des architectes IT de SFEIR

C’est un peu la technique de l’hameçon. Dans cette époque, où le mot “gratuit” fait office de slogan marketing, mieux vaut offrir au client ce qui lui semble coûteux à lui et qui ne rapporte finalement pas grand chose. Un IDE ou un outil de design n’a jamais donné un retour sur investissement énorme en lui-même. C’est la raison pour laquelle Eclipse a toujours été gratuit. Ce qui rapporte vraiment ce sont les licences serveurs, bien entendu. Et des outils de développement gratuits, ce sont des développeurs qui testent l’outil, montent en compétences dessus, prennent des habitudes, des réflexes et deviennent les meilleurs ambassadeurs de la marque. Et les managers sont souvent plus influencés qu’on ne croit par leurs développeurs ou designers, surtout si ceux-ci sont enthousiastes.

Cette offre, c’est donc une façon de promouvoir l’outil SharePoint dans son ensemble, en courtisant les développeurs. De la même manière, Windows SharePoint Services est fournit gratuitement avec Windows Server et vise cette fois les administrateurs. On l’utilise, on y prend goût et puis on s’aperçoit des améliorations réelles qu’apporte MOSS, qui lui, est facturé au processeur. Il y en a pour tout le monde et tout le monde est gagnant.

Alors, à quand Visual Studio ou la gamme Expression gratuits ?

A télécharger sur : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=baa3ad86-bfc1-4bd4-9812-d9e710d44f42

Q&A sur ce changement : http://office.microsoft.com/en-us/sharepointdesigner/HA103607621033.aspx

La journée d’aujourd’hui a commencé fort, avec un keynote de Neal Ford Language Oriented Programming: Shifting Paradigms. Une présentation impressionnante, avec des slides à faire pâlir d’envie Al Gore, et une parfaite maîtrise…

S’appuyant sur un cas concret, Neal montre que la façon de résoudre un problème dans le monde informatique d’aujourd’hui est souvent de créer un framework (aussi petit soit-il) qui généralise le problème, puis de le configurer pour résoudre le cas particulier qui nous préoccupe. Or cela conduit à du code qui est rempli de “bruit” (comprendre: redondance et constructions syntaxiques), illisible par les personnes du domaine métier, et donc ne peut être validé. Que fait-on alors? On externalise le code dans un fichier de paramétrage, XML forcément, mais ça ne le rend pas plus lisible par le métier…

La solution ce sont les DSL, Domain-Specific Languages, qui permettent d’exprimer des notions propres au métier d’une façon accessible aux hommes du métier. On peut les diviser en:

• DSL internes: utilisant les constructions du langage hôte
• DSL externes: indépendants d’un langage

Un exemple de DSL interne en Java est JMock, qui permet d’écrire des choses du genre:

   one(gt).getGreeting(); will(returnValue(”Good afternoon”));

C’est ce quon appelle “fluent interface”, car on cherche à imiter le langage naturel, quitte à introduire des artefacts sans utilité (“bubble words”). En Java ça reste fortement contraint par la rigidité du langage, mais dans les langages dynamiques on peut faire des choses beaucoup plus avancées.

XML est une forme de DSL externe, a fortiori.. Mais selon Neal XML est obsolète ! (Pas de polémique…). Le futur c’est de modéliser le métier à un niveau d’abstraction supérieur, que ce soit via un langage ou en manipulant un arbre abstrait (ce que certains IDEs tendent déjà à faire), et ensuite d’exécuter le résultat dans un contexte qui, selon le cas, donnera un schéma de DB, un exécutable, etc.

Ce fut de loin la meilleure conf des 2 premiers jours, prenante et stimulante…

Ensuite je choisis d’assister à la conf Son of SOA: Event-Driven Architecture and the Real World, par Eugene Ciurana (LeapFrog). Ca commence par des challenges (calendrier serré, équipe à construire, politique IT rigide, existant à intégrer, …) qui sont autant de challenges si on les voit d’un autre angle. Le choix a été de mettre en place un architecture Resource-Oriented, où tout est considéré comme une ressource, services comme données, et acccessible par une URI. Même si ça ressemble furieusement à du REST, Eugene s’en défend; en effet il y a quelques différences, notamment le mélange entre verbe et nom dans l’URI, mais globalement la différence est si fine qu’elle est invisible.

Eugene a mis en place des outils “best of breed”, avec MuleESB à la place d’honneur, en tant que backbone et resource container. Aussi choisis: Crowd pour le SSO, GWT (tiens…), Wicket, Communiqué (CMS). Au final une success story bien ficelée.

Ensuite je vais découvrir Comet: Building a richer, more interactive web application, avec Ric Smith de kaazing.com. Il s’agit d’expliquer les mécanismes qui permettent de faire du reverse push, ou reverse AJAX, c'est à dire de permettre à une application AJAX d'être notifiée par le serveur de nouveaux événements, par opposition au polling où c'est le client qui interroge périodiquement le serveur. Les avantages sont clairs dans des applications type finances, jeux ou paris, ou tous domaines où le 1/10 de seconde peut faire la différence.

Historiquement, la première façon d'implémenter le push est un iframe invisible, dans lequel le serveur reçoit en continu des balises <script> qui déclenchent l'exécution de callbacks côté browser. Ca marche, mais avec des effets de bord parfois très gênants (clignotement du curseur, fuites mémoire, ...).

Deuxième technique, le XHT long-polling: le client lance une requête qui ne revient que lorsque des données sont dispo. La connexion est fermée, et ré-établie immédiatement. Problèmes: léger overhead dû à la reconnexion, et latence possible.

Autre option, XHR streaming. Pour cela, on a besoin que le browser implémente "onreadystate". La réponse à la requête XHR ne se termine jamais, et lorsque des données sont dispo un callback est appelé. Principal souci, le support limité de cette fonctionnalité dans le parc de browers.

Dernière option, la connexion socket, qui nécessite un plugin (Flash, SIlverlight, Java). Ici on s'appuie sur des fonctionnalités du plugin pour établir une connexion serveur rémanente et notifier le browser.

Enfin, à l'avenir HTML5 intégrera la notion de server-side events, et le serveur pourra alors envoyer un type MIME application/x-dom-server-event qui activera un callback. Mais ce n'est pas pour demain.

Un point important à considérer est le couplage connexion-thread qui existe dans les serveurs classiques; en effet si 100 000 clients sont en attente d'évenements, on ne peut pas admettre de créer autant de threads. Jetty et d'autres résolvent ce problème avec la notion de "Continutation" qui permet de rendre les threads indépendants des connexions.

Un tour d'horizon super intéressant du problème !

Avant de manger, un Expert Panel: Languages: The Next Generation, composé de Ted Neward, Ola Bini et Guilaume Laforge, discute de la prochaine génération de languages. C'est très divertissant, et il en ressort surtout qu'il n'y aura pas de "next big language", mais que comme Neal Ford l'a prédit, les DSL vont prendre le devant de la scène, avec les langages dynamiques...

Midi, cette fois j'ai compris le truc pour ne pas faire la queue aux plats chauds: d'abord le buffet froid où il n'y a personne, ensuite les plats chauds!

Je saute le Vendor Tech Brief, encore GigaSpaces (eh oui ils sont le principal sponsor). Je vais récupérer mon T-shirt JavaBlackBelt gagné au concours hier, et une petite démo de JavaRebel s'avère assez impressionnante: rechargement à chaud des classes sans arrêt redémarrage! Un confort et une productivité qu'on a oublié sous Java, à force d'appeler des scripts ant et de redéployer à tout bout de champ.

The Enterprise Without a DB, par John Davies: ça fait longtemps que je traîne l'obligation de travailler avec des bases relationnelles comme un boulet, d'où mon intérêt pour ce sujet. John montre l'absurdité de la situation: le schéma FpML compte plus de 4000 éléments, et peut aller jusqu'à 12 niveaux de profondeur. Il est quasiment impossible de mapper un tel schéma avec un ORM. Les DB XML de leur côté n'ont pas d'API standard, et ont des performances sous optimales. Ce que propose John: utiliser le caching, la mémoire quoi, et travailler avec un data grid. Il cite plusieurs outils qui tendent vers ce but: GemStone, TangoSol (acheté par Oracle), GigaSpaces, Terracotta.

Malheureusement, de trop nombreux outils (reporting, etc) et un poids historique des tenants du camp "DB" rend cette approche exotique, et pour encore longtemps.

What's new in EJB 3.1, par Anotnio Goncalves: Non EJB n'est pas mort! Même si la spec 2.1 l'a presque tué... Aujourd'hui les EJB 3 (JSR 220) sont un soulagement pour qui fait des EJB: POJOs, interfaces simples, injection, annotations, peu de XML à écrire... Les EJB 3.1 (JSR 318) ont pour objectif de les rendre encore plus simple à utiliser, et d'amener de nouvelles foinctionnalités. On note déjà que JPA a son propre JSR (317), ce qui aidera peut-être à redorer son blason. Ensuite l'interface locale devient facultative! l'injection reste obligatoire. Il sera aussi possible de packager des EJB dans un WAR tout simplement, en gardant la fonctionnalité EJB. Enfin différents profils seront définis: A (minimal, pas d'EJB), B (EJB lite), full (EJB complet plus une trentaine d'autres specs). Nouveau encore: la notion de singleton, les appels asynchrones, et le timer service.

Java EE 6 (sortie Q1 2009) embarquera EJB 3.1.

On finit par un Fireside Chat: Zero Turneround in Java Development, où je revois les démos JavaRebel et Grails, plus Geert Bevin (Uwyn) qui présente RIFE.

Rendez-vous demain pour la clôture!

En quelques heures de présentations, assumées comme un écho de la grand-messe de Las Vegas, c'est tout le nouveau visage du web qui a été dessiné. La toile de fond c'est internet bien sûr. Mais le support lui, devient multiple. Les applications riches sont à la fois sur internet mais aussi sur le poste de travail ou sur le mobile. Et la même information doit être disponible partout avec un mot d'ordre : la continuité. On doit pouvoir regarder le début d'une émission à la télé et la fin sur son PC ou son mobile. Il en va de même pour tous les services disponibles ou envisageables.

Parallèlement, l'enjeu n'est plus d'être présent sur internet mais d'y être vu, d'y être "trouvé" (selon l'expression de Dick Lantim). Tous les moyens sont bons pour entraîner les gens (de leur plein gré) sur votre site. Facebook est omniprésent ? Faites des mashups qui reprennent les points clé de votre site et feront de véritables appels d'air vers lui (Popfly). Google est incontournable mais n'aime pas beaucoup les sites multi-média ? Silverlight devient scrawlable (Quand l'agent détecté est un robot ou scrawler, le contenu renvoyé est du pur html, c'est le Silverlight SEO pour Search Engine Optimisation). Vous communiquez via MSN Messenger mais vous aimeriez envoyer autre chose que du texte ? Vous pourrez sous peu envoyer en guise de message des extraits de vidéos glanées sur les web tv (sous forme de cue point).

Enfin, la fidélisation devient primordiale. Après avoir fait venir l'utilisateur, le client, il faut qu'il reste, il faut qu'il adhère (dans tous les sens du terme). Il faut trouver les bonnes affordances (le gros mot n'est pas de moi mais d'Amélie Boucher de People Square). Là est mis en exergue la différence fondamentale entre utilité et utilisable. Si votre site est utile, les gens viendront, si il est "utilisable" (ergonomique) ils resteront. Et il ne faut pas négliger cela. Car à quoi servirait de déployer tant d'efforts et de budget pour sortir ce site dont vous rêviez, dont le marketing rêvait, que vos clients attendaient avec impatience, si après une heure de tentatives infructueuses, les-dit clients repartent insatisfaits, n'ayant pas compris comment ça marchait.

Allez, je ne résiste pas à une petite formule choc offerte pour l'occasion :

RDA + RIA* = RIA**

(* Rich Internet Application, ** Rich Interactive Application)

Cette formule est lourde de sens. Eh oui le focus n'est plus sur internet, il est sur l'interactivité.