Devoxx – Spring, le futur Spring 3.1 et Spring Social

Plusieurs conférences sur Spring et son écosystème ont logiquement eu lieu à Devoxx cette année. C’était hier « Productivity Enhancements in Spring 3.1 » et aujourd’hui « Spring Social« . Voyons de quoi elles parlaient.

Productivity Enhancements in Spring 3.1

Costin Leau a commencé par remettre Spring dans le contexte actuel: l’évolution de Java EE tend vers une adoption rapide de EE6, Tomcat 7 apporte le support des Servlet 3 (de JEE 6) et le Cloud propose des solutions très diverses, de GAE basé sur Jetty à Amazon Elastic Cloud en passant par VMWare CloudFoundry proposant Tomcat. Bref les solutions sont multiples et Spring entend s’imposer en tant qu’élément commun permettant les bonnes pratiques facilitant le passage d’un environnement à l’autre.

Costin est ensuite entré dans le vif du sujet en détaillant les nouveautés qu’apportera Spring 3.1. Mais une précision s’imposait d’abord. Spring est souvent critiqué pour la verbosité de ses appplicationContext.xml, mais Costin a tenu à rappeler que depuis plusieurs années on peut configurer entièrement le conteneur en Java. Et c’est même disponible en Spring 2.0, grâce à un add-on ! Les critiques envers le xml ne sont donc pas fondées: comme toujours, Spring offre le choix.

Les nouveautés de Spring 3.1 sont les suivantes:

Nos applications doivent pouvoir être déployées dans différents environnements (serveur local, Cloud) ainsi que différents contextes. 2 fonctionnalités aident à cela:

• Afin de disposer des MEMES artefacts à déployers dans les différents environnements, il faut être capable de savoir dans quel environnement se trouve l’application pour qu’elle puisse adapter son comportement. On ne veut pas avoir à contruire des war/jar/ear/etc spécifiques à un environnement donné ! Une abstraction des propriétés a donc été effectuée (plus de détails ici) et elles peuvent donc être accédées de façon quasi-transparente tout en étant stockées dans:
  • JNDI
  • des propriétés systèmes
  • des fichiers .properties.
• Des profiles de beans permettant d’activer ou non certains beans seulement dans certains contextes. Par exemple en dev, vous n’utiliserez que qu’un mock d’authentification alors qu’en production le vrai service sera appelé. Couplé avec la configuration Java-based, on se contentera d’annoter un bean @Profile(« dev ») par exemple.
• Le c-namespace permet de simplifier légerement ses ApplicationContexts. Ainsi un bean pourra s’écrire

  <bean id="foo" class="x.y.Foo" c:bar-ref="bar" c:baz-ref="baz" c:email="foo@bar.com">
  
  <!-- au lieu de: -->
  <bean id="foo" class="x.y.Foo">
    <constructor-arg ref="bar"/>
    <constructor-arg ref="baz"/>
    <constructor-arg value="foo@bar.com"/>
  </bean>
  

• L’utilisation d’un cache se fera de manière aisée, de façon déclarative. Cette fonctionnalité est basée sur les paramètres d’entrée de la méthode et le principe est « même entrée, même sortie ». Les annotations @Cacheable et @CacheEvict parlent d’elle-même. Pour cacher les données, EHCache est prévu (ainsi qu’une ConcurrentMap pour le dev) mais on pourra aussi se brancher aisément sur GemFire ou Redis.

  // ici on utilise seulement la valeur brute de l'ISBN comme clef
  @Cacheable(value="book", key="#isbn.rawNumber")
  public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)
  
  // Suppression des entrées du cache avant de le recharger
  @CacheEvict(value = "books", allEntries=true)
  public void loadBooks(InputStream batch)
  

