All posts in Java EE

Quelles perspectives pour Java et le développement Mobile ?

By Caroline Kaercher / 28 novembre 2019 / 1 Comment
ApéroTech 4 DocDoku Flutter Oracle Code One Java
Quelles perspectives pour Java et le développement Mobile ?

C’est la question posée aux intervenants et participants de notre dernier ApéroTech du 14 novembre dernier à Toulouse.

A la découverte de Flutter 

Pour lancer l’ApéroTech sur le sujet du futur du développement Mobile, Thibaud a présenté une alternative à React Native : Flutter, lancé par Google. Les participants ont ensuite pu bénéficier d’une démo en live de l’API Spatioport pour découvrir les capacités du framework.

Retour d’experiences croisées sur Oracle Code One 2019

L’ApéroTech s’est poursuivi avec l’intervention d’Olivier et Bertrand, heureux participants du dernier Oracle Code One à San Francisco qui ont fait le point sur l’avenir de l’écosystème Java.
JVM, GraalVM, JakartaEE, Microprofile et Kubernetes : de multiples bouleversements accompagnent les mutations des environnements d’exécution.
Les impressions à chaud de Bertrand sont à retrouver sur son article ici.

Merci aux intervenants et participants pour leurs échanges et leur belle énergie !

Nous avons hâte de vous retrouver en mars 2020 pour une nouvelle édition.

Informations et inscriptions sur la page Meetup Les Z’ApéroTech.

Retour sur EclipseCon France 2018

By Olivier Bourgeat / 9 juillet 2018 / 4 Comments
En septembre 2017, Oracle annonçait sa décision, en accord avec les autres grands acteurs du marché que sont IBM et RedHat, de transférer les technologies JavaEE à la fondation Eclipse pour «rendre le processus d’évolution de ces standards plus agile» [4].
Cette annonce a provoqué un séisme au sein de la communauté Java et a levé de grandes interrogations sur l’avenir de la plateforme, sur le positionnement du projet Eclipse MicroProfile et sur l’état d’avancement de cette transition.
Comme chaque année DocDoku1 était présent à l’EclipseCon France 2018, rendez-vous annuel de la communauté Eclipse à Toulouse.
Comme à chaque fois un thème est à l’honneur. Cette année il était légitime que ce soit le tour de la plateforme «entreprise» pour Java d’être sous le feu des projecteurs.
Étant moi même à l’affût d’information sur l’avenir de cette plateforme, j’ai profité de l’unique journée à laquelle j’ai pu venir, pour me concentrer sur JakartaEE et MicroProfile.

JakartaEE

JakartaEE

Au début de cette année, la communauté a choisi le nom JakartaEE pour désigner ce qu’Oracle appelait JavaEE. En effet Oracle a souhaité conserver ses droits sur la marque Java, il fallait donc trouver un autre nom.
Pourtant à la fin de l’année 2017 la fondation Eclipse avait annoncé la création du projet Eclipse Enterprise for Java (EE4J).

EE4J ou JakartaEE ?

Eclipse Enterprise for Java [5] est le projet «chapeau» pour tout ce qui concerne les technologies JavaEE, c’est à dire les API mais aussi les implémentations de référence transférées aussi par Oracle.
Eclipse JakartaEE Platform [6] est donc un sous-projet de EE4J qui reprend ce qu’était la spécifiaction de la plate-forme JavaEE : la définition d’un environnement d’exécution résultant de l’agrégation d’un ensemble spécifications d’API.
On trouve naturellement par ailleurs un sous-projet pour chaque API (Servlet, EJB, …) mais aussi les implémentations de références développées au sein de la fondation Eclipse ou par Oracle comme Yasson, EclipseLink, Glassfish, Grizzly, Jersey, …

Où en est la transition ?

Tout d’abord la procédure de transfert est longue car Oracle doit faire des vérifications (propriété intellectuelle, licence, …) pour chaque élément transféré.
En outre, les CTS2/TCK3 d’Oracle ne sont pas libres.
Nous apprenons que la transition se fera en plusieurs étapes :

  • Rendre JakartaEE 8 officiellement compatible avec JavaEE 8.C’est à dire obtenir une implémentation de référence JakartaEE qui passe les CTS/TCK actuels d’Oracle.
  • Fournir des CTS/TCK libres pour JakartaEE et s’assurer que l’implémentation de référence JakartaEE passe avec succès ces tests.
  • Une fois ces deux objectifs atteints JakartaEE pourra évoluer selon le processus normal de la fondation Eclipse.

