Veille technologique semaine 27

Bonjours à tous,

pour le bulletin de cette semaine, je vous propose les sujets suivants :

• un résumé sur la présentation de JEE 6 par Adam Bien au club Java de PARIS
• JEE 6 et les événements : natif pour les EJB 3.1
• un groupe de travail qui démarre une spécification sur les notifications pour le Web
• la réutilisation : un rêve ? L'article mentionne qu'un excès de configuration complexifie l'utilisation "Maximize reuse minimizes use" : attention aux usines à gaz !
• Quelques définitions de vocabulaire UML.
• Les slides sur une présentation au sujet des annotations Java.
• La surcharge et la redéfinition : deux concepts à ne pas mélanger (respectivement override et overload en anglais).

Bonne lecture.

Java EE 6 par Adam Bien

Lightweight killer apps with nothing but vanilla Java EE 6, par Adam Bien (http://adam-bien.com)
Adam est membre du JCP, et a écrit le livre Real World Java EE Patterns.

• Lightweight ?
• rapide
• simple
• small
• lean
• short turnaround cycles : déployer le plus rapidement possible pour être productif
• easy : convention over configuration

Spring vs JEE : Java EE repose davantage sur les conventions, mais Spring donne davantage accès à toutes les options de configuration. A part ça, leurs fonctionnalités sont grosso modo les mêmes aujourd'hui, c'est une affaire de goûts.
Et les autres langages ? Ruby, Groovy... ? Ce sont des technologies intéressantes, mais du point de vue de l'entreprise, pas encore matures ou reconnues. De plus, il est difficile de trouver des développeurs expérimentés.

Architectures modernes

ECB
En Java EE 6, il y a 3 couches : Boundary (interaction avec des systèmes externes : utilisateur ou webservices), Control, Entity.
Pour des applications CRUD, Boundary+Entity sont suffisants, car la plupart du temps la couche service n'est qu'un delegate vers la couche Entity.
On voit ici que le modèle ECB (Entity-Control-Boundary) est indépendant de l'implémentation de Java EE.

DDD
Le Domain Driven Design tente de mettre les use-cases métiers au centre du développement. C'est un peu l'inverse de ECB, orienté technique.
Le DDD pousse à avoir un domaine riche, bien encapsulé ; il n'y a donc pas réellement besoin de couche service dans ce cas.
Adam pointe vers le site http://www.antiifcampaign.com/ qui pousse à remplacer les IF par des classes bien encapsulées et l'utilisation des design patterns (Strategy...).
Le DDD est principalement stateful : le graphe d'objet en mémoire contient l'état du système. Il est alors assez difficile de sauvegarder ce graphe en base de données par exemple. Si plusieurs clients (au sens client du système, pas utilisateur) modifient le graphe de manière simultanée, il est difficile de merger leurs modifications.
Par contre, il est possible de tester le système de manière autonome, sans même avoir de base de données, puisque le système est auto-contenu.
Cette approche est "lean" car moins de couches techniques sont mises en oeuvre : les données et leur traitement sont co-localisés. De plus, elle s'interface bien avec les architectures REST : il suffit d'exposer les objets comme des Ressources.

JSF 2
Avec JSF 2, on peut accéder directement à des Managed Beans ou à des EJB, grâce à un Expression Language. La couche de configuration et d'intégration est donc très légère, voire inexistante.
Adam montre le code d'un EJB, et explique qu'il met la visibilité de ses services injectés (ex: EntityManagers) à "packaged", de manière à simplifier les tests unitaites (injection manuelle). Nicolas Martignole intervient en déclarant qu'il utilise plutôt la visibilité publique partout où il peut, et prend en exemple le framework Play. De nombreux développeurs ne sont pas d'accord et rappellent l'utilité des différents niveaux de visibilité et leur impact sur la sécurité et la robustesse du système.

Service-driven architectures
Ces architectures mettent l'accent sur une couche de service indépendante de ses "clients" : interface utilisateur, webservices... Chaque couche est isolée et possède ses propres modèles et traitements.
Elles sont la base des architectures SOA.

SOA vs DDD : les frères ennemis
Les deux sont des bonnes pratiques... chacun dans un contexte particulier.

Au final, le discours d'Adam Bien est assez anti-conformiste : supprimez les interfaces, les DAO, réduisez le nombre de couches !
Assez surprenant dans le context actuel, où les blueprints Spring et Sun sont martelés dans les écoles et les entreprises.

Qu'y a-t-il dans Java EE 6 ?

EJB 3.1
Les EJB 3.1 sont très simples :

@Stateless
public class SimpleSample {
   public void doSomething() {}
}

Notez qu'il n'y a plus besoin de définir l'interface métier comme dans les EJB 2 ! Il est toujours possible de le faire, mais c'est optionnel.
Mais alors, comment tester ? En fait, il n'y a absolument pas besoin d'interfaces pour tester unitairement : Mockito le fait très bien par exemple. En particulier, les Interceptors fonctionnent directement sur les classes, contrairement aux proxies dynamiques qui demandent la présence d'interfaces.

De même, a-t-on vraiment besoin des DAOs ?
Très généralement, la base de données survit largement aux applications qui y accèdent, il est donc contre-productif (voire stupide) de fournir une couche d'adaptation "au cas où".

JNDI enfin standardisé
... pour des noms enfin portables !

EJB 3.1 + REST
Grâce à l'annotation @Path, on peut exposer un EJB 3.1 en tant que service REST. Pas de XML, pas de configuration de container.

Timers
L'annotation @Schedule permet de définir des expressions type "cron" pour scheduler des traitements.

Singletons
L'annotation @Singleton permet, avec @PostConstruct, de créer des singletons simplement et de manière sûre.

Tâches asynchrones
Les méthodes annotées @Asynchronous sont exécutées dans des transactions en arrière-plan. Elles renvoient des objets de type Future<?>.
L'usage raisonné des méthodes asynchrones peut vraiment faire la différence en termes de performances ! Adam raconte qu'une entreprise était prête à laisser tomber Java pour du C car leurs performances étaient mauvaises. Le fait de configurer certaines méthodes en @Asynchronous a permis de multiplier les performances et ainsi sauver l'application Java.
Les méthodes asynchrones sont exécutées par un pool de threads géré par le container.

Instrumentation
Les EJB exposent automatiquement des 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
CDI est l'héritier des anciennes JSR 299 et 330.
CDI s'inspire de ce qui a été introduit par Spring, mais pousse les possibilités plus loin. En particulier, CDI est type-safe.

Adam a principalement réalisé des démos en "live".
Il a ainsi passé en revue à peu près toutes les fonctionnalités principales de Java EE 6, des EJB aux vues JSF, en passant par les méthodes asynchrones, les intercepteurs, et l'injection avec @Inject (y compris pour injecter un simple POJO qui n'en demandait pas tant !).

