Blog Objet Direct

Le dernier Paris JUG avant la pause estivale était consacré entièrement à Java EE 6.

Adam Bien, membre du JCP et Java champion, nous a fait une présentation en deux parties : d’abord les concepts et ensuite des exemples de code en direct.

Les concepts.

L’utilisation des annotations et du principe de « convention over configuration » fait souffler une brise légère sur notre vision de Java EE !

Java EE se veut maintenant rapide, simple, léger, « lean » et permettre des cycles de développement court. Bien sur la comparaison avec Spring arrive très vite : Spring nécessiterait plus de configuration et Java EE 6 serait plus basé sur les conventions.

D’abord j’aimerais insister sur le principe de « convention over configuration » qui a fait le succès de frameworks très productifs tels que Ruby on Rails, Grails ou encore Play. Si l’ensemble reste fortement configurable dans la joie des fichiers XML, ce principe permet d’alléger considérablement le travail de développeur et donc de le rendre plus productif. Cela permet aussi d’avoir un framework plus cohérent.

Adam Bien nous fait un retour sur l’ensemble des concepts phare de l’architecture : ECB, SOA et DDD.

Il nous présente d’abord le pattern Entity Control Boundary qui est un pattern similaire à MVC et son application avec JEE 6. Il en vient ensuite rapidement au concept du Domain Driven Design qu’il met en avant ! Ce qui fera plaisir à certains L’idée est d’avoir des entités riches et réellement utiles et d’enlever la couche DAO. Les domaines sont mis en avant au détriment des services. La logique s’oppose donc à l’architecture SOA classique qui s’articule autour du trio Service/DAO/Domain. C’est une approche avec état qui permet alors d’adresser certains problèmes plus simplement et de remettre la complexité du métier au sein de l’application. La synchronisation entre les objets et la base de données se fait grâce à JPA/Hibernate. Elle permet aussi d’avoir moins de couche technique et s’interface très bien avec REST.

Il présente aussi la facilité de mettre en place la vue avec JSF 2 qui permet  d’accéder directement à des Managed Beans ou à des EJB, grâce à un Expression Language. La couche de configuration de la vue en devient presque inexistante.

Il fait bien sur le tour des apports et des nouveautés de Java EE 6 :

• un JNDI standardisé
• EJB 3.1 + REST facilité avec l’annotation @Path (pas de XML, pas de configuration de container)
• des timers similaire au « cron » avec @Schedule
• des singletons avec @Singleton (en combinant avec @PostConstruct, on peut ainsi créer des singletons simplement et de manière sûre).
• tâches asynchrones avec @Asynchronous qui renvoient des objets de type Future<?>.
• EJB qui exposent directement leur métriques en JMX.
• Selon Adam, la différence de performances entre un Pojo et un EJB est infinitésimale – alors que la possibilité de monitorer l’application en production est « priceless ».
• CDI qui s’inspire de ce qui a été introduit par Spring

Dans la deuxième partie de cette soirée, Adam Bien fait le tour en direct des principales fonctionnalités de Java EE 6.

En conclusion, pour quelqu’un qui, comme moi, n’a pas une grand expérience sur toute l’architecture SOA et qui fuit les fichiers de configurations, Java EE 6 semble clair, facile à prendre en main et réellement efficace ! La mise en avant de l’approche DDD est aussi de bonne augure la qualité des applications.

Allez pour compléter, vous trouverez d’autres excellents résumés ici :

• http://thecodersbreakfast.net/index.php?post/2010/07/06/Paris-JUG-Java-EE-6-par-Adam-Bien
• http://www.touilleur-express.fr/2010/07/07/soiree-paris-jug-java-ee-6-par-adam-bien/
• http://jduchess.org/duchess-france/blog/ejb-3-x-lightweight-killer-apps-but-nothing-more-than-adam-in-action/

• 

Dans la lignée des annonces du Google I/O 2010, il y a bien sur Android 2.2 alias Froyo qui apporte son lot de fonctionnalités.

