Écrit en juin 2008 Par définition le secteur des nouvelles technologies est en évolution constante, le domaine J2EE en particulier. Les frameworks ont fleurit à tout va ces dernières années. Je propose d'essayer de dresser un bilan ou du moins un état des lieux au moment où J2EE est rebaptisé JEE. Table des matières 1 Petit flashback 1.1 Au début 1.2 La communauté Open Source prend la main 2 Bilan mitigé 3 La réponse de Sun 3.1 Java EE 5 3.1.1 JSF 3.1.2 EJB 3 3.1.3 JPA 4 Conclusion

Petit flashback

Au début

Il est toujours intéressant de brancher la machine à remonter le temps pour mieux comprendre le présent voir même anticiper l'avenir.

Le langage Java a donc plus de 10 ans maintenant. Par-dessus ce langage de base, Sun à rapidement mis en œuvre le nécessaire pour réaliser des développements côté serveur avec les spécifications des JSP et Servlet. A cela se sont ajoutés les EJB.

Ces éléments permettaient déjà à l'époque de répondre aux exigences des applications aussi bien en termes de front (pages JSP, servlet) qu'en termes de persistance de données, transaction, scalabilité (architecture distribuée), sécurité, etc. Sans oublier bien évidement la portabilité (multi plate forme).

La communauté Open Source prend la main

Puis la communauté open source n'a pas attendu Sun pour enrichir le domaine J2EE. Rapidement des frameworks tels que Struts ont fait leur apparition. Ce dernier par exemple a permis d'imposer de façon plus stricte le pattern MVC aujourd'hui incontournable.

J'ai cité Struts mais on peut également citer Tapestry, Wicket, SpringMVC, etc pour la partie Web et bien sûr Hibernate, Ibatis et autres pour la partie mapping objet et persistance de données.

Il est important de préciser que certains frameworks tels que Hibernate ou Spring sont en partie nés d'un reproche fait aux EJB. Ce reproche se résume à une complexité de mise en œuvre et à des problèmes de performance (souvent dus à une mauvaise utilisation des EJB).

Bilan mitigé

Nous voilà donc face à une multitude de frameworks aussi bien sur la partie Web que sur la partie Back. Comment choisir ? La courbe d'apprentissage d'un framework peut être rude, le choix est donc important.

Parfois ce choix est dicté par le client, il va peut être falloir se former seul ou presque en peu de temps, dans la douleur, notre code ne sera pas parfait au début, il va surement falloir revenir dessus par la suite. Tout cela a un coût.

Parallèlement à tout ça, Microsoft propose des outils de plus en plus riches et complets avec un environnement de développement unique. La concurrence commence donc à être rude pour J2EE.

La réponse de Sun

Ces dernières années, Sun a multiplié les événements dans le domaine J2EE.

Plusieurs initiatives importantes :

• La sortie de Java EE 5 (avec beaucoup de simplifications)
• Les Sun Tech Days un peu partout dans le monde
• La sortie d'un concurrent très sérieux de Eclipse (NetBeans 5)
• La sortie de Glassfish (Serveur J2EE de Sun donné à la communauté Open Source)
• Le rachat de MySQL et le renforcement de son outillage

Java EE 5

Il y aurait vraiment beaucoup de choses à dire sur Java EE 5. Je recommande d'ailleurs la lecture de l'ouvrage d'Antonio Goncalves « Java EE 5 ».

On va tout de même essayer de résumer les choses. La démarche de Sun a été simple, elle a consisté à se rapprocher des responsables des frameworks majeurs du marché pour enrichir les standards de Sun. On peut citer par exemple la forte contribution du responsable de Struts à JSF ou celle des contributeurs d'Hibernate à la définition de l'interface JPA pour la persistance.

Java EE 5 embarque les nouveautés majeures suivantes :

• JSF
• EJB 3
• JPA

JSF

JSF constitue la partie web. Son approche est très nouvelle. La courbe d'apprentissage est réputée abrupte car il s'agit de penser autrement mais à mon sens l'effort en vaut la peine.
JSF a notamment été pensé pour être extensible.
On peut voir JSF comme un socle autosuffisant pour réaliser beaucoup de choses élémentaires voir plus pointues sur lequel peuvent se greffer des frameworks ou librairies plus avancées ou plus spécifiques en vue d'un besoin précis.

Voici quelques compléments très intéressants voir incontournables :

• MyFaces
• Seam pour l'intégration des EJB
• Facelets pour encore mieux séparer les métiers de développeur et webdesigner
• Shales pour une gestion avancée des Web flow
• ...

La naissance des ces éléments illustre bien de l'adoption de JSF comme un standard même si la partie n'est pas encore gagnée.

Vous trouverez ici des exemples de ce qu'on peut faire avec Tomahawk de MyFaces (Apache) 

