[Architecture] EJB ou pas EJB ? Je suis perdu ...

Bonjour,

Depuis début janvier que je fais de la veille sur les techno J2EE, j'ai appris énormément et je commence à me faire une bonne idée d'une architecture J2EE type.
Mais je commence aussi a me perdre dans toutes les possibilités qui s'offrent à moi, je viens donc a vous pour me conseiller et me recentrer un petit peu.

La problèmatique
Nous devons gérer des échantillions, ajout/modification/suppression et de la consultation. Et cette gestion, surtout la consultation, doit se retrouver au sein de plusieurs applications utilisateurs ( ecrite en java ou autre ).

Mon début de solution
Donc il va de soit que cette gestion des échantillions doit se retrouver implémenter sous forme de composant, qui sera appelé par les différentes applications clientes.
Les applications clientes étants soit écrites en java, soit dans un autre langage, deux implémentations seront réalisées, une standard (couplée a un framework web ou webstart) et l'autre avec des webservices.
Comme nous voulons garder une intégrité des données, nous mettons aussi un framework de persistence, Hibernate, en standalone (jmx) sur un serveur jboss, pouvant dialoguer avec les deux implémentations (sinon la persistence est cassée)

Ma grosse intérogation
Alors que je maitrise maintenant ma couche persistence et ma couche présentation, un grand flou reste sur comment réaliser ma couche métier.
Je lis partout qu'il ne faut pas utiliser EJB (bien qu'avec l'arrivé des EJB 3) mais d'un autre coté de je ne vois pas comment implémenter cette couche sous forme de composant distant !

Alors existe-t-il une solution à la quelle je n'aurais pas pensée ?
Et par la même occasion ne vous génez pas si vous avez des critiques a apporter a cette architecture, je suis prenneur :)

Merci

Bonjour,

D'abord les EJBs:
1) C'est lourd
2) Il faut un conteneur allant de gratuit à très cher
3) Il faut former les gens en interne pour la gestion de la bête
4) C'est très bien pour la partie répartie et clustering
5) C'est très bien pour les transactions métiers mais pour ca il y spring, c'est bcp plus léger et plus simple
6) C'est un enfer à tester
7) Les EJB3 c'est bien mais ce n'est pas finaliser et mieux vaut ne pas être le beta-testeur

Donc je dirais, tu veux une appli accessible par web ou un autre langage
:arrow: utilise un web service.

Maintenant si ton appli à une tolérance de panne faible mais alors vraiment faible, le clustering t'imposera les EJB pour eviter le single point of failure. Mais attention queleu'un qui utilise c'est argument ne doit pas oublier qu'il faut alors mirrorer et la DB et le gestionnaire de trx.

Merci pour ta réponse rapide,

Bien entendu mon intention première était de ne pas utiliser les EJB, mais je me suis finalement rendu compte que vis à vis de ce que j'avais envisager il n'y avait pas d'autres possibilités.

Le problème des webservices c'est que pour le moment c'est un peu lourd en performance (merci JAX-RPC) et que c'est juste une option facultatif. Il n'y a pas de java dans la boite, mais il y a de forte chance qu'il n'y ai que ca avec le temps. Donc je ne veux pas me baser que sur les WS (interet de faire des WS en total java ??), mais sans les écarter totalement.

Le solution JBoss ne me fait pas peur et y a pas grand monde à former (personne si je reste dans la boite et une personne si on ne me garde pas (je suis en stage)). Et je l'utilise déjà dans mes tests pour la gestion des transactions et Hibernates en standalone (ce que je n'aurais plus besoin tu va me dire si je passe en total webservices)


En gros la question formulée autrement :
Y a t'il un autre moyen de faire des composants distants sans passer par les EJB ? ou sans déployer mon jar dans toutes mes applications ?

RMI, très simple si on utilise Spring (plus complexe sans) : http://www.springframework.org/docs/reference/remoting.html

Si tu te décides à utiliser les EJB :
- ne mets pas de code métier dedans
- utilise une couche de service sous forme de POJO et laisse l'EJB déléguer le traitement en appelant cette couche

Ton architecture sera alors plus facilement testable en dehors du conteneur. Je ne peux que te conseiller d'utiliser Spring pour simplifier encore plus...

Citation:

---

Envoyé par Jamatic

Et je l'utilise déjà dans mes tests pour la gestion des transactions et Hibernates en standalone (ce que je n'aurais plus besoin tu va me dire si je passe en total webservices)

---

C'est pas clair ce que tu dis

Non mais en fait, je crois que tout ce que j'ai dit depuis le debut n'est pas très clair :mrgreen:

Reprenons à la base (en oubliant mon deuxième message) : mon composant de gestion des échantillions.
Comment en faire un composant autonome ? pour ensuite l'appeler via une couche web service ou l'appeller directement de ma couche présentation.

Avec la précision que tous tournera sur le même serveur.

Citation:

---

Envoyé par Jamatic

Non mais en fait, je crois que tout ce que j'ai dit depuis le debut n'est pas très clair :mrgreen:

Reprenons à la base (en oubliant mon deuxième message) : mon composant de gestion des échantillions.
Comment en faire un composant autonome ? pour ensuite l'appeler via une couche web service ou l'appeller directement de ma couche présentation.

Avec la précision que tous tournera sur le même serveur.

---

Ben si avec spring tu peux faire un pojo qui est soit instancié par un main, soit par spring justement. Qui lui même accedde à la DB et fait les traitements métiers. Seules restrictions JMS, dans ce cas ca va dépende quelle couche de transport tu vas utiliser (JBOSS ou autres)

Désolé mais je vois pas ce que spring vient faire là ? :?

