insideIT.fr : le blog des architectes IT de SFEIR

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

Tag - Architecture

Fil des billets - Fil des commentaires

mardi 16 juin 2009

Domain Driven Design : Eric Evans à l’EPITA le 15 Juin 2009

Le Paris JUG a fait très fort en réunissant plus d’une centaine de personnes à l’EPITA : bien que la conférence ait été annoncée quelques jours à l’avance et que le lieu de rendez-vous ait changé, c’était dans une salle presque comble que nous nous retrouvions hier soir.

La popularité montante du DDD mais aussi le networking y sont probablement pour beaucoup. C’était donc Eric Evans en personne qui a présenté sa session «DDD: putting the model to work» que vous pouvez suivre sur InfoQ Lors de cette session, Eric définit les termes «domain» et «model» :

Domaine : Ensemble de connaissances, d’influences ou d’activités.

Modèle : Ensemble d’abstractions qui décrivent des aspects que l’on a choisi dans un domaine. Le modèle est destiné à résoudre des problèmes liés au domaine qu’il représente.

Eric insiste alors sur le fait qu’un modèle ne doit pas tenter de résoudre tous les problèmes mais doit au contraire être restraint à des scénarios spécifiques. Il cite en exemple une vieille carte de la chine qui était utile à l’époque mais dans le contexte actuel où l’export est au coeur de l’économie chinoise, elle ne répond plus aux nouveaux besoins liés à l’ouverture de la Chine. De même l’exemple du planisphère montre qu’un modèle a tendance à s’éloigner de la réalité.

Le domaine du transport de conteneurs qui est tiré du livre «Domain-Driven Design» est intéressant car un modèle qui marchait bien pour les réservations et le calcul d’itinéraires (un itinéraire est composé de n étapes) n’a pas de sens si on tente de l’appliquer à un contexte d’optimisation des transports (il faut alors définir une structure de graphe).

Il y a toujours plusieurs modèles pour un domaine : il est nécessaire alors de bien délimiter les contextes. Le contexte est un cadre autour d’un mot ou d’une affirmation et qui va déterminer le sens de ce dernier. Un contexte délimité va alors limiter le champ d’application d’un modèle et par conséquent le simplifier et le rendre utilisable.

Enfin le DDD n’est pas toujours une solution appropriée car elle nécessite un dialogue avec les experts du domaine pour réaliser un modèle. Ce processus doit de plus suivre une approche itérative car on est toujours amené à faire du refactoring. Ce dialogue nécessite également de définir un langage commun (Ubiquitous language). Le modèle reprend alors les termes définis par ce langage et reste synchronisé avec ce dernier (implique les refactorings).

Il existe des frameworks encore au stade expérimental qui permettent de faciliter cette démarche. Qi4J (prononcer tchi-for-j) a été mentionné, il se base sur les motifs définis dans le livre d’Érice Evans. Son concepteur fait une comparaison avec un exemple DDD standard dans cette vidéo (Oredev 2008). C’est très prometteur !

Ont également été cités les BRMS, les langages fonctionnels et les DSL qui sont bénéfique à une approche DDD notamment par leur expressivité.

Et aussi dans la catégorie «considérations métaphysiques», pourquoi le terme «domain» plutôt que «business», sachant que l’on utilise souvent le terme «métier» en Français. Selon Éric on ne parle pas toujours d’un métier en DDD. À méditer :)...

Pour en savoir un peu plus, le livre d’Éric «Domain-Driven Design» semble être la référence. Notez également qu’Antonio Goncalves sera au Monde en Tique le 20 Juin pour dédicacer son livre sur Java EE 6.

samedi 21 juin 2008

TheServerSide Java Symposium - Jour 3

Troisième et dernier jour du symposium…je n’ai pas gagné l’iPod qui était en jeu, dommage, j’aurais pu tester GWT dessus ;)

