Patterns J2EE / EJB

Nous allons utiliser une base de données (BD) pour stocker les messages postés par les gentils utilisateurs. Dans un monde idéal :

• le design de votre application devrait être construit avant celui de votre BD. Cependant, d’expérience, c’est peu souvent le cas. Il faut donc pouvoir s’adapter ;
• vous avez un administrateur de BD (DBA) à votre disposition. Ne supposez pas parce que vous connaissez SQL que vous savez administrer une base de données ! Si vous dirigez une équipe, j’insiste sur la nécessité d’engager un DBA au moins à titre temporaire, et ne lésinez pas sur les séminaires d’une semaine proposés par les vendeurs de BD. Ceci étant dit, je ne m’étendrai pas sur l’optimisation de la BD. Ma vue est celle du développeur qui connaît SQL.

Notre forum sera amplement plus simple et moins sophistiqué que celui de www.developpez.com, il ne contient que deux types d’objets :

• POST. Un Post est un message ;
• FORUM. Un Forum est un regroupement de Posts. Nous aurons plusieurs forums, par exemple l’un qui s’appelle JAVA et l’autre J2EE.

Le modèle présenté est une façon simple de représenter notre système. Nous avons une relation one-to-many entre POST et FORUM, ce qui signifie qu’un FORUM peut contenir plusieurs POSTs. Un POST a un POST parent, c’est notre façon de représenter un fil (suite de POSTs).

L’un des énormes avantages d’utiliser J2EE est la possibilité d’acheter une partie de son système plutôt qu’avoir à le construire soi-même. Il existe deux moyens de réaliser la persistance en utilisant les EJB.

• Bean Managed Persistence : le développeur doit coder la persistance.
• Container Managed Persistence : le container gère la persistance.

La seconde solution (CMP) offre de nombreux avantages, en particulier portabilité, rapidité de développement, performance et robustesse. Préférez-les autant que possible.

Il existe deux moyens d’accéder à un EJB, en utilisant :

• son interface Remote, ou distante ;
• son interface Locale.

• l’utilisation de l’interface distante implique la sérialisation et RMI, donc le passage d’objets au travers du réseau. L’utilisation de l’interface locale est directe, donc beaucoup plus rapide. Limiter le nombre d’appels distants est un facteur important pour la performance de votre système ;
• lors d’un appel distant, les paramètres sont passés par valeur, la référence n’ayant aucun sens dans ce cas. Lors d’un appel local, les paramètres sont passés par référence. Des comportements différents existent donc entre les deux appels. Gardez ceci en tête.

Voici sans doute le pattern J2EE le plus utilisé. Le problème est le suivant : chaque appel distant est coûteux, il faut trouver un moyen de les limiter. Une Session Façade est une session bean qui a accès aux interfaces locales d’autres beans (parce qu’ils vivent dans la même JVM). Un appel à une méthode d’un Session Façade entraîne généralement plusieurs appels vers un ou plusieurs autres beans.

Supposons par exemple le cas suivant : un modérateur veut déplacer un fil (série de POSTs) d’un FORUM vers un autre.

Nous avons ces étapes :

1. Trouver le premier POST du fil à déplacer ;
2. Trouver tous les POSTs qui suivent le fil ;
3. Déplacer chacun des POSTs.

Le modérateur ne veut se soucier que du fait qu’il déplace un fil. Notre Session Façade va posséder la méthode deplaceFile qui prend comme argument l’identifiant d’un POST.

Le réseau se trouve entre le serveur WEB (Servlet Container, ou SC) et la Façade. Les appels entre Façade et POST CMP sont locaux. Notre opération ne requiert qu’un seul appel distant, quel que soit le nombre de POSTs à déplacer.

De façon générale, c’est un bon exercice de ne pas générer d’interfaces distantes pour ses EJB persistants. En d’autres termes, une façade porte bien son nom, un mur entre application et persistance.

Notre façade pourrait faire tout un tas d’autres choses, comme vérifier l’autorisation de l’utilisateur qui a instancié la requête. Une façade peut aussi appeler d’autres Session Beans ou Message Driven Beans. La leçon à retenir étant qu’il faut limiter le nombre d’appels distants.

Le Session Façade Pattern présenté plus haut implique un challenge supplémentaire. Puisque nous n’avons pas de référence directe à notre objet persistant, comment allons-nous lire le contenu d’un objet ? Heureusement, cette limitation à une solution très simple, et qui ajoute même de nombreuses possibilités d’amélioration. Le Value Object n’est autre qu’un objet qui offre une vue figée de notre entité à un moment donné. Voyons un exemple de code :

