Application J2EE avec ou sans EJB

Version imprimable

07/01/2011, 20h06
mesken

Application J2EE avec ou sans EJB

Dans la plupart de document traitant du J2EE, l'usage des EJB sont facultatifs pourtant chaque fois qu'on parle de J2EE on pense directement aux EJB. Et j'hésite un peu à me décider. Il est vrai il y a des raison quant à utiliser les EJB ou pas, mais jusque là je ne suis pas fixé. Voici ma question.
Une application de grande envergure, supposons un ERP qui inclu (Gestion des RH, de la contabilité, des inventaires, de la paie) sans EJB peut-elle être aussi scalable, robuste, portable, extensible, performante, stable que la même application avec EJB
07/01/2011, 22h28
tlesol

Bonsoir,

Alors pour vous aiguiller un peu, il est bien sûr possible de faire une application de grande envergure sans ejb et d'avoir une application plus performante, plus stable, plus ....
Mais le problème est de savoir combien de temps cela va t'il prendre pour obtenir une telle application, et combien de fois il va falloir reprendre le code parce que l'architecture / les techniques choisies ne sont pas les bonnes.

Lorsqu'on choisit un ORM, c'est pour se simplifier la vie. (La simplification ne vient pas de suite malheureusement car il faut un temps d'apprentissage de l'outil.)

En gros, à votre place je partirais bien volontiers sur des ejb3 ou hibernate pour la partie accès aux données.

Pour aller plus loin, je dirais que pour rendre plus "scalable" votre application j'y ajouterais un framework d'injection de dépendance tel Spring (qui fait plein d'autre chose)

En tout cas, bon courage!
07/01/2011, 23h49
sebastien.moratinos

Le choix d'utilisation d'ejb3 ou non doit être dicté à mon avis par :
1 / un fort besoin transactionnel
2 / JMS
3 / rapidité de développement
4 / scalability
5 / les compétences en ejb3 de l'équipe

Mais vraiment, c'est l'aspect transactionnel qui m'a le plus impressionné pour les ejb3.

Pour ta question, la réponse est oui.
09/01/2011, 02h03
lunatix

ceci dit, une application bien concue n'a pas besoin d'EJB pour etre scalable. (j'aurais meme tendance a dire qu'une application java bien peut meme se passer de la couche JEE et etre parfaitement scalable).
11/01/2011, 08h06
mesken

Merci pour les réponses. Je voudrais juste précisier que l'application sera déjà en J2EE il s'agissait juste de se décider EJB ou pas. Excuser moi je suis nouveau tout est encore concepts et je m'y met petit a petit.

1) Je voudrais préciser que nous avons opter pour GWT (GXT), celà veut dire qu'il faudra se lancer dans Spring, j'aimerai avouer que j'y ai beaucoup entendu parler sans vraiment utiliser. Quelqu'un peut-il avoir une bonne documentation là dessus ? Et s'il faut utiliser Spring quelles sont les contraintes ? Open Source Vs Entreprise.

2) ça de dire qu'il faudra faire du GXT+ Spring + EJB

3) J'espère qu'il est bien possible de combiner POJO et EJB3. C'est à dire dans mon application, je décide d'utiliser quelques EJB a certains endroits et pas à d'autres.

4) Sébastien a parler de transactionnel, c'est un terme que j'entends beaucoup au niveau des EJB mais c'est encore abstrait. Est ce à dire que ce n'est que dans le cadre bancaire ? Peut-on parler de transaction dans le cadre de l'exemple que j'ai pris plus haut (ERP élargi).
11/01/2011, 08h41
tlesol

Bonjour,

Alors pour répondre brièvement à tes questions :

1) La documentation de Spring que j'utilise à 90% est la doc de référence
http://static.springsource.org/sprin...eference.html.

Mais Spring est une grosse boîte à outils. L'atout premier de Spring est de faire de l'injection de dépendance. Il me semble intéressant de te renseigner la dessus si tu ne connais pas le principe

2) Oui, je ne pense pas que ce soit déconnant ;)

3) Oui tu peux faire ce que tu veux. Tu peux utiliser des ejb ou tu veux, même si a mon avis il faut se forcer à avoir une cohérence dans l'application.