En regardant l’état d’avancement on peut voir que la migration d’une bonne partie des projets est déjà bien avancée.

Un point sur les licences

Le système actuel de licence d’Oracle (CDDL4 et GPL5v2 des spécifications, API et RI ; TLDA6 pour l’usage des TCK et de la marque JavaEE) vont également changer en Eclipse Public License (EPLv2)

Comment la plateforme évoluera-t-elle ?

Les API sortent du giron de JCP7 et des JSR8 pour rejoindre le système des Working Group d’Eclipse et du processus de spécification de la fondation.
Grâce à ce changement, l’Eclipse Foundation espère une plus grande agilité et flexibilité.$
On nous indique que la stratégie d’évolution sera la standardisation a posteriori des bonnes idées qui ont fait leurs preuves à l’instar des exemples célèbres comme Hibernate, Weld, Jersey qui ont donné JPA, CDI et JAX-RS.
Notons que le JCP ne disparaît pas, il continue de fonctionner pour ce qui concerne JavaSE.

JakartaEE vs. MicroProfile

JavaEE 6 a vu l’arrivée de la notion de profil (Web Profile, Full Profile) au sein de la plateforme JavaEE. Le constat de l’époque étant que toutes les applications n’avaient pas besoin de l’ensemble des technologies de la plateforme.
Avec l’arrivée du Cloud Computing et succès des architectures micro-service (comprendre à base de VM), Eclipse MicroProfile propose une spécification de profil encore plus minimal, concurrent direct de Spring Boot [7], basé essentiellement sur les API standard CDI, JAX-RS et JSON-P auxquelles s’ajoutent quelques API nouvelles (Config, Health, Metrics, …).

MicroProfile

Eclipse MicroProfile [8] est donc une spécification alternative d’un ensemble d’API adaptées à la mise en œuvre d’applications architecturées sous forme de micro-service.
D’abord basé sur un nombre très limités d’API, la plateforme évolue comme le montre le tableau [Table:1]

Évolution de Microprofile
API/MicroProfile 1.0 1.1 1.2 1.3 1.4 2.0
CDI 1.2 – – – – 2.0
JSON-P 1.0 – – – – 1.1
JAX-RS 2.0 – – – – 2.1
Config 1.0 – 1.1 1.2 1.3 –
Health Check 1.0 – – –
Metrics 1.0 1.1 – –
Fault Tolerance 1.0 – 1.1 –
JWT Propagation 1.0 – 1.1 –
Open Tracing 1.0 1.1 –
Open API 1.0 – –
Rest Client 1.0 1.1 –
JSON-B 1.0

Une des forces des spécifications ouvertes, comme pour JEE, est de permettre de fédérer divers éditeurs. Grâce à cela il existe plusieurs implémentations de MicroProfile (voir le tableau ci-dessous).

Implémentations de MicroProfile
Éditeur Implémentation
IBM Open Liberty [9]
RedHat WildFly Swarm [10]
Payara Payara Micro [11]
Apache Tomee [12]
Hammock Hammock [13]
Kumuluz KumuluzEE [14]

Avec les implémentations de MicroProfile, il est possible de déployer une application de plusieurs façons :

  • l’application, les dépendances et le runtime sont packagés dans un seul et même JAR exécutable.Format popularisé par Maven et Spring Boot, la taille de l’archive peut devenir si importante que cela peut poser des problèmes lors de déploiements fréquents (déploiement continu)
  • L’archive JAR contient l’environnement d’exécution, l’archive WAR les ressources métier et les éventuelles dépendances tierces.Avantage, Le WAR est plus léger à déployer car il ne contient que ce qui est spécifique au métier. Cela rappelle le mode de déploiement dans un serveur JavaEE.

12-Factor Application