import java.io.Serializable;
import java.util.Date;
public class PostVO implements Serializable{
    private Long postID;
    private String posterName;
    private Long parentPostID;
    private Date postDate;
    private String messageContent;
    private Long forumID;
    
    public PostVO(Long postID,
            String posterName,
            Long parentPostID,
            Date postDate,
            String messageContent,
            Long forumID){
        this.postID = postID;
        this.posterName = posterName;
        this.parentPostID = parentPostID;
        this.postDate = postDate;
        this.messageContent = messageContent; 
        this.forumID = forumID;
    }
    
    public Long getPostID(){
        return postID;
    }
    public String getPosterName(){
        return posterName;
    }
    public Long getParentPostID(){
        return parentPostID;
    }
    public Date getPostDate(){
        return postDate;
    }
    public String getMessageContent(){
        return messageContent;
    }
    public Long  getForumID(){
        return forumID;
    }
    public Key getKey(){
        return new PostKey(postID);
    }
}

Le mot-clef ici est Serializable. En effet, ce Value Object (VO) est l’objet auquel nous ferons traverser le réseau. Il est donc nécessaire que l’objet et tous ses membres soient « Serializable ». Grâce au VO, nous pouvons accéder aux membres de notre entité sans faire d’appels répétés à notre EJB persistant.

Un EJB persistant utilise une clef primaire pour identifier une entité, notre VO va utiliser cette même clef pour s’identifier. Une clef primaire pour un EJB a des règles strictes à suivre, dont :

• les variables doivent être déclarées publiques ;
• hashcode et equals doivent être implémentées pour optimiser les recherches. Dans notre cas, leurs implémentations sont triviales et appellent les méthodes de la classe Long. Plus généralement, hashcode() va être utilisée par le container pour retrouver un EJB dans son cache, et nous l’utiliserons pour notre propre cache.

Notre exemple de code est légèrement simplifié, nous verrons plus tard qu’une bonne idée est pour un VO d’implémenter une interface (par exemple nommée VO) qui ne définit aucune méthode ni variable. Nous verrons qu’un VO est un excellent candidat pour être mis en cache et ainsi démultiplier nos performances. Mais avant ça, il nous reste deux trois points à voir afin de rendre notre application plus solide.

Le client, quel qu’il soit, GUI, Servlet container (SC) ou autre a besoin d’un moyen de localiser les objets distants, en l’occurrence notre Session Façade. Le service de nommage couramment utilisé avec J2EE est JNDI, la méthode à suivre est simple et supposée connue. Malgré tout, dans le but de rendre notre système flexible et réutilisable, nous définissons un Service Locator, dont le seul but est de servir au client des Home interfaces, par exemple en implémentant un pool. Notre service locator est simple et n’implémente qu’une seule méthode : getPostFacade() : PostFacade.

Un Service Locator est un bon candidat pour le Singleton Pattern.

En voilà un joli nom, n’est-ce pas ? Pas de panique, ce pattern n’est autre qu’une adaptation du pattern Wrapper (ou Adapter) bien connu, appliqué au modèle J2EE. Son but est multiple :

• se débarrasser de la dépendance du client pour J2EE. J2EE offre les bases nécessaires pour séparer le client du serveur. Complètement. Dès lors, un « import javax.ejb.* » dans une servlet est malvenu. Pourquoi ? Parce que le développeur de votre EJB peut changer certaines signatures de méthodes à tout moment. Cela veut-il dire que chacune de vos servlets doit être mise à jour ? Le Business Delegate va nous permettre de regrouper en un seul endroit tous les appels distants ;
• transformer les exceptions génériques en exceptions propres à votre application ;
• proposer des méthodes spécifiques à votre client ;
• exécuter des portions de code nécessaires à chaque appel distant. Patience, nous irons plus en détail lorsque nous expliquerons notre principe de cache.

Voici un exemple d’implémentation de méthode dans notre Delegate :

public class Delegate{
    public PostVO findPost(long postID) throws ApplicationException{
        try{
            
            // On va commencer par regarder dans le cache ici
            // nous verrons ca plus loin
            
            PostFacade facade = ServiceLocator.getPostFacade();
            return facade.findByPostID(new Long(postID));
        }catch(javax.ejb.FinderException ex){
            Log.log(severity, ex.getMessage());
            throw new ApplicationException("Post introuvable.");
        }
    }
}