4) Le transactionnel dont parle sébastien est l'encapsulation de requête SQL dans une même transaction. (Pour faire simple).
Voici un exemple :
Lors d'une action tu dois faire 2 insert en base.
Le premier Insert passe sans problème.
Le deuxième plante.
Il faut que le premier soit annulé par un rollback pour maintenir une cohérence des données.

Il faut donc mettre ces deux accès à la base de données dans une même transaction.

Rassure-toi, Spring, permet de gérer facilement le côté transactionnel de ton application.

J'espère que ca a pu t'aider.
11/01/2011, 09h48
sebastien.moratinos

Citation:

Envoyé par mesken

nous avons opter pour GWT (GXT), celà veut dire qu'il faudra se lancer dans Spring,

Non, GWT n'a rien a voir avec Spring. J'utilise GWT sur un de mes projets mais pas Spring.

Citation:

Envoyé par mesken

2) ça de dire qu'il faudra faire du GXT+ Spring + EJB

8O Pourquoi Spring + ejb ?
Si tu utilise les ejb 3 et tout javaee 5 ou 6, pourquoi tu voudrais rajouter Spring.
De plus la stack techno de ton appli est affreusement lourde :
GWT, faut l'avaler le machin.
+ GTX, allez hop des librairies en plus
+ EJB, donc appli découpé et complexe.
+ Spring, Boum !

T'aura fini la prise en main et config de tout ça dans 3 mois mais t'aura pas fait une ligne de code...

Quand on débute, il faut utiliser des technos simples

Citation:

Envoyé par mesken

C'est à dire dans mon application, je décide d'utiliser quelques EJB a certains endroits et pas à d'autres.

Oui c'est possible. Mais pourquoi ne pas tout faire en ejb... ce serait quoi l'intérêt ?

Sur un nouveau projet, il ne faut pas cumuler les technos inconnues.

Tu ne connais aucune des technos mentionnées et tu as pris les plus complexe.
Exemple :
Si tu sais faire du jsp/servlet alors fait : ejb + jsp/servlet.
11/01/2011, 09h50
mesken

Merci beaucoup tlesol, je peux voir beaucoup d'ouverture à partir de tes explication
I see, thanks a million.
24/01/2011, 08h53
mesken

Merci bcp sebastien.moratinos. Je reviens à la charge. Quand on apprend, les choses s'éclaircissent au fur et à mesure.
En fait un as raison, ça prendra bcp de temps. Mais comme tu le consate, le projet est lourd et on veut y mettre du meilleur. Nous comptons consacrer environ 3 à 4 mois pour maitriser les diverses technologies qu'ont aura décider d'utiliser, avec un projet test avant de passer au vrai morceau à croquer
et dans notre cas d'étude, nous commençons par JSP+Servlet(MVC), puis on passe à JSP+Servlet+EJB, ensuite GWT/GXT (MVP), après GWT/GXT + EJB et en fin Spring..... Même s'il faut 4 mois, pourvu que des bases solides soit posées.
Je voudrai dire que nous choisissons GXT ou GWT à cause de la complexité des interfaces liées au projet et il ne faudra surtout pas que les pages se rechargent (Ajax/Javascript sont primordiales).

Actuellement voici mes préoccupations

1) Il y a trois type de clients
a) Simples entreprise (d'environ 50 employés)
b) Entreprises moyennes (d'environ 150 employés)
c) En fin grandes entreprises avec plusieurs agences de 250 employés environ chacune avec des serveurs délocalisées dans chaque agence (Distribuée)
Ma question se pose au niveau de l'architecture, les clients de type a) et b) n'auront pas les moyen d'investir pour une architecture distribuée, mais les clients de type c) le pourront sans problème.
Nous sommes face à un dilemme : faudra t-il faire deux applications ? une pour les petites entreprises et une intégrant les EJB pour les grandes à entreprises qui supporteront architecture distribuée ?Ce qui sera trop lourd et prendra beaucoup de temps.

2) La version 3 de Spring étant plus évoluée, pouvons nous travailler simplement avec Spring et implémenter selon le client mais avec un développement unique ?

Merci pour vos éclaircissements.
24/01/2011, 10h03
sebastien.moratinos