On commence par une conférence de Geert Bevin: Boldly go where the Java language has never gone before. On le sait, Java ce n’est pas qu’un langage, c’est un langage, une JVM et une plateforme, qui ont chacun leurs points forts mais aussi leurs limites. Dès lors, l’idée, qui est à la mode ces derniers temps, c’est que l’on peut remplacer ou modifier un de ces composants pour “pousser l’enveloppe” lorsque les limites se font sentir.

Geert cite 4 exemples pour illustrer cette approche.

  1. Terracotta: il s’agit d’une extension de la JVM qui facilite la scalabilité des applications, en permettant de mettre des JVM en cluster. Déclarativement, certains objets (“shared objects”) sont répliqués entre toutes les JVM, et accédés indifféremment (avec du lazy loading) par toutes les instances. On a ainsi étendu le comportement natif de la JVM.
  2. RIFE continuations: déjà évoqué hier au sujet de Comet, il s’agit pour prendre une image de prendre une photo de l’état d’un thread, comme un “save game” (c’est l’image donnée par Geert). On peut à tout moment appeler pause(), ce qui crée une sauvegarde et rend la main immédiatement, puis reprendre à partir de n’importe quel état avec resume(). Les continuations sont organisées en arbre (parent = continuation à partir de laquelle on a restauré). Encore une fois, on change la sémantique habituelle de la JVM dans sa gestion des threads.
  3. GWT: on ne présente plus GWT, Geert fait un rappel des principes de fonctionnement (translation Java->Javascript, mode hosted vs. compilé, debugging, etc.). Ici on a remplacé l’ensemble du stack Java par une plateforme web pure, et seul le développement utilise le stack Java standard. Un participant pose la question du JavaScript généré, et Geert dit que pour lui c’est un problème, car le JavaScript généré est illisible et impossible à débugger… je bondis intérieurement, et j’irai voir Geert à la fin pour lui expliquer que pour GWT, le browser est la plateforme, la lisibilité du JavaScript généré est aussi peu importante que la lisibilité du bytecode généré par le compilateur Java! Je ne pouvais pas laisser passer ça…
  4. Android: la plateforme mobile de Google. Comme pour GWT, le développement et debugging se font en Java, avec les IDEs habituels, et un émulateur de la plateforme mobile (équivalent au mode hosted de GWT). En revanche pour le déploiement, le bytecode Java est converti en bytecode (.dex) pour la machine virtuelle Dalvik, qui est l’équivalent de la JVM.

On aurait pu multiplier les exemples, notamment les langages dynamiques qui fleurissent sur la JVM, mais le point est fait. A mon sens, ces multiples extensions et détournements sont plus des preuves de la puissance de Java que de sa faiblesse, car Java reste toujours au centre d’un écosystème qui est plus bouillonnant que jamais.

 

Deuxième conf: JCR: TheServerSide as a Content Application. David Neuscheler (days.com) introduit JCR, version 1.0 (JSR 170) et 2.0 (JSR 283), les diférentes fonctionnalités d’un système de CM, etc. Puis il fait une démo en prenant une page du site TheServerSide.com, et en la transformant en appli client JCR. Pour tout dire c’est un peu fastidieux, et d’où je suis on n'arrive pas à lire le code ! J'aurais peut-être dû choisir la conf sur MapReduce dans l'autre salle...

 

Dernière conf du matin, Michael Keith présente What's new in JPA 2.0. Les objectifs étaient multiples:

  • standardiser les propriétés
  • remplir les manques de l'ORM
  • rendre la modélisation objet plus flexible
  • fournir une abstraction du contrôle du cache
  • contrôle du verrouillage (locking)
  • fournir des "hooks" pour des frameworks propriétaires
  • améliorations JPQL
  • etc.

Je ne vais pas détailler les nouveautés, mais globalement il semble que le groupe de travail JPA a bien écouté les utilisateurs, et lorsque JPA 2.0 sera sorti, il sera difficile de justifier l'utilisation directe d'une API de persistence propriétaire.Au passage, la présentation a été agrémentée d'une page culturelle sur les oies du Canada...

 

