Technologies

A la recherche de JEE (1)

Publié le : Auteur: vhanniet Un commentaire
technologies

Généralement, lorsqu’on parle de Java/JEE on se réfère à la plate-forme Java utilisée pour développer de l’informatique. De gestion le plus souvent pour ce qui nous concerne. Cette plate-forme comprend :

  • Une (ou des) versions du langage Java
    • actuellement Java 7 est la plus récente version de Java disponible, Java 8 est dans les tuyaux – mais le plus souvent les projets utilisent Java 5 ou Java 6 puisque la dernière grosse rupture était sur Java 5
    • en pratique, une « version » du langage veut dire un compilateur qui va traduire le code source Java en bytecode, ainsi que la « machine virtuelle Java » (JVM) qui pourra interpréter ce bytecode pour l’exécuter
  • Des librairies Java qui fournissent toute sorte d’outils et de services

Pour simplifier, disons qu’on peut appeler Java SE (Java Standard Edition) l’ensemble de tous ces éléments. Java SE est disponible sous deux formes :

  • Le bundle (= paquet cadeau en français !) Java Runtime Environment (JRE) qui est l’environnement d’exécution des applications Java
  • Le bundle Java Development Kit (JDK), qui contient le JRE, qui est l’environnement nécessaire au développement Java et qui contient, notamment, le compilateur

Avec un JDK on peut développer des programmes Java . Mais on ne va pas très loin ! En effet, disposer (seulement) d’un compilateur Java et de librairies de bas niveau (*) veut dire qu’on peut :

  • Ecrire des programmes avec un éditeur de texte, les compiler et les exécuter. C’est bien, mais il ne faut pas qu’il y ait, comment dire, trop de programmes. Ni des programmes trop gros. Parce que les fonctions d’un éditeur sont surtout orientés sur l’édition et qu’ici on a aussi d’autres problèmes à gérer. Dont par exemple la gestion de versions du code source…
  • Qui plus est, sauf à réinventer la roue ou à réaliser des « exercices de programmation » , ces programmes ont certainement besoin d’exploiter une infrastructure logicielle fournissant des services de plus haut niveau. Comme par exemple un SGBD…
  • (*) en fait, curieusement, on trouve dans Java SE Swing et AWT qui sont des frameworks d’IHM pour client lourd. Ce n’est pourtant pas vraiment ce qu’on peut appeler des librairies de bas niveau…

Donc, en restant pour le moment sur un simple plan « Je veux développer un programme Java utilisable et maintenable mais pas réinventer l’informatique », on va avoir besoin :

  • D’un environnement de développement intégré (IDE), qui constitue la station de développement des développeurs à partir de laquelle ils ont accès de manière coordonnées à tous les outils nécessaires à un développement productif (y compris ce qui suit)
  • D’un environnement de gestion de cycle de vie logiciel, qui peut aller jusqu’à l’Application Life-cycle Management (ALM), couvrant par exemple la gestion des versions, mais aussi l’intégration continue, les tests automatisés, le travail collaboratif, la gestion des exigences, etc.
  • De frameworks (ie de librairies fournissant des services de tous niveaux, jusqu’aux plus élaborés) :
    • supportant d’une part une architecture adaptée au projet dans la phase d’exécution/production : un moteur de SGBD, un moteur de messagerie, etc.
    • facilitant d’autre part le développement des interfaces entre le programme Java écrit par le développeur et ces frameworks

Tous ces composants ne font pas partie directement de la plate-forme Java. Ils peuvent généralement tous être utilisés pour développer dans d’autres technologies. Mais ils sont nécessaires pour développer en Java.

Et JEE dans tout ça ? J’y viens…

