Le but de ce petit tutorial est de créer un tunnel SSH et rediriger un port local non sécurisé vers celui-ci. Autrement dit, il vise à écrire en Java, et ce grâce au framework JSch, l'équivalent de la commande suivante :

ssh -i "/home/samir/.ssh/privateKey.key" -f -N username@10.10.10.10 -L 8181:localhost:80

C'est parti !

Nous allons voir ensemble comment intégrer le framework Dozer au sein d'une application utilisant Maven et Spring et réaliser nos premiers mappings de classe. C'est parti !

Plus besoin de présenter les modules existants du monde Hibernate : Search, Validator, Shards et Envers. Mais un nouveau est apparu dans l'une des conférences de Devoxx animée par Emmanuel Bernard : il s'agit d'Hibernate OGM.

Dans les couloirs de Devoxx, tout le monde parle NoSQL et BigData : plusieurs conférences étaient proposées sur ce sujet notamment avec des démonstrations de Cassandra et MongoDB. Actuellement, la volumétrie des données et la complexité de certains modèles métiers nécessitent de revoir la façon dont sont organisées et stockées les données. La performance et la disponibilité des données sont au cœur des problématiques de beaucoup d'applications.

Mais Hibernate ne compte pas faire objet de figuration dans le monde NoSQL et propose de faire du NoSQL en conservant son API de persistence JPA et en proposant une décorrélation des objets et de la structure de données. Les entités ne seront plus stockées dans une base de données relationnelle mais sous forme d'entrées clé/valeur (à l'image d'une Map).

Hibernate OGM (Object Grid Mapper) a pour objectif de conserver la gestion actuelle de la persistance des entités (objets métiers) mais en proposant un stockage basé sur les dataGrids reconnus pour leur gestion simplifiée de la scalabilité.

En d'autres termes, le projet OGM nous permet de persister nos entités métier existantes dans une base de données non relationnelle sans être obligé de revoir la conception du modèle métier. OGM assure aussi la continuité du langage de requêtes JP-QL, même si pour le moment certaines requêtes complexes restent encore non réalisables.

