Java University – Introducing Java & JEE

Oracle Java EE Logo

Cet article s’adresse à:

  • Tous les étudiants qui découvrent JavaEE ou qui aimeraient en comprendre les concepts en quelques minutes.
  • Ceux qui utilisent Java avec des frameworks alternatifs (ex: Spring) et qui aimeraient s’imprégner des principes de Java EE.

 

Alors voila, vous avez commencé à jouer avec Java, en ligne de commande.  Peut être certains ont même eu le plaisir de jouer avec des librairies graphiques comme Swing, JavaFX, SWT.

Mais de plus en plus, on vous rabache les oreilles avec JEE. Mais en fait, c’est quoi JEE?

1 – Java Enterprise Edition, c’est quoi?

JEE, c’est une specification (spec). Concrêtement, c’est un ensemble de documents techniques qui définissent une norme. Dans le monde java, ces normes là sont appelées JSR (Java Specification Request). Par exemple, la dernière version JEE 7 est structurée par la JSR-342, un joli bébé de 286 pages. A l’intérieur, on trouvera des documents qui décrivent un ensemble de services, d’interfaces, et de protocoles, qui peuvent eux mêmes être des références vers d’autres JSR (38 pour être exact, chacune du même ordre de taille).

A quoi ça sert?

A définir des méthodes et donner des outils pour créer des applications robustes et distribuées. Alors oui, ça veut tout et rien dire, mais on peut le voir comme un ensemble de composants qu’on peut utiliser pour ne pas réinventer la roue et faciliter vos développements.

Java EE est un ensemble de spécifications destinées à faciliter la création d’applications robustes et distribuées.

Aujourd’hui, il existe de nombreuses technologies fournies à travers JEE, et vous pouvez en avoir une description exhaustive par version en suivant ce lien:

http://en.wikipedia.org/wiki/Java_EE_version_history

2 – Un peu d’Histoire

2.1 Genèse de Java

Quand Java est sorti en 1995, il a bénéficié d’une popularité phénoménale, notamment grâce à:

  • une syntaxe élégante et proche du C
  • une gestion automatique de la mémoire
  • au fait qu’il soit pseudo-compilé, et donc exécuté de manière uniforme sur toutes les plateformes

Tout a commencé au début des années 90 quand Patrick Naughton reçut la proposition de créer une nouvelle technologie destinée à remplacer le C++ (énorme source de frustration à l’époque pour son manque de flexibilité et de gestion de la mémoire) sous le nom de code Project Stealth (furtif).  Il fut rapidement rejoint par James Gosling et Mike Sheridan, le projet changea de nom pour devenir the Green Project.

Au cours des mois suivants, l’objectif se précisa et devint davantage un travail autour d’un langage destiné à des terminaux embarqués. Là où le C++ ne pouvait pas se positionner, car étant bien trop lourd et non conçu à cet effet. Le nom du nouveau langage: Oak.

En 1993, les travaux autour de Oak ont été soldés par de nombreux échecs, liés à des appels d’offres perdus autour de PDAs et de Télévision interactive pour le cable américain. L’équipe trouva son salut en s’intéressant à une technologie qui venait de sortir: le premier navigateur web populaire, un projet sous le nom de Mosaic édité par NCSA, qui sera rapidement remplacé par Netscape.

Mosaic Browser

Ils décidèrent d’orienter Oak en direction d’une technologie émergente et très prometteuse pour toucher le grand public: internet. Le concept était simple: avoir un langage de plus haut niveau (faire abstraction de la gestion de la mémoire, du hardware, de la plateforme), avec une API simple, intégrable dans un navigateur web. De là est né l’applet Java.

Java a largement contribué à l’avènement du web, puisqu’il constituait à l’époque l’unique moyen de créer des interfaces riches dans un navigateur web. Il fut rapidement adopté par de nombreuses communautés de développeurs, et devint très rapidement à la mode.

Des technologies concurrentes (Flash, Javascript, Silverlight) sont apparues sur le marché et ont enrichi l’offre, mais Java gardait l’avantage avec ses applets car il bénéficiait d’une portabilité sans équivoque.

2.2 Avènement de Java 2 Platform, Enterprise Edition

Malgré tout, les technologies évoluent rapidement, et Java cherche à convenir à la fois à des clients lourds (avec l’arrivée de Swing dans Java 1.2) mais doit continuer à répondre à la croissance exponentielle du web.