Citation:

Envoyé par mesken

1) Il y a trois type de clients
a) Simples entreprise (d'environ 50 employés)
b) Entreprises moyennes (d'environ 150 employés)
c) En fin grandes entreprises avec plusieurs agences de 250 employés environ chacune avec des serveurs délocalisées dans chaque agence (Distribuée)
Ma question se pose au niveau de l'architecture, les clients de type a) et b) n'auront pas les moyen d'investir pour une architecture distribuée, mais les clients de type c) le pourront sans problème.
Nous sommes face à un dilemme : faudra t-il faire deux applications ? une pour les petites entreprises et une intégrant les EJB pour les grandes à entreprises qui supporteront architecture distribuée ?Ce qui sera trop lourd et prendra beaucoup de temps.

Je ne comprends pas le problème.
Qu'entends tu par architecture distribuée pour ton projet, qu'est ce qui est distribué ?
Tu veux que les clients a et b n'est qu'un seul serveur avec couche IHM + Service, et que les clients c puissent s'ils le veulent avoir des serveurs pour IHM, et d'autres pour Service pour des problèmes de montée en charge par exemple ?

Si c'est ton problème, alors il suffira d'utiliser des ejb local pour les clients a et b et des ejb remote pour les clients c. Celà nécessite juste de changer une annotation. Par contre faut que tu te renseigne sur le RMI.

Citation:

Envoyé par mesken

2) La version 3 de Spring étant plus évoluée, pouvons nous travailler simplement avec Spring et implémenter selon le client mais avec un développement unique ?

Je ne comprends pas ta question.
24/01/2011, 14h31
mesken

Voici ce que je veux dire par là.
Pour les clients de type a) et b) c’est dire les PMI et les PME, ils peuvent simplement investir pour deux serveurs. Ici ce sera du 3-tiers , ou même du Client/Serveur – même sans EJB, on peut gérer ça.
- Un serveur (web + Logique )
- Et un serveur pour la Base de Données.
Pour les clients de type c) qui sont de grandes entreprises avec près de 10 agences et chaque agence a environ 500 employés. Et ils auront plusieurs serveurs délocalisés pour satisfaire les requêtes concurrentielles. Ils auront plus d’un serveur d’application et il y aura une nécessité de Load Balancing entre les serveurs. Ici ce sera du 5-tiers ou 10-tiers. Je me dis que l’usage des EJB est obligatoire dans ce cas.
1) Ma question était donc de savoir si on travail directement avec les EJB, ça fera que les petits clients seront obligés d’avoir un serveur d’application (JBoss) par exemple, en plus des autres serveurs. Ce qui ne nous arrange pas, on veut que peut importe le cas, qu’il trouve son compte, que le développement de l’application soit unique mais l’implémentation varie selon l’utilisateur.
2) Ma 2e question au sujet de Spring est que, si on utilise Springs sans EJB, est ce qu’il peut gérer ce cas de Load Balancing sur plusieurs site et reste scalable ?
24/01/2011, 15h31
sebastien.moratinos

Citation:

Envoyé par mesken

Ici ce sera du 5-tiers ou 10-tiers. Je me dis que l’usage des EJB est obligatoire dans ce cas.

C'est pas ça du n-tiers (ce n'est pas le nombre de serveurs). Toi tu parles de 3 tiers, avec pour chaque tiers un cluster.
L'usage des EJB n'est pas du tout obligatoire.

Citation:

Envoyé par mesken

1) Ma question était donc de savoir si on travail directement avec les EJB, ça fera que les petits clients seront obligés d’avoir un serveur d’application (JBoss) par exemple, en plus des autres serveurs. Ce qui ne nous arrange pas, on veut que peut importe le cas, qu’il trouve son compte, que le développement de l’application soit unique mais l’implémentation varie selon l’utilisateur.

Contrainte : pas de serveur d'application JavaEE -> pas EJB

Citation:

Envoyé par mesken

2) Ma 2e question au sujet de Spring est que, si on utilise Springs sans EJB, est ce qu’il peut gérer ce cas de Load Balancing sur plusieurs site et reste scalable ?

