GWT - Hibernate et les RequestFactory

Il s'agit probablement de la solution la plus souvent implémentée à ce jour dans les applications GWT/Hibernate. C'est également la plus facile à définir et à mettre en place. Ce pattern d'architecture consiste à définir de nouveaux objets (appelés objets de transfert) qui sont de simples POJO. Ils ne sont pas instrumentés, ne contiennent pas d'intelligence mais seulement les données qui doivent êtres échangées entre le client et le serveur. Il est donc très facile de les rendre sérialisables afin qu'ils deviennent éligibles au transfert via des appels de services RPC.

Souvent, les données présentent dans un DTO correspondant exactement aux données affichées à l'écran ou sur une partie de l'écran. Les DTO peuvent avoir la même structure que les objets persistés mais ce n'est pas nécessairement le cas. La représentation des objets en base de données n'est pas toujours adaptée à une utilisation côté client.

La création et l'alimentation des DTO sont en général faites de manière manuelle et restent à la charge du développeur. Cependant, il est possible d'utiliser des frameworks de mapping Objet/Objet qui permettent de définir au moyen d'un fichier de configuration XML des couples d'attributs qui doivent être mappés l'un sur l'autre. Le framework de ce type le plus connu est Dozer. Attention toutefois, dans certains cas l'usage de tels framework peut s'avérer être une mauvaise idée. Si par exemple, les DTO contiennent beaucoup de valeurs calculées ou si les types des attributs sont souvent différents entre les DTO et les objets persistés, la définition d'un tel mapping bien que toujours possible, peut être lourde à mettre en place et difficile à maintenir.

La solution Gilead est présentée ici pour alimenter la discussion technique mais ce framework n'est pas une option d'avenir car il n'est plus maintenu. La dernière version (1.3.1), vieille d'un peu plus de deux ans, supporte les annotations JPA2, Hibernate 3.5 et GWT 2.0.

La solution consiste, contrairement au pattern DTO, à rendre sérialisables les entités persistantes sans définir de nouveaux objets. Pour cela, Gilead parcourt les graphes d'objets et remplace les proxys Hibernate non sérialisables par des références null et les implémentations spécifiques Hibernate (e.g. PersistentSet) par des implémentations issues de JavaSE.

La plus-value apportée par le framework est sa capacité à stocker (soit côté serveur, soit dans les objets eux-mêmes) les métadonnées nécessaires à la reconstruction des graphes d'objets Hibernate. De cette manière, un objet persisté envoyé puis modifié côté client pourra sans problème être rattaché à une session Hibernate à son retour côté serveur.

Sa mise en œuvre est plutôt simple. Elle se résume en trois points :

• les entités persistantes doivent hériter de la classe LightEntity ;
• les classes d'implémentation RPC doivent hériter de PersistentRemoteService ;
• le PersistentBeanManager de Gilead doit être initialisé.

Il n'y a que quelques lignes de code ou de configuration à écrire pour mettre en place le mécanisme qui s'exécute ensuite de manière transparente.

Comme annoncé en introduction, ce projet est au point mort. L'arrêt de la maintenance est intervenu à peu près au moment de l'arrivée d'une nouveauté dans GWT : Les RequestFactory.

Les RequestFactory sont apparues dans la version 2.1 de GWT. Elles ont été introduites pour répondre à la problématique dont il est ici question.

Les RequestFactory vont nous permettre de faire transiter sur le réseau les données contenues dans des objets non sérialisables. Comme son nom l'indique, le but d'une RequestFactory est de créer des requêtes. Pour cela, une API plutôt minimaliste fournit une sorte de builder permettant de construire une requête HTTP qui sera plus tard envoyée en POST au serveur.

Le corps de cette requête est une chaîne de caractères au format JSON dans laquelle on trouve principalement les informations suivantes :

• les données d'identification du service à invoquer côté serveur ;
• les paramètres d'appel du service ;
• les noms des propriétés correspondant aux relations qui devront être transmises côté client.

Côté serveur, le traitement de cette requête va être délégué à une RequestFactoryServlet. Celle-ci se charge de parser la requête, d'effectuer l'appel de service, puis de sérialiser le résultat dans la réponse envoyée au client.

Par opposition au mécanisme RPC qui offre une vision service, les RequestFactory offrent une vision requête. Nous verrons d'ailleurs plus tard dans un exemple que l'envoi des requêtes devra être codé explicitement par le développeur, ce qui est totalement transparent dans le cas d'un appel RPC.

Il y a tout de même un point commun entre les deux approches, dans les deux cas les appels serveur sont faits de manière asynchrone. Là où en RPC on utilise un AsyncCallback pour traiter le retour de l'appel, on utilisera un Receiver avec les RequestFactory.

On lit souvent que les RequestFactory sont orientées ressources par opposition au mécanisme RPC qui est orienté services. Je ne serais pas si catégorique. Effectivement, initialement les RequestFactory étaient destinées à faciliter les opérations CRUD sur des entités persistantes dans le cadre d'une architecture orientée ressources. Cependant, il n'y aucun inconvénient à les utiliser pour effectuer tout type d'appel de service.

Passons maintenant à un exemple de mise en œuvre au travers d'un cas concret. L'exemple qui va suivre n'a pas vocation à être exhaustif mais simplement à mettre en avant les principales caractéristiques des RequestFactory.