En 1998, conscient du manque d’outils orientés web et du manque de cohérence autour des technologies à ce sujet, Sun décide d’annoncer JPE (Java Professional Edition), une couche supplémentaire à Java qui proposerait des outils pour créer des applications distribuées. Sun publie Java 2 Platform, Entreprise Edition (J2EE) en décembre 1999. La spécification inclut notamment ces technologies:

Servlets 2.2, JDBC 2.0, JNDI 1.0, JSP 1.2, EJB 1.1, JTA 1.0, JMS 1.0, JavaMail 1.1…

 Java EE découle d’un besoin de norme, de standards, pour que les entreprises puissent créer des applications distribuées et orientées web.

Chaque nouvelle version de J2EE (renommé en Java EE pour Java Enterprise Edition en 2005) est accompagnée de nouvelles technologies, ou de nouvelles versions des précédentes.

2.3 Les serveurs d’application

Comme Java, Java EE est une norme. Ce sont uniquement des interfaces, des comportements, et des concepts qui sont décrits sur papier.

Il est naturellement livré avec une implémentation de référence. Néanmoins, chacun est libre de créer sa propre implémentation. De la même manière qu’un client pourra exécuter son code Java sur une JVM de son choix (selon le constructeur), un serveur qui implémente l’ensemble des spécifications de J2EE est appelé un serveur d’application.

J2EE 1.2 fut l’occasion pour de nombreux constructeurs d’implémenter et de vendre leurs propres serveurs d’applications, dont les plus connus:

  • WebLogic avec WebLogic Server (racheté par BEA en 1998 puis par Oracle en 2008)
  • IBM avec Websphere Application Server

En parallèle, de nombreuses alternatives OpenSource feront leur apparition, notamment

  • Sun Java System Application Server, qui deviendra GlassFish lors de la sortie de Java EE 5. C’est l’implémentation de référence de Java EE. Depuis 2013, le support commercial de GlassFish a été abandonné par Oracle, qui se concentrera sur son autre serveur d’application corporate WebLogic.
  • RedHat JBoss application server, devenu WildFly en 2014.

Chaque éditeur a bien sur ses spécificités en termes de déploiement et de configuration, ce qui rend la migration de l’un à l’autre extrêmement laborieux (bien plus aisé maintenant que dans le passé). Du chemin a été fait entre 1999 et aujourd’hui. Au début des années 2000, il pouvait s’écouler plusieurs heures pour redémarrer un serveur d’application de production. Les machines capables de les faire tourner étaient des monstres et difficilement portatifs. Maintenant, votre serveur d’application se lance en quelques secondes, et votre application se déploie en quelques minutes. Difficile d’imaginer les contraintes de déploiement de l’époque.

Quid de Tomcat, Jetty, … ?

Si un serveur d’application implémente l’ensemble des specs de Java EE, il y a certains éléments très répandus et utilisés dans la quasi totalité des webapps (Servlets, JDBC…), et d’autres qui le sont moins (JMS, JAX-RPC, JMX…). Oracle en a donc défini un sous-ensemble, appelé Web Profile, qui contient uniquement ces technologies indispensables à la création d’applications web, et qui sont implémentées par des serveurs appelés conteneur web (web container) ou (servlet container), les plus connus étant Tomcat ou Jetty.

Un serveur d’application est contexte d’exécution pour des applications web Java EE. Il se doit d’implémenter l’ensemble des spécifications de Java EE.

Un container web, ou container de servlet (web/servlet container) est un contexte d’exécution qui n’implémente que le profil Web de ces spécifications.

3 – Les principaux blocs de Java EE

Si nous voulions être exhaustifs, voici l’architecture qu’il faudrait vous présenter pour comprendre l’ensemble de JEE:

Architecture Java EE 7

Dans le cadre de ce document, nous allons uniquement parler des technologies qui devraient faire partie intégrante de votre bagage technique, ne serait-ce qu’au niveau des concepts qu’elles mettent en oeuvre.

3.1 Servlets

Les servlets sont des composantes web basés sur java, et qui génèrent du contenu dynamique. Elles sont gérées par un container de servlets et permettent d’interagir avec des clients web via requête/réponse.

La dernière version Servlets 3.1 est structurée et décrite dans la JSR 340.

Dans la plupart des cas, on utilise une Servlet pour générer dynamiquement des pages appelées par un client dans un navigateur web. Chaque Servlet est associée à un URI, et l’appel de ce dernier depuis le navigateur déclenchera le contenu d’une méthode de votre Servlet.