Pas que je ne veux pas de spring, je l'utilise déjà a toutes les couches (spring ORM, spring AOP, spring Core et spring Remote (vivement spring WS)).
Mais je vois pas en quoi ca va rendre mon composant autonome sur mon serveur.

Ou il y a vraiment quelques choses que je n'ai pas saisie dans les fonctionnement des serveurs d'applications ou une subtilité de spring encore inconnue a mes yeux !

Ca doit être ca qui t'es inconnu:

Code:

---

1 2 3 4 5 6 7 8 9 10

<!-- RMI Remoting --> <bean id="SecurityBusinessServiceRMIServer" class="org.springframework.remoting.rmi.RmiServiceExporter">   <property name="serviceName" value="SecurityBusinessService"/> <property name="service" ref="SecurityBusiness"/> <property name="serviceInterface" value="net.zekey.business.security.ISecurityBusiness"/>   <property name="registryPort" value="1199"/> </bean>

---

Le composant (objet métier ) SecurityBusiness devient disponible par RMI, comme un ejb, tu peux l'utiliser d'un ws, d'un tomcat ou de toutes autres appli standalone. Moi je l'utilise pour faire l'authentification de tout mes projets. La seule restrictions c'est le cluster ca tu n'as pas.

Et avec cette solution pas besoin de registry ou quoi que ce soit d'autre

Ok, mais vu que tout sera executé sur le même environnement, pourquoi rajouter une surcouche RMI ?

Je crois qu'un bon récapitulatif s'impose de l'architecture que je veux mettre en place :D
En partant du plus bas niveau :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

MySQL | Hibernate (HAR) | Metier(?AR) (DAO + Domain) | | Framework Web Web Services (WAR) (WAR) | | Navigateur PHP, C#, ... Web

---

Joli le dessin :mrgreen:

Tous tourne au sein du même serveur d'application JBoss.

C'est ce que tu avais compris ?

En tout cas merci beaucoup du temps que vous me consacré

Ben c'est toi qui veux des composants distants.
Si tu penses que tu maitrise bien les EJB et que ca ne te fais pas peur alors vas-y, c'est fait pour.

Nous ce que l'on (enfin moi au moins) c'est qu'en prod les EJB c'est lours et pas facilement testable. Mais si tu veux de toutes facons utiliser un JBOSS.
Tu n'as qu'a faire une stateless bean pour le métier.

Citation:

---

Envoyé par zekey

Ben c'est toi qui veux des composants distants.

---

Excuse je me suis mal exprimé, mais non je ne veux pas de composant distant.

Citation:

---

Envoyé par zekey

Si tu penses que tu maitrise bien les EJB et que ca ne te fais pas peur alors vas-y, c'est fait pour.

Nous ce que l'on (enfin moi au moins) c'est qu'en prod les EJB c'est lours et pas facilement testable. Mais si tu veux de toutes facons utiliser un JBOSS.
Tu n'as qu'a faire une stateless bean pour le métier.

---

Ba si je peux m'en passer, je le ferais volontier, mais si tu me dis qu'il n'y a pas d'autres solutions, mis a part modifier mon archi, on va regarder ce que ca donne (voir être beta testeur ejb 3 :))

Ben honnetement avec ton archi moi j'aurais utilisé spring.

j'ai l'impression qu'on tourne en boucle :lol:.

J'utilise deja spring a tous les niveaux, mais en quoi et comment il va rendre ma couche métier autonome ?

Citation:

---

Petit parenthèse EJB3

Pour un bean statless, il faut dans le service importer une classe et rajouter une annotation sur la classe

Code:

---

1 2 3 4 5 6 7 8

import javax.ejb.Stateless;   @Stateless public class Addition implements AdditionRemote, AdditionLocal { public int plus(int a, int b) { return a + b; } }

---

Puis pareil pour les interface

Code:

---

1 2 3 4 5 6 7 8 9 10 11

import javax.ejb.Remote;   @Remote public interface AdditionRemote extends Addidtion { }   import javax.ejb.Local;   @Local public interface AdditionLocal extends Addidtion { }

---

Merci les annotations :D

---

Citation:

---

Envoyé par Jamatic

j'ai l'impression qu'on tourne en boucle :lol:.

J'utilise deja spring a tous les niveaux, mais en quoi et comment il va rendre ma couche métier autonome ?

---

Disons le autrement de quoi as tu besoin dans ton conteneur que tu ne pourrais avoir en dehors ?

Ba .....

1. Imaginons je crée un jar de mon composant métier, exclusivement composé de ma classe dao et de ma classe domain.
2. Que je veuille le déployer a un seul endroit
3. Pour le réutiliser ensuite dans plusieurs applis

Ca je peux le faire en dehors d'un conteneur J2EE ?

Citation:

---

Envoyé par Jamatic

Ba .....

1. Imaginons je crée un jar de mon composant métier, exclusivement composé de ma classe dao et de ma classe domain.
2. Que je veuille le déployer a un seul endroit
3. Pour le réutiliser ensuite dans plusieurs applis

Ca je peux le faire en dehors d'un conteneur J2EE ?

---

C'est ce que nous disions avec RMI. Ton jar tu l'executes parce que dans le main tu charge le service. Et puis voila
Naturellement si deja tu réunis plusieurs services ensemble.

Ca se tient, mais ca fait aussi un peu bricolage ...
Je sais pas si je vais arriver a vendre ca (n'oublis pas je suis que stagiaire :roll: )

Je garde une option ejb3 tout de même ;)

En tout cas merci de ta patience :)

méfies toi le peu d'xp que j'au avec EJB3 me fais dire que ca manque encore un peu de maturité. Notamment si tu accéde a l'eJB en dehors du JBOSS