La méthode nous retourne le Value Object (VO) dont nous avons parlé plus haut. Elle s’occupe de chercher le cache, loguer les erreurs et transformer l’exception en quelque chose d’acceptable pour notre client. Une servlet par exemple peut maintenant appeler cette fonction et ne jamais savoir tout ce qui se passe derrière le rideau.

Ce type d’architecture permet de définir efficacement les rôles dans une équipe, un développeur pour les EJB, un pour les servlets. Utilisez ce pattern sans modération !

À ce stade du design, nous avons un système solide, portable, robuste et flexible. Que demande le peuple ? La performance. Ou comment donner des ailes à cette belle application. La solution n’est pas nouvelle : utiliser un cache. Cela repose sur un fondement simple : la mémoire ne coûte pas cher. Ajouter une barrette de mémoire à votre machine peut diviser par 10 ou 100 le nombre d’appels via JDBC, suivant le type d’application, et d’expérience, une proportion non négligeable des problèmes de performance est due aux très chers appels à la BD.

Prenez un cas typique d’application où à chaque visite sur votre site Web, un utilisateur engendre 10 appels à la base de données. Au fur et à mesure que votre site se popularise, lorsque le nombre d’utilisateurs est multiplié par 10, le nombre d’appels à la BD est multiplié par 100. À ce rythme, ajouter une machine à votre île de BD n’est qu’une solution très temporaire, même s’il est vrai que la BD elle-même a son propre système de cache.

Notre solution consiste à installer un système de cache au niveau de notre Servlet Container (SC). Maintenant, lorsque le nombre d’utilisateurs est multiplié par 2, ajoutez un SC. Les SC sont peu chers, beaucoup moins que les BD ou les EJB containers. Nous n’utiliserons nos EJB que si le résultat attendu n’est pas dans le cache. Il est possible que votre vendeur propose déjà ce service, auquel cas, il ne vous est pas nécessaire de l’implémenter.

Que contient le cache ? Le cache peut être aussi simple qu’une Hashtable dont la clef est la clef du VO (Key). Le cache implémente le pattern Singleton (voir remarque plus haut).

Nous avons déjà vu brièvement que chaque Value Object devrait implémenter l’interface VO, et chaque Key (comme PostKey) devrait implémenter l’interface Key. Cela va nous permettre de définir la méthode suivante dans notre cache :

public VO getObject(Key key) ;

Une fois cette méthode implémentée, c’est le moment de la référencer dans notre Business Delegate.

Réécrivons notre Business Delegate de la sorte :

pblic class Delegate{
    public PostVO findPost(long postID) throws ApplicationException{
        try{
            
            VOCache cache = VOCache.getInstance();
            
            PostVO vo = cacahe.getObject(new PostKey(postID));
            if(vo == null){ // l'objet n'est pas en cache
                PostFacade facade = ServiceLocator.getPostFacade();
                vo = facade.findByPostID(new Long(postID));
                cache.put(new postKey(postID), vo);
            }
            
            return vo;
        }catch(javax.ejb.FinderException ex){
            Log.log(severity, ex.getMessage());
            throw new ApplicationException("Post introuvable.");
        }
    }
}

Et voilà, il ne nous reste plus que deux détails à régler :

1. Limiter la taille de notre cache ;
2. S’assurer que le cache est toujours à jour.

Limiter la taille de notre cache consiste à utiliser une version améliorée de Hashtable, qui se débarrasse des objets qui n’ont pas servi depuis longtemps, au profit de nouveaux objets. La technique ici est largement variable, et dépend grandement de votre application. Par exemple, faites le ménage à chaque fois que la limite supérieure de taille est atteinte. Ou bien implémenter un système de compteur pour se débarrasser des objets les moins usités.

Plus délicat est le problème de s’assurer qu’il n’existe pas d’objets invalides dans notre cache. Et voici le challenge : notre cache est sur un SC, distant de notre EJB container. L'EJB n’a aucun moyen d’appeler une méthode sur notre SC. Qu’à cela ne tienne. Nous allons utiliser JMS pour réduire ce problème à néant. Définissons un Topic dans notre EJB container. L'EJB persistant va jouer le rôle du Publisher et placer des messages sur ce Topic à chaque fois qu’il réalise un update (voir spec. EJB).

Notre cache, il va s’inscrire comme Listener de ce Topic et recevoir des messages d’invalidation, qui, vous l’avez compris contiennent la clef de l’objet à invalider. Le cache définit la méthode suivante :

invalidate(Key key) :void

Il ne fait rien d’autre que d’enlever l’objet de notre cache.