Interactions des servlets avec un client

Si les servlets sont très utiles pour faire du déclenchement de processus métier, elles sont en revanche moins utilisables pour faire de la présentation (retourner du code HTML). En effet, ceci impliquerait d’écrire du code HTML dans des objets String depuis votre classe, et de les renvoyer au client. Peu ergonomique, très complexe à maintenir. C’est là qu’on utilisera les JSP

 Les servlets sont des composantes qui génèrent du contenu dynamique et permettent d’interagir avec des clients. On les utilise généralement pour générer des pages appelées par un client dans un navigateur web

3.2 Les JSP

La JSP (Java Server Page) est un composant permettant de créer de manière textuelle des pages web dynamiques. Plus simplement, une JSP permet d’écrire du code de présentation (en général du code HTML) et d’y affecter des comportements et données dynamiques de façon simple. Cette page sera convertie et compilée par votre web container en… une servlet!

Le grand avantage longtemps pébliscité par les créateurs de la JSP est qu’elle permet un bon découpage des rôles. Un développeur frontend sera capable de créer les pages, le look&feel de l’application avec des JSP sans connaitre java, et le développeur java pourra s’occuper de la logique métier en amont sans toucher à la JSP.

C’est un argument qui a de moins en moins de sens (mais nous sommes ouverts au débat!) et on préfèrera parler d’un bon découplage entre la couche de présentation, et le controlleur, dans des modèles classiques MVC.

Les JSP facilitent et encouragent l’utilisation de composants réutilisables, que ce soit des JavaBeans ou des tags, pour faciliter la création de widgets, et le passage de données (data binding).

La dernière version JSP 2.3 est structurée et décrite dans la JSR 245.

 Une JSP permet d’écrire du code de présentation et d’y affecter des données dynamiques. Elle facilite un bon découplage entre la couche de présentation et le controlleur métier.

3.3 La JSTL

La JSTL (Java Standard Tag Library) est simplement une librairie de tags (comme son nom l’indique!), destinée à fournir les composants de base pour enrichir vos JSP.

Des exemples? Faire une boucle, des conditions, afficher des attributs passés dans la requête ou dans des variables de session, créer des urls, internationaliser les chaines de caractère, et bien d’autres choses.

La dernière version JSTL 1.2 est structurée et décrite dans la JSR 52.

3.4 JSF

JSF (Java Server Faces) est un framework Java pour créer des web UI (User Interface) de façon intuitive. Il propose des composants graphiques et un ensemble d’outils qui diminueront grandement le temps de développement.

JSF a très longtemps été un des frameworks les plus critiqués du monde java. La version 1.0, sortie en 2004, a largement été adoptée par de nombreux développeurs. Très rapidement, de nombreuses plaintes ont vu apparaitre le jour, pour plusieurs raisons:

  • JSF 1.0 n’est pas HTML-friendly, le code généré va à l’encontre d’un grand nombre de bonnes pratiques de la programmation web.
  • Le framework s’appuie très peu sur des composantes côté client: JSF 1.0 est extrêmement stateful, (c’est à dire que Chaque composant a un état côté serveur)
  • Il provoque un rafraichissement complet de la page lors d’une quelconque modification d’un composant. Les performances d’applications complexes sont catastrophiques.
  • Ce facteur est aggravé par le fait que les composants ne sont pas personnalisables, et les développeurs avertis n’ont pas la possibilité de modifier ces comportements de façon simple. JSF étant une spécification, la grande majorité des développeurs est limitée à utiliser les composants fournis par l’implémentation qu’ils choisiront d’utiliser. Il faut utiliser des librairies additionnelles (RichFaces, IceFaces…) pour faire de l’AJAX.
  • Le framework permet de faire du quick-start, mais est en réalité ultra complexe et requiert une réelle expertise lorsque l’application atteint une taille critique, souvent plus complexe que d’écrire le côte HTML soi même. Rares sont les développeurs JSF qui auront l’expertise nécessaire pour maintenir leur couche de présentation de façon propre.
  • Une configuration XML peu intuitive

En 2009, JSF sort en version 2.0 et adresse certains des points critiques de la version précédente, notamment:

  • Une intégration en natif de fonctionnalités AJAX
  • La notion de partial processing (pas de rafraichissement complet de la page, juste du composant)
  • Des déclarations simplifiées par annotations
  • Création de composants externes simplifiée
  • Meilleure gestion des ressources statiques (CSS, js …)