On retiendra surtout la machine virtuelle Dalvik qui intègre le Just In Time ou compilation à la volée ce qui permet d’améliorer la performance des applications de 2 à 5 fois mais aussi l’intégration du moteur javascript V8 au navigateur embarqué qui met les performance devant l’iphone 3G et même l’ipad.

Il y aussi le support du Flash en version 10 qui permet de se démarquer de la concurrence

On notera aussi le partage de la connexion 3G avec un ordinateur, l’amélioration du market, la possibilité de stocker les applications sur la SD card et de nouvelles APIs.

Plus d’informations ici : http://android-france.fr/2010/05/20/android-2-2-froyo-est-officiel-voila-la-liste-des-fonctionnalites/

Pour information, la mise à jour est disponible sur le mobile de Google ou Nexus One. Pour les autres mobiles sous Android, on pense aux derniers HTCs, il faudra attendre que les constructeurs s’adaptent ce qui montre aussi les limites de la stratégie de Google en terme de diversification du marché.

• 

Voici le résumé de cette soirée Scala du Paris JUG.

Première présentation par Sadek Drobi, chroniqueur à InfoQ.

Sa présentation est une introduction aux bases de Scala et à ses particularités.
Le choix de l’introduction par l’exemple et le code en direct rend la compréhension difficile pour le non connaisseur (la syntaxe ayant bien sûr ses particularités).

La deuxième présentation réalisée par deux chroniqueurs de Xebia est plus classique et permet de mieux se faire une idée de Scala.

Scala créé en 2002 par Martin Odersky est actuellement en version 2.7. C’est un compromis entre programmation orientée objet et programmation fonctionnelle.
Le langage se place au dessus de la JVM et est intéropérable avec Java.
Scala prone la non nullité, l’immutabilité et le tout objet (les types primitifs n’existent plus).
Il permet l’inférence de type, de spécialiser les fonctions, une simplification des listes, le support natif du XML…
L’idée est aussi de passer facilement de l’objet au fonctionnel.
Le gros avantage de Scala est de simplifier fortement certains besoins.
Le singleton devient natif avec « object ».
Le pattern matching (« case class ») permet de simplifier énormément le pattern visiteur.
Les traits (« with ») permettent d’ajouter facilement des comportements soit à une classe (interface en plus évolué) soit directement à une instance. En gros cela permet de remplacer facilement la programmation orientée aspect.
L’API actors permet d’offrir une gestion différente du threading et de la concurrence.
Elle se base sur les éléments suivant :

• un objet qui vit dans la JVM
• pile de messages type mailbox
• il recoit des messages et y répond
• soit 1 thread par actor
• soit un pool de threads
• remote actors (jvm distante)

Un actor n’utilise un thread que s’il fait un traitement.
Alors qu’en Java, on va gérer la concurrence en mettant des locks, avec un actor, il n’y a plus ce problème, il n’y a plus d’état partagé. On transmet des messages (souvent immutables) entre Actors.
AKKA est un framework Scala rajoutant de la performance et des fonctionnalités.
Pour information, il y a des framework offrant cette fonctionnalité en java (simplification des remotes actors, stratégies de redémérage ..) !

Eclipse et surtout IntelliJ permettent de travailler sur Scala.

Les présentateurs font alors leur conclusion suivante :
Les avantages de Scala sont forts :

• code plus concis
• tests plus métier
• gestion directe de certains pattern (visiteur, singletons)
• Gestion de la concurrence

Mais il y a bien sûr des problèmes :

• Maitrise du langage
• Peut devenir complexe
• Courbe d’apprentissage
• Probleme avec java
• Difficulté à introduire dans les entreprises sur les dev critiques (nouveaux concepts …)