Je répète, c'est soit Spring soit EJB3 ! Je n'ai pas connaissance d'une quelconque utilité de mixer les 2 pour une nouvelle appli.
Le load balancing, ça se fait avec tout.

Tu mélange un peu tout les termes, je te conseil de revoir la base de l'architecture des applications.
25/01/2011, 09h55
mesken

Merci bcp , il est vrai que je commence à comprendre mieux bien que j’ai encore quelques points d’ombres, mais bon…. Tes éclaircis sur les points suivants m’aideront à creuser d’avantage, même si c’est en quelques 4 lignes de réponse.

1) Je croyais que le nombre de tiers était lié aux serveurs, c’est-à-dire, n-tiers = n-1 serveurs (1 tiers représentant le client)

2) Qu’est ce qu’une architecture distribuée ?

3) En dehors de leur caractère transactionnel, quel est donc le rôle primordial des EJB qui les rendrait incontournable dans une situation données.

4) Enfin, si tu devais concevoir une unique application J2EE pour les petites entreprises qui ne peuvent qu’avoir un serveur et les grosses entreprises avec des milliers d’employés répartis dans plusieurs agences et plusieurs villes. Comment t-y prendrais-tu ?

Tes réponses à ces questions m’aideront beaucoup

Merci.
25/01/2011, 12h05
sebastien.moratinos

Citation:

Envoyé par mesken

1) Je croyais que le nombre de tiers était lié aux serveurs, c’est-à-dire, n-tiers = n-1 serveurs (1 tiers représentant le client)

1 tier = 1 couche de ton système

:google2: http://hoa-project.net/Manuel/Refere...e_n-tiers.html

Citation:

Envoyé par mesken

2) Qu’est ce qu’une architecture distribuée ?

:google2: http://fr.wikipedia.org/wiki/Archite...istribu%C3%A9e

Citation:

Envoyé par mesken

3) En dehors de leur caractère transactionnel, quel est donc le rôle primordial des EJB qui les rendrait incontournable dans une situation données.

Il n'y a pas de rôle primordial qui oblige à utiliser les ejbs, il y a juste des avantages que j'ai cité dans ma première réponse.

Citation:

Envoyé par mesken

4) Enfin, si tu devais concevoir une unique application J2EE pour les petites entreprises qui ne peuvent qu’avoir un serveur et les grosses entreprises avec des milliers d’employés répartis dans plusieurs agences et plusieurs villes. Comment t-y prendrais-tu ?

Je demanderai plus d'explication !
Concevoir une architecture et choisir des technos, çelà ne se fait pas avec ci peu d'élément.
26/01/2011, 07h58
mesken

Vous voulez me faire pousser les les veux blancs avant le temps !!!: roll:

Supposons que
- vous êtes le Directeur Technique d'une entreprise d'édition de logiciels.
- Vous étudier l'informatisation de certaines entreprises dans certains pays et vous vous rendez compte qu'il y a beaucoup a refaire.
- Vous mettez sur pied un nouveau concept. Vous préparez toute l'architecture fonctionnelle de ce nouveau concept que vous présenter à un échantillon d'entreprises grandes et petites dans certains pays où l'informatisation des entreprises n'est pas encore évoluée.
- Elles sont très intéressées. Et Vous décidez donc de mettre sur pied un ERP d'entreprise avec disons les modules tels que je l'ai dit plus haut : Gestion des RH, de la comptabilité, des inventaires et de la paie , dans un seul package.
- Pendant longtemps, vous avez développé avec PHP, Javascript, Ajax.
- Vous faite une formation en Java/POO que vous maîtriser déjà sans problème
- Vous êtes en train de vous former en J2EE et il y a tellement de techno et vous devez maitriser d'abord J2EE (architecture) et puis choisir une combinaison de techno que vous allez approfondir et travailler avec définitivement.
- Au niveau Web Tier , vu la complexité des fenêtres, il ne faudra surtout pas que les pages se rechargent (donc pas de JSP/Servlet simple - Ajax ou Javasript devront intervenir).
- Les clients sont de 2 catégorie comme je disais plus haut, grandes et petites.
Voilà le contexte, même si tu ne donne pas une solution définitive, juste quelques éléments sebastien.moratinos

Merci.