Compte rendu de SpringOne 2008

Pour ma part, la première image qui me vient à l’esprit s’apparente au fait de sortir d’un bon repas un peu trop gourmand. Rassasié de l’enchainement de conférences riches, et très variés, la rédaction de cet article nous fait l’effet d’un bon Rennie. Sous forme de récit, Moez nous racontera ces deux jours et ses ressenties. Pour ne pas être redondant, je vous présenterais seulement mes opinions. J’espère que vous êtes bien accroché à vos sièges car l’aventure ne fait que commencer…

Récit de ces deux jours, par Moez

En arrivant dans les lieux, premier constat : SpringSource a su mettre les petits plats dans les grands et réserver un multiplexe où les animateurs présentent dans des salles dignes de l’avant première de Star Wars. Les héros de la saga SpringSource étaient tous là…. Une logistique est organisée à la sauce Parley, avec une caméra braquée sur les intervenants et les slides qui défilent à un bon rythme.

Pour ma première participation à une grande conférence informatique, la bonne ambiance, l’excellent accueil et la magnifique organisation des équipes SpringSource m’ont rapidement plongé dans le bain. En effet, pas le temps de remettre les pieds sur terre, première présentation par Rod Johnson. Durant les 5 premières minutes j’avoue que j’ai eu du mal à me concentrer, bluffé par la présence de ce monsieur. Deux heures durant, il nous a dressé un positionnement clair, simple et rapide des produits Spring et a annoncé les grandes nouveautés.

J’allais enchainer par une présentation sur des cas d’utilisation de Spring. Erreur d’organisation et mauvais titre à la présentation, il s’agissait de Spring batch . Rien de grave, je n’ai pas regretté le fait d’avoir assisté à cette séance car j’ai découvert un super produit. Spring Batch est un framework mis en place pour résoudre les problématiques de batch. Une conception très simple qui se base sur les pratiques actuelles .Je pense que cette solution révolutionnera le monde des batchs comme l’a fait Spring Core dans le monde J2EE.

Beaucoup de suspense, beaucoup d’attente mais cela valait le coup. S2AP le nouveau serveur d’application de Spring est un embryon d’une future solution d’entreprise très modulaire, dynamique et robuste à la fois. Je ne sais pas si c’est l’effet OSGi ou si c’est l’effet d’une très bonne conception, la première version de S2AP apporte des réponses précises à des problèmes épineux. OSGI et S2AP sont à surveiller pendant les prochaines années, voir les prochains mois, car je pense qu’ils vont apporter pas mal de réponse à nos problèmes quotidiens. Prochainement, je vais publier deux billets pour présenter OSGI et S2AP.

J’ai ensuite eu le plaisir d’assister à deux excellentes présentations, l’une sur la gestion des transactions et les choix de performance dans un environnement Spring, une session présentée par Juergen Hoeller. L’autre session qui m’a beaucoup plu concerne les architectures RESTful et la solution à venir dans Spring 3.0, présentée par le spécialiste en la matière Arjen Poutsma.

La présentation sur la combinaison JSF Spring m’a confirmé qu’on avait fait de très bon choix en interne et m’a montré le chemin vers une solution qui semble fort intéressante basée sur JSF- SpringMVC et Spring. Cette formule magique s’appelle Spring Faces.

Si j’avais à choisir quel sujet présenté durant cette conférence est le plus intéressant, j’aurais beaucoup de mal. Ceci dit, j’ai quand même un faible pour Spring Batch.

Pour conclure, je trouve ma première participation à SpringONE très bénéfique et je suis très excité à l’idée de tester les technologies présentées pendant cette conférence afin d’en faire profiter nos clients et je ne manquerais surtout pas de vous en faire un retour !!

Spring Batch et S2AP, une tendance qui ne manquera pas de faire du bruit, par Frédéric

