Discussion :

[bricecol]

bonjour,

j'ai besoin de l'aide de quelques chevronnés sur les architectures n-tiers !

voilà, j'ai un projet à réaliser qui va me demander d'utiliser pas mal d'outils pour être "propre", interopérable, modulaire, fonctionnel etc.. il s'agit d'avoir, comme pour un jeu en ligne, un serveur et des clients, jusque là tout va bien ! il y aura une ou plusieurs BDD.

quelques "contraintes" :
- programmer en JAVA/(opengl ou éq.)
- utiliser PostgreSQL
- utiliser HIBERNATE ou éq.
- utiliser la techno RMI ou éq.

voici mon problème principal. je souhaite savoir s'il serait judicieux (et si c'est possible, je pense que oui) d'utiliser la technologie JAVA RMI de ce genre d'architecture et avec mes autres contraintes ??? est-ce que "ça se fait" ou il y a mieux / plus simple ?

grosso modo, voici mon schéma final. le client est un container semi-lourd je dirai car il possède tous les médias lourds (objets 3d principalement). mais le client est une interface et l'objet client est crée sur le serveur (conformément au fonctionnement RMI). le code des actions client (comme se déplacer, attaquer etc...) est donc côté serveur et le serveur gère tous les clients. le client n'est donc pas surchargé en code. après vient le mapping avec HIBERNATE et les BDD (ça c'est pas trop compliqué).

j'aimerais savoir ce que vous en pensez. ah j'oubliais, je comptais utiliser MAVEN pour les dépendances et la gestion du projet (deux sous-projets donc : client et serveur).

alors ? c'est un bon choix ou il y a des choses qui vous semblent inutiles ou au contraire il manque une couche au dessus / en dessous de quelque chose ?

merci d'avance pour votre aide !
(n'hésitez-pas si j'ai oublié de préciser qq chose ou si vous avez des questions)

[OButterlin]

Comme ça, "à la louche", ça me parait correcte.
Tu pourrais accessoirement utiliser EJB à la place de RMI (même si EJB s'appuit sur RMI-IIOP) qui pourrait t'apporter un + (sauf si tu as une forte contrainte performance et/ou pas de serveur JEE à disposition).
Dans ce contexte, EJB3 entity peut remplacer avantageusement Hibernate ("natif"), même si tu peux utiliser Hibernate comme implémentation de JPA (d'EJB).
Pour le reste, un client lourd (en quoi ? swing ?) pour les traitements graphiques, c'est ok... si tu veux dessiner ou t'interfacer avec des composants de la machine cliente... sinon, tu pourrais utiliser une architecture web à base de jsf + facelets + richfaces... ça fait des choses fabuleuses visuellement... ça dépend un peu de ce que doit faire le client...
Peux-tu préciser cet aspect ?

[bricecol]

Tu pourrais accessoirement utiliser EJB à la place de RMI (même si EJB s'appuit sur RMI-IIOP) qui pourrait t'apporter un + (sauf si tu as une forte contrainte performance et/ou pas de serveur JEE à disposition).
Dans ce contexte, EJB3 entity peut remplacer avantageusement Hibernate ("natif"), même si tu peux utiliser Hibernate comme implémentation de JPA (d'EJB).

EJB est basé sur RMI ? et en fait, c'st donc plus lourd mais d'après toi plus simple d'utilisation ? EJB3 entity pourrait donc "remplacer" hibernate ?

en fait, je dois faire un petit jeu. donc d'un côté un serveur (j'ai un serveur debian complètement sous contrôle et assez puissant) interfacé avec le ou les BDD que je créerait (je mettrait une interface si il y ena plusieurs mais normalement, au ébut, ce ne sera pas le cas). et un côté client JAVA/opengl. le client lui même, si j'utilise RMI sera une interface distante au serveur mais tout objet client "vivra" sur le serveur. bien sur, du côté client, je dois aussi utiliser opengl mais la n'est pas le problème.

la ou je galère c'est savoir exactement ce qui répondrait le mieux à mes besoins. je n'ai pas besoin d'avoir des perfs de fou également.

[OButterlin]

EJB est basé sur RMI ?

oui, quand on utilise une interface Remote

et en fait, c'st donc plus lourd mais d'après toi plus simple d'utilisation ?

Plus lourd, certainement, ça fait beaucoup plus que du RMI.
En résumé, RMI n'est rien d'autre qu'une invocation à distance d'une méthode alors qu'EJB fait bien d'autres choses "nativement".
Les plus importantes :
- persistance
- les transactions
- le maintient d'état

Globalement, on a 3 grands types d'EJB :
- Entity (pour la persistance)
- Session (avec ou sans état (stateful / stateless)
- MessageDriven (comme son nom l'indique, répondant à un message (JMS))

EJB3 entity pourrait donc "remplacer" hibernate ?

Oui, en quelque sorte.
Il faut comprendre que la partie persistance des EJB3 est basé sur l'api JPA.
Elle définit une "norme" et ça s'arrête là.
On a ensuite les implémentations de JPA, et c'est ici qu'on retrouve Hibernate.
L'avantage, c'est qu'on pourrait passer d'une implémentation Hibernate à une implémentation TopLink (ou EclipseLink) sans modification de code.

Je pense que ton explication du besoin (côté client) tend à pousser vers les EJB3 plutôt que RMI

[bricecol]

ok. quand tu parles de persistance, il faut que je sache de quel côté. en effet, les clients sont crées côté client mais vivent coté serveur. leur "infos" sont stocké dans une BDD, côté serveur donc.

je connais JPA, des annotations en fait. ensuite, si j'ai bien compris, hibernate se sert de ces annotations, de cette "norme", pour faire l'interface avec la BDD (enfin, on peut aussi mettre des DAO entre les objets annotés et hibernate je pense là n'est pas le problème, on pourrait alors changer facilement pr un eq. d'hibernate).

j'avoue que je n'ai que très peu tenter de faire fonctionner "tout çà" au sein d'un même projet en "cohabitation" sans trop de troubles ^^

bon, j'essaie de faire un petit schéma récapitulatif de tout ca et je reviens

merci bcp pour ton aide !

[OButterlin]

ok. quand tu parles de persistance, il faut que je sache de quel côté. en effet, les clients sont crées côté client mais vivent coté serveur. leur "infos" sont stocké dans une BDD, côté serveur donc.

Côté serveur, c'est ce qu'il y a de mieux et de plus sécurisé (si besoin).
Tu utiliserais un EJB session stateless (à priori) pour faire la persistance.
Dans ce cas, on peut voir cet EJB comme une DAO remote.

Sinon, pour Hibernate natif et DAO, ça fonctionne très bien aussi.
Rien n'empêche de mixer les éléments :
- EJB stateful pour conserver l'état entre différents appels de chaque client et faisant office de Contrôleur
- des DAO standards appelés pour l'accès aux données

(c'est juste un peu dommage de se priver de la puissance des transactions déclaratives des EJB3 avec JTA)