Discussion :

[le Daoud]

Bonjour,

Je m'occupe de la maintenance d'une application utilisant notamment Struts et des EJBs.
Le découpage est fait de la sorte :
Côté Web : Action appelant un ServiceDelegate
Côté business : un Bean appelé par le ServiceDelegate, qui appelle un Service (qui appelle éventuellement des DAO).

Je n'arrive pas à saisir l'intérêt de la couche Service utilisée par les EJBs. En effet, les méthodes de l'ejb et du service sont les mêmes, donc l'ejb ne fait rien, hormis appeler le service. Je suis perplexe. Auriez-vous une idée ?

Merci

[fr1man]

Les EJB sont surement utilisés pour la gestion "automatique" des transactions.
Chaque méthode de ton EJB session peut faire partie d'une transaction.
Ceci est déclaré dans le ejb-jar.xml.

[le Daoud]

Je te mets un exemple de déclaration d'ejb du fichier ejb-jar.xml :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
<session >
         <description><![CDATA[...]]></description>
         <display-name>Civilite EJB</display-name>
 
         <ejb-name>Civilite</ejb-name>
 
         <home>a.b.c.CiviliteHome</home>
         <remote>a.b.c.Civilite</remote>
         <ejb-class>a.b.c.CiviliteSession</ejb-class>
         <session-type>Stateless</session-type>
         <transaction-type>Container</transaction-type>
 
         <resource-ref >
            <res-ref-name>jdbc/steriagcv</res-ref-name>
            <res-type>javax.sql.DataSource</res-type>
            <res-auth>Application</res-auth>
         </resource-ref>
 
      </session>

cela confirme-t-il tes dires ?

[fr1man]

A priori oui:

<transaction-type>Container</transaction-type>

Le serveur d'application (container) va englober chaque appel de méthode de cet EJB dans une transaction.

Je pensais qu'il y avait d'autres paramètres à renseigner dans ce fichier, comme par exemple, sur quelles méthodes de l'EJB appliquer les transactions.
Si ça fonctionne comme ça, c'est que ça doit suffire.

[le Daoud]

Ca fonctionne bien comme cela, mais je ne vois pas l'intérêt de rajouter la couche service. En effet, l'ejb ne fait rien si ce n'est qu'appeler le service. Autour de moi on me suggère que cela a été fait avec l'idée qu'un service puisse être appelé par plusieurs EJBs... mais cela n'a jamais été utilisé dans l'appli, le service étant similaire à l'EJB (même méthodes, avec les mêmes noms)

[fr1man]

L'idée est de séparer les couches pour pouvoir les réutiliser.
Si tu décides de te passer des EJB, ce sera plus facile puisque ta couche de
service ne contient pas de code faisant référence aux EJB.
Elle est plus facile à utiliser dans d'autres contextes.

[xv-mnt]

Il me semble que c'est une implementation du patten business delegate au niveau de l'EJB.
Comme l'a dit fort justement fr1man, on sépare le traitement "métier" dans une classe service du traitement transversal (sécurité, transaction) situé dans l'EJB. Dans ce cas c'est de manière déclarative dans l'ejb-jar.xml.
Comme avantage, on peut tester unitairement le code métier en dehors d'un conteneur EJB, ce qui est plus facile à mettre en oeuvre .

[le Daoud]

Ok, merci bcp à vous.