Un stateless bean peut avoir une interface distante et/ou locale. L’inter-face distante (@javax.ejb.Remote) permet aux clients distants d’invoquer des méthodes de l’EJB. Les paramètres des méthodes sont ainsi copiés, sérialisés, puis transmis à l’EJB. On appelle ce mécanisme l’appel par valeur (call-by-value).
L’interface locale (@javax.ejb.Local) est utilisée par les objets résidants dans la même JVM que l’EJB. Les paramètres des méthodes ne sont pas recopiés mais passés par référence (call-by-reference).
JAVA Passage par valeur et référence Le passage de paramètres en local dans Java se fait presque toujours par référence. Seul un poin-teur (référence) vers un objet est passé à la méthode. Par contre, les données de type primitif (byte, short, char...) sont passées par valeur, c’est-à-dire qu’une copie de la donnée est mise à dispo-sition de la méthode et non l’originale.
5 – Traitements mét
La plupart de nos stateless session beans utilisent les deux interfaces. En effet, l’application YAPS Pet Store est constituée d’une interface graphique de type client lourd (Swing), utilisée par les employés et qui s’appuiera sur les interfaces @Remote, ainsi qu’une application web, hébergée sur le même serveur que les EJB, qui, quant à elle, utilisera les interfaces @Local. Les deux interfaces peuvent exposer des méthodes différentes.
Interface distante
L’interface distante définit les méthodes de l’EJB accessibles en dehors du conteneur (application Swing utilisée par l’employé). Cette interface est annotée par @javax.ejb.Remote.
Reprenons l’exemple du CustomerBean. Ci-après le code de l’interface
CustomerRemote: Interface distante
Comme vous pouvez le constater, cette interface ressemble de très près à n’importe quelle interface Java. La seule différence est la présence de l’annotation @javax.ejb.Remote qui informe le conteneur que cette interface peut être appelée de manière distante.
Les paramètres des méthodes distantes doivent être sérialisables pour être véhiculés à travers le réseau. Rappelez-vous que les entity beans que nous avons développés implémentent l’interface Serializable.
@Remote
public interface CustomerRemote {
Customer createCustomer(Customer customer, Address homeAddress) ; }
EJB Interface distante dans un cluster On utilise un cluster (groupe d’ordinateurs vu comme une seule machine) pour des raisons de performance, de répartition de charge, ou de tolé-rance aux pannes. Dans ce cas, il est nécessaire d’utiliser des interfaces distantes pour que les EJB puissent communiquer entre eux dans le cluster.
EJB RemoteException
Contrairement aux EJB 2.1, les méthodes n’ont pas besoin de lancer l’exception java.rmi.
RemoteException. Il est toujours possible de le faire, mais ce n’est plus obligatoire depuis la version 3.0 des EJB.
EJB Les stateless beans 2.x Pour vous faire une idée des modifications appor-tées à la spécification EJB, retrouvez en annexe le code source d’un stateless bean 2.1.
Code de l’annotation @javax.ejb.Remote package javax.ejb;
@Target({TYPE}) @Retention(RUNTIME) 3 Cette annotation s’applique à une classe.
public @interface Remote { Class[] value() default {};
}
3 Spécifie la liste des interfaces distantes sous forme de tableau de classes. Cet attribut est uti-lisé si la classe du bean implémente plus d’une interface distante.
Les Cahiers du Programmeur Java E
Interface locale
L’interface locale définit les méthodes accessibles à l’intérieur du serveur d’applications, c’est-à-dire par d’autres EJB ou applications web héber-gées sur le même serveur. Cette interface permet les appels locaux sans rajouter de surcoût lié à la sérialisation des paramètres qui devient alors inutile. Cette interface est identifiée par l’annotation @javax.ejb.Local. Ci-après, l’interface CustomerLocal définissant la même méthode pour créer un client.
Interface locale
DTO : design pattern ou anti-pattern
Aussi connu sous le nom de Value Object (VO), le design pattern Data Transfert Object permet de transporter des données du client au serveur et inversement en réduisant les appels réseaux. Ce design pattern est communément utilisé dans les architectures EJB 2.x. En effet, les entity beans étant représentés par des composants riches (heavyweight) – rappelez-vous les interfaces javax.ejb.EJBLocalHome ou javax.ejb.
EJBLocalObject– il est pénalisant de les manipuler en dehors du con-teneur (multiplication des appels distants). Les objets DTO, composés uniquement d’attributs et d’accesseurs, collectent des données de plu-sieurs entity beans pour en obtenir une vision uniforme et permettre leur manipulation par des stateless beans. Dépourvus d’accès à des res-sources externes, de logique métier, ou de persistance, ces DTO sont chargés à partir des attributs des entity beans, puis transmis au client pour enfin revenir au serveur. Ainsi, avec un seul appel distant, on obtient un DTO qui contient toutes les informations souhaitées.
Ce design pattern peut maintenant être vu comme un anti-pattern dans l’architecture EJB 3 si utilisé constamment. Comme nous l’avons vu, un entity bean est maintenant une simple classe Java et peut être facile-ment manipulé comme tel. De plus, comme nous allons le voir, les entity beans peuvent être détachés de leur gestionnaire de persistance pour traverser les différentes couches de l’application et, être vus comme de simples Pojo.
Bien entendu, le design pattern DTO peut toujours être utilisé dans cer-tains cas. Il n’est plus une pièce indispensable de l’architecture, mais tout simplement une solution supplémentaire utilisable dans une situa-tion particulière.
@Local
public interface CustomerLocal {
Customer createCustomer(Customer customer, Address homeAddress) ; }
APPROFONDIR Que signifie locale ? Bien que nous n’ayons pas encore vu le déploie-ment de l’application, la notion d’interface locale est fortement liée à ce processus. L’application YAPS Pet Store va être déployée dans un fichier ear (Enterprise Archive) qui contient tous les com-posants de l’application (EJB, application web, entity bean...). L’interface locale d’un EJB est visible et utilisable à l’intérieur de ce fichier ear. Si on déploie deux applications sur le même serveur (A.ear et B.ear), l’interface locale d’un EJB dans A ne pourra pas être vu par un EJB dans B. La visibilité n’est donc pas directement liée au serveur d’applications mais à l’Enterprise Archive (ear).
5 – Traitements mét
Comme vous pouvez le constater, le code est identique à celui de l’inter-face distante. La seule différence réside dans l’utilisation de l’annotation
@Local au lieu de @Remote.