• Les servlet en version 3.0 seront de la partie avec un support de l’upload asynchrone grâce au nouveau MulitpartResolver.
• Spring sera à jour pour supporter de nouvelles versions de librairies:
  • Hibernate 4, pas encore sorti, déjà supporté.
  • Quartz 2.0 et 2.1. Mais leurs API n’étant pas compatible avec les précédentes versions, il faudra sans doute écrire du code spécifique. La compatibilité Quartz 1.5+ est de toutes façons conservée.
  • JDBC 4.1 apporté par Java 7
  • le framework fork-join lui aussi dans Java 7

Et la question qui vous brûle les lèvres est de savoir quand vous pourrez enfin mettre la main sur toutes ces bonnes choses: la RC1 est déjà disponible, la RC2 devrait débarquer la semaine prochaine et la version finale, Spring 3.1 GA « soon after ». Courage, ça ne va pas tarder !

Pour une description exhaustive des nouveautés de Spring 3.1, rien de mieux que la doc officielle.

Spring Social

Josh Long nous a quant à lui présenté Spring Social, une librairie qui fournit des abstractions pour faciliter les interactions avec les réseaux sociaux.

Comme nous le savons tous, les réseaux sociaux de nos jours sont fondamentaux: nombre de marques comptent sur eux pour leur marketing, pour assurer un support et suivi des utilisateurs, pour obtenir du trafic qualifié sur leur site… Même si vous n’êtes pas vous-même sur ces réseaux, tôt ou tard, vous travaillerez sur des projets où vous devrez interagir avec eux.

Tous ces réseau offrent des API HTTP/REST, ce qui est bien. Ce qui est mal par contre, c’est qu’ils disposent tous de formats et particularités qui nécessitent d’écrire du code spécifique à chacun.

Se connecter

Avant d’interagir avec les réseaux sociaux, il faut commencer par s’y connecter. Là intervient la notion de service provider.

Paramétrer la Connection

Mais encore faut il que votre webapp soit autorisée à manipuler le compte de votre utilisateur sur le réseau social. Pour cela, il faut que celui-ci l’y autorise. Et comme la suite des étapes, notamment pour l’authentification OAuth n’est pas triviale, Spring Social fournit le nécessaire pour faciliter et rendre générique ces étapes dans Spring MVC: c’est le ConnectController.

Interragir

Et pour utiliser toute la puissance de chaque réseau social, un module client spécifique est implémenté pour chacun et vous permettra d’accéder à vos listes d’amis (Facebook), de twitter (Twitter) ou d’autoriser un énième chasseur de tête à vous parler du poste extraordinaire qu’il a pour vous ou vos collègues (LinkedIn).

L’avantage d’un tel système est que si Facebook, par exemple, décide du moindre changement  de comportement de son API, le module client spécifique fournit par Spring sera rapidement mis à jour de façon à ce que vous puissiez continuer de façon transparente à y accéder.

Bien sûr un tel système d’abstraction a un certain coût et si vous souhaitez seulement interagir avec Twitter par exemple, vous feriez peut être mieux de passer directement par une librairie spécifique comme Twitter4J. Mais si vos besoin évoluent et que vous pouvez être amené à ajouter Facebook ou TripIt, la petite plomberie requise par Spring Social sera bien négligeable face au gain apporté par l’API unifiée.

Pour terminer, Josh a parlé de l’intégration de Spring Social avec Spring Intégration. Ce dernier apporte tout particulièrement le principe d’Hollywood (« don’t call us we’ll call you ») permettant de définir des callback qui seront appelés lorsque certains critères (plus de x mails reçus, arrivé d’un tweet, etc…) seront vérifiés. L’intégration se fait aisément avec des flux comme Twitter, RSS/Atom, l’envoi et la réception de mails POP3, SMTP, IMAP…

Bref, en plus du stand CloudFoundry, Spring était bien présent cette année sur le salon au travers de plusieurs conférence. Le framework continue à évoluer et à abstraire les accès à d’autres APIs. On regrettera juste ne pas avoir eu la moindre présentation sur Grails à se mettre sous la dent, d’autant que la version 2.0 ne saurait tarder.