Soit le domaine métier ci-dessous. Il s'agit d'un simple annuaire dans lequel une personne peut avoir plusieurs adresses.

Nous avons deux entités reliées par une relation qui sera déclarée Lazy. Il s'agit du cas le plus simple nous permettant de mettre en œuvre les RequestFactory de manière non triviale.

Ci-dessous le code des entités côté serveur (allégé des getters et setters ainsi que des méthodes equals et hashcode).

Interface PersonProxy

@ProxyFor(Person.class)
public interface PersonProxy extends EntityProxy {
    public int getId();
    public void setId(int id);
    public String getFirstname();
    public void setFirstname(String firstname);
    public String getLastname();
    public void setLastname(String lastname);
    public String getPhone();
    public void setPhone(String phone);
    public String getEmail();
    public void setEmail(String email);
    public Set<AddressProxy> getAddresses();
    public void setAddresses(Set<AddressProxy> addresses);
}

Interface AddressProxy

@ProxyFor(Address.class)
public interface AddressProxy extends EntityProxy {
    public int getId();
    public void setId(int id);
    public String getLine1();
    public void setLine1(String line1);
    public String getLine2();
    public void setLine2(String line2);
    public String getZipcode();
    public void setZipcode(String zipcode);
    public String getCity();
    public void setCity(String city);
    public String getState();
    public void setState(String state);
    public String getCountry();
    public void setCountry(String country);
}

Nous allons ensuite définir la fameuse RequestFactory. Elle est unique pour toute l'application. Il s'agit d'une interface qui étend RequestFactory et qui contient des méthodes renvoyant des stubs des interfaces de services. Dans notre cas, nous aurons une seule interface de service.

La RequestFactory de l'application

public interface AddressBookResquestFactory extends RequestFactory {
 
    PersonRequest personResquest();
 
}

L'interface de service étend RequestContext. Elle est annotée de manière à définir la classe d'implémentation des services. Cette classe peut être l'entité elle-même. C'est la solution la plus simple, c'est celle que nous allons mettre en place ici. La classe d'implémentation peut aussi être une classe DAO dédiée en définissant un ServiceLocator. Ce point ne sera pas abordé ici.

L'interface va comporter deux services :

• pour lire un objet Person par son nom et prénom ;
• pour sauvegarder ou mettre à jour en base de données un objet Person.

Interface de services PersonRequest

@Service(Person.class)
public interface PersonRequest extends RequestContext {
 
    Request<PersonProxy> read(String firstname, String lastname);
 
    Request<Void> saveOrUpdate(PersonProxy person);
 
}

Comme vu précédemment, ces services sont implémentés directement dans l'entité Person.

public static Person read(String firstname, String lastname) {
    // lecture de la personne sans ses adresses
}
 
public static void saveOrUpdate(Person person) {
    // Mise à jour de la personne
}

En réalité, l'entité n'implémente pas l'interface au sens strict, mais la classe d'implémentation doit être en phase avec l'interface. On constate que les méthodes de l'interface PersonRequest renvoient des objets de type Request paramétrés par le type de retour effectif des méthodes implémentées côté serveur.

N.B. Le plugin Eclipse de développement GWT détecte les incohérences entre les interfaces RequestContext et leurs implémentations.

Par ailleurs, les méthodes d'implémentation sont déclarées statiques car elles ne s'appliquent pas à une instance en particulier. Il est en revanche possible de définir des méthodes d'instances lorsque cela a du sens. Le cas typique est la définition d'opérations CRUD.

Côté serveur, il reste à déclarer dans le descripteur de déploiement de l'application Web, la servlet qui va traiter les requêtes.

<servlet>
    <servlet-name>requestFactoryServlet</servlet-name>
    <servlet-class>com.google.web.bindery.requestfactory.server.RequestFactoryServlet</servlet-class>
</servlet>
 
<servlet-mapping>
    <servlet-name>requestFactoryServlet</servlet-name>
    <url-pattern>/gwtRequest</url-pattern>
</servlet-mapping>

Afin que le client GWT puisse utiliser la RequestFactory, nous devons ajouter une ligne de déclaration dans son descripteur de module.

<inherits name='com.google.web.bindery.requestfactory.RequestFactory' />

Le client peut maintenant instancier la RequestFactory et l'initialiser en lui passant en paramètre l'EventBus de l'application.

AddressBookResquestFactory requestFactory = GWT.create(AddressBookResquestFactory.class);
requestFactory.initialize(new SimpleEventBus());

III-C-1. Envoyer une requête de lecture▲

Request<PersonProxy> req =
   requestFactory
       .personResquest()
       .read("Barack", "Obama");

req.fire(new Receiver<PersonProxy>() {
    @Override
    public void onSuccess(PersonProxy person) {
        ...
    }
});

Request<PersonProxy> req =
   requestFactory
       .personResquest()
       .read("Barack", "Obama")
       .with("addresses");

III-C-2. Modifier des entités côté client▲

PersonProxy person = ...
PersonRequest editRequest = requestFactory.personResquest();
person = editRequest.edit(person);

editRequest.saveOrUpdate(person).fire(new Receiver<Void>() {
    @Override
    public void onSuccess(Void response) {
        ...
    }
});