Discussion :

[rOmAle]

Bonjour à tous,

Je voudrais vous présenter mon projet open source: "fast4j :: EJB Bridge".
Ce projet vous permet de déployer dans un conteneur JEE des services Spring définis dans un contexte "classique". Toutes les fonctionnalités offertes par Spring (gestion des transactions, AOP, etc...) sont conservées. Les services Spring peuvent alors être accédés par un client EJB de manière complètement transparente !

Evidemment, vous pouvez développer vos services en dehors du conteneur JEE, comme des services Spring classiques, ce qui est un grand avantage. Plus besoin de redéployer des EJB pour tester vos services !

N'hésitez pas à y jeter un oeil : c'est open source, et je suis ouvert aux critiques !

http://code.google.com/p/fast4j

Alexandre ROMAN

[ego]

Après une première lecture de ton projet, peut être un peu trop rapidemment, l'intérêt m'échappe totalement vu ce que Spring propose déjà.
J'ai peut être raté un truc ?!

[rOmAle]

Spring propose de construire un contexte d'application derrière un EJB. Lorsque ton EJB Session est créé, le contexte s'initialise et tu peux alors l'utiliser.

Le but de mon projet est d'augmenter la productivité des développeurs, en créant des services basés sur des POJO, gérés par Spring. En phase de développement, nul besoin de déployer ces services dans un conteneur pour les tester. Tu bénéficies également de toutes les fonctionnalités de Spring pour tes services (AspectJ, etc...).

Lorsque tu es prêt, tu packages tes services avec ejbbridge dans un EAR que tu déploies dans un conteneur JEE, et tous tes services Spring pourront être accédés par un client EJB. Un EJB session facade délègue tous les appels aux services Spring.

Ainsi, tu combines le meilleur des deux mondes : la rapidité et la souplesse de développement avec Spring, et la capacité de déployer tes services dans un conteneur JEE. Pour les clients accédant à tes services, c'est complètement transparent !

Qui plus est, tu peux gérer avec ejbbridge un contexte par appel de service. Cela te permet de passer des métadonnées lors de chaque appel, de l'exploiter/modifier au niveau de tes services, et de le récupérer au retour. Ce mécanisme me permet de gérer un conteneur de messages d'erreur, alimentés par mes services (je suis en mesure de gérer des messages sans pour autant lever d'exception : j'ai le choix), et de connaître l'identité de l'utilisateur connecté.

J'espère avoir été clair

[ego]

Mais le principe du pattern "Business Interface" où une interface Java est à la fois implémentée par l'interface Remote d'un EJB et par un POJO me semble convenir à ton besoin.
Dans ce cas, EJB ne fait que de la délégation vers le POJO. Le POJO peut donc être déployé hors serveur d'application.
L'EJB n'est pas connu du client; le client ne connait que la "business interface" et va, dans la factory Spring, récupérer le service sans savoir qu'il est ou non "remote".
Au final, tu peux tester le client et le serveur en dehors d'un serveur d'application. Si en plus tu utilises XDoclet, tu dois pouvoir générer l'implémentation de l'EJB qui n'a qu'à faire de la délégation.
Et pour finir, tu peux avoir 2 versions de la "business interface", une qui lance des RemoteException et l'autre (celle connue du client) qui ne remonte pas ces RemoteException; ainsi le client n'est pas pollué par l'aspect distribution.

Est-ce que ton projet va plus loin que cela ?

[rOmAle]

En fait, ejbbridge propose aux développeurs une approche simple et rapide de ce que tu viens de décrire. Nul besoin de passer par XDoclet pour générer le code de chaque EJB, ejbbridge déclare déjà un EJB de façade. On développe "simplement" le service avec Spring, et ejbbridge devient la cerise sur la gâteau : l'intégration et le déploiement dans un conteneur JEE devient un jeu d'enfant. Il n'y a (presque) rien à faire !

L'autre idée qui me plaît avec ejbbridge, c'est la possiblité d'utiliser l'équivalent d'un contexte de service. Ce contexte naît côté client, et peut contenir toute sorte d'infos. Il arrive côté service métier, qui peut alors le remplir à son tour et exploiter les données envoyées par le client. Lorsque le client reçoit le résultat du service, le contexte est également disponible. A mon sens, cela ouvre pas mal de possibilités. Il y a un exemple d'utilisation dans l'archive téléchargeable : je te laisse faire ton propre avis

[ego]

ok, je vais prendre plus de temps pour regarder