Comme hier et avant-hier, déjeuner avec un lance-pierres... et en plus ils ont enlevé les machines à café !

 

L'après-midi commence avec Choosing a Web framework, par Shashank Tiwari. En fait de conseils pratiques, il s'agit d'une énumération de définitions, de généralités, de questions (quel problème résout un framework, quel problème crée-t-il?), tout ça pour finir par dire que toutes les raisons sont bonnes de choisir un framework, y compris parce qu'il est à la mode ou pour faire bien sur son CV !!! Au final si on est en recherche d'un framework, cette conférence ne fait qu'ajouter à la confusion et à l'incertitude. Ou comment gâcher un bon sujet.

 

Case Study: Better Software with the Spring portfolio, par Eberhard Wolff (SpringSource Allemagne). Pour info, SpringSource est la société qui emploie tous les committers de Spring, mais aussi certains de Tomcat et Apache. Spring, outre le framework bien connu, c'est aussi dynamic modules, batch, integration, webflow, etc.

On nous propose un cas de système de traitement de commande à architecturer autour de Spring. Le système peut recevoir des commandes par Web Services. La démarche classique est de définir une interface Java, implémentée par un POJO, et de générer le WSDL à partir de cette interface. Or cette démarche présente des inconvénients: le WSDL expose de facto l'interface d'une classe interne.. que se passe-t-il si le WSDL doit changer? D'autre part certains types communs en Java, comme Map, ne sont pas supportés en WSDL...Eberhard propose d'inverser la démarche: puisque le contrat avec les clients est le WSDL, on part du WSDL et on base le traitement d'une commande sur le schéma XML correspondant. Ansi on n'expose pas d'interface interne, on traite un objet Java généré à partir du message envoyé, via un système de mapping (JAXB/XStream). La logique est découplée de l'interface. La classe qui traite le message est un Endpoint qui est annoté via les annotations Spring. Eberhard en profite pour rappeler que Spring est trop souvent assimilé à XML, mais qu'on peut très bien faire du Spring sans XML (ou presque, soyons honnête..)

Pour rendre robuste le WebService, on peut aussi baser le traitement du message sur des expressions XPath. Ceci permet d'avoir un contrôle plus fin sur des messages qui seraient incomplets, et donc ne pourraient pas être mappés avec la solution précédente.

Eberhard introduit également les notions de pipes et filtres, qui sont des pipelines de traitement, supportés par Spring Integration, et configurables par XML (tiens donc).

Spring fournit également une approche à la notion de batch, mal résolue en Java; notamment le problème des redémarrages en cas d'interruption volontaire ou non. Un batch Spring c'est une série d'étapes, chaque étape lit quelque chose (un record dans une base probablement) et écrit quelque chose (résultat du traitement). Cette notion est supportée par Spring batch.

 

Dernière conf de la journée, et du symposium: Real GWT applications, par Jeff Dwyer. Une énième présentation rapide des principes de GWT, et une petite démo sur le site tocollege.net, dont une partie est réalisée en GWT. Jeff fait une petite séance rapide de live coding, et montre le débugging en mode hosted. Puis il insiste, un peu trop peut-être, sur les problèmes pour envoyer des objets métier au client provenant d'hibernate: les proxies dynamiques cassent le mécanisme de sérialisation GWT. Il existe des solutions: Hibernate4GWT et GWTHibernateFilter. Je lui ferai remarquer à la fin que ce n'est pas forcément la meilleure idée, et qu'avec Dozer il est facile de populer des objets spécialisés pour les transmette au client, car je n'ai pas forcément envie de voir mes objets métier transiter sur le fil, on ne sait jamais ce qui peut s'y trouver demain...

Jeff conseille judicieusement d'utiliser un pattern Command pour les communications du client. Il aborde la sécurité, notamment les attaques XSRF, et présente Goggle Gears pour les applis offline.

La présentation était un peu rapide, mais l'intérêt pour la techno est évident. J'espère que cette présentation (qui a été donnée deux fois lors du symposium suite à la forte demande !) y aura contribué.

 

