Les projets évoluent durant les développements, l’architecture aussi…
Rappel des faits
Lorsque notre projet a débuté, nous avons utilisé une architecture standard : portail Liferay, portlet applicative contenant les jar dont elle a besoin (y compris les jar d’accès à la couche métier), le tout se basant sur le couple magique Spring / Hibernate.
Mais voilà, au fur et à mesure de l’avancement du projet, nous nous sommes rendu compte que :
- Cette architecture comportait quelques failles (notamment la gestion du cache, de la taille des portlets et de l’impact d’une modification d’un jar métier sur le re-déploiement de toutes les portlets).
- De nouveaux besoins sont apparus comme l’ouverture de notre système à une application externe (Intalio en l’occurence), le seul moyen de communication étant les web services.
Le constat était clair : il faut migrer vers une architecture en web services avec des portlets ne comprenant que les jar de présentation, les composants métiers étant regroupés au sein d’une web app, la communication entre ces deux couches étant réalisée par l’intermédiaire de web services.
Le choix du "code first"
Nombreux sont les articles sur la toile présentant l’approche "contract first" comme la bonne pratique à utiliser pour la mise en oeuvre des web services. Spring offre d’ailleurs un outillage très intéressant dans ce domaine Spring Web Services – Reference Documentation.
. . . → Lire la suite: Web service code first avec jax-ws