Cette version redonne espoir à ceux qui utilisaient déjà le framework, et améliore grandement les possibilité de scalabilité. Mais la mauvaise réputation de JSF ne lui permet pas encore de revenir de ses déboires.

La version 2.2 (JSR 344) sortie en 2013 apporte surtout deux nouveautés:

  • Un meilleur support de l’HTML5
  • Des vues stateless (sans état)

JSF est un UI framework Java qui propose de nombreux composants afin de faciliter et réduire au maximum le temps de développement d’une interface web. La première version avait de grosse lacunes, mais de nombreux problèmes ont été adressés depuis lors, ce qui en fait une option sérieuse parmi la riche panoplie de frameworks UI disponibles.

Note sur Primefaces:

De nombreuses component libraries (bibliothèque de composants) ont été développées pour enrichir JSF (et s’utilisent donc avec une implémentation de ce dernier), et permettent de créer des UI bien plus modernes, en utilisant bootstrap et d’autres librairies bien connues. Certaines de ces librairies ont permis d’insufler un nouvel engouement pour JSF.

Mais alors, quel UI framework choisir?

Il existe plusieurs dizaines de framework UI en Java, JSF étant l’implémentation par défaut de JEE. Tous ces frameworks, malgré les améliorations qu’on souhaitera leur apporter, sont stateful par définition. C’est un choix de conception qui a un sens.

V8, un gamechanger

Les UI frameworks ont longtemps été à la mode et surtout le seul moyen de produire des interfaces riches avec des performances optimales. Le moteur Javascript, meilleur complément pour faire travailler le client plutôt que le serveur, était à l’époque très lourd et peu performant, ne pouvant pas permettre des traitements complexes.

En 2010, Google change la donne et sort un moteur javascript appelé V8. Si je ne m’attarderai pas sur les changements de fond qu’il apporte (par humble manque de compétence), il symbolise une grande fracture technologique dans le monde du web. On est maintenant capable de faire tourner des jeux 3D dans son navigateur (Mozilla a présenté en 2013 le moteur d’Unreal Tournament porté dans son navigateur) et vous trouverez des exemples stupéfiants de ce qui peut être fait avec du Web GL.

Depuis, et de plus en plus, on voit émerger de nouveaux frameworks javascript (ember, backbone, angular…) qui remettent en question le modèle de serveur web dynamique, favorisant les appels en AJAX vers des API REST (une architecture d’échange de données basée notamment sur le protocole HTTP).

Vous allez me dire que ca ne répond pas à votre question. Et vous avez raison! Si je ne me prononce pas sur un choix plutôt que l’autre, c’est bien parce qu’il n’existe pas de silver bullet, et j’insiste sur ce point.

Voici néanmoins quelques éléments de réflexion qui j’espère vous permettront d’orienter votre décision.

Pour le Framework Java:

  • le javascript expose beaucoup plus de code côté client, et potentiellement une partie de votre logique métier y sera déportée. Dans certains cas, ce n’est pas une option!
  • mon projet n’est pas destiné à une utilisation grand public, je n’ai pas à me soucier de problématiques de scalabilité, j’ai les ressources nécessaires pour générer mes pages.
  • je n’ai pas de compétences développement front.
  • mon projet est une preuve de concept, et j’ai un TTM (délai de mise sur le marché) particulièrement court.

Pour le Framework côté client, et une API REST:

  • j’ai besoin de performances, je veux faire travailler le client et non le serveur.
  • je veux découpler au maximum mon backend (côté serveur) et avoir une API unifiée pour des frontends différents (Mobile, web, client lourd, flux…).
  • je n’ai pas de logique métier critique dans ma couche de présentation.
  • j’ai ou je travaille avec des développeurs front qui ont une connaissance poussée des frameworks javascript.

3.5 Les EJB

EJB (Enterprise Java Bean) est une spécification qui facilite la distribution de composants (appelés Beans) sur le réseau. EJB sont de trois types différents, qu’il est important de distinguer:

Les Session-Beans: Qu’ils soient avec (stateful) ou sans (stateless) état, un Session-Bean est un objet qui contient du code métier exécutable par un ou des appelants. Ce sont typiquement des services hébergés sur le serveur d’application qui seront appelables par les clients de façon transparente via le réseau. Les clients posséderont uniquement une interface de ce dernier, permettant au code métier d’être conservé et protégé.

Les Entity Beans: Les EJB Entité permettent de gérer des objets ayant vocation à être persistés. Utilisés avec des ORM (Object Relational Mapping), ils sont un moyen efficace de représenter les entités en base de données sous forme d’objets Java.