Ouf, le marathon est fini ! Beaucoup de choses passionnantes ont été présentées, et on sent qu'on est à un tournant car pour ainsi dire "ça part dans tous les sens", l'écosystème Java, aux frontières autrefois bien nettes, commence à devenir une galaxie en expansion avec des projets qui poussent l'enveloppe et repoussent sans arrêt les limites, des polémiques (et encore, on n'a pas abordé les closures !). Le monde Java de demain sera certainement bien différent de celui d'aujourd'hui, mais Java en restera probablement le centre de gravité...

Il me reste à visiter Prague (superbe ville) et regarder les Turcs se qualifier sur l'écran géant au centre ville...

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!

mercredi 18 juin 2008

TheServerSide Java Symposium - jour 1

Le TSSJS Europe se tient à Prague cette année, du 18 au 20 juin. Les thèmes majeurs proposés sont assez alléchants, jugez-en:

  • les frameworks web (spring, struts, JSF)
  • les nouveaux langages de l'écosystème java (groovy/grails, scala, jruby)
  • les nouvelles versions de spécs (JEE 6, EJB 3.1, JPA 2.0)
  • concurrence, performance, scalabilité
  • SOA

A part quelques événements communs (keynotes, etc) il y a en général 3 sessions simultanées, ce qui rend parfois le choix cruel...

Le premier keynote "Supporting RIA space" est délivré par Stephan Janssen, le fondateur et président du BeJUG, fondateur de JavaPolis et de parleys.com, un site qui met en ligne des conférences filmées avec les slides synchronisées. C'est ce site qui lui servira de support pour tester différentes technologies RIA dont il nous fera part...

Premier point délicat: définir une application RIA... Pour la petite histoire le mot a parait-il été inventé par Macromedia, et donc absorbé par Adobe. Mais ça ne nous avance pas. Un application RIA c'est une application Riche (mais pas tout à fait comme une application desktop), et qui utilise Internet (mais pas forcément tout le temps)...

Bref l'éventail est grand, RIA encore mal cerné, et les technologies qui permettent de faire du RIA innombrables. Stephan en a retenu quelques unes et a expérimenté le portage du site parleys.com sur ces technos.

  1. le site original, HTML, rien à dire
  2. refactoring en DHTML/JavaScript avec Scriptaculous. Conclusion: il faut un doctorat en JavaScript, et la compatibilité cross-platform est un enfer... (quelle surprise!)
  3. GWT: développement et debugging agréable en Java avec les outils Java, support du bouton back, et "99% cross platform" ( un seul if/then dans tout le code). Un seul point noir est relevé par Stephan: le site n'est pas indexé correctement par Google!
  4. Flex: le résultat est extrêmement semblable à GWT, avec un peu plus d'"eye candy", transitions animées et choses similaires. Techno mature, mais l'indexation Google est inexistante, sauf à utiliser des artifices (redirections)
  5. JavaFX: résultat sexy style Flex, avec en plus la possibilité d'utiliser le Java existant. Pas de support Mac...

Au final le site actuel est la version Flex, avec intégration AIR, mais on note bien que GWT n'a reçu que des éloges...

Deuxième conf, là il faut choisir... JSF? qui utilise encore JSF... JPA/Hibernate? déjà fait... Je reste donc dans la salle principale pour entendre Costin Leau (SpringSource) parler de "Spring Dynamic Modules".

On le sait, Java ne gère pas les versions des classes ou le remplacement dynamique, et il est impossible à deux versions d'une même classe de coexister. OSGi fournit une solution, en définissant une notion de "module" ou "bundle", qui est simplement un ensemble de classes, auquel s'appliquent les notions de

  • cycle de vie
  • "class space"
  • règles de visibilité
  • versionnage

