Explication sur les interfaces locales.

Version imprimable

13/05/2008, 20h33
rteuteu55

Explication sur les interfaces locales.

Bonsoir,

Je souhaite comprendre quel et la zone que l'on appelle locale pour les ejbs.
En effet, j'ai réalisé 2 ejbs de test (1 ejb session et un ejb entité).

Mon ejb session appel mon ejb entité via son interface locale. J'ai mis ça dans un même répertoire, un même jar avec les fichiers xml qui correspondent et tout marche.

J'ai alors entrepris de séparer mes 2 ejb dans 2 jar différents. Mais la impossible de refaire marcher mon lien.

Je me demande donc si 'interface local' signifie le jar (ou l'ear), ou si l'on peut appeler une interfaces locale depuis un bean déployer (grâce à un autre jar) sur le même container ?
14/05/2008, 11h30
rteuteu55

Peut - être ai-je mal exprimé mon problème ? ou celui - ci est-il plus pointu que je ne le pense ! j'ai également posté sur le forum de sun mais j'ai le semtinent qu'aucun retour viable ne me sera fait sur leur forum ...
14/05/2008, 11h48
fr1man

Pour moi, local signifie dans la même JVM.
Tu peux donc avoir plusieurs ejbs déployés dans des jars différents sur le même serveur d'application et utiliser leurs interfaces locales.
14/05/2008, 14h40
phantomass

Citation:

Envoyé par fr1man

Pour moi, local signifie dans la même JVM.
Tu peux donc avoir plusieurs ejbs déployés dans des jars différents sur le même serveur d'application et utiliser leurs interfaces locales.

A condition qu'il soit dans le même EAR
14/05/2008, 15h04
fr1man

Citation:

A condition qu'il soit dans le même EAR

Je ne pense pas.
Tu peux très bien avoir plusieurs EJB déployés sous forme de JAR au sein du même serveur et utiliser les interfaces locales.
14/05/2008, 16h54
rteuteu55

Citation:

Je ne pense pas.
Tu peux très bien avoir plusieurs EJB déployés sous forme de JAR au sein du même serveur et utiliser les interfaces locales.

dans ce cas je veux bien que tu m'explique un peut plus !!
14/05/2008, 17h06
fr1man
Qu'est ce qui te bloque ?
L'accès à l'interface local ou remote n'est qu'une question de parametrage de lookup JNDI ou d'annotations.

J'ai une petite application packagée en war qui utilise des servlets.
Ces servlets appellent mon ejb, déployé en jar sur le même serveur d'application, de la manière suivante:
Code:

1 2 PersonneServiceLocal personneService = (PersonneServiceLocal)ctx.lookup("PersonneServiceBean/local");
14/05/2008, 18h18
rteuteu55

tu utilise : ("PersonneServiceBean/local"), le /local m'intrigue !

Dans l'état actuel, j'ai une erreur : cannot create container. Voila mon ejb-jar :

Citation:

<?xml version="1.0" encoding="ISO-8859-15" ?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd" version="2.1">
<display-name>lesbeans</display-name>
<enterprise-beans>
<session>
<display-name>lesbeans/IdentitySFR</display-name>
<ejb-name>IdentitySFR</ejb-name>
<home>org.beans.identity.IdentityHome</home>
<remote>org.beans.identity.Identity</remote>
<ejb-class>org.beans.identity.IdentitySFR</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Container</transaction-type>
<ejb-local-ref>
<ejb-ref-name>ejb/ident</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<local-home>org.beans.identity.IdEntLocalHome</local-home>
<local>org.beans.identity.IdEntLocal</local>
<ejb-link>IdentityEntity.jar#IdEntEC2L</ejb-link> 
</ejb-local-ref>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>IdentitySFR</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>

et l'appel de mon ejb entité depuis mon ejb session :

Citation:

try {
Context ictx = new InitialContext();
idEntLocalHome = (IdEntLocalHome) ictx.lookup("IdEntLocalHome");
System.out.println("IdentitySFR : lookup IdEntLocalHome ok");
} catch (NamingException e) {
System.out.println("IdentitySFR : Cannot get IdEntLocalHome :" + e);
throw new CreateException("Cannot get IdEntLocalHome");
}
14/05/2008, 18h25
petrone

@local/@remote

Local/Distance?
Les EJB distantes(remote) à l'exécution suposent la sérilialisation des parametres et des valeurs de retour. Ceci induit une perte de temps.

Donc chaque fois que c'est possible il faut préférer une interface local

Quid de la visibilité des EJB local?
Une EJB local est visible à l'intérieur de l'archive (ear) qui la contient et uniquement la.
14/05/2008, 18h35
rteuteu55

bon en gros j'ai un problème ou les avis divergent ... :?

fr1man si tu à un example simple un lien vers un tuto je suis prenneur, mon ami google et plustot peut bavard sur ce sujet.

Il me semble plus logique que tu dise juste ! En effet, pourquoi limiterait-on la zone locale à l'EAR ??
14/05/2008, 20h54
fr1man

Mon exemple d'appel est valable avec les ejb3.
C'est un peu différent avec les ejb 2.1 que tu as l'air d'utiliser.

Pour petrone et phantomass, vous oubliez qu'un ejb n'a pas forcément besoin d'un ear, il peut très bien être déployé en tant que jar.

Je confirme donc ce que j'ai dit:
- local: même JVM
- remote: JVM différente
14/05/2008, 23h30
rteuteu55

Citation:

Envoyé par fr1man

Mon exemple d'appel est valable avec les ejb3.
C'est un peu différent avec les ejb 2.1 que tu as l'air d'utiliser.

Pour petrone et phantomass, vous oubliez qu'un ejb n'a pas forcément besoin d'un ear, il peut très bien être déployé en tant que jar.

Je confirme donc ce que j'ai dit:
- local: même JVM
- remote: JVM différente

Merci de l'info ! donc si je comprends bien, si j'utilise les ejb3 (il me suffit de changer de version de container), je pourrais faire des appels en local en utilisant d'après se que j'ai pu voir :
- ctx.lookup("monBean/local") ??

dans ce cas je dois trouver un vrais tuto sur le descripteur de déploiement ejb-jar :?
15/05/2008, 09h53
fr1man

Et puis en EJB3, tu peux te passer du descripteur ejb-jar.
Je pense que tu dois pouvoir trouver de bons tutos sur le net.
Moi, j'ai un bouquin en français qui est pas mal pour une bonne introduction.

En tout cas, il y a de gros changements entre les EJB 2.1 et 3, surtout le passage des Entity à JPA.
A voir quelles sont tes contraintes.
15/05/2008, 10h35
OButterlin

Une différence fondamentale entre l'usage de l'interface local vs remote (ce qu'avait commencé à expliquer petrone) est qu'en local, le passage des paramètres se fait par référence alors qu'en remote, c'est un passage par valeur (serialization/deserialization).
Outre le surplus de temps que ça peut induire, il peut exister de grosses différences de comportement (par exemple sur des propriétés en lazy loading)

En contre partie, via l'interface local, comme on est sur la même jvm, on ne peut plus utiliser de load/balancing et autres mécanismes répartis.

J'aurais tendance à conseiller ceci :
- utiliser l'interface remote pour les EJBs session facade
- utiliser l'interface local pour la granularité derrière la facade (si tous les EJB sont sur le même serveur, sinon, remote bien sûr)

Autre petit point :
il est souvent intéressant de créer un projet EJB uniquement pour les Entity et d'autres projets EJB pour les DAO et services d'accès qui les utilisent.
C'est un peu contraignant, il faut passer par un EAR et référérencer le jar des Entity dans le persistence.xml mais on gagne en clarté et maintenance des "briques" applicatives.

Maintenant, pour ce qui est des jar dans le même ear, il me semble que ce n'est pas obligatoire, mais ça pourrait dépendre des serveurs...

A+
15/05/2008, 11h33
rteuteu55

Pour ce qui est des contraintes que j'ai actuellement, je dirais surtout celle de comprendre !!

Sinon pour le load balancing, je pensais comme tu le dis (OButterlin) le réaliser sur les Ejb session (en façade). Je veux garder mes Ejb Entité en interfaces local uniquement, il me semble plus sécurisé de faire ainsi !!

Pour ce qui es du serveur, pour le momment je pense utiliser Jonas qui est libre, pour découvrir, cela me semble adapté !

Enfin : "Et puis en EJB3, tu peux te passer du descripteur ejb-jar." haha intéréssant ! Mais je suis alors perplex de savoir comment cela fonctionne? Dois-je alors utiliser les "@local", "@...." dans mes Ejb ?? Le seul point que j'ai totalement mis de coté dans mes recherches :oops: ??
15/05/2008, 11h45
jamguard

Citation:

Envoyé par OButterlin

Maintenant, pour ce qui est des jar dans le même ear, il me semble que ce n'est pas obligatoire, mais ça pourrait dépendre des serveurs...

Merci beaucoup pour cet éclairage.

Quelqu'un sait si JOnAS "interdit" à ses EJBs "locaux" de communiquer entre eux quand ils ne sont pas dans le même "package" ?
Par exemple : deux jars qui ne sont pas dans un même EAR mais déployés sur la même machine.

J'avoue que je n'ai pas trouvé mieux sur Google que cette piste :
http://www.redhat.com/docs/manuals/r...ns-ejbref.html

Déjà, dans la première partie, ils expliquent que la balise ejb-link est optionnelle alors que j'ai un message d'erreur qui me rapporte qu'elle est manquante lorsque j'essaie de faire sans dans le déploiement de deux composants appartenant au même jar...
"If the referred bean is defined in the same EJB-JAR or EAR file, the optional ejb-link element of the ejb-ref or ejb-local-ref element can be used to specify the actual referred bean."

mais le plus important c'est que je n'arrive pas à comprendre la fin de cette documentation, à partir de :
"If the referring component and the referred bean are in separate files and not in the same EAR,..."

Si vous avez un début d'explication ou une piste à travers un lien pour maîtriser cet aspect de cette technologie, merci d'avance.

Tu peux également utiliser JBoss4.2.2 qui est gratuit et très intéressant
(JBoss Seam + RichFaces dans un contexte de développement JSF)

Pour ce qui est des descripteurs de déploiement, OUF, on s'en passe ! ;)

Tes classes contiennent des annotations qui sont interprétées par le loader sur le serveur d'application.
Par exemple :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
@stateless
public class MonEJBSession extends MonEJBSessionRemote
{
   @PersistenceContext(unitName="Projet1PU")
   private EntityManager entityManager;
 
    @EJB(name="CollaborateurFacade/local")
    private CollaborateurFacadeLocal facade = null;
 
...
}
 
ou
 
@Entity
@Table(name="maTable")
public class MonEntity implements java.io.Serializable
{
   private static final long serialVersionUID = 1L;
   private Integer uid;
   private String name;
 
   @Id
   @GeneratedValue()
   @Column(name = "UID", unique = true, nullable = false, insertable = true, updatable = true)
   public Integer getUid()
   {
       return this.uid;
   }
 
   public void setUid(Integer uid)
   {
       this.uid = uid;
   }
 
   @Column(name = "NAME", unique = false, nullable = true, insertable = true, updatable = true, length = 60)
   public String getName()
   {
       return this.name;
   }
 
   public void setName(String name)
   {
       this.name = name;
   }
}

15/05/2008, 12h31
OButterlin

Citation:

Envoyé par jamguard

Quelqu'un sait si JOnAS "interdit" à ses EJBs "locaux" de communiquer entre eux quand ils ne sont pas dans le même "package" ?
Par exemple : deux jars qui ne sont pas dans un même EAR mais déployés sur la même machine.

Je ne sais pas, je n'ai jamais utilisé JOnAS.
Ce qui pourrait poser problème (à vérifier pour JOnAS) c'est le nom utilisé dans le lookup.
Quand le déploiement se fait via un EAR, par défaut, il faut préfixer les noms par le nom de l'EAR alors que sans EAR, il n'y a pas ce préfixe.
21/05/2008, 09h53
rteuteu55

merci pour ces réponses qui m'ont aidés à comprendre.