Pour rappel, «Application à 12 facteurs» est une méthodologie pour construire des applications SAAS9.
Les 12 facteurs en question sont:

  1. Une seule base de code, versionnée (Codebase)
  2. Déclarer explicitement et isoler les dépendances (Dependencies)
  3. Ne pas stocker la configuration dans le code (Config)
  4. Tous les services sont vus comme des ressources «tierces» (Backing services)
  5. Stricte séparation entre la construction, la livraison et l’exécution d’une application (Build, release,run
  6. Les processus d’une application sont sans-étatProcesses
  7. Les services (Web) sont exposés via un port réseau (Port Binding)
  8. L’application se décompose en processus parallèles (Concurrency)
  9. L’application doit pouvoir être démarrée et arrêtée à la demande (Disposability)
  10. Garder les environnements (développement ,recette, production) aussi similaires que possible(Dev/Prod parity)
  11. Les logs sont un flux d’événements indépendant de la manière dont ils sont stockés (Logs)
  12. Les processus d’administration doivent s’exécuter dans le même environnement que l’application (Admin Process)

La présentation d’Emily Jiang [2] nous montre comment l’association de la plateforme MicroProfile et Kubernetes permettent de mettre en œuvre une application selon ces principes.

Codebase
Le code source de l’application est géré par Git (sur GitHub).
Dependencies
La construction et la gestion des dépendances est gérée par Maven.
Config
Les configmaps Kubernetes et l’API Config servent à injecter les propriétés de configuration dans l’application.
Build-Release-Run
Une plateforme d’intégration continue prend en charge le packaging pour chaque environnement.
Processes
L’API REST permet de mettre en œuvre les processus sans-état
Port Binding
Kubernetes et l’API Config sont responsable de l’affection des ports
Concurrency
Le découpage en micro-services et Kubernetes permettent de gérer la mise à l’échelle
Disposable
L’API Fault Tolerance permet de rendre l’application résiliente aux arrêts des processus.
Dev/Prod Parity
Kubernetes Helm permet de s’assurer que les différents environnements sont similaires
Logs
ELK10 permet d’indexer et de gérer les journaux.
Admin Process
L’outillage standard de Kubernetes (kubectl exec) permet des déclencher les processus d’administration.

Sécurité sans-état avec JWT

La sécurité est un aspect fondamental pour les applications d’entreprise, celui-ci est d’ailleurs pris en compte dans JavaEE (avec plus ou moins de souplesse) depuis les tous débuts de la plateforme.
Les architectures micro-service («SOA avec un nom sexy» dit Jean-Louis Monteiro [3]) ne font pas exception, mais l’aspect sans-état nécessaire pour faciliter la gestion de la charge change la donne.
Jean-Louis discute des inconvénients des différentes options d’authentification et de propagation des identités:

Basic Auth
présente plusieurs risques car :
– le couple login/motdepasse est envoyé à chaque requête,
– risque d’attaque DOS du référentiel de sécurité.
OAuth 2.0
basé sur une paire de jetons (access/refresh) recrée au final une session HTTP côté serveur pour garder une trace des jetons générés (et confiés au client) : cela consomme de la mémoire et du temps de calcul car chaque micro-service activé doit vérifier les tokens
JWT
est un format de jeton similaire à SAML mais codé en JSON. Ils contiennent des informations signées et potentiellement chiffrées. Dans ce cas de figure les informations signées, donc non altérables, sont stockées côté client.

L’association JWT + OAuth 2.0 permet de réduire considérablement les ressources nécessaires côté serveur : seules des références de jeton sont conservées (pour la révocation) et chaque service peut vérifier la signature du jeton de manière autonome.
Une présentation de la mise en œuvre de se mécanisme avec l’API JWT propagation de la plateforme MicroProfile vient enfin compléter la brillante démonstration.

JakartaEE + IOT

Une démonstration concrète de la mise en œuvre de technologies JavaEE et de l’Internet des Objets.
Payara Micro [11] est une déclinaison du serveur d’application Payara Server (basé sur Glassfish), pensée pour les micro-services «conteneurisés».
Ce micro-serveur d’application est compatible MicroProfile, mais malgré sa taille (moins de 70Mo),il supporte la mise en cluster, les connecteurs JCA, le Clustering, JCache, les EJB Timer, les événements CDI distribués.
Comment obtenir un serveur d’application si léger ? En faisant l’impasse sur les API historiques les moins pertinentes pour ce genre d’application m’a-t-on indiqué.
Grâce à sa légèreté, sans trop de compromis quant aux fonctionnalités, nous assistons à la démonstration d’une application capable d’agréger des données en provenance de capteurs (d’humidité dans le cas présent) à travers des applications JavaEE déployées sur des nano-ordinateur de type RaspberryPi.
Événements CDI distribués, connecteur JCA pour des échanges de messages asynchrone (MQTT), services REST sont au rendez-vous pour démontrer que les technologies JavaEE ont aussi leur place dans le monde des ressources contraintes de l’IOT.

Kubernetes : retour d’expérience

La fondation Eclipse est en cours de migration de sa plateforme d’intégration continue depuis Cloodbees Jenkins Enterprise vers une solution basée sur un cluster Kubernetes (OpenShift).
À partir de sa propre expérience de migration, Mikaël Barbero nous présente une excellente introduction à Kubernetes [1]
Kubernetes [15] est un système Open Source d’orchestration de conteneurs (VM) permettant d’automatiser le déploiement, la configuration, la gestion et la montée en charge d’applications ou de micro-service «conteneurisés».
Contrairement à la plateforme JavaEE où le conteneur – la machine virtuelle Java – est limitée à l’exécution de bytecode, les conteneurs (machines virtuelles) gérés par Kubernetes sont plus génériques car indépendants d’un OS, d’un langage et d’une plateforme pré-définis.
Là ou les serveurs d’application JavaEE permettaient d’orchestrer des machines virtuelles Java au sein d’un cluster, des outils comme Kubernetes réalisent sensiblement le même travail avec des conteneurs Docker dans le cas présent.
On perçoit comment ont évolués les usages ces dernières années: plutôt que de dépendre des capacités d’un serveur d’application JavaEE, limitées plus ou moins au monde Java, on préfère utiliser un outillage tiers pour gérer un cluster de machines virtuelles plus générales

Conclusion

Que ne lit-on pas ici et là sur la nature «monolithique» de la plateforme JavaEE, que l’on oppose à une architecture fragmentaire des micro-services.
Pourtant JavaEE/JakartaEE ne décrit pas comment doit être implémenté l’environnement d’exécution mais défini seulement un ensemble d’API qui doit être disponible et un format de packaging. Chaque type de composant est d’ores et déjà distribuable, alors pourquoi ne pourrait-on pas voir JEE comme la définition d’une PAAS11 tout à fait capable de construire des applications à base de micro-services ?
Est-ce la difficulté de morceler la plateforme comme ce qui a été réalisé lors des premiers profils (Web et Full) ? Est-ce la nécessité de conserver une compatibilité ascendante ?
Le succès des solutions MicroProfile (ou dans une certaine mesure Springboot ou Dropwizard) nous apprend que:

  • On doit pouvoir choisir les technologies strictement nécessaires à la mise en œuvre d’une application ou d’un composant applicatif.L’intégration de systèmes de modules dynamiques comme OSGI dans les implémentations des serveurs d’applications permet d’ores et déjà de ne charger en mémoire que les composants nécessaires, reste la configuration parfois complexe d’un domaine que l’on voudrait déléguer à des systèmes moins spécifiques.
  • Micro-service ou pas, le contexte des applications d’entreprise nécessite de disposer de solutions pour simplifier la mise en œuvre des aspects transverses (sécurité, transaction, distribution, tolérance aux pannes, métrologie, surveillance, journalisation, …).Il suffit, pour s’en convaincre, de regarder l’évolution des API de MicroProfile. Si les nouvelles API répondent à de nouveaux usages, elles peuvent également profiter à JakartaEE, mais à ce rythme MicroProfile restera-t-il «micro» ?
  • Le choix de la standardisation adoptée par Sun/Oracle ou la fondation Eclipse permet de fédérer les efforts des différents éditeurs et de favoriser la portabilité et l’interopérabilité.

Maintenant que JavaEE est en passe d’être libéré de la tutelle – soit-elle symbolique – d’Oracle, l’enthousiasme des participants à la conférence était au rendez-vous.
Grâce à la disponibilité de systèmes de virtualisation par conteneurs capables d’exécuter des composants (Java ou non); d’outils permettant la gestion d’infrastructures complexes de type Cluster ou Cloud; la modularité sera à mon avis le défi auquel devra répondre la plateforme JakartaEE, soit en intégrant ou définissant de nouveaux profils comme MicroProfile, soit plutôt en proposant une plateforme totalement modularisé pouvant être composée à la carte, à l’instar du travail réalisé sur JavaSE.
Demain, déployer une application JakartaEE consistera-t-il à découvrir à partir d’un paquetage les API utilisées, de provisionner un conteneur contenant le strict nécessaire et d’exécuter le tout ?
Merci enfin à toute l’équipe de la fondation Eclipse qui ont encore une fois réussi à organiser un événement fantastique.
Bravo à tous les conférenciers pour la variété et la qualité des présentations.

Références

1. Mikaël Barbero. 2018. Kubernetes 101. Retrieved from https://www.slideshare.net/mikaelbarbero/kubernetes-101-a-cluster-operating-system/
2. Emily Jiang. 2018. Build a 12-Factor Microservice in Half an Hour. Retrieved from https://www.eclipsecon.org/france2018/sites/default/files/slides/Build12FactorAppUsingMP.pptx
3. Jean-Louis Monteiro. 2018. Stateless Microservice Security via JWT, TomEE and MicroProfile. Retrieved from https://www.eclipsecon.org/france2018/sites/default/files/slides/2018_EclipseConEU_StatelessRESTSecurityWithMP-JWT.pdf
4. 2017. Opening Up Java EE – An Update. Retrieved from https://blogs.oracle.com/theaquarium/opening-up-ee-update
5. Eclipse Enterprise for Java. Retrieved from https://projects.eclipse.org/projects/ee4j
6. JakartaEE. Retrieved from http://microprofile.io/
7. Spring Boot. Retrieved from https://spring.io/projects/spring-boot
8. Eclipse MicroProfile. Retrieved from http://microprofile.io/
9. Open Liberty. Retrieved from https://openliberty.io/
10. WildFly Swarm. Retrieved from http://wildfly-swarm.io/
11. Payara. Retrieved from https://www.payara.fish/
12. Apache TomEE. Retrieved from http://tomee.apache.org/
13. Hammock. Retrieved from https://hammock-project.github.io/
14. KumuluzEE. Retrieved from https://ee.kumuluz.com/
15. Kubernetes. Retrieved from https://kubernetes.io/
  1. DocDoku est membre solution de la fondation Eclipse↩
  2. Compatibility Test Suite↩
  3. Tehnology Compatibility Kit↩
  4. Common Development and Distribution License↩
  5. Gnu Public License↩
  6. Technology License and Distribution Agreement↩
  7. Java Community Process↩
  8. Java Specification Request↩
  9. Software As A Service↩
  10. Elasticsearch, Logstash, Kibana↩
  11. Platform As A Service↩

Les micro services peuvent-ils remplacer les serveurs d’applications ?

By Florent Garin / 31 décembre 2012 / 3 Comments

Un concept en fin de vie ?

Durant ces dix dernières années, particulièrement dans l’écosystème Java, le serveur d’applications fut le roi. Tout bout de code « server side » finissait fatalement déployé sur cet élément hautement important du système d’information. Comme nous l’enseignons nous-mêmes en formation son rôle est de fournir les services techniques aux applications (connexions aux bases de données, gestion du cycle de vie des composants, module d’authentification, supervision des transactions…) déchargeant ainsi les développeurs de l’implémentation de cette tuyauterie ; tâche critique et souvent difficile.

Cette séparation des responsabilités est au cœur de la philosophie Java EE, la spécification de la plateforme distingue en permanence les activités incombant aux développeurs d’applications de celles prises en charge par les administrateurs gérant l’infrastructure ou encore justement les fonctionnalités devant être assurées par le serveur d’applications.

Si on peut comprendre cette logique, pensée pour les environnements complexes des grandes organisations où le SI est géré de manière centralisée, cette approche souffre néanmoins d’une rigidité et d’une lourdeur certaine, chaque application nécessite avant d’être déployée que l’on paramètre son environnement technique sur son conteneur.

Les micro services

Les micro services s’inscrivent dans une démarche opposée : la notion de serveur d’applications (conteneur) gouvernant l’exécution des composants d’application déployés en son sein n’existe plus. Chaque micro service est une application « standalone » tournant dans son propre processus. Ces applications communiquent entre elles au travers de web services de type REST sans l’intermédiation d’un middleware devenu encombrant, à la manière des commandes Unix qui s’agrègent avec un simple pipe. Leur périmètre est généralement réduit, elles font une chose et s’attachent à bien le faire, ainsi on pourra les réécrire si nécessaire complètement en limitant les coûts.

REST a montré qu’il était néfaste de chercher à s’abstraire coûte que coûte du protocole HTTP, les micro services nous enseignent qu’il n’est sans doute pas optimal de chercher à effacer le système d’exploitation comme les serveurs d’applications Java se sont évertués à le faire, en voulant recréer un OS dans l’OS.

Les frameworks

Qui dit nouveaux paradigmes dit nouveaux frameworks. Toujours dans l’univers Java, il y a bien sûr le presque déjà vieux Playframework qui adopte une stratégie résolument de rupture en proposant une pile logicielle avant-gardiste et encourageant fortement l’usage du langage Scala, même si Java est également supporté. Un autre framework, bien que moins audacieux, mérite tout autant que l’on s’y intéresse, il s’agit de Dropwizard. Ce framework possède l’avantage de capitaliser sur des technologies matures, bien connues des développeurs Java EE comme Jersey, Jackson, Jetty ou encore Hibernate validator. La courbe d’apprentissage sera donc douce.

Allez bonne année et RDV en 2013 pour mettre tout ceci en pratique !

Hibernate dirty checking

By Florent Garin / 6 septembre 2010 / 1 Comment

Les ORM (Object-Relational Mapping) sont aujourd’hui des technologies matures ; l’essentiel d’Hibernate a été versé au standard Java EE au travers de la spécification JPA qui en est maintenant à sa deuxième version.
Les réfractaires à la technologie, qui préfèrent encore utiliser directement l’API JDBC ou (moindre mal) les templates JDBC de Spring, sont aujourd’hui de moins en moins nombreux. Malgré tout, s’il est donc vrai qu’un ORM apporte une solution élégante à la problématique de persistance de nos applications, il faut aussi admettre qu’en déléguant une partie du travail d’interaction avec la base de données à ces outils nous perdons un peu en contrôle ce qui introduit de nouvelles difficultés. Parmi celles-ci il y a la bonne prise en compte du « dirty checking ».

Le « dirty checking » est un mécanisme d’Hibernate qui consiste à lister parmi les objets attachés ceux qui ont été modifiés pour ensuite propager ces modifications en base. Ce comportement du framework doit être bien compris car il peut être source d’effets secondaires indésirables.

Hibernate peut lancer une opération de « dirty checking » à plusieurs occasions :

  • Lors d’un flush, qui intervient au moment du commit de la transaction ou d’un appel explicite par EntityManager.flush(),
  • Juste avant l’exécution d’une requête de type « select ». Ce cas de figure peut sembler moins évident que le premier mais la raison est relativement simple : la requête sera exécutée au niveau de la base de données, il est par conséquent capital que les données modifiées dans la transaction en cours qui peuvent influencer le résultat de la requête soient « flushées ».

Si la plupart du temps, le « dirty checking » se fait dans la plus grande transparence sans que le développeur n’ait à s’en soucier, il arrive aussi que son déclenchement soit gênant. Par exemple dans le cas de traitement de masse où le nombre d’objets attachés est très important cette opération peut pénaliser fortement les performances. Par ailleurs, si l’on souhaite avoir la main sur l’ordonnancement des requêtes SQL, il est embêtant qu’une simple recherche JPQL déclenche une série de requêtes de type « update » à la suite d’un « dirty checking ».

Comment faire alors pour maîtriser la propagation des modifications dans la base et éviter les traitements de « dirty checking » intempestifs ?

Hibernate étant un framework souple et paramétrable, il offre pas mal de possibilités au développeur pour gérer cela : on peut travailler dans un mode « read only », on peut aussi utiliser la classe StatelessSession qui est spécialement pensée pour dérouler des opérations en bloc (sans « dirty checking » automatique). Si l’on préfère, probablement à raison, rester sur le standard JPA, il suffit de positionner le « flush mode » comme ceci :

EntityManager.setFlushMode(FlushModeType.COMMIT);

Ainsi les objets ne seront synchronisés avec la base de données qu’à la fin de la transaction, au moment du commit. Évidemment, il faut là aussi être sûr de son coup, il convient de bien vérifier qu’aucune requête de sélection ne sera perturbée par ce flush tardif.

JSF 2.0, enfin correct !

By Florent Garin / 18 avril 2010 / 1 Comment

Voila quelques mois maintenant sortait dans sa version finalisée la spécification Java EE 6.
Dans la foulée la version 3 de glassfish était mise à disposition.

Globalement, la plateforme va vers plus de modularité et de simplicité avec notamment la généralisation des annotations ou encore l’apparition des profils qui servent à regrouper les API Java EE en plusieurs familles. Pour l’instant, il n’existe que deux profils, le profil complet et le profil Web.

Java EE a clairement atteint aujourd’hui l’âge de la maturité, le modèle de développement standard Java pour les applications d’entreprises n’a plus de véritables faiblesses comme par le passé avec les abominables EJB2. Malgré tout, parmi les nombreuses briques définies par la spécification, il en reste une que les développeurs auront tendance à substituer par une alternative open source ; je pense à JSF.

JSF n’a jamais été le framework brillant devant lequel on tombe en émerveillement le jour où on le découvre. Il n’a pas l’étoffe d’un Struts qui au début des années 2000 structura en MVC nos applications web ni la souplesse de Spring Ioc, la puissance de Spring AOP ou encore la simplicité de GWT. Toutefois la version 2 efface les principaux reproches qui étaient faits au framework en apportant :

  • Support de la méthode HTTP GET qui permet de faire des URLs « bookmarkable »
  • Support d’AJAX avec le rendu partiel de la vue
  • Moteur de templating
  • Navigation implicite entre les pages (<navigation-rules> n’est plus obligatoire)
  • Facelets préféré aux JSP
  • …

Ainsi aujourd’hui, il est possible de choisir JSF 2 pour implémenter la couche de présentation d’une application web sans forcément faire une erreur !

Le futur de JSF

By Florent Garin / 19 janvier 2008 / 4 Comments

JSF ne s’est pas encore, gardons espoir, véritablement imposé comme LE framework web java.
La première des raisons est sans doute sa complexité. Essayez d’expliquer à un féru de php son Unified Expression Language pour vous en convaincre.
Deuxièmement, la spécification de JSF ne définit qu’une palette de composants graphiques très limité. Dans un projet réel, ceux-ci suffisent rarement ; il faut alors se tourner vers des extensions propriétaires, perdant du même coup la neutralité vis à vis de l’implémentation de JSF.
Enfin, le dernier point problématique est la difficulté d’intégration de JSF et d’AJAX.
Il est en effet compliqué de mixer l’approche purement « server-side » de JSF avec une logique AJAX où une partie du MVC est directement implémentée sur le client en javascript.
La jsr 314, celle de JSF 2.0, devrait remédier à cela en apportant des modifications importantes au cycle de vie notamment le parcours partiel de l’arbre des widgets.
Cela va dans le bon sens, néanmoins, il n’en demeurera pas moins que de plus en plus la logique cliente se trouvera portée par du code AJAX, laissant à JSF la gestion des tâches annexes.
Si JSF 2 marquera indéniablement l’acceptation d’AJAX par Java EE, ne faudrait-il cependant pas aller plus loin, en d’autre terme ; pour préserver sa pertinence, JSF 3 ne devra t-il pas être un framework en bonne partie javascript ?