Un service au sens OSGi c'est simplement une classe, un POJO qui exporte des méthodes au travers de la visibilité. Le reste est caché de l'extérieur, ce qui permet à plusieurs versions de cohabiter sans conflit. Spring 2.5 sera OSGi-compliant et intègrera la notion de bundle. On pourra également réagir aux événements qui affectent le cycle de vie des services (création, suppression, etc). Les dépendences OSGi sont localisées dans le contexte Spring, et non dans le code.

Au final cela semble très prometteur, reste à voir dans quelle mesure cela s'appliquera à nos développements. Annoncé également, la sortie du futur S2AP, SpringSource Application Platform... Pas plus de détails là-dessus.

Deuxième session de la matinée: monitoring, management sur la plateforme Java 6, par J-F Denise, responsable JSR 262 chez Sun.

Beaucoup de rappels sur JMX et les MBeans, l'agent JMX, l'agent remote... Depuis Java 5, l'outil JConsole est fourni avec le JDK et permet d'interroger une JVM qui tourne, y compris des MBeans. C'est une bonne chose de le rappeler, car le JDK est fourni avec beaucoup d'outils trop peu connus, car pour beaucoup l'IDE est la seule interface qui existe avec Java.

Implémenter un MBean est simple (juste une interface), mais peut poser des problèmes: si le MBean retourne un type composite sous forme d'une classe maison, il faut que le client JMX dispose de cette classe aussi dans son classpath !! Pour relaxer cette contrainte, Sun introduit les MXBeans, qui permettent de faire cela, et via un mécanisme interne, transforment les objets complexes sérialisés en des classes standard qui peuvent être lues par le client sans modification de son classpath.

Autres outils fournis avec le JDK 6: jps, jmap, jhat, jinfo... Et un nouvel outil qui ne fait pas à proprement parler du JDK: jvisualvm. C'est un outil intégré et extensible de troubleshooting, fonctionant avec des plugins, et qui regroupe les fonctionnalités éclatées dans divers outils... La RC1 est disponible depuis le 6 mai.

Avant de manger, un keynote par Nati Shalom de GigaSpaces "Getting ready for the cloud". Il s'agit en fait de 40 minutes de marketing pendant lesquelles le message est martelé sur tous les tons: vos applications ne sont pas scalables, parce que bâties sur des silos. La solution: remplacer les silos par un "cloud", une plateforme qui virtualise les 3 tiers habituels (middleware virtualization) et qui est la seule à pouvoir assurer le "scaling on-demand". Et comme par hasard, GigaSpaces a un framework qui le permet. OK, le message est passé.

Déjeuner avec un lance-pierre, pas le temps de digérer on attaque l'après-midi. Eh non, après avoir erré dans les coursives, je me rends compte que la conf qui m'intéressait (Comparing Dependancy Frameworks) est annulée... J'assiste sans conviction à un case study "Using JSR-272 and Spring for a Monetary System".

Ensuite, encore un dilemme: Holly Cummins, spécialiste des outils de diagnostic chez IBM (au style capillaire improbable), présente "Java Performance Tooling", mais je choisis "Simplifying JEE Development with Grails" par Guillaume Laforge, project manager de Groovy.

L'idée de Grails c'est d'appliquer les principes de productivité de Ruby et Groovy, tout en s'appuyant sur les bibliothèques et infrastructures existantes (Java, Spring, Hibernate, servlet containers, etc.). Par exemple, Grails génère un WAR, qui peut être déployé tel quel sur un serveur d'applications. Grails utilise GORM, un ORM bâti sur Hibernate, WebFlow, domain-specific languages, GSP (un équivalent de JSP), supporte des plugins, et nécessite aussi peu de fichiers de configuration que possible grâce à des conventions de nommage.

La démo est impressionnante, en quelques lignes et en live Guillaume crée deux classes, les relations entre elles, les tables correspondantes, les mappings relationnels, les finders, les controleurs, l'interface web... et redéploie sans redémarrer quoi que ce soit! Est-ce que ce serait Ruby on rails, avec la scalabilité et la puissance en plus??