Au delà de Java SE, et ce depuis l’origine de Java chez Sun, il existe d’autres déclinaisons de librairies pour Java qui vont au delà des simples commodities de niveau « langage de programmation moderne ». Typiquement, actuellement, Oracle propose différents autres environnements :
(cf. http://www.oracle.com/fr/technologies/java/overview/index.html)

  • « Enterprise Edition » : c’est justement Java EE (voir plus loin)
  • « Micro Edition » : orienté Java embarqué, c’est Java ME
  • « Java for Mobile Devices »… Ah ben non en fait, c’est aussi Java ME !
  • « Java FX » : plate-forme d’interface utilisateur avancée… Tiens c’est curieux. C’est une plate-forme orthogonale aux autres puisque toute application (SE, EE ou ME) dispose nécessairement d’une interface homme machine (ne serait-ce que pour son administrateur…)

Comme on peut le voir, tout ça reste quand même relativement confus. Ces environnements sont généralement appelés Software Development Kit (SDK), ce qui est logique d’un point de vue technique. Mais cette terminologie viennent malheureusement se confondre, quand on se dépêche de mettre en place son environnement de travail, avec JDK (Java SE DK). D’autant plus que selon leurs déclinaisons ces SDK et leurs bundles contiennent, ou pas, le JDK et que de toute façon le JDK est indispensable puisque celui-ci est à la base de toute plate-forme Java !

Par ailleurs, certains bundles ne contiennent pas que des librairies, comme on pourrait s’y attendre, mais peuvent également contenir des frameworks d’infrastructure. Par exemple, tous les nombreux bundles du SDK Java EE contiennent le serveur d’application GlassFish. Qui lui même, même si ça n’apparaît pas directement dans la description du bundle, embarque Java DB qui est l’implémentation Oracle du SGBDR Apache Derby… Ouf !
Clairement, cette face de Java, au delà de Java SE, est celle où les entreprises qui soutiennent la plate-forme Java espère faire du business (elles peuvent également en faire dans les à côté IDE, ALM et frameworks). Historiquement d’ailleurs, c’est un des business modèles des entreprises de taille mondiale qui ont soutenu Java : Sun (NetBeans, Solaris…), IBM (WebSphere…), BEA (WebLogic…). On est donc dans une zone où il convient de faire attention financièrement à ses choix d’architecture.

Mais alors, qu’est-ce que Java EE ? Et doit-on utiliser Java EE lorsqu’on est une entreprise qui a choisi la plate-forme Java ?

Java EE est un ensemble de technologies supplémentaires à celles proposées par Java SE… Heu, pas tout à fait en fait comme indiqué ici :
http://www.oracle.com/technetwork/java/javaee/tech/index-jsp-142185.html

On voit notamment au paragraphe « Java EE-related Specs in Java SE » que Java SE implémente quelques spécifications EE ! Bref, ça reste un peu compliqué.
Une bonne façon de « voir » concrètement ce qu’est Java EE est d’étudier une application Java EE, par exemple YAPS.

Est-ce qu’on doit utiliser Java EE pour développer en Java en entreprise ? En fait c’est en premier lieu la nature de l’application qui guide le choix. Voyons ce que propose Java EE :

  • Web Services Technologies (JAX…)
  • Web Application Technologies (Servlet, JSF…)
  • Enterprise Application Technologies (CDI, EJB…)
  • Management and Security Technologies

Clairement, si on développe une application qui utilise le Web et ses technologies, qui gère des « objets métier » riches, qui implémente des exigences non fonctionnelles sérieuses, Java EE est une solution… Hep ! Pourquoi « une » solution et pas « la » solution ?
C’est « une » solution car c’est la vocation initiale de Java EE. Ce n’est pas « la » solution parce que… Ne serait-ce que parce que personne ne fait comme ça ou qu’avec ça ! Sans aucunement chercher une quelconque polémique (ce qui serait trop facile si on parlait des EJB par exemple !), force est de constater que toute application d’entreprise Java utilise de nombreux frameworks et librairies « non JEE ». Par exemple, les IHM d’applications Java Web ont longtemps été réalisées en grande partie avec Struts, un des framework de la fondation Apache. Par exemple, il y a peu d’applications récentes qui n’utilisent pas Hibernate, qui est dans le giron JBoss/Red Hat. Sans même parler des nombreuses technologies Spring, qui ont donné naissance à la société SpringSource.

Est-ce que toutes ces technologies sont des implémentations de spécifications Java ? Et les SDK JEE par qui sont-ils implémentés ?
Les SDK JEE sont développés par… Je ne sais pas ! Certainement Oracle, mais il y a certainement d’autres contributeurs. A ce sujet il faut se rappeler que Java n’est pas open source !
Les technologies autour de Java ne sont pas des implémentations strictes des spécifications Java car sinon elles seraient… Distribuées par Oracle ? Qui plus est, il est de plus en plus fréquent que les JSR copient/collent des idées apparues dans l’écosystème Java et les « standardisent » quelques années plus tard. Java à la traîne des javaistes ? C’est exactement ça ! Et ça n’a rien de choquant puisqu’il est même plutôt sain que les standards soient éprouvés avant de devenir standards…

Ce qu’on peut retenir c’est que l’écosystème Java est très (très très) riche, que la coopétition entre les pourvoyeurs de technologie y est quotidienne, et que toute plateforme Java d’entreprise (JEE) est constitué d’un assemblage de technologies provenant de sources différentes. Le point commun fédérateur est Java SE, son JRE et son JDK. JEE est plus un réceptacle pour solidifier et standardiser les meilleures pratiques une fois celles-ci prouvées…

Timeline Java

Java et son écosytème large, depuis les années 2000 – Graphique trouvé ici

Un lien utile pour découvrir l’historique JEE :
http://en.wikipedia.org/wiki/Java_EE_version_history