Revue de Presse Xebia

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Actualité éditeurs / SSII

• Valider vos méthodes avec Hibernate Validator 4.2.0
• Distribuer vos logs avec Kafka 0.6
• Une implémentation NIO du connecteur AJP de Tomcat

Evénements de notre communauté en France et à l’étranger

• Un déplacement plein d’enseignements

Actualité éditeurs / SSII

Valider vos méthodes avec Hibernate Validator 4.2.0

Pour rappel, comme nous l’avions déjà évoqué ici, Hibernate Validator permet de faire de la validation de bean suivant la JSR-303 – Bean Validation. Cette JSR propose de standardiser les mécanismes de validation qu’un développeur est souvent amené à faire à la main en utilisant entre autre des annotations ou alternativement des fichiers xml. Cette normalisation a l’avantage d’uniformiser au sein d’une même application les couches de présentation (des frameworks de présentation comme Wicket par exemple propose leur solution), les couches de service ou de persistence avec les mêmes outils.

A titre d’exemple:

public Person {
	@NotNull
	private String name;

	@Past
	private Date birthday;
}

où @Past contraint que la date soit dans le passé.

Hibernate Validator est la version d’implémentation de cette JSR et contrairement à ce qu’on pourrait croire n’impose pas d’utiliser Hibernate. D’ailleurs JBoss/Hibernate propose un TCK pour les développeurs désireux de valider leur validateur.

La grande nouveauté de cette version est la possibilité de faire de la validation au niveau de la méthode:

public @NotNull String saveItem(@Valid @NotNull Item item, @Max(23) BigDecimal price)

Comme on peut remarquer, il est à présent possible de valider les paramètres ainsi que la valeur de retour d’une méthode. Pour valider cette méthode il faut ensuite créer un validateur:

MethodValidator validator = Validation.byProvider( HibernateValidator.class )
    .configure()
    .buildValidatorFactory()
    .getValidator()
    .unwrap( MethodValidator.class );

Et ensuite utiliser une des méthodes du validateur:

public interface MethodValidator {
    public <T> Set<MethodConstraintViolation<T>> validateParameter(T object, Method method, Object parameterValue, int parameterIndex, Class<?>... groups);
    public <T> Set<MethodConstraintViolation<T>> validateParameters(T object, Method method, Object[] parameterValues, Class<?>... groups);
    public <T> Set<MethodConstraintViolation<T>> validateReturnValue(T object, Method method, Object returnValue, Class<?>... groups);
}

On peut trouver le mécanisme un peu rébarbatif si on doit répéter l’opération sur chaque méthode et pour chaque paramètre mais, comme le suggère ce post, on peut facilement l’associer à un aspect pour automatiser ces validations.

Parmi les autres nouveautés on peut également à présent combiner les contraintes autrement que par conjonction et un nouveau mécanisme de templating des exceptions a été ajouté. Les détails de la release se trouvent ici, ici et là

Distribuer vos logs avec Kafka 0.6

Comme nous vous l’avions annoncé il y a un peu plus de 6 mois dans la revue de presse, LinkedIn a rendu open source son broker de messages atypique Kafka. A l’occasion de la sortie de la version 0.6 Neha Narkhede, ingénieur chez LinkedIn, nous rappelle les cas d’utilisation principaux de Kafka:

• Collecter des logs pour les insérer dans Hadoop ou dans un data warehouse pour une analyse offline.
• Nourrir directement des applications en écoute d’alertes en temps réel (pour la sécurité par exemple).
• Déployer les données recueillies d’Hadoop vers des applications.

Ces cas d’utilisation ont grandement guidé l’architecture de Kafka qui accentue beaucoup plus la rapidité à envoyer les messages, la garantie de persistence et le clustering au détriment d’une plus grande responsabilisation des consommateurs de messages qui ont en charge l’acknowledgement et la découverte de la topologie des brokers.

Parmi les nouveautés de cette nouvelle version on notera:

• Ajout d’un load balancing automatique pour les producteurs de messages. En masquant la topologie du cluster, Kafka peut s’appuyer sur un load balancer hardware et utilise zookeeper pour la partie logique.
• Possibilité d’envoyer de façon asynchrone les messages.
• Possibilité d’enrichir sémantiquement les partitions afin par exemple de rapprocher les données liées au niveau du métier

Un très bon article des ingénieurs de LinkedIn décrit très bien l’architecture de Kafka dans le cas de la génération de logs et qui contient des comparatifs, à prendre avec beaucoup de précaution, avec ActiveMQ et RabbitMQ. Je vous laisse deviner le grand vainqueur.

Une implémentation NIO du connecteur AJP de Tomcat

Cela aurait pu passer inaperçu car cette fonctionnalité a été ajoutée dans la version mineure de Tomcat 7.0.16, le connecteur AJP implémente à présent l’API New I/O pour gérer ses pools de threads. Un article très pédagogique de Mark Thomas, ingénieur chez SpringSource, met en lumière cette nouvelle fonctionnalité.

Jusqu’à maintenant à un thread sur un serveur Apache HTTPD, par exemple, devait correspondre un thread du côté des serveurs Tomcat. Donc pour 1000 threads sur deux serveurs HTTPD devaient correspondre 2000 threads sur chaque serveur Tomcat branché derrière. On comprend vite la complexité et les limitations engendrées.

Cette nouvelle implémentation permet de gérer plus intelligement ces threads côté Tomcat, à l’aide de quelques threads (l’article recommande pas plus de 10) on peut maintenir un ensemble de connections sans problème.

Un grand pas pour les utilisateurs de ce connecteur, sans oublier qu’il existe également le mod_proxy_http, la comparaison entre les deux étant détaillés dans notre article ici.

Evénements de notre communauté en France et à l’étranger

Un déplacement plein d’enseignements

Cette RDP est l’occasion de faire un petit bilan sur le court déplacement, début juin, de 3 de nos Xebians Parisiens chez nos collègues Néerlandais. L’objectif de ce voyage était triple:

• Favoriser les échanges d’expériences sur la transition vers l’agilité
• Passer en revue le modèle de pépinière interne
• Renforcer les liens entre entités

Jean-Laurent et Gilles ont apporté leur contribution au XKE Néerlandais en présentant chacun un sujet aux membres de la business unit Agile Consulting and Training (ACT), l’un sur l’évolution d’une équipe agile dans la durée, l’autre sur la transformation agile à grande échelle. Pendant ce temps Aurélien a longuement discuté des projets pépinières chez Xebia NL et du modèle de contribution associé. La journée s’est terminée par une présentation de l’ensemble des missions en cours au sein de ACT portant sur la transition des organisations vers l’agilité. Les références de nos voisins sont impressionnantes et nous repartons avec des nouveautés plein la tête.

Si nous ne devions retenir qu’une chose de ce voyage ce serait sans aucun doute la découverte du livre Business Model Generation qui présente un canevas simple et puissant pour discuter et formaliser un business model. Un outil qui nous paraît indispensable pour le Product Owner et son travail de priorisation et valorisation de ses stories.

Nous avons également découvert des obstacles à l’agilité que nous connaissons peu en France, certaines entreprises pratiquent par exemple la politique de bureau libre, ce qui empêche fortement la colocalisation. Nous repartons plus riches de nos différences culturelles quant à la mise en application de SCRUM et des pratiques agiles. Pour un voyage dans la patrie de Gert Hofstede, le fondateur de la théorie des dimensions culturelles, ce n’est peut être pas si étonnant.