insideIT.fr : le blog des architectes IT de SFEIR

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 8 octobre 2008

VS 2010 et .Net 4.0 surfent sur la vague des plateformes Next gen

die_hard_4_1 Si vous vous souvenez (ce dont je doute), nous avions ici même annoncé un 1 avril la sortie imminente du framework 4.0. Le canular était gros ? La réalité le dépasse. Un certain "Rosario", nom de code de la future version de Visual Studio s'annonce tonitruant. Son optique est plus que jamais de faciliter l'interaction entre architectes, designers d'applications, programmeurs, testeurs, chefs de projets et commerciaux, de briser les silos. Et pour cela qu'offre-t-il ?

- Un outil de gestion du cycle de vie des applications (ALM pour Application Life-cycle Management).

- Des interfaces graphiques de design métier et système à base d'UML et de DSL: les "modeling tools". Ce n'est donc pas un hasard si Microsoft a rejoint l'OMG il y a peu.

- Un vrai effort a été fait du côté des outils de tests (qui manquaient un peu jusque là) pour apporter enfin une alternative aux sempiternels tests manuels.

- Une plus forte adhérence aux méthodes agiles avec TFS (le Team Foundation Server) qui devient un vrai Hub de collaboration entre acteurs du projet.

- Des outils permettant de travailler sur les bugs non reproductibles.

Cette nouvelle version est la confirmation d'une nouvelle stratégie entamée dans le passage de la version 2005 vers 2008 qui est celle d'un dialogue réel avec les utilisateurs de Visual Studio. Et l'ouverture à l'open source qui se confirme comme pour l'intégration de jQuery, le framework javascript open source pour l'AJAX.

Qu'apporte le framework 4.0 de son côté ? Il surfe sur le Cloud Computing, vise plus que jamais le "developer delight", confirme la percée du parallel computing, des traitements distribués, de l'exploitation des processeurs multi-coeur, il améliore la partie SOA (notamment avec REST pour WCF), augmente les interactions entre WF et WCF. Et ce n'est qu'un début. Le reste sera annoncé à la PDC (Professional Developers Conference), à suivre donc.

Maintenant, pour désamorcer les moqueries que l'on sent déjà venir sur la vitesse des sorties de nouveau framework, rappelons que depuis le Framework 2.0, chaque nouvel opus vient compléter le précédent et non le remplacer. Donc pas de panique. Pas la peine de tout remettre en cause dans les applications existantes, votre plan d'action visant à convaincre votre chef de projet de la nécessité de passer au framework 3.5 (et qui vous promet déjà de longs débats) ne vole pas en éclat.

Je préfère laisser la conclusion au Senior Vice President de la division développeurs de Microsoft, S. Somasegar :

"With Visual Studio 2010 and the .NET Framework 4.0, we are focussed on the core pillars of developer experience, support for the latest platforms spanning client, server, services and devices, targeted experiences for specific application types, and core architecture improvements. These pillars are designed specifically to meet the needs of developers, the teams that drive the application life cycle from idea to delivery, and the customers that demand the highest quality applications across multiple platforms. You can expect to hear a lot more about Visual Studio 2010 and the .NET Framework 4.0 in the coming months."

Plein de promesses en perspectives et pourtant c'est pas encore Noël ! Alors à votre avis, en avril prochain, on vous fait le coup du Framework 5.0 ou il faudra taper plus haut ?

jeudi 19 juin 2008

TheServerSide Java Symposium - Jour 2

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!