Couche métier = forcement EJB ? [Résolu]

[jothi35]

Bonjour,

Je me pose une question depuis un moment. Lorsqu'on parle de J2EE et plus précisemment de sa couche métier, on parle tout le temps d'EJB. Est-ce qu'il est pas possible d'avoir autre chose que des EJB comme par exemple un programme Java accessible par RMI ou JMS ?
Si c'est le cas, est ce que des outils comme JBoss permettent de faire tourner des couches métier qui ne sont pas des EJB ?

Il y a surrement des topics qui parlent déjà de ça mais j'ai pas réussit à les trouver, si c'est le cas, je veux bien que vous m'envoyez les liens. J'ai bien essayé de chercher mais c'est pas évident pour une question aussi générale.

[viena]

tu peux tres bien faire du J2EE sans EJB, avec des classes metier en java par exemple. Pas mal de boite (comme celle ou je bosse actuellement) n'utilisent pas les EJB (lourd, pas encore tres stables... en attente de la version 3) et s'en sortent tres bien. De ce fait, JBoss n'est plus tres utile.
Tu peux tres bien avoir :
une couche interface (souvent JSP via struts).
une couche metier (classes java... eviter de les mettre dans les actions, c'est pas beau...)
une couche d'acces aux données (via JDBC ou mapping (hibernate, CastorJDO....))

[bmoussaud]

Pour faire simple je dirait que l'utilisation des EJB pour une couche métiers est necessaire si tu as :
* besoin d'un contexte transactionnel
* besoin de sécurité (role, autorisation,...)
* besoin de distribution (application répartie)
* besoin de fortes montée en charges (présente ou à venir)

si tu réponds oui à au moins 1 point, ca se réflechit
à 2 la réponses est OUI !

Les EJB ne sont pas compliqués ,...qu'on se le dise...!

NB: dans les 4 points, je n'ai pas parlé de persistence et c'est voulu !

[jothi35]

Tout d'abord, merci de vos réponses.

La solution dont tu parle viena est celle que j'utilise actuellement. Le problème est que je vais avoir une application qui n'a pas d'interfaçe web, ni d'interfaçe graphique d'un autre type d'ailleur, c'est en faite un composant métier qui devra rendre certains services à d'autres composants.
Une première solution est d'écrire les classes du composant métier en pure java, de faire une librairie que les autres composant inclus.
Mais je me demandais s'il était pas possible que mon composant métier tourne tout seule dans sa propre JVM et soit appelé par les autres composants de manière distante. Par exemple par RMI.
Je me demandais dont si un serveeur comme JBoss par exemple permettait de faire tourner mon composant métier bien qu'il ne soit pas EJB. Et si ce n'est pas le cas, comment je fais pour rendre mes services accessibles ?

[bmoussaud]

pour ton probleme de distribution je te propose d'utiliser les EJB (un des points que j'avais cité) car faire du rmi classique ca va etre plus difficile à deployer par la suite....
Sinon dans ton cas tu peux utiliser les WebServices : soit sous forme SOAP (cf projet AXIS de jakarta) soit tout simplement des servlets propriétaires ou tu passerais les arguments en GET (sur URL avec des &). Si ton modèle est simple cette derniere solution peut être efficace tout en restant avec des technologies simple et éprouvés[/b]

[viena]

les WebServices me semblent en effet une excelente solution.

[bmoussaud]

Envoyé par viena

les WebServices me semblent en effet une excelente solution.

Merci

[ego]

juste histoire d'ajouter peut être qq précisions.
Dans le cas d'utilisation de composants par d'autres applis, sans connaitre ton contexte et de manière générale, je te recommande de créer des objets métiers en pur Java.
Ensuite, en fonction des accès distribués dont les autres applis auront besoin, cela te permettra facilement de wrapper tes objets métiers dans des EJB ou des WebServices. Tu peux regarder pour cela de design pattern Business Delegate.
Un autre avantage de faire des classes Java pures est que tu peux tester facilement tes objets dans un contexte en dehors du conteneur Web/EJB.
C'est aussi très facile pour des développeurs ne connaissant pas J2EE de réaliser des objets métiers et un spécialiste de J2EE pourra se charger de wrapper ces objets dans la techno voulue. Si tu as du temps tu pourras utiliser pour cela un outil comme XDoclet ou si tu as encore plus de courage, tu pourras TRES avantageusement regarder le framework SPRING. Je te le recommande vivement, au moins pour l'avenir.

[jothi35]

Je suis effectivement parti sur la solution d'écrire des classes en pure Java pour implémenter mes services métiers. J'ai également une interface java à partir de laquelle dérive l'implémentation. Ensuite, j'utilise le design pattern factoy pour récupérer cette implémentation métier de manière transparente vis à vis du client de mes services. Ainsi, si dans l'avenir, je veut utiiser des EJB au lieu d'utiliser directement l'implémentation, je mettrais en place comme tu l'indique ego le design pattern Business Delegate et ma factory renverra ce delagate à la place de l'implementation. Cette dernière sera wrapper alors en EJB.

En tout cas, merci beaucoup pour toutes vos réponses.

[ego]

à tes heures perdues, tu pourras lire la doc du framework SPRING qui t'en dira long sur la manière de concevoir des objets métiers (entre autres). Tes classes pures Java, on les appelle aussi POJO - Plain Old Java Objects