Un autre atout majeur de JSF vient de son association à un IDE tel que NetBeans. Ce dernier permet de développer des pages en mode visuel (voir capture d'écran). La productivité peut être ainsi accrue. Cependant - dans un premier temps - il me semble indispensable de développer sans ces assistants afin de bien s'approprier la technologie JSF.

On sent que Sun a essayé de répondre (à priori efficacement) la concurrence Microsoft en terme d'outillage et de productivité.

EJB 3

Certain disent que Sun aurait du rebaptiser les EJB tellement le changement est énorme. Rebaptiser les EJB aurait peut être aussi permis de reconquérir ceux qui ont assez mal vécu l'utilisation de EJB dans le passé.

Pour résumer, l'utilisation des annotations a engendré la disparition pure est simple des descripteurs de déploiement y compris pour les EJB Entité (Au passage : on conserve les notions d'EJB Entité, Session avec et sans état ainsi que les MDB).

...

@Entity
public class Customer implements java.io.Serializable{

    //access methods for cmp fields
    private String id;
    private String firstName;
    ...

    public Customer(){

    }

    @Id
    @Column(name="customerid") // Nom de la colonne
    public String getCustomerID(){      //primary key
        return id;
    }
    public void setCustomerID(String id){
        this.id=id;
    }

    public String getFirstName(){
        return firstName;
    }
    public void setFirstName(String firstName){
        this.firstName=firstName;
    }

    ...

    @OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER)
    // Description de la relation avec la table "Adress"
    public Collection<Address> getAddresses(){
        return addresses;
    }
    public void setAddresses (Collection<Address> addresses){
        this.addresses=addresses;
    }

    ...

}

...

public class CustomerAppClient {

    @EJB // EJB en variable globale (injectée automatiquement ensuite)
    private static CustomerSessionRemote sess;

    public static void main(String args[]) {
        try {
            String CUSTOMER_ID="99999";

            System.out.println("Searching for customer with id:"+CUSTOMER_ID);
            Customer searchedCustomer= sess.searchForCustomer(CUSTOMER_ID);

            if(searchedCustomer==null){
                throw new Exception("searched customer not found");
            }

            System.out.println("found customer with id:"+CUSTOMER_ID);
            System.out.println("First Name:"+searchedCustomer.getFirstName());
            System.out.println("Last Name:"+searchedCustomer.getLastName());

        } catch(Exception e) {
              e.printStackTrace();
        }
    }
}

Enfin un seul fichier source Java suffit à définir un EJB.

Bref je pense qu'on peut dire que Sun a su redresser la barre pour notre plus grand confort de développement. Là encore les assistants de NetBeans se révèlent précieux.

JPA

JPA et les EJB 3 sont intimement liés dès qu'on utilise des EJB Entité de type CMP.

JPA est une interface élaborée avec la participation des contributeurs d'Hibernate définissant le mapping d'objets avec la base de données.

JPA peut être utilisé avec ou sans les EJB, grâce à cette interface, notre couche de DAO peut reposer sur Hibernate, TopLink (fournit par Oracle à la communauté Open Source) ou autre. Ces implémentations deviennent interchangeables.

Il ne faut cependant pas écarter l'utilisation exclusive d'Hibernate ou autres framework du même type pour des besoins plus précis. JPA ne définit qu'un certain nombre de services de base (assez complets du reste).

Conclusion

Sun a pondu son langage (Le Java) il y a plus de 10 ans, puis un certain nombre d'API (J2EE et autres) pour simplifier la vie des développeurs. Mais le cadre est resté vague. Donc les frameworks sont nés.

Sun a joué la belle au bois dormant pas mal de temps puis s'est enfin réveillé il y a environ 2 ans en sortant Java EE 5, NetBeans 5 et Glassfish. Java EE 5 proposant plus de simplicité (annotations, EJB3, moins de XML, ...) et un meilleur cadre pour la couche présentation avec JSF. Et évidement Glassfish, car il ne fallait pas trop compter sur JBoss, BEA et encore moins sur Websphere pour être Java EE 5 compliant aussi vite.

Bref, j'ai l'impression que Sun essaye de poser des rails. Evidement ça ne se fait pas en un clin d'œil et d'ailleurs personne n'a vraiment osé se jeter dans le bain Java 5 dès sa sortie même si tout le monde s'accorde à dire que ça apporte plus de simplicité. Les EJB 3 me semblent être une bonne illustration du progrès.

Pour conclure comme le dit Antonio Goncalves (auteur du bouquin Java EE 5 chez Eyrolles) dans son article intitulé « Why are we not using Java EE 5? » je pense que grâce à cet effort de Sun on peut dire aujourd'hui qu'il est plus simple et plus « standard » de réaliser une application reposant sur du « Sun essential » JSF/EJB3/JPA que sur Struts/Spring/Hibernate.