Pas le temps de s’endormir, les présentations de début de journée déclenchent les classiques effets spéciaux qui savent donner l’eau à la bouche de ses participants… Rod Johnson, Adrian Colyer, Rob Harrop ont su donner une dynamique à la journée pour nous tenir en haleine jusqu’à la fin.

En effet, le mot « visionnaire » tourne dans ma tête en me remémorant les pointures Rod Johnson, Juergen Holler, Thomas Risberg, j’en passe et des meilleurs. Le Spring que j’ai connu en 2005 avait l’air d’avoir percé les plafonds en secouant la base d’une plateforme J2EE stagnante. 2008 est l’année où Spring aura remué la communauté Java encore une fois en s’attaquant non plus à la partie Framework d’entreprise, mais aussi à la partie infrastructure. Tout d’abord, cette révolution s’adresse aux infrastructures Batch.

Jusqu’à aujourd’hui, aucune architecture batch en Java n’a pu percer, et pour cause, les batchs sont tous des programmes particuliers ne pouvant pas rentrer dans le cadre des applications conventionnels. Les problématiques de performance, volumétrie, encombrement des services, etc. sont le quotidien de ces programmes qui poussent souvent à faire le grand écart, et donner des architectures très hétérogènes. Cela dit, Spring Batch a sû trouver le bon périmètre, lever les bonnes problématiques pour se concentrer sur des fonctionnalités techniques récurrentes. D’ailleurs Dave Syer nous présente sa maxime très convaincante "On ne devrait jamais investir d’argent à développer une fonction, qui ne participe pas à la réalisation de notre métier". Pari réussi, mais n’en dévoilons pas trop, nous entrerons plus en détail dans d’autres articles qui vont suivre.

Autre gros poids lourds qui se profile, Spring propose de s’attaquer au domaine des middlewares, et même directement dans la cour des serveurs JavaEE. SpringSource Application Plateform propose une infrastructure pour déployer des applications Web et surtout des modules OSGi. Plus besoin des EJB, un module OSGi se propose de répondre à la couche de service.

Mon avis est qu’il offre pour l’instant un bon serveur pour le développement, mais pas encore prêt pour la production. Ce qui m’a agréablement surpris, est que ce produit a su reprendre les concepts essentielles des serveurs JavaEE, tout en posant sa pierre à l’édifice. Par exemple, les fichiers de configuration ne sont pas en XML mais en JSON, ce qui donne une bien meilleure lisibilité. Lors de la publication des erreurs, les ClassNotFoundException sont surchargées pour indiquer quel bundle a provoqué l’erreur, et même, propose des suggestions lors de l’apparition de certaines coquilles !! Fidèle à leur habitude, les gens de Spring Source nous proposent un produit original qui saura apporter sa propre touche, et promet de faire du bruit.

D’autres produits sont présentés avec plus ou moins maturité "Spring Integration" qui est encore dans une phase beta mais qui créer ex nihilo une architecture basée sur des évenements (Even Driven Architecture). Spring Security, venant de l’ex-Acegi, a su apporter toute la puissance du produit Acegi, en le mettant à niveau de tout. Plus de besoin de paramétrer 5 pages de configuration; avec la fameuse tendance de Spring à rendre les configurations faciles, Spring Security vous propose remplir les quelques informations indispensables, puis s’occupe du reste !! La sécurité des applications est enfin à la portée de tous.

Ouf, ça y’est, je pense que l’effet du Rennie m’est passé et je suis enfin prêt à dormir 🙂

Cependant, attendez vous à retrouver d’autres articles sur la plateforme Spring, à qui nous promettons un bel avenir! Prochaine étape, nous vous retrouvererons bientôt pour l’interview du responsable et du lead developer de Spring Batch, Dave Syer. A très bientôt !!

Frédéric TU & Moez LOUATI

