Patterns J2EE / EJB

Date de publication : 01/02/2003 , Date de mise a jour : 14/03/2005

Par Christophe Ludet (home)
 

Patterns J2EE / EJB
Ou comment donner des ailes à votre application

Introduction

1. Le modèle de données

• 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ée ! 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.

• 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.È

2. Accéder à la base de donnée

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

3. Local et Remote Interfaces

• Son interface Remote, ou distante
• Son interface Locale !

Deux points importants à saisir :

• 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.

4. Session Façade

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

5. Value Objects

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);
	}
}

• Les variables doivent être déclarée public
• 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é par le container pour retrouver un EJB dans son cache, et nous l'utiliserons pour notre propre cache.

L'utilisation d'un VO va considérablement soulager notre EJB container et notre BD, mais ce soulagement se fait a un prix : un VO n'est qu'une image figée de votre entité, c'est a dire qu'un client peut se trouver en possession d'un VO dont les valeurs ont déjà expiré. Nous allons voir plus tard comment se débarrasser de cette limitation.

6. Service Locator

De façon générale, dans une application distribuée ou multi-threadée, l'utilisation du Singleton pattern doit se faire avec prudence. Le piège du pattern Singleton, c'est qu'à l'évidence, il n'est pas inter-jvm. Dans notre cas, ce cas est tout a fait acceptable et même approprié. Chaque client aura son propre Service Locator Singleton.

7. Business Delegate

• 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 servlet 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.

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.");
		}
	}
}

8. External SC VO Cache

public VO getObject(Key key) ;

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.");
		}
	}
}

1. Limiter la taille de notre cache.
2. S'assurer que le cache est toujours a jour.

invalidate(Key key) :void

Ce système d'invalidation ne vous protège pas des accès directs à la BD, via un client SQL par exemple, ou toute autre application. La plupart des BD offrent l'accès exclusif par une application, c'est une solution. Ou, si plusieurs applications accèdent la même BD en même temps, il est impératif de construire une couche supplémentaire (par un Observer pattern par exemple), ou désactiver tout système de cache, celui de votre SC, et celui de votre EJB container. Ce problème est toujours vrai si vous utilisez un quelconque cache.

Ce système de cache à un coût. Celui d'envoyer des messages JMS à chaque mise à jour. Ce coût, comme souvent, peut devenir insignifiant si le nombre de requêtes excède le nombre de mises à jour. Il est possible d'étendre plus loin notre système de cache, et aller jusqu'a cacher des collections de VO, par exemple des collections de POST. Pourquoi ne pas mettre en cache la collection de 10 ou 15 POSTs que nous voulons afficher par défaut sur la première page de notre forum. Cette page est typiquement appelée de nombreuses fois, c'est autant de fois que nous allègerons notre BD, pour lui laisser les choses qu'elle seule sait si bien faire, comme un moteur de recherche par exemple.

9. L'architecture

Références

• www.developpez.com, Le meilleur site francophone pour développeurs.
• Design Patterns, by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.
• Mastering Enterprise JavaBeans (2nd Edition) by Ed Roman (Author), Scott W. Ambler (Author), Tyler Jewell (Author)
• http://java.sun.com/blueprints/patterns/catalog.html, pour une liste de Patterns J2EE.