July 03, 2005
Petite tentative de bilan
Bon, alors, si j'essaie de résumer un peu mon feeling sur JavaOne:
- Desktop: cette fois-ci, c'est la bonne! (enfin, on espère). La communauté s'est vraiment activée sur le sujet, avec des projets comme Spring RCP ou bien JGoodies ainsi que différents projets java/desktop ce qui a motivé Sun a proposer des nouveautés. Celles-ci seront axées NetBeans, sachant qu'une intégration des travaux SwingLabs est à l'étude (pour le moment, cela reste une couche)
- Web: ça commence à sentir bon pour JSF, qui dispose d'un implémentation autre que la RI (MyFaces d'Apache), qui respecte la norme de portail et pour qui des composants sont disponibles (même si on aimerait un spectre plus large). Struts a du soucis à se faire, surtout si l'aspect portail/portlet accroche et est bien porté par les éditeurs. Que dire alors de Tapestry, de plus en plus isolé...
- Enterprise Edition: EJB 3.0 provoque un sacré intérêt de la part des développeurs (deux sessions pleines à craquer) et Sun est attendu au tournant. Hibernate va tenter de se "standardiser" un minimum sous l'influence de Gavin King, tout en gardant son indépendance.
- Standard Edition: je vais dire une banalité, mais je n'avais pas réalisé à quel point il est important de réellement passer à Java 5.0 (pour moi, c'était toujours trop tôt) pour des raisons de performances (bien sûr), pour les apports du langage et aussi parce que la plupart des exemples de specs/futures specs Java présentées intégraient ces nouveautés de langage. A titre d'exemple, NetBeans 4.1 a besoin de Java 5.0...
- Mobilité: il y a 2 ans, c'était apparemment le thème phare de Sun; aujourd'hui, on propose des applications et surtout de l'outillage pour essayer de rendre plus crédible cette offre. A en croire Sun, Java est déjà "partout" sur les mobiles, j'aurait tendance à en douter...
June 30, 2005
JavaOne, la der!
General Session
Dernière general session avec le papa de Java, James Goslin...
Un premier focus est fait sur NetBeans et sur l'aspect rich client: ils rejouent la démo qui m'avait totalement conquis lors de la session JDNC et qui montre la qualité des nouveaux composants, ainsi que le niveau de productivité impressionnant que l'on atteint avec NetBeans.
Tout cela est le travail de plusieurs équipes en parallèle, NetBeans bien sûr mais aussi JDNC/Swinglabs et deux autres projets OS XXX. Je n'ai toujours pas réussi à télécharger cette version, mais apparemment ça ne serait tarder.
Deuxième focus sur J2ME et sur la simplicité de coding qu'il est possible d'atteindre grâce à... NetBeans! Bon, la démo est moins renversante et le genre d'application produite reste quand même assez peu sexy et avec une ergonomie plutôt douteuse.
Deux autres focus plus exotiques: le contrôle de capteurs en Java, ce qui permet de par exemple traiter l'intformation d'un grand nombre de capteurs mesurant la température de l'eau, et un sur Java en temps réel pour le contrôle de drônes (mis en place par Boeing), ce qui est un pas en avant puisque
Java n'était pas forcément la solution la plus directe (elle est choisie essentiellement pour des raisons de portabilité et de rapidité de développement par rapport à C++).
Dernier compétiteur du concours sur la "machine à lancer les t-shirts" qui devient d'ailleurs le gagnant du concours à l'applaudimètre. Petit clin d'oeil, puisque c'est la solution la plus brute (médiévale même) qui l'emporte: une grosse catapulte à t-shirts. Comme quoi, la simplicité prime...
Suit une discussion sur l'avenir de la technologie et de Java: le challenge n'est plus dans la vitesse de processeur, mais dans le multi-processeurs et donc dans le parallélisme. Les recherches actuelles chez Sun sur les prochaines générations de langage cherchent à exploiter ce parallélisme et donc à proposer un langage qui va tirer naturellement parti des possibilités de parallélisation des futures machines sous-jacentes. Mmmm...
Première session : Loosely Coupled: Implementing Service-Oriented Architectures with Java Business Integration (JSR 208)
Un des buzz de la conférence (n°1 dans les sessions les plus vues), qui surfe sur un buzz un peu plus ancien: SOA.
La session commence par une synthèse de ce qu'est SOA pour le présentateur: pour lui, SOA est un choix d'architecture en couches (layers) qui s'oppose à une architecture monolitique et dont les couches seraient:
Ouf! On est d'accord sur la définition et sur la vision.
Une architecture SOA doit être mise en oeuvre par les équipes IT (le "service layer provider") et par les unités métier ("process layer definer"). Comment met-on tout cela en musique? Par une approche top/down qui part de la définition métier de ce qu'on veut exposer et non par de wrapping bête et méchant de l'existant en Web Services.
Un ensemble de règles générales sont ensuite présentées: coarse-grained business services, approche asychrone - qui est le point sensible et difficile à mettre en oeuvre-, XML/Document based, JBI-based...
JBI, justement, qu'est-ce que c'est? C'est la spec JSR 208, releasée en final draft le 28 juin (c'est tout frais!). Elle définit l'architecture d'un méta-container pour services et un ensemble de SPI pour mettre des plugins de deux types:
Bon, ça n'a pas l'air trop mal tout cela, l'architecture semble globalement propre (même si je ne suis pas un expert mondial de l'intégration). Reste que, comme tous les standards, il ne vaut quelque chose que s'il est respecté et pour l'instant il n'existe que l'implémentation de référence de Sun; il y a cependant fort à parier que l'achat de SeeBeyond sera un bon moyen de promouvoir cette architecture...
Deuxième session: Introduction to Eclipse's Rich Client Platform
Présentation vraiment générale et, si on connaît la technologie (ce qui est mon cas) et qu'on a vu les différents tutoriaux sur le sujet, rien de bien nouveau ici.
En deux mots, l'idée est d'utiliser Eclipse comme un container d'applications, l'IDE devenant une de ces applications déployées comme un plugin.
NetBeans le fait aussi, même si la version d'Eclipse est (à mon avis) mieux packagée et plus utilisable... moyennant le même problème que toujours: le fait d'utiliser SWT comme sous-jacent.
Deux nouveautés sympatiques de la version 3.1:
Troisième session: Java Technology Generics Programming with Parameterized Types in Java Platform 5.0
Intéressant, surtout si comme moi on n'est pas rentré dans les détails des nouveautés apportées par la 5.0. Les génériques apportent un vrai plus à Java (typage fort des collections & plus de vérifications compile-time) mais avec une complexité sous-jacente qui demande de bien comprendre les mécanismes, surtout pour bien gérer les notions d'héritage.
Très didactique et instructif + bien bas niveau comme on les aime!
Quatrième session: A Case Study in J2EE Scalability and Redundancy: The Daily Planet
Mouef, mouef, mouef... beaucoup de généralités, rien de très concret puisque volontairement l'intervenant d'Oracle ne rentre pas dans le détail des solutions techniques des différents éditeurs. Du coup, on reste un peu sur sa fin, surtout que le titre laissait présager un vrai retour d'expérience, avec du concret.
Dernière general session avec le papa de Java, James Goslin...
Un premier focus est fait sur NetBeans et sur l'aspect rich client: ils rejouent la démo qui m'avait totalement conquis lors de la session JDNC et qui montre la qualité des nouveaux composants, ainsi que le niveau de productivité impressionnant que l'on atteint avec NetBeans.
Tout cela est le travail de plusieurs équipes en parallèle, NetBeans bien sûr mais aussi JDNC/Swinglabs et deux autres projets OS XXX. Je n'ai toujours pas réussi à télécharger cette version, mais apparemment ça ne serait tarder.
Deuxième focus sur J2ME et sur la simplicité de coding qu'il est possible d'atteindre grâce à... NetBeans! Bon, la démo est moins renversante et le genre d'application produite reste quand même assez peu sexy et avec une ergonomie plutôt douteuse.
Deux autres focus plus exotiques: le contrôle de capteurs en Java, ce qui permet de par exemple traiter l'intformation d'un grand nombre de capteurs mesurant la température de l'eau, et un sur Java en temps réel pour le contrôle de drônes (mis en place par Boeing), ce qui est un pas en avant puisque
Java n'était pas forcément la solution la plus directe (elle est choisie essentiellement pour des raisons de portabilité et de rapidité de développement par rapport à C++).
Dernier compétiteur du concours sur la "machine à lancer les t-shirts" qui devient d'ailleurs le gagnant du concours à l'applaudimètre. Petit clin d'oeil, puisque c'est la solution la plus brute (médiévale même) qui l'emporte: une grosse catapulte à t-shirts. Comme quoi, la simplicité prime...
Suit une discussion sur l'avenir de la technologie et de Java: le challenge n'est plus dans la vitesse de processeur, mais dans le multi-processeurs et donc dans le parallélisme. Les recherches actuelles chez Sun sur les prochaines générations de langage cherchent à exploiter ce parallélisme et donc à proposer un langage qui va tirer naturellement parti des possibilités de parallélisation des futures machines sous-jacentes. Mmmm...
Première session : Loosely Coupled: Implementing Service-Oriented Architectures with Java Business Integration (JSR 208)
Un des buzz de la conférence (n°1 dans les sessions les plus vues), qui surfe sur un buzz un peu plus ancien: SOA.
La session commence par une synthèse de ce qu'est SOA pour le présentateur: pour lui, SOA est un choix d'architecture en couches (layers) qui s'oppose à une architecture monolitique et dont les couches seraient:
- access: c'est la couche qui expose les services et qui permet de construire un process business en assemblant des services. C'est la couche à formaliser en SOA.
- process
- service
- resource
Ouf! On est d'accord sur la définition et sur la vision.
Une architecture SOA doit être mise en oeuvre par les équipes IT (le "service layer provider") et par les unités métier ("process layer definer"). Comment met-on tout cela en musique? Par une approche top/down qui part de la définition métier de ce qu'on veut exposer et non par de wrapping bête et méchant de l'existant en Web Services.
Un ensemble de règles générales sont ensuite présentées: coarse-grained business services, approche asychrone - qui est le point sensible et difficile à mettre en oeuvre-, XML/Document based, JBI-based...
JBI, justement, qu'est-ce que c'est? C'est la spec JSR 208, releasée en final draft le 28 juin (c'est tout frais!). Elle définit l'architecture d'un méta-container pour services et un ensemble de SPI pour mettre des plugins de deux types:
- en amont, des éléments de bindings ne contenant aucune logique métier et dont le rôle est de prendre en charge le transport et la gestion des protocoles. On a des binders SOAP, FTP, HTTP, ...
- en avant, des moteurs de services qui exposent et aggrégent la logique métier
Bon, ça n'a pas l'air trop mal tout cela, l'architecture semble globalement propre (même si je ne suis pas un expert mondial de l'intégration). Reste que, comme tous les standards, il ne vaut quelque chose que s'il est respecté et pour l'instant il n'existe que l'implémentation de référence de Sun; il y a cependant fort à parier que l'achat de SeeBeyond sera un bon moyen de promouvoir cette architecture...
Deuxième session: Introduction to Eclipse's Rich Client Platform
Présentation vraiment générale et, si on connaît la technologie (ce qui est mon cas) et qu'on a vu les différents tutoriaux sur le sujet, rien de bien nouveau ici.
En deux mots, l'idée est d'utiliser Eclipse comme un container d'applications, l'IDE devenant une de ces applications déployées comme un plugin.
NetBeans le fait aussi, même si la version d'Eclipse est (à mon avis) mieux packagée et plus utilisable... moyennant le même problème que toujours: le fait d'utiliser SWT comme sous-jacent.
Deux nouveautés sympatiques de la version 3.1:
- wizard de création d'application RCP dans Eclipse IDE
- déployabilité via Java Web Start d'une application Eclipse RCP
Troisième session: Java Technology Generics Programming with Parameterized Types in Java Platform 5.0
Intéressant, surtout si comme moi on n'est pas rentré dans les détails des nouveautés apportées par la 5.0. Les génériques apportent un vrai plus à Java (typage fort des collections & plus de vérifications compile-time) mais avec une complexité sous-jacente qui demande de bien comprendre les mécanismes, surtout pour bien gérer les notions d'héritage.
Très didactique et instructif + bien bas niveau comme on les aime!
Quatrième session: A Case Study in J2EE Scalability and Redundancy: The Daily Planet
Mouef, mouef, mouef... beaucoup de généralités, rien de très concret puisque volontairement l'intervenant d'Oracle ne rentre pas dans le détail des solutions techniques des différents éditeurs. Du coup, on reste un peu sur sa fin, surtout que le titre laissait présager un vrai retour d'expérience, avec du concret.
June 29, 2005
JavaOne, day 3
Première session : High-Performance Java Foundation Classes/Swing Technology in the Real World: Lessons Learned While Developing Yahoo! SiteBuilder (Ethan Nicholas, Senior Engineer Yahoo)
Après les sessions "théoriques" sur la GUI, une session orientée "retour d'expérience" de la part d'un ingénieur de Yahoo sur l'application Swing client riche qu'ils ont mis en place. Deux mots sur l'application: elle permet d'éditer en live son site web sur Yahoo (connection temps-réel: ce que je modifie dans la GUI est mis à jour sur le site); utilisée par 130 000 personnes; constituée de 600 classes Java environ.
Tout d'abord pourquoi le choix de Java pour l'implémentation?
- La rapidité de développement: V1 en moins d'un an (whaou... première fois que j'entends cet argument)
- Les features standard de Java convenaient aux besoins de l'appli
- Cross-plateforme, puisqu'ils avaient potentiellement de nombreux utilisateurs sur Mac... ce qui finalement n'a pas marché: la JVM sur Mac est apparemment méga bugée et l'application a explosé en morceaux lors des tests, si bien qu'elle n'est pas dispo sous Mac OS. Ca fait mal, ça.
- support de MDI, avec version multi-fenêtre ou onglets
- description de tous les menus, raccourcis claviers et classe Java associées dans des ... properties files! XML a été écarté pour des problèmes de temps de start-up
- gestion des Action par super classes abstraites: les 209 actions possibles dérivent de 4 classes de base qui contiennent la gestion des événements via listener. Ce mécanisme a été mis en place pour optimiser le temps de réponse, une délégation au niveau de l'action de base étant trop lente vu le très grand nombre d'événements déclenchés par l'application (avant, un ctrl+A sur une page pouvait prendre plus de 10s). De plus, cela permet de desactiver des paquets d'actions selon que, par exemple, aucun site web n'est sélectionné
- description de la GUI via XML, pour diminuer la quantité de code pour créer la GUI. Le layout choisi est une version wrappée de Gridbaglayout pour des raisons de performances: lorsque que l'on utilise des layouts plus accessibles, la tendance est de multiplier le nombre de panels, ce qui alourdit grandement le temsp de traitement. GridBagLayout est complexe mais optimisé
Ainsi, le chargement de l'application est géré dans 2 threads: un pour la GUI et un autre en background qui charge tous les éléments nécessaires par la suite et qui sont consommateurs de ressources (JavaHelp, HtmlRenderer, JFileChoser, library XML, ...).
Pour les updates complexes entre actions utilisateurs et un preview pane par exemple, l'idée est de ralentir le temps de repaint et d'en effectuer un que toutes les 250 ms par exemple.
Un soft reference cache a également été mis en place sous la forme d'une Hashmap contenant en mémoire tous les éléments déjà utilisés par le user (popup, panels, ...), cette map étant vidée par la garbage collector à un rythme dépendant des ressources de la machine sur laquelle s'exécute l'application.
Une présentation plutôt sympa, avec un intervenant vraiment péchu et qui a bien creusé le sujet. Je vais aller jeter un coup d'oeil à cette application, qui a vraiment été développée "user-oriented" ce qui est une bonne philosophie. Son message principal est: "attention quand on manipule l'event thread", parce qu'il est le principal responsable des performances de l'application.
Ils ont utilisé OptimizeIt (Borland) pour le profiling de l'application.
Deuxième session: Hibernate 3.0 (Gavin King, JBoss)
Argl... Quel animal! Il est rapide, part dans tous les sens, regorge d'idées mais de dieu! Il n'est pas évident à suivre! En plus, il ne parle pas Anglais mais Australien ;)
(GAVIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIN !!!!)
Petit panorama d'Hibernate:
- Hibernate 3.0 est la version courante, une 3.1 est prévue pour bientôt
- Hibernate annotations : sous-projet, implémentation de la spec JSR 220; sur le sujet, GK reconnaît que les annotations sont une excellente solution pour la gestion des mappings. Releasé la semaine dernière, ce projet permet une meileure intégration avec Struts et JSF
- Hibernate entity manager: moteur de persistence d'EJB 3.0
- JBoss EJB 3.0 micro-container: une beta version sera bientôt disponible
- Hibernate tools: suite de plugins Eclipse pour reverse engineering, visualization, ...
Suit une très longue démonstration sur la meilleure manière de gérer l'héritage avec Hibernate dans le cas d'un mapping objet / relationnel. En objet, le subtypage est utilisé pour l'héritage de comportement ce qui ne concerne pas le modèle; en relationnel, il est possible d'avoir plusieurs types pour une même item, ce qui n'est pas possible en objet : encore un exemple de "mismatch". Je ne rentre pas dans le détail de la démo qui montre sur un exemple super simple (3 objets: folder et document qui hérite de file) les stratégies d'héritage possibles via les annotations (@Inheritance(strategy=JOINED, TABLE_PER_CLASS, SINGLE_TABLE, ..)) et les conséquences que cela peut avoir sur les performances bdd et sur la complexité des requêtes HQL pour la récupération des objets.
Un petit panorama ensuite sur les stratégies de fetching et sur le moment du fetch pour traiter le problème de "l'association fetching": j'ai une grappe complexe, quelle stratégie utiliser pour éviter que pour chaque descente à l'étape n+1, un aller-retour serveur se produise ("n+1 select problems"). Toutes les solutions sont parcourues et pour lui la meilleure est le "subselect fetching" (possible depuis la version 3.0). Elle consiste à faire 2 selects à chaque étape et donc à récupérer les coups d'après potentiel; c'est la bonne solution parce qu'elle est recursive et donc scalable.
Démonstration sur les filtres Hibernate, qui permettent à l'aide de métadata de placer des filtres dans les mappings et, via un "enableFilter()" au runtime, on garde un code non pollué par des filtres. Une application possible est l'application de paramètres de sécurité (on filtre selon le rôle de manière transparente pour le code métier).
Preview sur Hibernate 3.1 qui prendra en compte le bulk update/delete (qui est défini par ailleurs dans EJBQL 3.0).
Bon, je n'ai pas compris toutes les subtilités, mais ça reste impressionnant. Il promet plein de nouvelles features dans Hibernate 3.1 et j'ai le sentiment que, malgré la rapprochement avec EJB 3.0, il a toujours envie de garder son indépendance et proposer des features "maison" avancées. A suivre... En tout cas, on a vu toute la richesse / complexité d'Hibernate et, franchement, je suis plus que convaincu que l'optimisation Hibernate est un métier à part entière.
Troisième session: RFID and Java Technology--a Reality
Bon, je tente une petite session originale, pour sortir un peu des sentiers... quelle erreur!
L'intro est alléchante et promet une overview des problématiques RFID et des différentes architectures pour répondre à ces problèmes. Le seul soucis, c'est que les orateurs pré-supposent une connaissance des différentes normes (EPCS??), technologies et hardware associés... le tout sur fond de lecture bête et méchante de slide: beurk! je pars au bout de 20mn en trouvant leur approche peu didactique
Quatrième session : Tapestry in Action, par le créateur / tech-lead du projet Howard Lewis Hiss.
Il commence par une petite interview de la salle: "qui a déjà utilisé Struts? - 80% de la salle lève la main - qui aime bien Struts? - 2/3 restent levées...". Le ton est donné!
En deux mots Tapestry est un framework "component-oriented" dont la motivation est de permettre un développement simple et rapide, basé sur la ré-utilisation de composants. Et non, ce n'est pas juste un moteur de templating, un Struts ++ ou bien un "one-man project".
Le principal fait d'arme de Tapestry est theserverside.com, réalisé entièrement dans cette technologie.
La présentation est un tutorial sur Tapestry, plutôt vivant et bien animé. Malgré la volonté de "rendre les choses les plus naturelles possibles", je ne suis pas ébloui par la simplicité de la chose...
Là où le bas blesse est que le marché du framework Web est déjà bien encombré et JSF fait de plus en plus de bruit, avec une approche proche de celle de JSF. Le positionnement de Tapestry est d'autant plus problématique que JSF va sans doute être intégré à Java EE 5.0 ce qui sonne un peu le glas pour cette technologie...
Un bon point tout de même: l'adaptation d'un application Tapestry en portlet se fait semble-t-il sans problèmes...
Les slides sont dispos ici.
Cinquième session : Spring and JavaServer Faces Technology: Synergy or Superfluous? (Rod Johnson, Inteface 21 et XXX d'Oracle)
On continue avec les stars: c'est Rod Johnson, créateur de Spring, qui s'y colle ce coup-ci et de dieu!! Il est écossais avec un accent à couper au couteau... décidemment, entre Gavin King et lui, heureusement qu'ils écrivent aussi des bouquins ;)
L'idée de la présentation est de montrer comment intégrer JSF et Spring, en montrant qu'ils sont totalement complémentaires et non concurrents.
Ainsi, JSF est un framework web qui:
- suit la spécification JSR 127
- est multi plate-forme
- propose une vue et un controlleur
- propose un modèle de gestion par événements et un management du cycle de vie des pages
- est extensible (mécanisme de decorator)
- est un framework de liant
- est un IoC container, qui permet de "keep the POJO code clean"
- propose un framework AOP, dont l'objectif est d'appliquer des services au POJO sans pollution du code (par aspect)
- gère l'accès aux données de manière indépendante par rapport à la technologie sous-jacente (Hibernate, Toplink <la présentation est en collaboration avec Oracle>, JDO, ...)
- gère les transactions
- propose un framework web MVC
- fonctionne sur le mode "pick & choose"
Les deux solutions proposent une approche POJO, laisse le framework gérer les objets (cycle de vie, événements) et permet une abstraction vis-à-vis des technos sous-jacentes.
Deux manières d'intégrer:
- on référence les beans Spring comme des managed beans JSF, ce qui a pour inconvénient de toujours conserver deux types de beans mais se fait en une ligne XML dans le fichier de conf de JSF
- on utilise le projet OS jsf-spring qui permet un support bi-directionnel
Pour l'aspect persistance, RJ encourage l'utilisation d'interfaces DAO portant des finder, save et aggregate methods (count, ...) ce qui permet d'être agnostic par rapport au moteur de persistence mais simplifie également le mocking pour les tests.
Des projets complémentaires:
- Spring WebFlow: une extension de JSF OS (sourceforge)
- Acegi Security: super framework de sécurité qui sera intégrée à la prochaine version de Spring
- Shale
Session intéressante, je suis encore un fois bluffé par la bête que j'ai en face de moi. RJ a réussi son coup: il a prouvé l'intégration sans problème de Spring et JSF, qui va rentrer dans Java EE et donc, indirectement, renforce la pérennité de Spring (s'il fallait en prouver le besoin...)
Sixième session : How to Build Rich Desktop Client Applications Using NetBeans Platform 4.1
Dernière session sur NetBeans RCP: un tutorial sur comment coder un reader RSS (décidemment, dès qu'on parle Desktop, c'est TOUJOURS l'exemple que l'on prend). En deux mots, l'idée est de proposer NetBeans comme une plate-forme (et non un IDE) dans laquelle on code des "modules" qui vont constituer l'application, ce qui permet de profiter d'un framework de plus haut niveau. Cette feature est possible depuis la version 4.0, qui est un refactoring majeur de la 3.6 et donc les travaux se sont concentrés sur l'architecture de l'application (structuration en modules indépendants).
Bon, autant le dire tout de suite, je n'ai pas été emballé: je connais pas trop mal Eclipse RCP et là, c'est la même chose mais en version cra-cra. 3000 fichiers de configuration XML à éditer à la main (on nous promet que dans NetBeans 4.2 on aura une GUI) pour configurer une application RCP "vide". De plus, apparemment de nombreuses règles de cohérence entre ces fichiers existent mais elles ne sont controllées par rien...
Une fois la phase de configuration terminée, on code... encore du XML pour disposer les wigets dans la GUI de la plate-forme et pour faire le branding de l'application. Reste (un peu) de code Java pour tout le reste.
Le résultat est ... incroyablement moche (je ne suis pas un fan de Swing, mais alors là, on atteint des sommets). Tout cela, Eclipse RCP le fait déjà depuis 1 an, avec un modèle de programmation plus sympatique et accessible, ainsi qu'un modèle de docking de composants (organisés en vue/perspective) que NetBeans n'a pas.
Ambiance!
Elle n'est pas belle, la vie?
Petite détente devant "Rock Academy" entre 2 sessions...
Coding challenge: qui codera le plus vite un use case? Avec suivi en live sur des écrans placés derrière les codeurs... (bouuuuuh!! y'en a qui regarde la JavaDoc: tricheurs!!). Et "Oui", on est obligé de coder en Java ;)
Petite détente devant "Rock Academy" entre 2 sessions...
Coding challenge: qui codera le plus vite un use case? Avec suivi en live sur des écrans placés derrière les codeurs... (bouuuuuh!! y'en a qui regarde la JavaDoc: tricheurs!!). Et "Oui", on est obligé de coder en Java ;)
L'usine de la peur
Je reviens de la petite soirée organisée par Sun pour ses client français: fort sympatique et assez riche en discussions. Le thème à dérivé des sessions JavaOne à plus particulièrement des sujets de "la vie courante" du développeur et notamment les usines de développement! Plusieurs personnes avec qui j'ai abordé le sujet m'ont opposé le même argument: "c'est génial, mais c'est dur à mettre en place parce que les développeurs le vivent un peu comme une sanction".
Bizarre non? C'est la première fois qu'on me dit ça et c'est étrange la vision que l'on peut avoir... Est-ce lié au lien "usine de dev"="contrôle qualité"="sanction en cas d'erreur". Pour moi, si on implique les développeurs et qu'on leur explique les bienfaits de la chose (contrôle de leur code, responsabilisation, visibilité sur le travail de l'équipe, non régression, etc.), il n'y a pas de raison qu'ils n'adhèrent pas au processus.
C'est également lié à un aspect organisationnel: l'usine de dev va souvent être pilotée par le chef de projet ou bien par une équipe d'architectes qui est extérieure au projet. Peut-être la confier à un développeur de l'équipe?
En tout cas, je n'ai jamais eu ce type de retour sur les projets que j'ai pu faire.
Bizarre non? C'est la première fois qu'on me dit ça et c'est étrange la vision que l'on peut avoir... Est-ce lié au lien "usine de dev"="contrôle qualité"="sanction en cas d'erreur". Pour moi, si on implique les développeurs et qu'on leur explique les bienfaits de la chose (contrôle de leur code, responsabilisation, visibilité sur le travail de l'équipe, non régression, etc.), il n'y a pas de raison qu'ils n'adhèrent pas au processus.
C'est également lié à un aspect organisationnel: l'usine de dev va souvent être pilotée par le chef de projet ou bien par une équipe d'architectes qui est extérieure au projet. Peut-être la confier à un développeur de l'équipe?
En tout cas, je n'ai jamais eu ce type de retour sur les projets que j'ai pu faire.
JBoss rules
Quatrième session : How to Build Killer Portlets Using JavaServer Faces Technology, présentée par Stan Silvert (JBoss)
Wahou! C'est blindé et je suis le dernier à pouvoir rentrer dans la salle: le sujet est chaud, les gens sont motivés!
JSF est à l'honneur et l'objectif est de montrer que si on veut faire du portail, c'est la JSR 168 (JSF) qu'il faut implémenter. Aujourd'hui, il existe la Reference Implementation et MyFaces de Jakarta qui semble plus évoluée.
Toute application JSR 168 compliant peut tourner dans un container de servlet classique ou bien dans un conteneur de portlet (portal), l'avantage de la deuxième solution étant de permettre de bénéficier normalement des autres avantages des solutions de portail (...) ... lorsque ceux-ci seront JSF compliant! Le premier à l'être est JBoss Portal 2.0, démo à l'appui. La piste Struts est rapidement enterrée: le portage serait ho-rrible, comme le montrent les 10 slides (volontairement chargés) d'instructions à suivre; ce portage devrait s'appuyer sur Apache Struts-bridge.
Le deuxième avantage des portlets est l'aspect composant de la chose, qui pousse à la ré-utilisabilité et peut lancer un marché de composants web. Le premier à se lancer sont Oracle, ainsi que MyFaces qui propose aussi ses propres composants.
Le troisième (petit) avantage est de laisser le portail gérer l'état des portlets: chacun peut en effet prendre les états VIEW, EDIT et HELP, le basculement étant gérer par le framework et l'affichage par le container de portlet.
Pas mal tout cela! A la question: "qui a déjà codé des portlets?", on a facile 25% de la salle qui répond. L'heure de JSF approche mais elle ne pourra se faire que lorsque les éditeurs de portails implémenteront JSR 168...
Cinquième session: Workflow, BPM and Java Technology présentée par Tom Baeyens (JBoss).
Aïe, il fait désormais beau dehors... Vite, un sujet un peu "exotique" pour que je reste (une autre session sur la gui Java me tuerait) ;)
La problématique est d'offrir un framework unique (un core framework) pour les différentes problématiques d'intégration identifiées: BPM (optimisation de process, basé sur des extractions de données des process), Workflow management (gestion de tâches attribuées à des utilisateurs avec des rôles et des actions possibles différents) et orchestration (problématique technique d'intégration)... mais sans proposer un moteur répondant à toutes ces problématiques. En effet, l'objectif est de proposer une base commune pour gérer les problématiques à l'intersection de ces trois aspects.
D'un point de vue technique, le problème est que Java ne sait pas gérer les états d'attente (process A attend que le process B ait fini de traiter des actions pour reprendre la main).
D'un point de vue organisationnel, il ne faut pas que les contraintes techniques de développeurs influent sur la modélisation du business analyst.
La solution magique?? Graph Oriented Programming!! (le nouveau buzz de l'espace?)
Ce framework définit comment on parcourt un graph et comment on gère les interruptions/reprises. Simplicité est le mot d'ordre: 3/4 classes maximum, en se basant sur des design patterns de base (chain of responsability, command) et sur JMS par exemple pour l'aspect asynchrone. On dispose alors d'une base commune qui permet d'évoluer vers le besoin spécifique qui évite de ré-écrire from scratch un framework spécifique.
JBoss est spec lead sur le sujet (enfin... c'est intégré à JBoss depuis peu), avec son implémentation jbpm outillée dans un plugin Eclipse, et qui récupère ainsi 4 ans de R&D sur le sujet (wahou! tout ça pour ça). On dispose ainsi d'un langage (jbpl) commun aux développeurs et aux business analysts.
La démo est assez sympa, plutôt visuel et semble efficace: on crée graphiquement dans Eclipse un workflow, on déploie dans JBoss et on a un portail qui gère les différentes étapes du workflow et l'assignement au personnes concernées par chaque rôle.
Les vraies perspectives? Est-ce que cela va être intégré à une JSR? Ou bien est-ce la réponse de JBoss aux différentes offres de ses concurrents (BEA, WebSphere) sur les solutions d'EAI? Les JSR les plus proches sont:
Wahou! C'est blindé et je suis le dernier à pouvoir rentrer dans la salle: le sujet est chaud, les gens sont motivés!
JSF est à l'honneur et l'objectif est de montrer que si on veut faire du portail, c'est la JSR 168 (JSF) qu'il faut implémenter. Aujourd'hui, il existe la Reference Implementation et MyFaces de Jakarta qui semble plus évoluée.
Toute application JSR 168 compliant peut tourner dans un container de servlet classique ou bien dans un conteneur de portlet (portal), l'avantage de la deuxième solution étant de permettre de bénéficier normalement des autres avantages des solutions de portail (...) ... lorsque ceux-ci seront JSF compliant! Le premier à l'être est JBoss Portal 2.0, démo à l'appui. La piste Struts est rapidement enterrée: le portage serait ho-rrible, comme le montrent les 10 slides (volontairement chargés) d'instructions à suivre; ce portage devrait s'appuyer sur Apache Struts-bridge.
Le deuxième avantage des portlets est l'aspect composant de la chose, qui pousse à la ré-utilisabilité et peut lancer un marché de composants web. Le premier à se lancer sont Oracle, ainsi que MyFaces qui propose aussi ses propres composants.
Le troisième (petit) avantage est de laisser le portail gérer l'état des portlets: chacun peut en effet prendre les états VIEW, EDIT et HELP, le basculement étant gérer par le framework et l'affichage par le container de portlet.
Pas mal tout cela! A la question: "qui a déjà codé des portlets?", on a facile 25% de la salle qui répond. L'heure de JSF approche mais elle ne pourra se faire que lorsque les éditeurs de portails implémenteront JSR 168...
Cinquième session: Workflow, BPM and Java Technology présentée par Tom Baeyens (JBoss).
Aïe, il fait désormais beau dehors... Vite, un sujet un peu "exotique" pour que je reste (une autre session sur la gui Java me tuerait) ;)
La problématique est d'offrir un framework unique (un core framework) pour les différentes problématiques d'intégration identifiées: BPM (optimisation de process, basé sur des extractions de données des process), Workflow management (gestion de tâches attribuées à des utilisateurs avec des rôles et des actions possibles différents) et orchestration (problématique technique d'intégration)... mais sans proposer un moteur répondant à toutes ces problématiques. En effet, l'objectif est de proposer une base commune pour gérer les problématiques à l'intersection de ces trois aspects.
D'un point de vue technique, le problème est que Java ne sait pas gérer les états d'attente (process A attend que le process B ait fini de traiter des actions pour reprendre la main).
D'un point de vue organisationnel, il ne faut pas que les contraintes techniques de développeurs influent sur la modélisation du business analyst.
La solution magique?? Graph Oriented Programming!! (le nouveau buzz de l'espace?)
Ce framework définit comment on parcourt un graph et comment on gère les interruptions/reprises. Simplicité est le mot d'ordre: 3/4 classes maximum, en se basant sur des design patterns de base (chain of responsability, command) et sur JMS par exemple pour l'aspect asynchrone. On dispose alors d'une base commune qui permet d'évoluer vers le besoin spécifique qui évite de ré-écrire from scratch un framework spécifique.
JBoss est spec lead sur le sujet (enfin... c'est intégré à JBoss depuis peu), avec son implémentation jbpm outillée dans un plugin Eclipse, et qui récupère ainsi 4 ans de R&D sur le sujet (wahou! tout ça pour ça). On dispose ainsi d'un langage (jbpl) commun aux développeurs et aux business analysts.
La démo est assez sympa, plutôt visuel et semble efficace: on crée graphiquement dans Eclipse un workflow, on déploie dans JBoss et on a un portail qui gère les différentes étapes du workflow et l'assignement au personnes concernées par chaque rôle.
Les vraies perspectives? Est-ce que cela va être intégré à une JSR? Ou bien est-ce la réponse de JBoss aux différentes offres de ses concurrents (BEA, WebSphere) sur les solutions d'EAI? Les JSR les plus proches sont:
- JSR 207: process definition for Java (spec lead chez... BEA!)
- JSR 208: Java Business Integration (JBI), avec une problématique plus large (intégration de services)
June 28, 2005
Riche, vous avez dit riche?
Première session: Architectural Overview of the Apache Geronimo Project.
Allons voir du côté d'Apache ce qu'ils proposent... L'idée: proposer à la fois un serveur d'application J2EE basé sur des composants OSS existants (Jetty, OpenEJB, ActiveMQ) ou bien sur du code Geronimo spécifique, et un framework au-dessus, avec un modèle de programmation teinté IoC dont les objectifs sont:
La présentation n'est (à mon avis) pas assez technique et on a du mal à voir vraiment ce que propose le projet. Il y a bien sûr des bonnes idées (orienté configuration d'application, focus sur la disponibilité de l'application, ...) mais aujourd'hui, quel intérêt aurait-on à utiliser cette solution? Le marché du serveur d'application OS est bien occupé par JBoss et pourquoi apprendre un autre modèle de programmation IoC quand on peut utiliser Spring directement...
Par ailleurs, lors des évolutions des briques sous-jacentes (Jetty par exemple), ils sont obligés de faire une branche puis de migrer Geronimo pour intégrer la nouvelle version: bonjour le bordel...
Fin de la présentation, celui qui présente explique que des tas des personnes sont impliquées dans le projet et demande que celles présentes dans la salle se lèvent: un seul barbu (mais alors vraiment barbu) répond au premier rang.... aïe...
Deuxième session: Creating a Desktop Java Technology Application Leveraging Open Source: End to End, avec l'auteur du livre "Java Desktop Live".
Ah! Le vif du sujet! L'objectif de la session est de présenter les solution OS qui facilitent aujourd'hui le développement Java Desktop. Les problématiques présentées:
Des questions s'enchaînent, d'autres personnes sont intéressées et il semble que Spring RCP est vraiment complet, avec beaucoup de services techniques sympas (sécurité, binding, validation, ...) et beaucoup de widgets (wizards, frame principale, ...). Le comitter affirme qu'il a déjà fait plusieurs projets "importants" java rich client avec Spring RCP sans problème... Mmmm... Très alléchant tout cela, il va falloir aller regarder sérieusement!!
Je cours attraper un sandwich et je suis de retour pour...
Troisième session: Simplifying Java Technology Desktop Client Construction Using JDesktop Network Components (JDNC).
Désormais, il faut parler de SwingLabs, qui est l'émulation de JDNC, le projet étant devenu trop gros: SwingLags est splité en sous-projets sur la validation, le binding, jdnc (qui devient un sous-projet), etc...
Et là! BAAAAM!! La démo qui calme! (mais alors vraiment - à télécharger ici une version pas complétement à jour malheureusement... il faudra me croire, j'ai vu la nouvelle version!!) avec tous les composants/features disponibles actuellement. Accrochez-vous:
... et tout ça est disponible NOW! Bon, le seul problème, c'est que les équipes qui bossent dessus (environ 6/7 personnes dont la moitié chez Sun) sont différentes de celles qui bossent sur Swing et on ne sait pas trop quand tout cela sera intégré au JRE. Pour le moment, à chaque version de JRE est prévu une version de JDNC (pardon, SwingLabs), même pour Dolphin (JRE 7.0)... un peu de coordination, Messieurs, diantre!
Personnellement, je suis complétement conquis, j'ai hâte de voir tout cela. Ils ont un stand dans le Java Pavillion: je foooooooooooonce!!
Allons voir du côté d'Apache ce qu'ils proposent... L'idée: proposer à la fois un serveur d'application J2EE basé sur des composants OSS existants (Jetty, OpenEJB, ActiveMQ) ou bien sur du code Geronimo spécifique, et un framework au-dessus, avec un modèle de programmation teinté IoC dont les objectifs sont:
- la scalabilité: pouvoir utiliser le framework sur un simple poste de développeur ou bien en cluster pour une application d'entreprise de manière transparente
- accès sur la configuration et le contrôle de l'application (et non du serveur d'application), en se basant sur JMX
- architecture non intrusive, dont le composant maître est le GBean (modèle à base d'IoC), qui possède son cycle de vie respectant JSR 77
La présentation n'est (à mon avis) pas assez technique et on a du mal à voir vraiment ce que propose le projet. Il y a bien sûr des bonnes idées (orienté configuration d'application, focus sur la disponibilité de l'application, ...) mais aujourd'hui, quel intérêt aurait-on à utiliser cette solution? Le marché du serveur d'application OS est bien occupé par JBoss et pourquoi apprendre un autre modèle de programmation IoC quand on peut utiliser Spring directement...
Par ailleurs, lors des évolutions des briques sous-jacentes (Jetty par exemple), ils sont obligés de faire une branche puis de migrer Geronimo pour intégrer la nouvelle version: bonjour le bordel...
Fin de la présentation, celui qui présente explique que des tas des personnes sont impliquées dans le projet et demande que celles présentes dans la salle se lèvent: un seul barbu (mais alors vraiment barbu) répond au premier rang.... aïe...
Deuxième session: Creating a Desktop Java Technology Application Leveraging Open Source: End to End, avec l'auteur du livre "Java Desktop Live".
Ah! Le vif du sujet! L'objectif de la session est de présenter les solution OS qui facilitent aujourd'hui le développement Java Desktop. Les problématiques présentées:
- layout
-
- ceux du JRE sont trop simples ou trop complexes (ok!), donc difficilement utilisables)
- des options OS intéressantes sont disponibles (ExplicitLayout, TableLayout, FormLayout) et effectivement, sur un exemple on voit rapidement la lisibilité et la compacité du code par rapport au verbeux GridBagLayout
- ceux du JRE sont trop simples ou trop complexes (ok!), donc difficilement utilisables)
- databinding
-
- JDNC et Spring RCP, qui sont toujours en évolution
- JGoodies: 1.0 released et facilement adaptable. C'est la solution qu'il préconise... Le fonctionnement: une interface ValueModel avec des get/setValue, add/removeValueChangeListener qui est ensuite bindée sur un widget ("BasicComponentFactory.createTextField(new ValueModel(...))").
- validation
-
- JDNC / Spring RCP
- JGoodies: encore une fois le préféré, puisque independant du binding
- FormBuilder
-
- c'est un object construisant automatiquement un formulaire sur la base d'un objet Java, en gérant le layout, le binding, la validation. Le présentateur en a codé un et va le rendre disponible sur java.net.
- Threading: deux approches possibles
-
- synchrone: deux frameworks OS permettent de lancer dans un deuxième thread le paint de l'interface pendant que le thread principal traite les demandes utilisateur:
-
- Spin (sourceforge): intrusif puisqu'il faut implémenter une interface
- Foxtrot (sourceforge): plus light ("Worker.post(new Job(){run(...)})")
- Spin (sourceforge): intrusif puisqu'il faut implémenter une interface
- asynchrone: SwingWorker, qui sera intégré dans Java SE 6.0 (Mustang) et qui est disponible dans JDNC. Le fonctionnement se fait par implémentation d'une classe abstraite qui dispose des bonnes méthodes pour paralléliser les traitements.
Des questions s'enchaînent, d'autres personnes sont intéressées et il semble que Spring RCP est vraiment complet, avec beaucoup de services techniques sympas (sécurité, binding, validation, ...) et beaucoup de widgets (wizards, frame principale, ...). Le comitter affirme qu'il a déjà fait plusieurs projets "importants" java rich client avec Spring RCP sans problème... Mmmm... Très alléchant tout cela, il va falloir aller regarder sérieusement!!
Je cours attraper un sandwich et je suis de retour pour...
Troisième session: Simplifying Java Technology Desktop Client Construction Using JDesktop Network Components (JDNC).
Désormais, il faut parler de SwingLabs, qui est l'émulation de JDNC, le projet étant devenu trop gros: SwingLags est splité en sous-projets sur la validation, le binding, jdnc (qui devient un sous-projet), etc...
Et là! BAAAAM!! La démo qui calme! (mais alors vraiment - à télécharger ici une version pas complétement à jour malheureusement... il faudra me croire, j'ai vu la nouvelle version!!) avec tous les composants/features disponibles actuellement. Accrochez-vous:
- widgets en pagaille (datepicker hyper-hyper-évolué, login panel, panel, task panes, ...)
- table et treetable hyper évoluées, avec filtre, sélection de colonne, resize paramétrable, ...
- hyperlink
- auto-complétion qui marche du feu de dieu
- gestion des transparences
- framework d'Action (décorelle actions des données et permet un ré-utilisation, le tout en mode déclaratif)
- framework d'authentification basé sur JAAS (indépendant des dialogues de login)
- framework de binding (différent de celui XML de JDNC) avec un dataPath (le nom du POJO par exemple), un BindingContext qui est instancié par une BindingFactory qui se charge des listeners, de la validation, des accès en écriture/lecture. Tous les composants JX.... sont "bindables" via ce framework. Avec ça, on fait de l'Hibernate finger inzenoze. Le framework supporte aussi du binding XML et DataSet, dont l'API est identique à celle d'ADO.NET
... et tout ça est disponible NOW! Bon, le seul problème, c'est que les équipes qui bossent dessus (environ 6/7 personnes dont la moitié chez Sun) sont différentes de celles qui bossent sur Swing et on ne sait pas trop quand tout cela sera intégré au JRE. Pour le moment, à chaque version de JRE est prévu une version de JDNC (pardon, SwingLabs), même pour Dolphin (JRE 7.0)... un peu de coordination, Messieurs, diantre!
Personnellement, je suis complétement conquis, j'ai hâte de voir tout cela. Ils ont un stand dans le Java Pavillion: je foooooooooooonce!!
JavaOne, 2ème jour: mangez des pommes!
C'est reparti, deuxième jour de marathon. On commence par une session générale avec le boss (Scott Mc Neal) au titre très "chiraquien": "réduire la fracture digitale". La présentation commence avec un défilé de différents partenaires, pour célébrer la réussite de Java dans tous les domaines. Petit scoop: Sun vient d'acheter SeeBeyond et le patron de SeeBeyond est là, pour venter les mérites de ce rapprochement et promet que la nouvelle plate-forme commune va "transformer vos applications mainframe en SOA parlant Java" (tout un programme).
Un exemple de réduction de cette fracture: sans se démonter, le responsable de la R&D de Sun explique comment en Inde il est désormais possible de faire les enchères sur les marché aux légumes grâce à son téléphone portable, ces enchères étant automatiquement traitées sur une plate-forme Java, ce qui permet de simplifie la vie des gens pauvres (qui ont bien entendu un téléphone portable Java) qui vont acheter leurs mangues tous les matins... je regarde autour de moi: je suis le seul à être médusé, bon.
Un deuxième business case un peu plus significatif: le système médical brésilien. Tout a été refondu sur la base d'une architecture Java et désormais, quelque soit le médecin que l'on consulte dans le pays, il a accès à notre dossier médical par un simple code barre placé sur la carte de sécurité sociale. Un véritable succès, et en plus, le code source est disponible en ligne avec une license open source pour tous les pays qui souhaitent l'utiliser pour leur système médical. Pas mal.
Un exemple de réduction de cette fracture: sans se démonter, le responsable de la R&D de Sun explique comment en Inde il est désormais possible de faire les enchères sur les marché aux légumes grâce à son téléphone portable, ces enchères étant automatiquement traitées sur une plate-forme Java, ce qui permet de simplifie la vie des gens pauvres (qui ont bien entendu un téléphone portable Java) qui vont acheter leurs mangues tous les matins... je regarde autour de moi: je suis le seul à être médusé, bon.
Un deuxième business case un peu plus significatif: le système médical brésilien. Tout a été refondu sur la base d'une architecture Java et désormais, quelque soit le médecin que l'on consulte dans le pays, il a accès à notre dossier médical par un simple code barre placé sur la carte de sécurité sociale. Un véritable succès, et en plus, le code source est disponible en ligne avec une license open source pour tous les pays qui souhaitent l'utiliser pour leur système médical. Pas mal.
Une BOF et au lit!
Allez, un dernier effort: direction le Mariott Hotel pour ma première BOF.
Ambiance feutrée de fin de soirée pour le sujet: JCP, Java Community Process, le process qui permet de passer d'une idée (géniale?) à une JSR. Qu'est-ce qu'une JSR? Elle se compose de trois éléments: la spécification en elle-même, une implémentation de référence et un kit de test permettant de vérifier que toute autre implémentation respecte la spécification (Java Compatility Kit). En moyenne, le process prend 450 jours depuis l'idée à la release.
Les principaux sujets relevés sont:
Pas mal ces bofs, même si la participation n'est pas toujours maximale (pas mal de monde qui écoute, peu de questions, ...). En tout cas, ce process est pas mal et je me demande s'il ne pourrait pas être appliqué ailleurs, comme un process d'innovation collaborative... chez OCTO par exemple?
Bon, il est 22.30, je suis crevé: direction le lit!!
Ambiance feutrée de fin de soirée pour le sujet: JCP, Java Community Process, le process qui permet de passer d'une idée (géniale?) à une JSR. Qu'est-ce qu'une JSR? Elle se compose de trois éléments: la spécification en elle-même, une implémentation de référence et un kit de test permettant de vérifier que toute autre implémentation respecte la spécification (Java Compatility Kit). En moyenne, le process prend 450 jours depuis l'idée à la release.
Les principaux sujets relevés sont:
- le mode de licensing, qui est laissé au libre choix du responsable de la JSR: cette liberté conduit souvent à une certaine hétérogénéité entre les différentes technologies. La solution: des JSR "bundle" qui regrouppent plusieurs autres JSR
- le problème des JSR dormantes: des specs qui commencent et qui ne se terminent jamais.... c'est justement le rôle du JCP de relancer, voir de demander de passer le témoin à d'autres
- la communauté est super large: plus de 900 entreprises dans le process, avec plus de 60 entreprises menant des JSR
- Sun n'a pas de rôle spéciale, mais ne participe que comme un membre à part entière de la review. Il dispose tout de même d'un droit de véto pour tout ce qui touche à la structure du langage.
- le workflow est le suivant: jsr submission -> jsr review+vote -> early draft -> public review -> final approval ballot -> final release
- on trouve tout sur ... www.jcp.org!
Pas mal ces bofs, même si la participation n'est pas toujours maximale (pas mal de monde qui écoute, peu de questions, ...). En tout cas, ce process est pas mal et je me demande s'il ne pourrait pas être appliqué ailleurs, comme un process d'innovation collaborative... chez OCTO par exemple?
Bon, il est 22.30, je suis crevé: direction le lit!!
Search
my advertisement
Sites partenaires
Albums