10 Responses to “Compte rendu de SpringOne 2008”


  1. 1 Alexis MP 13/06/2008 à 11:21

    "Les fichiers de configuration ne sont pas en XML mais en JSON, ce qui donne une bien meilleur lisibilité" Choix intéressant…. C’est quand même ignorer tous les éditeurs et autres validateurs XML. Ou sont les parseurs validants JSON?

  2. 2 Pirmin 13/06/2008 à 15:03

    Merci à Frédéric et Moez pour ce reportage. L’enthousiasme primesautier fait chaud au cœur ;-). Cependant je vous avoue être resté un peu sur ma faim car, au-delà d’afficher une fierté, certes compréhensible et légitime d’avoir côtoyer tel ou tel gourou Java ou d’admirer l’« opulence » des invités, il me semble qu’il faudrait surtout et avant tout proposer une analyse critique de l’ensemble de l’architecture logicielle basée sur Spring. Les questions ne manquent pas. Je vous propose un "best of" personnel à la fin du post. A mon sens, un bref rappel des principes fondateurs de Spring aurait été souhaitable : injection de dépendance et AOP. Enfin, il me semble qu’il faut aussi prendre position et analyser Spring en comparaison avec la solution standard qu’offrent la quincaillerie des API JEE 5 et un conteneur lourd constitué d’un serveur d’application. Il y a donc une mise en perspective historique à faire. Si l’injection de dépendance est un bon pattern permettant à la fois de découpler des composants logiciels et d’agréger de manière cohérente des frameworks, pourquoi, selon vous, ce principe d’organisation n’a-t-il pas supplanté l’option classique du serveur d’application et de la panoplie d’API de JEE 5 ? Devrait-il le supplanter selon vous ? Si oui pourquoi ? Si non pourquoi ? Dans quelles circonstances ? etc… Voilà les questions qu’il nous faudrait approfondir et débattre en tant qu’ingénieurs, plutôt que de dresser un catalogue de features … Je vous propose 4 questions liées à Spring qui me paraissent importantes. Elles concernent aussi bien les derniers gadgets du jour ou que les principes fondateurs de Spring (AOP et IoC): 1. Sur le site de Spring, on nous dit que l’AOP joue un rôle de plus en plus important dans la nouvelle mouture de Spring (intégration d’AspectJ). Mais j’avais cru comprendre que tout l’intérêt de Spring était justement d’appliquer un modèle de programmation POJO explicite et simple ; tout du moins si on le compare par exemple aux EJB 2.x de sinistre mémoire. Le problème d’objets managés comme les EJB était que nombre d’action étaient prisent « en coulisse » par le serveur d’application (au moyen de callback methods) et demande donc de la part du développeur d’être lucide sur ces nombreux mécanismes implicites. Or l’AOP, justement cela revient à définir, une structure complexe d’opérations en coulisse qui se déclenchent automatiquement. Il semble donc qu’on ai tourné en rond, on est parti avec une bonne idée simple, l’IoC/IdD, pour revenir au complications de l’AOP. Quelle est votre analyse ? 2. L’usage des annotations de Java 5 semble se généraliser dans Spring. Ne risque-t-on pas là aussi de se retrouver avec une myriade de mécanismes implicites difficile à contrôler ? Longtemps on nous a seriné qu’il fallait externaliser le paramétrage dans des descripteurs de déploiement et ne pas polluer le code avec du paramétrage. Pourquoi ça a changé maintenant ? La question concerne Spring et Java 5 dans son ensemble. 3. Spring permet de définir une notion customisable de session. J’ai toujours été frappé par la myriade de définitions différentes que recouvre ce malheureux concept de session : session JDBC, session HTTP, session Hibernate, session JPA, session utilisateur, session transactionnelle, j’en passe et des meilleures… Chaque notion est différente avec de subtils distinguos parfois même entre versions d’un même framework. Selon vous, la notion customisable de Spring permet-elle de mettre de l’ordre dans cette anarchie et d’y voir un peu plus clair ? 4. Si l’injection de dépendance est suffisante pourquoi ne pas baser toute l’architecture JEE là-dessus dans le JDK et abandonner la notion de serveur d’application ? Quand la communauté Java comprendra-t-elle que « moins » c’est « mieux » ?

  3. 3 Frédéric Tu 16/06/2008 à 11:02

    Je suis content que l’article suscite plein de questions.. ca veut dire que Spring est une plateforme qui intéresse beaucoup de personnes. Et je suis vraiment convaincu de sa puissance. Alexis => JSON possède aussi une grammaire et possède obligatoirement un validateur et un parseur. Le vrai problème serait pour moi qu’il n’existe pas forcément d’outil immédiatement sous la main pour colorier les différents éléments. Cependant, si tu pouvais voir l’incroyable lisibilité des fichiers de configuration comparés à ce que je côtoie tous les jours, je pense que ca peut faire changer d’avis. Ensuite, si tu es convaincu sur le principe, il n’y aura pas de problème pour trouver les outils (même en général) qui viendront jamais assez vite. Pirmin => Le sujet de cet article était essentiellement basé sur l’événement en lui même; et lorsqu’un hote vous accueil, on se doit de remarquer l’accueil en lui même 😉 Ensuite le ton étant donné, l’aspect macro et les outils devaient suivre. En ce qui concerne les détails (ce que nous sommes tous intéressés par), d’autres articles vont venir sur le blog (cela permet de tenir en haleine) Sinon c’est avec grand plaisir que je répondrais à tes questions.. (Juste le temps de les avoir sous les yeux, et c’est parti)…

  4. 4 Pirmin 16/06/2008 à 14:24

    L’aspect macro c’est d’abord de rappeler quels problèmes Spring est sensé résoudre et comment il les résout comparativement à d’autres solutions et de prendre sur ces sujets une position personnelle et argumentée. Ce ne sont pas là des détails, c’est justement l’ESSENTIEL de notre métier. Le langage de configuration des fichiers de configuration et la qualité de l’accueil, selon moi, c’est des détails … ce qui ne veut pas dire qu’il ne faut pas dire merci à son hôte 😉 Sinon, je cherche moins un gourou qui répondra à toutes mes questions et mes doutes, qu’à démarrer sur ce blog un débat contradictoire entre ingénieurs qui se posent des questions et qui ont, sur les technologies, leur propre regard critique et pourquoi pas leur propres propositions. Sur la plateforme Java Enterprise dans son ensemble, j’ai déjà eu l’occasion de m’exprimer sur ce blog. L’alternative Spring m’apparaît intéressante pas sa simplicité, du moins à l’origine, mais il faut la passer à la moulinette de l’analyse et pas se contenter d’établir un simple inventaire d’API.

  5. 5 Frédéric Tu 16/06/2008 à 18:06

    Avant de commencer, le thème de l’événement était orienté vers la présentation des différents éléments de la plateforme Spring. Pour tout compte, entre Spring Batch, Spring Security, Spring Application Platform, … je n’ai pu assister qu’à une seule présentation de bonne conception par Eberhard Wolff, et une présentation de démarche d’optimisation par Thomas Risberg.Le sentiment primesautier étant passé et l’objectif de la présentation SpringOne n’étant pas la présentation d’une méthodologie, je vais plutôt m’appuyer sur ma propre expérience de Spring pour essayer de te répondre (même si elle ne fait pas office de réponse officielle Spring 😉 : 0) Pourquoi l’IoC si incroyable, n’est-il encore si peu présent dans les entreprises? Tout d’abord, ma première réponse serait "question d’habitude". Les développeurs ont acquis l’habitude d’aller directement chercher les informations dont ils ont besoin, plutot de que de le demander. Pourquoi abstraire un objet alors que c’est moi qui va coder son implémentation? En bref, il est difficile de faire abstraction de l’instant présent (développement), quand tout est présent sur la machine locale; et penser au cycle de vie de la classe (intégration, test, maintenance et correction, …). La deuxième réponse est la lisibilité : lorsque je plonge dans mon code, chaque classe injectée ne m’est pas connue et je dois aller regarder dans un autre fichier pour savoir quel est mon lien. Une instanciation direct sans aucune autre forme de procès, c’est quand même bien pratique.=> Ainsi l’IoC demande un peu d’effort de conception (coût), alors que l’on n’est pas sûr que l’on va bénéficier des retombées (rentabilité). D’ailleurs, je pense que l’IoC devrait être imposé pour certaines classes par les concepteurs.1) La bonne idée du POJO et de l’IoC était que le développeur n’avait plus à se soucier de savoir comment récupérer une ressource (impliquant souvent ouverture de socket et protocole pour la gestion du cycle de vie). Ainsi, le code n’avait plus à dépendre de l’infrastructure et donc testable-né (ou serial-testable, un mot que je viens d’inventer). L’AOP est pour moi, le code qui est là pour ajouter de la transversalité aux POJO. Par ex, le monitoring de temps, la tracabilité des appels, la sécurité n’entrent pas en jeu dans le développement du code métier propre dit ! Avant le code devait suinter de toute cette problématique alors qu’elle est transparente avec l’utilisation de l’AOP. Deuxième notion, la factorisation de code. Ce code "technique" est factorisé depuis chaque POJO pour être regroupé dans une classe (cf. pattern Separation of Concern). Le troisième arguement concerne l’écriture du code après coup. Comment tisser un ensemble de fonctionnalité de suivi, de profiling, … sans recompiler le code d’une application qui fonctionne bien depuis mathusalem?=> En gros, le POJO, c’est pour les développeurs, l’AOP c’est fait pour des experts qui interviennent sur l’infrastructure sans rien imposer aux développeurs métier. Le problème réside plus dans le fait que les développeurs en voit un bout dans les fichiers de configuration… Encore un petit effort à faire?2) Spring n’est pas une doctrine ou un cadre rigide qui dicte aux développeurs comment coder (cf. le résultat de cette politique : la multitude de rustines autour de Struts). Rod Johnson insiste d’ailleurs sur l’ouverture de SpringFramework pour s’adapter aux maximum des habitudes des utilisateurs. L’ouverture vers les Annotations est une composante intéressante MAIS aussi dangereuse. Pour moi, les annotations sont des metadata qui doivent décrire une caractéristique de manière figée, et dont le changement nécessite une recompilation, un banc de tests, etc. Par ex, annoter une méthode qui est transactionnel PEUT être utile lorsque l’on doit imposer une caractéristique du CODE APPELE (non pas du code appelant). Coté Spring 2.5, l’annotation "ceci est un service" ne me choque pas, et entre bien dans cette dynamique… Le vrai problème, c’est plus l’autowiring @Component qui me fait peur car les objets annotés apparaissent dans le repository, sans demande explicite, et peuvent généré des problèmes de collisions de nom… Une classification de "dangereusité" (l’empreinte écologique) des annotations Spring serait un article bien intéressant ;)3) Je suis d’accord avec toi.. C’est du vrai n’importe quoi ! 😉 Comme Spring dit, ne prenez que ce que vous trouver bien… Faudrait se pencher sur la question.4) La notion API de JavaEE est en train de s’effriter (pourquoi ai-je à dépendre d’une classe qui me tirer le lien sur des dépendances lourdes de l’infrastructure?). Cependant, la notion d’administration offerte par l’infrastructure JavaEE, la configuration post développement des ressources et le suivi sont des concepts dont on ne pourra plus se passer! JavaEE permet aussi de distribuer les applications sur plusieurs machines selon la montée en charge, proposer des remontées d’erreurs centralisées, … Où configurer ces notions si l’infrastructure n’existe pas? Selon moi, le problème, c’est plus le degré de transparence et la bonne compréhension des concepts par les équipes de production… Et ce dernier point n’est pas souvent présent…

  6. 6 Alexis MP 16/06/2008 à 20:57

    Ok pour la grammaire JSON (JavaScript sérialisé), mais aucun IDE (à ma connaissance) n’intègre ne serait-ce qu’un éditeur en standard.

  7. 7 Pirmin 17/06/2008 à 09:43

    Bon, je constate non sans satisfaction que mes rodomontades n’ont pas été complètement inutiles ;-). Merci Frédéric pour ton analyse que je partage en partie. Quelques remarques en prenant les points dans l’ordre. 0) Tu dis : "Tout d’abord, ma première réponse serait ‘question d’habitude’ …" En effet, oui je crois que tu as raison, c’est l’habitude qui n’existe pas chez les développeurs. C’est le cœur de la question: l’habitude ! Si l’habitude ne s’instaure pas, je ne crois pas qu’il faille jeter la pierre aux développeurs, ou pas uniquement à eux. Selon moi, c’est un problème plus fondamental, qui touche aux « valeurs » de la communauté des informaticiens. Une valeur, selon moi est exagérée, c’est la « nouveauté » au détriment de la compréhension approfondie des mécanismes, comme tu le remarque d’ailleurs toi-même en conclusion de ton post. L’habitude c’est ce qui manque le plus à l’informatique. Cela heurtera certains esprits, épris de nouveauté à tout prix, mais je croix qu’aucun domaine du savoir, scientifique ou technique ne peut faire l’économie d’instaurer des habitudes. Les habitudes sont nécessaires à l’esprit humain pour libérer de la réflexion sur des tâches essentielles et intrinsèquement difficiles. Comment faire un système qui réponde aux besoins de mon client. Pour que l’habitude puisse s’instaurer il faut de la stabilité. Pour qu’il y ait stabilité, il faut dévaloriser un peu la nouveauté et réhabilité la pensée conceptuelle et abstraite. Bon, j’ai longuement exposé mes vues dans mes articles sur Essential Java [EJ] et ceux consacré à l’abstraction, je ne repasse pas une nouvelle couche sinon je vais finir par radoter 😉 1)… Quand tu dis « …Ainsi l’IoC demande un peu d’effort de conception… » ça confirme ce que je dis sous 0). Ton résumé « L’AOP est … le code qui est là pour ajouter de la transversalité aux POJO. » est très bon. Mais la transversalité est l’ennemie de la lisibilité justement. L’art de la conception c’est donc quelque part de naviguer entre transversalité et lisibilité, chaque extrémité ayant ses écueils. Quand tu dis « la sécurité n’entrent pas en jeu dans le développement du code métier », c’est là rien de nouveau, c’est ce qu’on disait déjà pour les EJB il y 7 ans… 2)… D’accord avec ton analyse « L’ouverture vers les Annotations est une composante intéressante MAIS aussi dangereuse. » et avec ta suggestion de faire une classification de dangerosité des annotations Spring. C’est ce genre de retour d’expérience qui est utile. 4) … C’est avec plaisir que j’apprends que « La notion API de JavaEE est en train de s’effriter ». Dans mon article 3 sur l’abstraction je propose (et je ne suis pas le seul) une approche plus radicale. Abandonner Java comme langage généraliste, mais bon c’est plus de la R & D et pour une SSII c’est un peu spéculatif. Dans le fond je crois simplement que le modèle d’encapsulation de la complexité dans des API a fait son temps et qu’il faudrait passer à autre chose. Le fond du problème c’est de répondre à la question : « qui a vraiment intérêt à ce que ça change ? » Ta conclusion, à laquelle j’adhère : « Selon moi, le problème, c’est plus le degré de transparence et la bonne compréhension des concepts par les équipes de production… Et ce dernier point n’est pas souvent présent… » étaient le point de départ sur mes réflexions dans EJ dans les papiers sur l’abstraction.

  8. 8 Frédéric Tu 18/06/2008 à 22:29

    Alexis > je ne doute pas que si la syntaxe JSON commence à percer, les outils viendront d’eux même, sinon ce serait une bonne idée pour démarrer un outil open source ;)Pirmin > "Bon, je constate non sans satisfaction que mes rodomontades n’ont pas été complètement inutiles ;-)."Disons que quand les questions sont constructives, c’est tj un plaisir pour y répondre. Dommage que le format commentaire n’est pas toujours adapté aux longues discussions.Pour cela, je ne relèverais que le point 1), car vu comment je suis bavard, je risque de ne plus m’arrêter. => Je suis d’accord avec toi sur le fait que "la transversalité est l’ennemie de la lisibilité", tout comme le cache est sensé améliorer la perf mais crée de la "viscosité" (la force qui nous freine tout changement). Trop d’encapsulation est l’ennemie de la performance… Et c’est ces décisions ne devraient pas être laissées à tout le monde selon la criticité du projet…Concernant ce que proposait les EJB 7 ans avant, en effet, rien de nouveau… juste le fait que ca deviennent à la portée de n’importe quel objet. N’est ce pas là une nouveauté? Si cela ne suffit pas, j’ai posé la question de l’accréditation au grain très fin (accréditation selon les paramètres passés) par Spring security, et c’est possible avec le mode AOP tout en restant hors du code métier! Et là, ca ne mérite t’il pas son pesant de cacahuètes ?? 🙂

  9. 9 Pirmin 19/06/2008 à 09:03

    Concernant l’encapsulation de la sécurité, ou tout autre code d’infrastructure hors du code métier, le fait que ça soit désormais à la portée de n’importe quel objet est certes une nouveauté. Mais la nouveauté n’a aucun intérêt si elle ne résout pas un vrai problème. Donc 1) quel était le problème à résoudre ? 2) pourquoi la solution de Spring est elle bonne, intéressante, etc… ? En matière d’évolution du langage, il y a selon moi 2 possibilité. La première est une approche conservative. On cesse de rajouter des annotions, des mécanismes AOP ou des API d’encasulation. On fait avec ce qu’on a, c’est à dire jdk 1.4. On crée de la stabilité pour créer de l’ "habitude" pour reprendre tes propres termes. La seconde et plus radicale, elle consisterait à ne conserver Java que pour la modélisation des objets métiers et le codage des règles de gestion. Pour le reste il faudrait inventer des DSL et les normaliser. C’est cette dernière approche qui a ma faveur. Hélas, les évolutions de Java EE avec les JSF et anotations, des frameworks comme Spring avec leur lot de nouveaux gadgets, créent,selon moi, plus d’entropie dans les esprits et dans le projets qu’il résolvent de vrais problèmes. Il faut choisir entre être conservateur et révolutionnaire 😉 Sur l’accréditation à grain très fin, je n’ai pas d’opinion, mais encore une fois la démarche doit être toujours la même 1) quel problème à résoudre ? 2) pourquoi ce qui est proposé constitue une amélioration.

  10. 10 David Andriana 07/07/2008 à 16:57

    Merci pour ce billet et ces commentaires informatifs. À propos du détail des fichiers de configuration XML ou son JSON, je trouve YAML bien plus intéressant, pour sa lisibilité : la structure dépend des sauts de lignes et des indentations, il n’y a pas de marqueurs de début et de fin, etc. Contrairement à XML ou JSON, on se prend rapidement avec YAML à partir dans des structures sans tags nommés (prévoir une structure de référence à côté, notamment pour la validation), mais à l’usage ce n’est pas un problème, bien au contraire. J’avais écrit deux trois mots sur le sujet : http://jefute.blogspot.com/2008/03/


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s




Mises à jour Twitter

Erreur : Twitter ne répond pas. Veuillez patienter quelques minutes avant d'actualiser cette page.

Entrer votre adresse e-mail pour vous inscrire a ce blog et recevoir les notifications des nouveaux articles par e-mail.

Rejoignez 29 autres abonnés

Catégories

Statistiques

  • 64 124 hits

%d blogueurs aiment cette page :