Les Message-Driven Beans: Utilisés pour la publication de messages asynchrones avec JMS. Nous ne nous étendrons pas sur ces derniers.

Tous les types d’EJB peuvent évoluer dans un contexte transactionnel, et leur cycle de vie est géré de manière autonome par le serveur d’application, au sein du conteneur d’EJB (on ne les instancie donc pas nous même). Ils permettent au développeur de s’affranchir de certains aspects techniques complexes, comme la publication de services pour des clients distants, la gestion des connexions à la base de données ou la gestion de transactions.

Les EJB sont des composants distribués, managés par le serveur d’application, qui permettent au développeur de s’affranchir de certains aspects techniques complexes comme la publication de services pour des clients distants, la gestion des connexions à la BDD, ou la gestion de transactions.

Lors de la sortie des EJB 1.1 en 1999, et jusqu’à l’arrivée de JEE 5 en 2006, les EJBs ont été les composants métier les plus critiqués de Java EE, étant considéré alors comme un conteneur lourd.

En effet, déclarer un EJB n’est pas une mince affaire. Pour une classe métier, il faut créer au moins deux interfaces (remote et home), et les implémenter dans sa classe. Ces interfaces ont pour but de définir les traitements métier qui seront publiés et visibles côté client, et de gérer le cycle de vie du bean. Il faut aussi créer un descripteur de déploiement au format XML.

A cette époque, bon nombre de développeurs vont donc décider de ne plus utiliser JEE et se reporteront sur des frameworks alternatifs comme Spring.

L’arrivée de la version 3.0 avec JavaEE 5 change la donne. JavaEE devient un conteneur léger pour les EJB, puisque tous les comportements sont gérés grâce à l’ajout d’annotations.

Aujourd’hui, choisir JEE ou un framework alternatif comme Spring n’est plus une contrainte, car ils se valent en termes de facilité d’implémentation et de fonctionnalités. C’est un choix de conception.

L’un apportera la sécurité d’être un standard supporté par Oracle et assure ainsi la pérennité dans le temps du choix technique. L’autre apportera une plus grande réactivité aux évolutions technologiques, et la possibilité de choisir précisément toute sa stack technique. Elle sera en revanche soumise aux aléas des solutions OpenSource: les bugs, les dépréciations, ou un support stoppé.

EJB 3.1 est la dernière version sortie avec JavaEE 7 en 2013. Elle est décrite par la JSR 318

3.6 Java Persistence

Java Persistence API, aussi appelé JPA, est une interface sortie avec JavaEE 5 en 2006. Elle repose essentiellement sur l’utilisation des annotations (introduites avec Java 5 en 2002), et simplifie grandement le développement des entités qui représentent les objets du monde relationnel (des base de données). JPA permet de définir des tables, colonnes, clés primaires, jointures, et de les apposer sur des attributs de classes pour automatiser toute une partie du mapping entre le monde objet et le monde relationnel (ORM).

Note: JPA s’utilise généralement avec des Entity Bean.

JPA est une API utilisant des annotations, permettant de simplifier grandement le développement des entités qui se chargent du lien BDD-monde objet (ORM, Object Relational Mapping).

La dernière version 2.1 de JPA date de 2013, est décrite par la JSR 338

3.7 JTA

JTA, ou Java Transaction API est un des blocs les plus importants de JavaEE, puisqu’il décrit les comportements nécessaires pour implémenter un systême transactionnel distribué. Les interfaces fournies permettent de gérer les différents partis concernés par la transaction, et de déclarer la logique de validation (commit) et d’annulation (rollback) de ces dernières, sur des critères d’échec définis.

JTA est un ensemble d’interfaces permettant de faciliter le support de transactions au sein d’une application distribuée.

La dernière version en date (1.2) est décrite par la JSR 907

4 – Bibliographie

Timeline et histoire Java Professional Edition

http://books.google.fr/books?id=Di_qAgAAQBAJ&dq=Java+Professional+Edition+1998&hl=fr&source=gbs_navlinks_s

http://java.coe.psu.ac.th/FreeOnline/TheServerSide.com/UnderstandingJ2EETV/J2EE.pdf

Java EE

http://en.wikipedia.org/wiki/Java_EE_version_history

JSF

http://davidwburns.wordpress.com/2012/04/23/why-i-dont-use-java-server-faces-jsf/

JSF is not what you’ve been told anymore

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.