Conf suivante, je choisis une prés de GlassFish, par Antonio Goncalves (Paris JUG). Pas grand chose à retenir, Glassfish est prêt pour la production, scalable, clusterisable, avec une belle interface d'administration (bon tous les gouts sont dans la nature). C'est l'implémentation de référence pour Java EE 5 et 6 et il est open source.

Plus intéressant, mais on ne s'étendra pas dessus, ce qui est annoncé pour la v3: un noyau ultra léger et ultra rapide (HK2: Hundred Kbyte Kernel), modulaire, avec des modules web, EJB, JRuby, PHP, JavaScript, etc. et le support OSGi! Bref, on reviendra.

Ouf, c'est fini, une bière, remise des prix du concours GigaSpaces/OpenSpaces... je discute avec le gagnant, un Brésilien qui a réalisé un projet pour la distribution des surplus alimentaires au Brésil (avec GWT en front!), l'occasion de pratiquer mon portugais :)

Demain la suite...

vendredi 23 mai 2008

Le plein de logiciels pour .Net !

ZzzzzzzzzOyé, oyé !

Me voilà de retour sur votre blog préféré après une petite période d'hibernation.

Pendant tout ce temps, j’ai constaté qu'il y avait pas mal d'activité sur les logiciels du monde .Net. Au delà de la mise à jour des "classiques" projets Open Source dont je vous fait régulièrement l'éloge sur ce site, de plus en plus d'éditeurs de logiciels payants proposent une version gratuite, limitée en fonctionnalités, ou afin d’être utilisée dans une application non commerciale. Je vais donc vous faire profiter de toutes mes découvertes.

  • Tout d'abord, quelques mise à jour :

