Architecture d'une application Web

Version imprimable

04/10/2006, 17h08
le Daoud

Architecture d'une application Web

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 ;)
05/10/2006, 09h23
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.

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

Code:

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 ?

05/10/2006, 10h14
fr1man

A priori oui:

Citation:

<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.
05/10/2006, 11h05
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)
05/10/2006, 11h22
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.
05/10/2006, 11h38
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 .
05/10/2006, 11h39
le Daoud

Ok, merci bcp à vous. :)