La démonstration montre que le passage au NoSQL sur une application existante se fait relativement rapidement : quelques modifications dans le fichier de configuration "persistence.xml" (ajout d'un provider HibernateOgnProvider) et ajouts d'annotations d'indexation.

Immédiatement, on constate que nos objets sont bien stockés sous forme de clé/valeur. La clé est constituée du nom de la table et de l'identifiant de l'objet. Et pour gérer les associations / relations entre les objets, OGM stocke un cache d'association avec une clé par navigation.

Emmanuel Bernard nous révèle alors, en détail, les outils et frameworks utilisés par OGM :

• Hibernate Core avec JPA/EntityManager pour la persistance des entités,
• Hibernate Search pour l'indexation des objets et composants de requêtes,
• Teiid pour permettre les jointures complexes et les agrégations de données,
• Infinispan pour le stockage distribué des données clé/valeur et des indexes Lucene.
  

Le principal inconvénient des outils actuels NoSQL est l'incapacité de gérer et de garantir le mode ACID (Atomicité, Cohérence, Isolisation et Durabilité) que toute transaction en base de données devrait avoir. Le recours à Infinispan dans OGM permet d'assurer cette gestion de transaction.

Le principe actuel d'OGM est donc d'utiliser et de combiner des projets matures ayant déjà faits leurs preuves dans des domaines différents.
L'objectif est de fournir:

Une structure relationnelle

avec un stockage en mode NoSQL clé/valeur

et toujours avec une API de requêtage (JP-QL)

Il existe à ce jour qu'une version alpha d'Hibernate OGM mais je pense que c'est un projet qui mérite d'être suivi car l'approche proposée pour combiner le modèle relationnel et le NoSQL me semble intéressante et relativement peu coûteuse à mettre en place.

Dans la panoplie des conférences Devoxx 2011, les équipes de SpringSource ont présenté les nouveautés et améliorations de la future version 3.1, et nous donnent même en avant-première les perspectives à venir !

Parmi les grandes nouveautés de Spring 3.1 présentées lors de la conférence Devoxx, j'en retiens deux. La première concerne les outils d'abstraction d'environnement à travers la définition de profils, et la seconde la possibilité de mettre en place simplement un système de cache.
L'exemple pris lors de la démonstration concerne la problématique récurrente de définition de la base de données. Dans le cas du profil de développement, c'est une base embarquée en mémoire qui sera utilisée alors que pour le profil de production, ce sera une base Oracle.
Pour mettre en place cette abstraction d'environnement, Spring propose de définir des profils. Pour définir un profil, rien de plus simple : il suffit de lui attribuer un nom.

• Configuration par fichier XML avec l'attribut profile
  

<beans profile="production">

         <bean id="dataSource" class="...">

     </beans>

     <beans profile="dev,integ">

        <bean id="dataSource" class="...">

     </beans>

• Configuration par annotation @Profile("production")
  

En fonction du profil activé au chargement de l'application, c'est seulement les éléments de configuration propres à ce profil qui seront utilisés : les autres seront purement et simplement ignorés. Il est même possible d'associer et de combiner les profils afin d'en avoir plusieurs actifs en même temps (à partir du moment où ils ne rentrent pas en conflit).

L'activation de profil(s) peut se faire de trois façons différentes :

• En renseignant un paramètre d'initialisation dans le fichier "web.xml"
  

<param-name>spring.profiles.active</param-name>

<param-value>production</param-value>

• En valorisant par programmation la propriété activeProfiles sur l'environnement du contexte
  

context.getEnvironment().setActivesProfile("production");

En passant l'information directement en ligne de commande en valorisant l'argument -Dspring.profiles.active

La gestion de l'abstraction d'environnement proposée par Spring permet donc de réduire le nombre de fichiers de configuration et/ou propriétés (plus besoin d'avoir autant de fichiers que de profils). Cela permet aussi de supprimer la substitution dynamique des variables de configuration (qu'il était possible d'effectuer en filtrant les ressources avec Maven).

Concernant la politique de définition de cache, là aussi, ce que propose Spring me semble intéressant. Il s'agit en fait d'un système générique de définition de cache complètement transparent. Le développeur indique quels éléments ou quels objets il souhaite mettre en cache. Le système de cache de Spring est complètement pluggable : vous pouvez brancher derrière votre gestionnaire de cache préféré : ehcache, concurrentMap... Là aussi, des annotations intuitives : @Cacheable, @CacheEvict, @CachePut. La mise en cache ou le retrait peut également intégrer des conditions qu'il est possible de mettre directement en argument de l'annotation via une expression SpringEL du type (#montant > 2000).

La définition d'un système de cache applicatif est généralement considérée comme relativement complexe à mettre en œuvre par les développeurs. C'est une des raisons pour laquelle sa mise en place intervient généralement assez tardivement dans le développement d'une application. C'est lorsque des soucis de performance commencent à apparaître que l'équipe de développement se penche sur la question de l'ajout d'un gestionnaire de cache. Avec la prochaine version de Spring, plus d'excuses. Les annotations de cache peuvent être déjà réfléchies et posées sur les classes de l'application même si la définition concrète du gestionnaire de cache n'est pas encore faite.

Avec la version actuelle de Spring, la configuration par annotations avait déjà une place importante. Avec la version 3.1, la dynamique continue et s'intensifie encore ! A la question "Qui utilise encore les fichiers XML pour configurer son contexte applicatif, très peu de mains se sont levées dans la salle !". Il semble donc que les annotations aient un très bel avenir.

Au delà des nouvelles fonctionnalités de la version 3.1, la politique de Spring pour le futur est clairement de s'ouvrir toujours plus et de faciliter l'interaction avec les outils et autres frameworks en vogue (JSF 2.x, Bean Validation, JPA, Java EE7, JCache...). Mais patience, ce sera pour les prochaines versions...

Quant à la roadmap proche, Spring 3.1 sera proposé en Release Candidate 2 (RC2) la semaine prochaine. Plus que quelques jours à attendre !

Vous est-il déjà arrivé d'avoir des problèmes d'encodage sur des fichiers de properties Java alors que vous étiez persuadé d'avoir modifié les préférences d'Eclipse sur tout le Workspace ?

Si cela est le cas, ce post devrait vous intéresser.

Mercredi soir au JUG nantais, nous avons pu assister à la présentation "Stateful is beautiful" d'Antoine Sabot-Durand.

Expert en Java EE depuis plusieurs années, Antoine nous a donné sa vision sur le paysage Java actuel, en particulier sur Java EE (Enterprise Edition) et l'alternative Spring.

L'objectif du billet est d'expliquer par des exemples concrets la notion de « Filter » (ou Web Filter, en français Filtre).
Pour vraiment comprendre la notion de « Servlet Filter » il faudrait les voir en action sur des exemples réels.
C'est justement ce que nous présentons ci-dessous.
La première partie de ce billet monte une démo simple mais très utile car elle détaille la création d'une « Servlet Filter » qui transforme la requête HTTP POST en simulant le cryptage du mot de passe.

Aucun pré-requis n'est exigé pour cette partie.

Dans la seconde partie, la démo s'intéresse à l'intégration du « Filter » à une application Web existante basée sur spring-security 2.x. Plus précisément, la « Servlet Filter » agit sur les « Filtres » de spring-security.
Cette seconde partie, d'un niveau très avancé, est réservée à ceux connaissant parfaitement spring et spring-security.
Ce qui est commun entre les deux parties est que nous partons d'une application Web existante et nous ajoutons les transformations utiles avec le filtre sans modifier le code java/jsp. Seul le fichier descripteur « web.xml » sera mis à jour.
NOTE. Les dépendances nécessaires seront indiquées.

Pour certaines applications sensibles, on préfère utiliser un système d’authentification forte par certificats, plutôt que des couples login/mot de passe. C’est de plus en plus le cas avec certaines applications Web ou encore des WebServices devenant des points d’entrées critiques dans le SI des clients.

Le principe de l’authentification forte est un principe de vérification mutuelle, le client à la connexion va vérifier le certificat présenté par le serveur (notamment l’autorité de certification qui signe les certificats) et inversement le serveur va vérifier que le certificat du client est valide et autorisé.

Réunir le duo "Scala" et "Spring" dans une démo est une belle entreprise.
Combiner le meilleur des deux rapidement est une expérience excitante!:)
A Netapsys, Spring est bien présent dans tous les projets J2EE.
Scala aura-t-il le même sort? Ce qui est sûr, Scala a tous les atouts pour.

Sur le net, bien que ce sujet est peu abordé mais vous trouvez ici un article intéressant sur ce thème.
Ce billet vous présente une démo qui montre comment, en 20 minutes, réaliser cette expérience (magique :)).

La démo reprend l'exemple d'envoi de mail (voir ici) que je recommande sa lecture :).

Passons aux choses pratiques...

Lors de l'introduction de la gestion de la sécurité en Java, les solutions se déclinaient sous forme d'extensions aux noms plus ou moins sympathique comme JAAS, JSSE et JCE, qu'il fallait venir rajouter dans ses applications. Et encore, suivant les régions, toutes n'étaient malheureusement pas disponibles.

Heureusement ce n'est plus que de l'histoire ancienne car désormais, Java propose en standard tous les outils qu'il vous faut pour sécuriser facilement vos données. Intéressons nous en particulier à deux aspects : La génération d'empreinte de fichier et le chiffrement de ces derniers.