NUnit 2.4.7 (30 mars 2008)
Apparition de nouveaux attributs RowTest et RowAttribute, suppression de log4net pour le log interne (ce qui pouvait poser des problèmes lors de l'utilisation d'une version différente avec l'application testée), et des corrections de bugs. http://www.nunit.org/index.php?p=releaseNotes&r=2.4.7
NUnitA noté qu'une version 2.5 alpha 2 (7 mai 2008) est également disponible. Elle apporte une extension "pNUnit" permettant de faire des distribués en parallèle, l'attribut RowTestExtension (alpha 2) TestCaseAttribute (alpha 1) et DataSourceAttribute (alpha 1). Il y a encore de nombreuses autres nouveautés.
http://nunit.com/index.php?p=releaseNotes&r=2.5

Spring.Net 1.1.2 (7 mai 2008)
http://www.springframework.net/docs/1.1.2/changelog.txt

Enterprise Library 4.0 (mai 2008)
http://msdn.microsoft.com/en-us/library/cc512464.aspx

Unity 1.1 (16 mai 2008)
http://blogs.msdn.com/agile/archive/2008/05/16/unity-refresh-v1-1.aspx

Logo monoMono (13 mai 2008)
4 ans après le début de Mono, l'API Winforms est maintenant complète (12776 méthodes quand même !)
http://jpobst.blogspot.com/2008/05/big-finale.html

Moonlight 0.6 (13 mai 2008)
Première release publique de Moonlight supportant Silverlight 1.0 sous Linux. Attention, toutes les fonctionnalités ne sont pas encore supportées, mais c'est déjà un grand pas !
http://tirania.org/blog/archive/2008/May-13-1.html

ReSharper 4.0 beta
L’excellent plugin ReSharper arrive en version 4. Au menu des nouveautés, le support de C# 3.0 et LinQ. Comme d’habitude, les mises en garde de l’utilisation d’une version béta sont de rigueur.
http://www.jetbrains.com/resharper/beta/beta.html.

  • Voici maintenant quelques "offres spéciales" de quelques éditeurs commerciaux :

NCache Express
NCache est un cache distribué qui permet également de répartir des sessions ASP.NET sur plusieurs machines. Il existe maintenant une version « Express », aux fonctionnalités limitées par rapport à la version entreprise.
http://www.alachisoft.com/ncache/ncache_express.html

40 composants DevExpress
DevExpress vend des composants graphiques de relativement bonne qualité. JetBrains utilise d’ailleurs certains d’entre eux dans ReSharper. Je viens de découvrir que DevExpress fournissait gracieusement 40 de leurs composants (XtraEditors Library, XtraNavBar, ASPxMenu and ASPxSiteMapControl), dans le cadre d’une utilisation non commerciale.
http://www.devexpress.com/free

Xceed WPF DataGrid
Xceed propose, tout comme DevExpress des composants graphiques à la vente. Il propose néanmoins un de leurs composants gratuitement : une DataGrid en technologie WPF.
http://xceed.com/Grid_WPF_Intro.html

Voilà de quoi agrémenter vos applications .Net !
N’hésitez à nous faire part de vos expériences sur l’utilisation de ces produits, et à nous faire connaître d’autres librairies de qualité.

lundi 11 février 2008

[TechDays 2008 - J1] Domain Driven Design par Sami Jaber

Après une rapide présentation de la 4ème édition du symposium DNG 2008 qui se déroule aujourd'hui, Sami a tenté de nous présenter le "Domain Driven Design" en une petite heure. Le DDD, pour faire court, est un design qui est apparu pour la première fois en 2003 sous la plume d'Eric Evans. Pour ceux qui par paresse ou manque de temps ne peuvent pas lire les 500 pages et quelques du livre d'Eric Evans, InfoQ en a résumé les principales lignes : DDD-quickly

Résumé de la présentation

Point de départ : de nouvelles technos comme Link modifient la manière de penser l'architecture en couches.

Architecture n-tiers traditionnelle

Les différentes couches sont Présentation, Services (use case fonctionnel), Domaine (objets métier) et Accès aux données. Les traitements métier sont concentrés dans la couche service. Par conséquent, le code est souvent procédural, peu objet, et dur à tester. Ceci pose également des problèmes de redondance et donc de maintenance du code.

Ceci se traduit par des méthodes de manipulation sans état, statiques, et des objets qui ne sont qu'une liste de champs avec getters setters. Les méthodes qui manipulent logiquement les données internes d'un objet ne se retrouvent pas dans l'objet mais dans une classe à part qui contient les méthodes statiques.

Une logique objet voudrait que les objets contiennent eux-mêmes les méthodes capables de manipuler leurs variables d'instances.

Domain Driven Design

Les différentes couches sont Présentation, Domaine, Application et Infrastructure. Le principe du DDD est de faire graviter la logique métier autour de la couche Domaine, autour des objets. Les objets contiennent le code métier, et font eux-mêmes les appels nécessaires au déroulement du service (appel à la couche service, appel à la base via la couche accès aux données, etc.)

En conséquence, ils constituent le point d'entrée du service et orchestrent l'interaction entre les couches. De fait, on ne peut plus faire simplement de l'injection de dépendance dans les objets, puisque cela suppose une manipulation des objets depuis une autre couche. Le "remplissage" des objets, leur instanciation, va donc être faite soit par de simples appels aux constructeurs, soit via des "Factory", appelées par les objets eux-mêmes.

Le mécanisme de manipulation des objets peut s'avérer complexe si l'agrégat d'objets est gros, si le nombre d'objets manipulés est important. Pour gérer cette manipulation, on va considérer cet agrégat d'objet comme une entité munie d'un objet racine, point d'entrée de l'agrégat.

Il peut s'avérer lourd de procéder à une instanciation et une injection de dépendances sur toute une arborescence d'objets lorsque le seul but est de récupérer des valeurs en base liées à ces objets. C'est là qu'interviennent les Value Objects, objets immuables qui autorisent simplement l'accès à l'information contenue dans ces objets en base.

Autre conséquence du DDD : la couche d'accès aux données classique disparaît : la couche des services n'est plus là pour appeler la couche accès : les données sont donc remontées autrement, via les "Repositories". Les repositories permettent d'effectuer les opérations de recherche en base.