Commençons la série des HJGMPB (How JEE 6 Gave My Productivity Back) avec la présentation de la gestion et définition de profils standards de déploiement introduite par EE 6.
L'une des critiques récurrente à l'encontre de la plate forme EE est sa lourdeur et sa fâcheuse tendance à accumuler les APIs peu maintenues, utilisées et élégantes par souci de rétro-compatibilité et de complétude.
Cela implique l'obligation pour les fournisseurs de serveurs d'application de proposer une implémentation pour chacune de celles-ci, qui seront ensuite déployées sur toutes les instances. Qu'elles soient utilisées ou non.
La spécification de la gestion des profils apporte la possibilité de configurer des types de déploiement standards ciblant des besoins précis. Ils définissent notamment les systèmes et APIs déployés et mis au service des applications. Ainsi, un bus d'entreprise ne nécessite certainement pas les technologies de vue comme les servlets ou JSF.
Le premier de ces profils à voir le jour est le "Web Profile" destiné à l'hébergement d'applications Web légères. Il se passe donc des APIs "entreprise" superflues telles que EJB2, JDO ou encore JMS.
Ne restent principalement que JPA, EJB3, JSF2, CDI et Beans Validation, tous utiles dans le cadre du développement web.
Cela permet à des serveurs d'application légers, comme Tomcat ou Caucho de se déclarer compatibles avec ce profil, bien que n'implémentant pas l'ensemble des spécifications EE6.
De ce fait, une application ciblant ce profil est d'autant plus portable et résistante aux changements futurs.
En outre, le temps de lancement et l'occupation en ressources du serveur d'application s'en trouvent réduits. Un avantage non-négligeable dans sa gestion des coûts et de la disponibilité.
Les développeurs ne sont pas en reste, le (re)lancement du serveur d'application étant récurrent dans le cadre de l'implémentation d'une application Web en Java. Le swap à chaud n'est malheureusement pas toujours applicable.
Le gain peut se révéler de l'ordre de la demi-heure par jour, ce qui est loin d'être négligeable.
Si par ailleurs, le projet est régulièrement déployé sur un serveur d'intégration continue, le temps gagné peut permettre un rythme plus soutenu de test sans engendrer de coûts supplémentaires. Et ainsi mettre en évidence plus rapidement la moindre régression détectée.
Il intéressant de noter que la majorité des fournisseurs de serveurs d'application reposent leur gestion des profils sur OSGi.
Utilisant un même standard de plugins, les fournisseurs partagent facilement leur travail.
"Web Profile" sera bientôt rejoint par de profils destinés à bien d'autres usages qui bénéficieront alors de tous les avantages suscités en terme de flexibilité et de performance.