Enfin quelques sociétés utilisant Scala :twitter (actors), ebay, EDF (http://www.scala-lang.org/node/3656), Siemens, Foursquare (lift)…

• 

Mercredi dernier avait lieu à la Cantine Paris, une conférence pour thème « The next open web platform » présenté par Daniel Glazman, Dominique Hazael-Massieux et Philippe le Hégaret.

Après une présentation du W3C, c’est un rapide retour sur les différentes “versions” du web : Web 1.0 avec html, url, http, pas d’opportunité d’interaction réelle avec le document puis Web 2.0 avec javascript, CSS, flash, bureau et mobile et maintenant Web 5.0 qui met en avant les parties données et interactions.

L’idée est d’abord d’améliorer HTML en intégrant pus naturellement les secondes générations de langage web (CSS, SVG, MathML….) mais il y a aussi de nombreux standards et nouveaux outils en préparation (WebSockets, CSS 3, WebGL, ECMAScript 5 …).

Le présentateur revient sur la fin de XHTML 2 et le fait qu’HTML 5 permettra la sérialisation aussi bien en html que xhtml.Il fait une présentation rapide de la très attendu nouvelle balise <video>.

Il présente quelques évolutions liés à CSS comme CSS Media queries qui permet d’adapter et choisir la feuille de style en fonction de la vue coté client (Bureau ou mobile par exemple), CSS Transition qui permet des transitions de style douces ou encore CSS Selector qui permet de sélectionner des éléments HTML directement sans être référencé dans le HTML (très utile pour les tables).
Il y a ensuite un état de SVG qui va enfin être supporté par Microsoft. Son intégration plus poussée permet par exemple avec l’utilisation d’HTML 5 d’intéragir avec une video (sous titre!).

La technique Gaussian blur permet l’affichage des formules mathématiques ou mettre des effets sur une image déjà présente.
Un nouveau présentateur décrit les futurs APIs permettant d’accéder au matériel (géolocalisation, caméra, calendrier, carnet d’adresses..). L’idée est vraiment d’améliorer l’expérience web et d’intégrer la réalité augmentée.

Un des projets est aussi de rendre les applications Web téléchargeables, signables, sellables, avec une interface utilisateur dédiée type widgets.

En conclusion, cette conférence présentée par des membres du W3C permet de se rendre compte de l’étendu des objectifs autour d’HTML 5 et de l’ampleur de la tache qui reste à effectuer. Il va falloir attendre la finalisation des APIs et leur implémentation dans les navigateurs. L’ensemble est à surveiller de près vu les possibilités et les simplifications que ces APIs apportent.
La présentation est disponible ici : www.w3.org/2010/Talks/0407-next-web-cantine

• 

Cet article est un résumé de la première soirée du Domain Driven Design Users’ Group Paris (lancé le 17 février dernier), avec une présentation de Greg Young sur le « Command and Query Responsability Segregation ».
Greg Young commence à nous présenter une architecture très classique dans les développements actuels.

L’ensemble de cette architecture se base sur une omniprésence de Data Transfert Objects sur l’ensemble des couches. Le comportement de l’application se retrouve dans le client. La montée en charge de l’application est très vite reportée sur la base de données. De plus on arrive très vite à parler avec des verbes techniques (Request DTO, Send DTO). Il n’y pas de modèle du domaine.

La première étape est de faire la transition entre les deux schémas ci-dessus. Le client ne doit plus travailler uniquement avec des DTOs.
Il doit communiquer au client avec le serveur à travers des commandes. Le service applicatif gère l’objet du domaine.
Cet objet encapsule son état et offre des comportements. On peut ainsi remettre en place les cas d’utilisation ou « user stories ».
L’étape suivante consiste à séparer l’écriture de la lecture car ces deux chemins représentent deux cas d’utilisation différents, avec leurs propres contraintes et besoins.

Dans le cas de la lecture, il est intéressant de remplacer l’accès à la base de données par un accès rapide et simple à la base de données (direct to DTO). Il reste maintenant le problème de la base de données. Avoir une seule base de données pour les deux cas d’utilisation est une solution simple dans le cas d’un système existant.
Cependant dans la majorité des applications (sauf peut-être certains systèmes financiers), il y a énormément plus de lecture que d’écriture. Il peut être alors très intéressant d’avoir deux bases de données avec un système de duplication maintenant la consistence des données entre les deux bases.

La base de données en écriture peut être normalisée et la base en lecture dénormalisée.
C’est une très bonne solution quand on pense au problème des rapports qui sont faits sur les bases.

•