Au final, ça donne quand même envie d'y rejeter un oeil, sérieusement.
On est loin des temps préhistoriques du XML à foison, des interfaces atroces (throws RemoteException, ça rappelle des souvenirs à quelqu'un ?), et des fonctionnalités limitées. Comme promis, Java EE 6, et notamment les EJB 3.1, fournit un modèle puissant et léger pour le développement d'applications robustes.

De mon point de vue, le principal défaut de la plateforme est la partie vue. Sérieusement, JSF, même 2.0, c'est... juste horrible. Et son concepteur l'a même avoué : il recommande maintenant de se tourner vers Wicket, pour les projets n'ayant pas un fort impératif d'utilisation des standards.

Le prochain Paris JUG se tiendra en septembre : repos pendant le mois d'août !


Decoupling event producers and event consumers in Java EE 6 using CDI and JMS
In this post I will share my recent findings about Container Dependency Injection in Java EE 6, in particular how to decouple the processing threads of event producers and event consumers.

Java EE 6 introduces a very nice dependency injection framework (CDI) that has superb support for the Observer pattern in the form of event broadcasting.


Web Notification Working Group Charter
The mission of the Web Notification Working Group, part of the Rich Web Client Activity, is to produce specifications that define APIs to generate notifications to alert users. A Notification in this context may be displayed asynchronously and may not require user confirmation. Additionally, events are specified for managing user interactions with notifications.


Reuse: Is the Dream Dead?
In general, the more reusable we choose to make a software component, the more difficult that same software component is to use. In the extreme, an infinitely reusable component is infinitely difficult to use. Dealing with the tension between reuse and use is a complex issue, and often, we fail. Largely, the problem has to do with dependencies.

This statement is a derivation of Clemens Szyperski's statement in Component Software: Beyond Object-Oriented Programming -
"Maximize reuse minimizes use."


Association, Aggregation, Composition, Abstraction, Generalization, Realization, Dependency
These terms signify the relationships between classes. These are the building blocks of object oriented programming and very basic stuff. But still for some, these terms look like Latin and Greek. Just wanted to refresh these terms and explain in simpler
terms.


Conférence : Les annotations enfin expliquées simplement
Mardi dernier, j'ai animé chez Zenika une conférence sur les Annotations.
Et le sujet est plus complexe qu'il n'y paraît. Outre les subtilités de leur syntaxe, les annotations disposent d'un outillage puissant à la compilation et au runtime, dont la maîtrise ouvre de nouvelles perspectives en termes de méta-programmation.
En particulier, j'ai démontré l'utilisation des Annotation Processors, qui permettent d'interagir avec le compilateur Javac, et de la Réflexion pour lire et injecter des annotations dynamiquement au runtime.


Overloading And Overriding
Conceptually overloading and overriding is way different. Only the notion about interface name is same in both cases. Other than that, you cannot find a common thing between them.
Overloading is using the same interface but with different inputs and getting different behaviour as output. Slightly confusing right. I hope by end of this article you may feel better.